Trouble with the rtsp vlc feed?
mpetach at netflight.com
Mon Oct 19 12:00:15 CDT 2009
On Mon, Oct 19, 2009 at 6:57 AM, Will Hargrave <will at harg.net> wrote:
> Joe Maimon wrote:
> > Anyone else having trouble with that?
> Not had any luck on either the unicast or multicast RTSP feeds. Flash works
> fine, though.
For those who had trouble with the feed, I took some notes this morning
from the first half of today's talks. Lunch break now, rest of the talks
be captured in separate mail at the end of the day.
2009.10.19 NANOG notes, Monday
Dave Meyer welcomes everyone to NANOG 47
at 0932 hours Eastern time.
Everyone please take note of the hosts
of NANOG 47, Arbor and Merit--thanks for
coming out and supporting it!
And next up, Betty Burke with some brief
Betty thanks the Merit president for allowing
them to host NANOG again--this is the traditional
thank you award given to the host.
Lisa Quimby from Arbor has done a lot of work
putting together the rest of the conference,
so a big thank you to them as well!
If you'd like to see the home base for Merit
to see the datacenter and some facilities,
contact Betty, she'll make arrangements, it's
about 30 minutes from here.
Don Welch from Merit has a few words now to
talk about what Merit is.
Formed in 1966 by 3 universities in Michigan
In 80s and 90s worked with IBM and MCI to run
June 3-4, 1994, NANOG 1 was held in Ann Arbor.
Non-profit, serve research and education networks;
provide a neutral ground for otherwise competitive
companies to come together.
Provide networking to libraries, universities,
and research organizations. Mostly fiber based,
provide layer 1, 2, and 3 services.
Awaiting AARA grants to build out more services.
Also providing additional services up the stack.
ATT is providing a 50Mb circuit to Ann Arbor, and
there out to the rest of the world via 10G.
co-founder of Arbor, welcome to NANOG47, and thanks
to the co-hosts.
Much of the work behind Arbor came from work and
research done under Merit in the early days.
Exciting new era of innovation from 1988 to 2009,
from communication focusing on voice to a massive
explosion of different communication systems and
styles. Information technology is integrating more
deeply into society, we have new ways to communicate,
collaborate, and share information. Networking will
continue to be at the center of this societal
Traffic growing rapidly on fixed and mobile networks.
IP traffic will double every 2 years through 2011
Video Internet drives much of the growth
Google serving more than a billion videos a day now.
Security threats clog bandwidth and increase costs
Pricing for data is fixed or dropping
Yesterday: the era of "look at me" attacks
primary motivation of hackers was bragging rights
worms and viruses were intended to simply wreak havoc
on the infrastructure
These were availablity attacks: impacting network access
and services, and often, reputations.
Today: Botnets, Mobility, Clouds, and Social Media
Profit motives and new opportunities
malware takes control of targets, enable C&C infrastructure,
and enable malware deployment
Political and Financial gains.
Tomorrow: 2009 and beyond
Future security challenges will follow internet
Profit motives here to stay
Politically motivated attacks are 21st century form
of street protest.
Protecting cloud infrastructure is key to long term
Collaboration is more important than ever
NANOG itself is example of collaborative nature
of our work
Cooperation and information sharing between
private and public sector will be critical
Cyber will grow to be ever more important to
our economic security and prosperity.
Craig Labovitz is up next, was one in a long
line of program chairs for NANOG
ATLAS Internet Observatory, 2009 annual report
This was a 2 year effort, Arbor, UMich, and Merit
Largest internet monitoring infrastructure in thew orld
Global deployment across 110+ ISPs/Content Providers
near realtime traffic and routing statistics -- 14Tbps
leverages commercial security/traffic engineering
Participation voluntary and all data sources anonymous
ATLAS observatory report
Few observations are completely unique/new
growth of video, flatter internet, Google, etc.
by press, academic papers, analysts, and NANOG
may be first to quantitatively measure these trends
First global traffic engineering study of Internet evolution
There's been other work as well
Observatory Data Details
Within a given ISP, commercial probe infrastructure
Monitors Netflow/Jflow/etc and routing across possible
hundreds of routers
Probes topology aware of ISP, backbone, and customer
There's nothing in the files that shows which customer
it comes from.
No fine-grained data--not the NSA!
What it observes
Relative inter-domain traffic between ISPs
based on small sample of ASNs and weighted towards core
roughly matches analyst ISP market data/distribution
data representative of global inter-domain traffic
focus on "market share" as opposed to absolute data
Inter-domain traffic volumes and ratios provide
important design/engineering metric
web hits, tweets, transactions, customers, etc.
no internal traffic
ISP success nor profitability
Consolidation of Content Contributors
content migrated out of enterprise/edge to aggregators
consolidation of large Internet properties
Now only 150 origin ASNs now contribute 50% of traffic
Consolidation of Applications
Browser increasingly application front end (eg mail, vid)
Applications migrate to HTTP of Flash ports/protocols
All other ports/app groups decline (except games and VPN)
Evolution of Internet Core and Economic Innovation
Majority of traffic direct between consumer and
Market shifts focus to higher value services (MSSP,
Experimentation with paid transit
Experimentation with paid content
End-to-end internet battle has been fought and lost;
even XBox 360 has moved to all port 80.
BGP hop count gone from average of 4 to 3.5 to 3,
and still down.
ISPs moving from transport/transit to higher value
Evolution of the Internet Core
1995 to 2007, picture of the hierarchical network
core from the end of the NSFnet era, still taught,
was somewhat true into early to mid 2000s.
ATLAS 10 in 2007:
Level3, GX, ATT, Sprint, NTT, Cogent, Verizon,
TeliaSonera, Savvis, AboveNet
based on analysis of anonymous ASN origin/transit data.
But between 2005 and 2010, the world started to
collapse of wholesale transit
grwoth of advertisement supported content
collapse of price of cloud hosting and CDN (panther)
Scarcity of datacenter capacity
cooling/power/virtualization made old datacenters
less useful; bar raised for new facilities.
Market Forces in new Internet
Price of IP wholesale transit is dropping towards
Revenue from Internet Advertisement is going up.
DrPeering site has these graphs.
Key macro level trends shaping how ISPs approach
ATLAS 10 today:
Level3, GX, Google (5.2%), XXX,XXX, Comcast, rest
Comcast and Google have joined the top 10, weren't
even in top 20 in 2007. These are non-tier 1 companies
according to Wikipedia, but Google is one of the
fastest growing origin ASNs, and is now #3; and Comcast
is climbing as well.
Tier1s are still large, and are still somewhat profitable,
and are carrying significant volumes of traffic.
Consolidation of Content
2007, thousands of ASNs contributed 50% of content
in 2009, 150 ASNs contribute 50% of all Internet traffic
Approximates a power law distribution.
The knee of the curve has changed. This is the
most dramatic change that has occurred in the
Hypergiants--big ASNs at far left side.
Top five pure-play CDN origin ASN groups
increasingly blurred lines between ISP and CDN
significant competition and new entrants
Only includes Akamai inter-domain traffic (likely 1/4 or
less of all traffic)
As category, CDNs represent close to 10% of all Internet
Commoditization of IP and hosting/CDN
drop price of wholesale transit
drop price of video/CDN
economics and scale drive enterprise to 'cloud'
Bigger get bigger
Google, Yahoo, MSFT acquisitions
Success of bundling / Higher Value Services
Triple and quad play
New economic models
Paid content (ESPN 360), paid peering, etc.
difficult to quantify due to NDA/commercial privacy
direct interconnection of content and consumer
driven by both cost and increasingly, performance
Direct peering is driving traffic distance closer to zero
Google, Akamai, others looking both at cost and
performance, as SLA-based metrics start to push
content closer to consumer
The new Internet is a densely meshed cloud
of ISPs, tier1/tier2s, global backbones,
and HyperGiants--large content, consumer,
and CDN providers.
Google's weighted percentage average traffic
Over time, Google absorbs YouTube traffic,
Google now accounts for 6% of all Internet
Google one of the fastest growing origin ASNs
In 2007, Comcast looked like a traditional MSO
Lacked a nationwide network backbone
Focused on residential services
depended on upstream transit
2009, Comcast is different
Net contributor of internet traffic
6th largest origin/transit group by volume
Evidence of new business models
Traffic ratio shifted from inbound, to
outbound; more content then eyeball network
Increasingly blurred lines between content and
Top ATLAS Global applications 2007-2009
Web, Video, VPN, Email, News, P2P, Games, SSH,
DNS, FtP, Other, Unclassificed
see the slide for exact numbers. Some like
P2P is hard to categorize as it keeps moving,
and some like Video don't necessarily catch it
all, as much of it moves to Flash video over
P2P is fastest shrinking; most moving to flash
or port 80 now.
Global P2P trends
Ports 6346, 6882, 6881, 4662
Global media cast P2P as the boogeyman, the driver
around network neutrality, etc. back in 2007.
By 2009, the great evil boogeyman of the internet
is falling, and falling fast; losing market share,
and turns out to have been mostly FUD.
Asia is slower to decline in P2P than other parts
of the world.
P2P still has significant volumes
slower growth, and some absolute decline
provider traffic management
(rate shaping, port limiting, etc.)
improved P2P clients/algorithms
(smarter clients localize traffic, etc.)
migration to other content sources
(peer to peer is a pain; is it shaky camera
rip, or true HD movie? Now, direct download,
direct CDN, hulu, iPlayer, etc. are taking over)
P2P replaced by direct download
Carpathia Hosting now represents 0.5% of all internet
Internet is at an inflection point
Transition from focus on connectivity to content
old global internet models are evolving
new entrants are reshaping definition/value of connectivity
New technologies are reshaping definition of network
"web" desktop apps, "cloud", CDN
changes mean significant new commercial, security, and
this is just the beginning
Rate of change is accelerating!!
Bill Norton: video is a much larger amount of traffic
for a given interaction; lots of MB vs reading an
email, twitter, etc. Does that skew the analysis?
Anyone carrying video traffic will show up very high
on the list; this would discount anyone not carrying
A: Yes, this shows very much that Video has dominated
the internet now, even if it's t
Q: Akamai asks if measurements do backbone to eyeball
edge, external traffic, etc.?
A: they try to capture as close to the edge
S: Akamai's edge traffic less than 20% now.
Q: When you rank networks by traffic, does it
ignore the vector of the traffic, and just look
at number of bits?
A: It was ranking in+out; though in comcast, you
see some of the in vs out delta. The tech report
has some in vs out breakdown.
Q: Are numbers peak, average, 95th?
A: Mostly average.
Intenet Operations and ARIN Policy--is there convergence?
Mark Kosters starts off the panel (ARIN CTO)
The oncoming runout of v4 addresses is really
driving a lot of these discussions.
Policy issues that affect you
4 byte ASNs
ARIN using 4 byte ASN; scary how many people
can't peer with them yet because of that.
old cruft in records; many people don't really
know about looming events coming on the horizon;
the easy landing period is getting shorter and
shorter. ARIN is membership based org, we as
members make the policies. Stay for the meeting,
or at least join the Tuesday night session!
Relaxed Transfer Policies
Focus on two policies
2 30 minute sessions
First session: focus on relaxed transfer policy
second, focus on IPv6 policy
RFC2050 doesn't mention purchasing space
NRPM section 8.3 added based on policy proposal 2009.1
8.3 allows the transfer (outside merger or acquisition)
of internet number resource registration rights to an
operator who can justify it.
Slippery slope to a market-based economy for address
Tom Daly Dynamic Network Services
ARIN relaxed transfer policy
Removes M&A requirements on address transfers,
permits "arbitrary" transfer
continues to require justification of need
Keeps ARIN as transfer agent
Does this create a grey market for address space?
"I'll trade your tainted, RBL-ed IPs for some clean ones"
Concerns about deaggregation upon exchange
Does ARIN become a title agency for IP address space?
new business opportunity for ARIN
Does his create new precedent for policies
Igor--Relaxed IP transfer policy is a good thing.
allows businesses to continue growing even after v4
run out point.
This could be a profit center for some companies
Can also help companies who cannot afford to migrate
to IPv6 quickly stay functioning.
Why is the policy written in such a way that it takes
legal counsel to really understand what it means!
Can we have simple english policy?
Who will handle the market?
when will it be set up?
what's the impact on the routing system?
should ARIN care?
Do the benefits outweigh the tradeoffs?
For us, most definitely!
It may make it more expensive, but very possible.
Oh. Maximizing slides would be good!
Aaron Hughes is up next, 6connect.net
transfers are happening, regardless of LIR or RIR
There are companies which will need IPv4 resources
to survive post IANA and RIR run-out
Operational impacts with or without policy in place.
Closing a sale now involves IPv4 resources
Justification process harder on our customers and on staff
Neither SBGP nor signing authorities in place
There are bad people trying to make money from:
resources they are assigned
resources they are NOT assigned
LIRs are not very good at tracking resource
assignments today (LOAs, IRR, whois checks)
most of these updates are easy to spoof.
We don't check LOAs very carefully when customers
show up and ask space to be routed.
IRRs mostly are mail-from, so adding new records,
or updating them, are far too easy.
M&A will be much harder to determine net worth
of asset (more work for legal and due diligence)
Company officers all over the world now know they
need more space (intent to educate about IPv6)
fiduciary responsibility to not run out
their staff objecting to IPv6
higher potential for fraudulent resource utilization
higher potential to waste IPv4 resources now to justify
space long before need (NAT flips)
Contact information is more likely to be accurate with a
system that updates upon transfer.
Clean transfers will have higher value than black market
Force better tools and policy to verify assignment
Routing table growth will force cleanup of de-aggregated
prefixes that do not *need* to be
Potentially force conditional route-maps/routing policies
to be enforced to reduce announcements except when needed
validate current process
prepare for some flavour of signing
inform your sales staff and modify process as needed.
inform your abuse staff
going to get harder to manage spammers
If you haven't already, start using IPv6 to reduce
the impact of transfers!
Dan Alexander, Comcast Cable
Transfer policy--enables new entrants to obtain IPv4
space during the transition
Primary goal of the transfer policy is NOT to extend
or perpetuate the use of IPv4; we're still supposed
to be focusing on the migration to IPv6.
Transfers likely to be of little use to large ISPs
This would at most cover about 6 months coverage at
the current global use.
Long term, IPv6 is the long term solution
IPv4 resources don't scale, given the number of new
devices joining the Internet.
speaking for himself
It's already happening;
if you have a commodity or anything that has some value,
someone will be interested in buying it, legally or
If the supply is limited, price will rise to the point
where someone will sell
Prohibition does not work!
How badly it works is proportional to the level of
demand (not volume)
History shows how badly prohibition fails.
when a /18 stands between you and the continued
existence of your business, would you buy an address
block on the black market?
Q: Heather Schiller, Verizon Business -- black market
will exist for 2 reasons; one for shady purposes, and
one if they don't have justification requirements.
A: No, the idea is to make sure that you don't force a
significant portion of the consumer base to create a
Q: do you support the current justification levels
in the transfer policy?
A: Yes, the current justification requirement is
reasonable; the current market is small; that's
what keeps it workable; if the black market gets
larger, the system starts to break down.
Q: Martin Hannigan; when you talk about markets,
recognize that it happens now; people will do what
they can to get around ARIN if they can make some
money off this. We need to wake up a bit and realize
it's not a tiny market.
A: Yes, we need to figure out how the operational
people will play in this space; right now, there's
some amount of registry involvement; but we need
to have some way to validate the authenticity of
Q: Jason Schiller, Verizon; ARIN does *not* make it
more difficult to get IP space as we get near depletion;
if you want to see rationing, get involved in the
conversations; at the moment, the current plan of
record is to have same level of justification we've
Q: Sandra Murphy, Sparta--how will this affect the
RPKICIDR work? This should work within that
framework without issue, so long as ARIN is part
A: Yes, if ARIN is no longer the transfer agent,
it becomes quite a challenge.
Q: RPKI system allows an entity to transfer all
its resources; but to ensure that the resources
can't be pulled back could be a challenge.
Q: Manish--this doesn't take into consideration
growth in the size of the global routing table.
In the past, ARIN has been uninvolved in this;
but as time goes on, this will cause the global
table to grow.
A: Table growth will occur, period; this is about
keeping the contact information up to date. And
you'll just need to keep growing your router gear
to keep up, that's part and parcel of doing
business on the internet today.
Q: Dave Meyer--second half of panel at 11:30.
Second part of policy panel
IPv6 polices--not a lot of operational experience
to back up policy
Big discussion on assignment sizes
Route Filtering /32s or /48s?
Should routing policy affect ARIN assignment/allocation
--should route filtering be based around ARIN
assignments? vice versa?
Are v6 policies hindering v6 rollouts?
Igor is up first
If you're an established ISP, getting IPv6 space is
can take less than 20 minutes
The "must announce a single aggregate" policy is
causing some people to delay deployment
Not everyone is willing to put all their eggs in
a single /32 announcement
multiple discreet networks
what about multiple non-connected datacenters?
how about branch offices?
There is hope!
2009-5: IPv6 Multiple discrete networks
should help somewhat
2009-7: open access to IPv6
removes the "single aggregate requirements"
please discuss and vote!
these policy changes help shape v6 rollout.
He's not saying IPv6 is easy and doesn't need policy
ARIN policies and IPv6 mandates
Some have suggested ARIN policies should mandate IPv6
deployment upon future requests for iPv4 resources
ARIN should strive for consistent RIR policies that
Frustration...a matter of priorities
It does require significant resources to make it happen.
timing--v6 deployments increasing even before we hit
the run-out point.
IPv6 is being deployed.
Comcast is connecting to other networks using IPv6
Trials will continue in to 2010
If you're not already working on IPv6, you need to
start now; it'll be too late if you wait until we
hit the IPv4 runout point.
Should ARIN make routing policy?
ARIN staff and the AC often say that ARIN does not do
the policy stating that a single /32 announcement is all
you shall make, is indeed routing policy.
Announcing a single prefix to everyone at every
location breaks all current models of traffic
Mainly an issue for those with a geographically
if all your stuff is in one location, not a problem.
But enterprises have similar issues with load balancing;
a single address doesn't allow for load balancing easily.
ES.net advertises two /17s with specific metrics, with
a /16 covering. They move huge single-streams, where
latency changes have a massive impact.
So, with no way to localize traffic, with no way
to balance traffic, with no way send metrics for
closest exit, traffic doesn't do the right things;
ARIN doesn't know how to run our networks, and
shouldn't be telling us how to route things.
Tom Daly is up next.
IPv6--all eggs in one basket.
Deaggs filtered in some operator networks
limit techniques for TE moves, adds, deletes, changes
less flexibility in overall routing policy by operators
not every network is a subscriber access network.
MicroAllocations for critical infrastructure doesn't
work for enterprises.
NPRM 4.10 Allocations up to /28?
That policy will do more to hurt the routing table
size than v6 PI space.
BCP 16 cannot be satisfied to maximum level;
separate LAN segments internally, single external
No multiple networks supported.
Aaron, last speaker
IPv6 policy vs operations
same slides as everyone else, so he just talks.
ARIN vs NANOG; why do we seem to come from different
sides of the issue?
Some people want a v6 internet that looks just like
the v4 internet, with NAT and RFC1918.
Others want the old central backbone back again,
going back 20 years ago.
If you're not in giving your vote, you're not being
heard! You need to vote, and show up!
Why is it VERSUS instead of AND? Why do we have
two different meetings?
The policy breaks multihoming, yes.
But people aren't following that. Some providers will
take your /48 and will announce it.
Others in the room follow the policy, and block the
We're lying to our registry; there are policies that
we've agreed to that we don't follow.
There's 2100 prefixes in v6, and half of them are
for TE. Why can't we write a document that makes
sense, that follows what we'll actually do?
Oh. And you have to be a "known ISP" to get v6
space; he had to justify a need for v4 IP space
and ASN before he could get v6 space.
This will continue to be a headache as we go forward!
Five minutes for questions.
Cathy Aaronson--ARIN advisory council.
They really need everyone to participate.
This is a very old policy, from when Kim Hubbard
ran ARIN. It doesn't meet our needs, so there's a
proposal written by Aaron's wife to change this.
They really do need people to stick around and
join the ARIN meeting, and help write and pass
more reasonable policies!
A: Tuesday night there will be a session to read
about the new policies.
Q: Owen DeLong, HE.net and ARIN advisory council.
Having policy at ARIN level reflect routing is a
very bad place to do control of routing policy.
There's talk of more policy to control route table
growth; it would be good for operator community to
get more involved in the ARIN process.
A: Aaron notes that today we don't have a place to
document best network operations practices. There
is no document repository for operator policies
genereally speaking. Tom notes that he's in a
relatively new organization, which doesn't have a
strong institutional knowledge background; there's
no place to look up to see why /24 was a boundry
line, and why /32 and /48 were picked for IPv6,
Cathy is back up again.
The reason there is routing policy in ARIN, when
the policy was writtin, everyone on the AC worked
in routing, and was concerned about table bloat.
They were trying to bring operator input at the
time, because at the time, that seemed to be the
right thing to do.
Q: Alain, speaking for himself. Allocation policy
and routing policy is the same thing. If we have
transfers happening, there will be pressure for
smaller and smaller blocks to be announced and
accepted. It doesn't mean that ARIN has to do the
routing, it just means that if ARIN has agreed to
allocate the space to you, there's a need for it
to be reachable!
Lee Howard, ARIN board of trustees, TWTC.
Thanks to ARIN for writing a best practices policy
document! ARIN will do the words we send them that
get discussed by the community; you need to send
better words to the community!!
Jason Schiller, Verizon;
Why do we route /24s across the board? Because we
created a swamp by allocating /24s to individual
We're about to create the same thing in IPv6 by
allowing /48's from PI holders. Soon
each v4 ASN announces on average 9 prefixes; if
we do similar in v6, we'll see similar breakups
in /32s, and then soon in PI /48s doing /52s or
/56s. The routing table will definitely get big
if we do that. It's not clear when, but at some
point in the forseeable future, there will be a
significant number of the v4 ASNs also doing v6,
and when that happens, you will need to be looking
at doing swapouts of your entire network routing
infrastructure to handle it.
Once we create a swamp, there's no way to drain
it, and there won't be a chance to implement a
Igor responds: perhaps the answer to some of that
is that the refresh cycle needs to be shrunk down,
and the cost of business needs to reflect that.
Responding to Igor, he looks at the impact of lost
customers if they don't route the space vs if they
do make the upgrades.
Kevin notes that most of us are business providers;
we will make a business decision as to whether or
not we can make the decision to route a million
prefixes or not. It will not be driven by what
ARIN decides, or by what NANOG decides, it'll be
Marla Azingera--what we do is what goes; one of our
two charters needs to be that one of the organizations
writes routing policy. So, do we modify NANOG charter,
do we modify ARIN charter to write routing policy, do
we create a third entity to do that?
Randy has last question? How did we come up with the /19?
It used to be /19 for registries, then /20, then /21; it
was a bunch of operators and registry people who got
together, and came to some level of agreement.
And at some point, the limitations of silicon kick in.
RAS is up next.
Scripting on Routers
On-box automation with JunOS
Phil Shafer phil at juniper.net
configuration is increasingly complex
network operators have custom design rules
no enforcement mechanism
cost of failure increasing
Database of Record
push the config from central system.
Goals for Scripting
promote high-level concepts and views
JunoScript XML API
XML to text rendering happens at CLI
automatic part of commit process
add new commands
trigger on specific events.
Commit scripts Internals
in XLST internally, actions are in XML
example--you can have constraints that require
certain conditions to hold true, like all LDP
enabled interfaces must have IGP running on them.
"apply-macro no-ldp" for example
can appear anywhere, takes a name as an argument
you can also repair/change configs around it.
you can fix problems before they occur.
config that is published to software components,
but not seen by the user
"show | display commit-scripts"
enforces constraints on ISO and MPLS
use the "jcs:emit-change" helper template.
can warn you about what it is fixing.
it inspects configuration in XML
uses XPath expresssions to local interesting nodes
pass in required arguments
There's a 1:1 mapping between config and XML
XML config as tree, XPath allows you to find things
in the tree.
Macro Expansion example
Three common threads
get better information
display to user
standard operating procedures
codify best practices in a script
may appear in configuration
may appear in the script itself
shows last dead reason, can try to bring it back up,
network issues are seldom one sided
diagnose scripts need access to remote device
compare config to ensure both sides are consistent
inspect remote state to see where problem lies
access to intermediate devices as well
shows information about each hop by RPC'ing to it.
op scripts can ask the user for input
var $response = jcs:get-input
var $password = jcs:get-secret
simple questions, or complex interactions
New "wizard" framework
Single point of configuration
run an op script in one location to deploy a service
in multiple locations
up-down syslog events
pic-restart triggered events
pic-restart.slax script to restart pic after issue
Event script possiblities
why script on routers?
get benefits of automation without blocking people from
logging into the router.
Anything you can automate makes the network run better
and run cheaper.
Automated BGP policy generation
Automated BGP prefix-limit management
Support case data gathering scripts
example of building BGP policy generation
script builds per-ASN communities/policies for
prepend AS-PATH 1x
prepend AS-PATH 2x
Automated BGP policy generation
Also useful for building AS-PATH leak filters
define a list of major ASNs you only want to hear "directly"
block any route with one of these reserved ASNs in in the
AS-PATH if the route didn't come directly from one of those
Useful for preventing leaks and suboptimal routing
If I peer directly with 701, I don't ever want to
accept their route from someone else.
Also useful for building policy frameworks
script can scan for the existence of a policy with
a standard name for each BGP neighbor
script automatically generates and maintains 44 lines
of new router configuration for every configured BGP peer
Automated BGP prefix-limit management.
operators use BGP prefix-limits as policy safety nets
if a BGP neighbor sends more prefixes than we believe is
normal, drop the BGP session for a certain period of time.
Somewhat effective at protecting against leaks
But difficult to maintain over time.
concept of "normal" is always modifying.
prefix limit based on current prefixes sent plus an
overhead factor, like (PfxCnt*1.25)+500
Uses a time-weighted average
Run the script once a night
allow manual runs if needed.
Automated support cases
opening vendor support cases
gather most common log files and support components,
and automatically upload them to vendor via FTP
How effective is this?
router configs are 62% smaller than if the commit
scripts aren't used.
questions to ras at nlayer.net
Q: Aaron Hughes--good talk; would be nice to check
peeringDB and set max prefix based on that.
While this is nice, companies are afraid to deploy
scripts; handing off control to scripts causes a
lot of consternation.
A: should be possible for script to pull information
from an external source like peeringDB, yes.
Lorenzo: As far as fear of scripts goes...human make
mistakes slowly. Scripts make mistakes...really fast.
RAS notes that you shouldn't do your scripting ad-hoc.
Do it in the lab, test carefully, and then deploy the
Jared notes that some vendors don't have commit or
rollback in their portfolio. We need to explain to
our vendors that they are losing business by not
having that support.
They push automated config to their startup-config
It would be nice if the vendor could support some
of these scripts, or provide them with the software
so they could be used more widely.
Chris Morrow--people get most scared of breaking the
entire network; it's usually tactical stuff that
breaks that way. Well planned, well tested, staged,
there's no reason not to do it.
Another person states that they've seen ISPs that
have "coders" who write horrible code; we have a
lack of competent talent backing up our scripts
on routers and support scripts.
Any coder who writes something has to have a good
understanding of the platform they're coding on;
the people who have that intersection of skillsets
is very, *very* small! More training in coding
for routers would be a really good thing.
Having a repository that those few, really good
people could contribute to would be nice.
http://juniper.cluepon.net/ has good repository of scripts
Randy Bush--it's not a 'coder', it's a software engineer;
it's easier to teach a software engineer about networking
Informal BOFs after lunch!
Return to the room by 2:30.
More information about the NANOG