BGP Path Filtering
I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's. I find lots of references (and understand) the basic ip as-path access-list 3 permit ^$ and it would seem that should we wish to provide transit for a bgp customer AS12345 we would use: ip as-path access-list 3 permit ^12345$ but I think this breaks if AS12345 prepends their advertisement. Next up is: ip as-path access-list 3 permit ^12345_[0-9]$* Which seems correct to me. Is this still best practice (or even correct)? Mark Radabaugh Amplex (419) 720-3635
I'd probably err on the most cautious side and use strict inbound prefix filters, only using outbound as-path filters toward upstreams as a sanity check. Unless you're a legacy peer with large networks, chances are you'll be expected to arrange for acl mods with your peers/upstreams to propagate your clients' announcements anyway. hth, Brian ps - you're correct - there doesn't appear to be a BCP. Common sense, tempered by a healthy dose of skepticism regarding one's clients' competency would seem to steer the solution :) On Thu, 15 May 2003, Mark Radabaugh wrote: : :I'm having a hard time finding best practices for filtering outbound bgp :announcements when providing transit to bgp-speaking customers. While we :currently multi-home to several providers it appears we will soon need to :provide transit for customers with their own AS's. : :I find lots of references (and understand) the basic : :ip as-path access-list 3 permit ^$ : :and it would seem that should we wish to provide transit for a bgp customer :AS12345 we would use: : :ip as-path access-list 3 permit ^12345$ : :but I think this breaks if AS12345 prepends their advertisement. : :Next up is: : :ip as-path access-list 3 permit ^12345_[0-9]$* : :Which seems correct to me. Is this still best practice (or even correct)?
On Thu, 15 May 2003, Mark Radabaugh wrote:
I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's.
I like using BGP communities: o filter announcements you receive from downstreams based on your criteria of choice o set a specific BGP community (yourAS:whatever) on announcements which are to be propagated to various places (upstream providers, etc.) o do output filtering based on the communities you set Make sure you clear yourAS:whatever in announcements from your BGP peers. You can use this same technique for prefixes you originate, so that all your outbound BGP filtering is based on communities. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
I like using BGP communities: o filter announcements you receive from downstreams based on your criteria of choice o set a specific BGP community (yourAS:whatever) on announcements which are to be propagated to various places (upstream providers, etc.) o do output filtering based on the communities you set Make sure you clear yourAS:whatever in announcements from your BGP peers.
You can use this same technique for prefixes you originate, so that all your outbound BGP filtering is based on communities.
I am hijacking this thread a bit. Setting communities is excellent advice especially if you are just starting out with downstream ASes. The question is that changing your communities down the road might be a big headache depending on whether you'll come to need more advanced ways of filtering your announcements than coarse communities allow. Especially when going (through growth or acquisition) from a single metro network to a multi-metro or national/international one. What criteria does the community think should be used when specifying communities. IMO, overspecificity [sp?] doesn't hurt, but others may (and have) disagreed. What's the BCP? Thanks, Deepak Jain AINET
To take a crack at it... - Route origin - customer, peer, transit provider, other (dial, etc) - Route geography - depends on your network, but some have seperate communities for POP, Country, Region, etc - Customer originated information - tweaks by your customers to selectively prepend, change local pref, not send to peers, or what not - Source AS - simply your AS:peer AS that the route was learned from There was an Internet Draft, last year, that summarized some of the approachs. I suspect overspecificity in this case has never done any harm, while lack of specificity has probably caused some heartache. - Daniel Golding On Fri, 16 May 2003, Deepak Jain wrote:
I like using BGP communities: o filter announcements you receive from downstreams based on your criteria of choice o set a specific BGP community (yourAS:whatever) on announcements which are to be propagated to various places (upstream providers, etc.) o do output filtering based on the communities you set Make sure you clear yourAS:whatever in announcements from your BGP peers.
You can use this same technique for prefixes you originate, so that all your outbound BGP filtering is based on communities.
I am hijacking this thread a bit. Setting communities is excellent advice especially if you are just starting out with downstream ASes.
The question is that changing your communities down the road might be a big headache depending on whether you'll come to need more advanced ways of filtering your announcements than coarse communities allow. Especially when going (through growth or acquisition) from a single metro network to a multi-metro or national/international one.
What criteria does the community think should be used when specifying communities. IMO, overspecificity [sp?] doesn't hurt, but others may (and have) disagreed. What's the BCP?
Thanks,
Deepak Jain AINET
On Friday, May 16, 2003, at 14:50 Canada/Eastern, Deepak Jain wrote:
The question is that changing your communities down the road might be a big headache depending on whether you'll come to need more advanced ways of filtering your announcements than coarse communities allow. Especially when going (through growth or acquisition) from a single metro network to a multi-metro or national/international one.
What criteria does the community think should be used when specifying communities. IMO, overspecificity [sp?] doesn't hurt, but others may (and have) disagreed. What's the BCP?
I don't know that this is "best", but I like it: + decide on a set of characteristics that will help make routing policy decisions today + allocate one unique 16-bit number to each of those characteristics (N) + apply corresponding community string attributes (THIS_AS:N) to routes in sensible places + configure your route export policy based on community string attributes present on routes + worry about other characteristics as and when they become useful/necessary, and not before Examples of characteristics I have seen in the wild are: + I was learnt from a peer + I was learnt from a transit provider + I was learnt from a customer + I was learnt over an exchange point + I was learnt over a private peering connection These are all markers to be used in setting internal policy, so the choice of numbers really doesn't matter. You can add or remove characteristics from your list when necessary without having to renumber anything. You can (and probably should) strip all these attributes before sending routes to EBGP peers, so nobody else has to see them. Specifying a list of characteristics that seem like they might one day be useful but which today do nothing to influence routing policy seems like a waste of effort. People might better spend their time checking that all their customer sessions have accurate import prefix filters. Joe
On Fri, 16 May 2003, Joe Abley wrote:
Examples of characteristics I have seen in the wild are:
+ I was learnt from a peer + I was learnt from a transit provider + I was learnt from a customer + I was learnt over an exchange point + I was learnt over a private peering connection
These are all markers to be used in setting internal policy, so the choice of numbers really doesn't matter. You can add or remove characteristics from your list when necessary without having to renumber anything. You can (and probably should) strip all these attributes before sending routes to EBGP peers, so nobody else has to see them.
You can & definitely should strip those community values on announcements you receive from EBGP peers. Interesting things happen if you let others turn your routing policy knobs when you think they can't reach them. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
On 5/16/03 1:26 PM, "Jay Ford" <jay-ford@uiowa.edu> wrote:
You can & definitely should strip those community values on announcements you receive from EBGP peers. Interesting things happen if you let others turn your routing policy knobs when you think they can't reach them.\
Agreed. Likewise, when you receive communities (and MEDs, ugh!) [if possible] you should reset them (v. employing 'additive'). Unnecessary propagation and/or uniqueness of many attributes (especially transitive) can that go unnoticed often have a significant impact on efficiencies of BGP update packing -- which subsequently impacts convergence, CPU & memory resource utilization, etc... -danny
On Fri, 16 May 2003, Danny McPherson wrote:
On 5/16/03 1:26 PM, "Jay Ford" <jay-ford@uiowa.edu> wrote:
You can & definitely should strip those community values on announcements you receive from EBGP peers. Interesting things happen if you let others turn your routing policy knobs when you think they can't reach them.\
Agreed.
Likewise, when you receive communities (and MEDs, ugh!) [if possible] you should reset them (v. employing 'additive'). Unnecessary propagation and/or
Hmm.. assuming you're interconnecting at multiple points with the same ASN they will probably want to indicate to you where to send traffic to them using MEDs, if you go stripping them out you lose that info, check the peering policy.. this may put you in breach. Even without a breach of policy the MED will help find the best path to a route thats identical at two points and if you take it out you lose that. Altho I'd agree if you'd say to clear the communities and MEDs on egress, thats an okay thing to do. Steve
uniqueness of many attributes (especially transitive) can that go unnoticed often have a significant impact on efficiencies of BGP update packing -- which subsequently impacts convergence, CPU & memory resource utilization, etc...
-danny
On 5/16/03 4:01 PM, "Stephen J. Wilcox" <steve@telecomplete.co.uk> wrote:
Hmm.. assuming you're interconnecting at multiple points with the same ASN they will probably want to indicate to you where to send traffic to them using MEDs, if you go stripping them out you lose that info, check the peering policy.. this may put you in breach.
Even without a breach of policy the MED will help find the best path to a route thats identical at two points and if you take it out you lose that.
Perhaps folks are foolish enough to put "MUST accept MEDs" in a bilateral peering agreement (note that if money is attached the circumstance change, but routing breaks all the same). They should be cautious, however, not only are MEDs the most obvious trigger for persistent route oscillation, they _very often break with aggregation (unless you're foolish enough to accept more-specifics as well!) and if compared between multiple ASes (or even in the same AS) often turn your "cold-potato routing" into "mashed-potato-routing" because of disjoint policies between different domains, or downright stupid MED-derivation mechanisms. Not intending to turn this into an MED rant, but more than a few of us have experienced brokenness on account of MEDs in the past .. NANOG and IDR WG archives have addressed these concerns a number of times. -danny
On Fri, May 16, 2003 at 11:01:16PM +0100, Stephen J. Wilcox wrote:
Hmm.. assuming you're interconnecting at multiple points with the same ASN they will probably want to indicate to you where to send traffic to them using MEDs, if you go stripping them out you lose that info, check the peering policy.. this may put you in breach.
Even without a breach of policy the MED will help find the best path to a route thats identical at two points and if you take it out you lose that.
Practical implementation note: The vast majority of the internet is completely incapable of setting correct MEDs. Even if they wanted to, it is often technical impossible due to aggregation. Realistically, MEDS usually break more than they help. If you want to improve connectivity, peer more. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
comments inline... On Fri, 16 May 2003, Stephen J. Wilcox wrote:
On Fri, 16 May 2003, Danny McPherson wrote:
On 5/16/03 1:26 PM, "Jay Ford" <jay-ford@uiowa.edu> wrote:
You can & definitely should strip those community values on announcements you receive from EBGP peers. Interesting things happen if you let others turn your routing policy knobs when you think they can't reach them.\
Agreed.
Likewise, when you receive communities (and MEDs, ugh!) [if possible] you should reset them (v. employing 'additive'). Unnecessary propagation and/or
Hmm.. assuming you're interconnecting at multiple points with the same ASN they will probably want to indicate to you where to send traffic to them using MEDs, if you go stripping them out you lose that info, check the peering policy.. this may put you in breach.
Even without a breach of policy the MED will help find the best path to a route thats identical at two points and if you take it out you lose that.
All a matter of perspective. I would assume most people want to use closest exit on their networks. Imagine how nice it would be if you could hand off traffic to a peer that is your closest exit, then force them to carry the traffic back to you at that same point from across the country or across the globe!
Altho I'd agree if you'd say to clear the communities and MEDs on egress, thats an okay thing to do.
Spank me if I'm wrong here, but you don't pass MEDs on transitively anyway. And if you strip communities off, you limit your peers/customers/providers from being able to use the same control that you are asking for. Guy Tal
In a message written on Fri, May 16, 2003 at 05:28:37PM -0500, Guy Tal wrote:
All a matter of perspective. I would assume most people want to use closest exit on their networks. Imagine how nice it would be if you could hand off traffic to a peer that is your closest exit, then force them to carry the traffic back to you at that same point from across the country or across the globe!
Since this started off talking about customers, I must also point out: Many customers want MEDs to be honored. They don't want their transit provider, who they are paying money to carry the bits where they want them to be, to be closest exiting to them. I would think the most common configuration in large networks is to honor meds from customers, not honor them from peers, but send them to peers. Note I said common, and not majority. Do MEDs have their problems? Sure. Are they worse than the alternatives? I don't think so. A lot of people do a lot of handwaving about how dangerous it is to use meds. I find that funny, working on a global network that uses them without major problem. Do you have to avoid some situations, sure...but that's no different than if you don't use them. I know more than a few networks that avoid MPLS traffic engineering through clever use of meds, for instance, a good trade off in my book. At the end of the day the best advice I have is to be mindful of what you do with MEDS. Too many people like to ignore them, and that is a problem. Don't want to send them, fine, but be religous about getting rid of them everywhere or you'll cause problems. Want to use them, fine, but make sure they mean something and aren't garbage. Ignoring the consequences of meds in your config choices _will_ cause you problems. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On 5/16/03 4:50 PM, "Leo Bicknell" <bicknell@ufp.org> wrote:
Since this started off talking about customers, I must also point out:
Many customers want MEDs to be honored. They don't want their transit provider, who they are paying money to carry the bits where they want them to be, to be closest exiting to them.
They want another feature, and someone sold them with the "we'll accept MEDs from you and not do closest-exit like your peers" line. They forgot to mention route oscillation might occur, or if the customer does any form of intelligent aggregation MEDs are probably broken, or if things aren't tweaked perfectly things can be worse than closest-exit, etc.., etc.. I've seen MEDs work "as advertised" (no pun intended ;-) in several configurations, but in general I've seen them break things first-hand in 3 very large networks.
I would think the most common configuration in large networks is to honor meds from customers, not honor them from peers, but send them to peers. Note I said common, and not majority.
"most common" would imply majority. I doubt that's the case.
At the end of the day the best advice I have is to be mindful of what you do with MEDS. Too many people like to ignore them, and that is a problem. Don't want to send them, fine, but be religous about getting rid of them everywhere or you'll cause problems.
You'll fix more problems then you'll cause, guaranteed. Folks are mesmerized by tuning yet another knob and assuming everything is dandy because they can ping some destination. It's more than that, much more. Take the update packing comments earlier as yet another effect.
Want to use them, fine, but make sure they mean something and aren't garbage.
How exactly do you make sure you're peers MEDs aren't garbage? Accept more-specifics? Configure and maintain their routers? And if they're multi-homed to another network and accept MEDs from them do you simply configure "always-compare-med" in your router and assume things are great? They're probably not. Most folks seem to have enough of a problem deriving their own.
Ignoring the consequences of meds in your config choices _will_ cause you problems.
Yes, that's why you remove them and understand the consequences of not doing so. RFC 3345 provides one such example, though I'm certain that aggregation breaks MEDs more often than anything. MEDs will work to influence route selection, no doubt, but you'd better read the fine print and between the lines. -danny
Spank me if I'm wrong here, but you don't pass MEDs on transitively anyway.
Correct. As a matter of fact, even advertising MEDs to IBGP is left as "an implementation issue", not a protocol requirement.
And if you strip communities off, you limit your peers/customers/ providers from being able to use the same control that you are asking for.
As everyone has different policies, they're likely stripped or ignored on ingress (or somewhere across the world) anyways. Given, you'd accept them on ingress from transit peers for RFC1998ish stuff, and perhaps under special circumstances from bilateral peers, but that doesn't mean you ever need to carry them past the ingress BGP router into your own network. The effects of propagating what's essentially garbage needlessly have real impacts on the convergence and stability characteristics of the global routing system. It essentially falls back Postel's robustness principle with "[...] be conservative in what you send". Though I've never put anything formal together (for general consumption), I have performed testing and seen the effects the presence of needless attributes have on efficiencies of BGP update packing (and all things subsequent), and they are very real. -danny
On Fri, 16 May 2003, Guy Tal wrote:
On Fri, 16 May 2003, Stephen J. Wilcox wrote:
On Fri, 16 May 2003, Danny McPherson wrote:
On 5/16/03 1:26 PM, "Jay Ford" <jay-ford@uiowa.edu> wrote:
You can & definitely should strip those community values on announcements you receive from EBGP peers. Interesting things happen if you let others turn your routing policy knobs when you think they can't reach them.\
Agreed.
Likewise, when you receive communities (and MEDs, ugh!) [if possible] you should reset them (v. employing 'additive'). Unnecessary propagation and/or
Hmm.. assuming you're interconnecting at multiple points with the same ASN they will probably want to indicate to you where to send traffic to them using MEDs, if you go stripping them out you lose that info, check the peering policy.. this may put you in breach.
Even without a breach of policy the MED will help find the best path to a route thats identical at two points and if you take it out you lose that.
All a matter of perspective. I would assume most people want to use closest exit on their networks. Imagine how nice it would be if you could hand off traffic to a peer that is your closest exit, then force them to carry the traffic back to you at that same point from across the country or across the globe!
Okay perhaps I didnt add enough detail, I'm not suggesting that you should accept them without sanity but within a city or region it helps to know where the best exit point is for that route. In my own situation I peer with some networks several times within the same building and its nice for them to hint to me where they want my traffic and vice versa, if I want to distribute load I send my hints to them.
Altho I'd agree if you'd say to clear the communities and MEDs on egress, thats an okay thing to do.
Spank me if I'm wrong here, but you don't pass MEDs on transitively anyway. And if you strip communities off, you limit your peers/customers/providers from being able to use the same control that you are asking for.
Hmm is the first bit optional? ;) Okay again I perhaps wasnt specific enough, I'm suggesting the MEDs and communities are useful between two peers who may be peering at multiple points, so this is engineering choices when the two paths are identical and all you have is the entry/exit point to choose. Steve
Guy Tal
On Sat, 17 May 2003, Stephen J. Wilcox wrote:
Hmm is the first bit optional? ;) Okay again I perhaps wasnt specific enough, I'm suggesting the MEDs and communities are useful between two peers who may be peering at multiple points, so this is engineering choices when the two paths are identical and all you have is the entry/exit point to choose.
Steve
The first bit definitely wasn't RFC compliant and is probably not AUP compliant either. :/ But on to more serious matters, you just have to be very careful that your policy is implemented uniformly. And don't forget that there are other factors that are examined before MED is looked at. Guy
On Thu, 15 May 2003, Mark Radabaugh wrote:
I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's.
I find lots of references (and understand) the basic
ip as-path access-list 3 permit ^$
and it would seem that should we wish to provide transit for a bgp customer AS12345 we would use:
ip as-path access-list 3 permit ^12345$
but I think this breaks if AS12345 prepends their advertisement.
yes it will
Next up is:
ip as-path access-list 3 permit ^12345_[0-9]$*
Which seems correct to me. Is this still best practice (or even correct)?
no, perhaps you mean ..[0-9]*$ but that still wont allow multiple prepends as it wont match the space only the numbers try ip as-path access-list 3 permit ^(_12345_)+$ which will allow one or more of their as's ASN is pretty crude tho, consider using a prefix list to filter each prefix and include length Steve
Mark Radabaugh Amplex (419) 720-3635
In a message written on Thu, May 15, 2003 at 10:29:18PM -0400, Mark Radabaugh wrote:
I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's.
I strongly recomend you prefix list filter your customers, rather than AS path filter them. While AS path filters to prevent some kinds of abuse and accidental mistake, they still allow your customer to hijack any address space in your network (and possibly beyond) at any time.
ip as-path access-list 3 permit ^12345$
but I think this breaks if AS12345 prepends their advertisement.
Probably you want something more like: ip as-path access-list 3 permit ^(12345_)+$ ip as-path access-list 3 permit ^(12345_)+(6789_)+$ Giving both the customer, and customer with a customer case. That is both specific, and allows for prepends. Your example has a couple of problems:
ip as-path access-list 3 permit ^12345_[0-9]$*
First, it's not a valid regex ($* need to be *$), second, it allows any (single) AS behind 12345, so it's hardly a useful filter. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Thu, 15 May 2003, Mark Radabaugh wrote:
I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's.
There are several different methods possible, however be careful with using the same sledge hammer for every sized project. Small ISPs with only a few eBGP neighbors (i.e. less than a dozen) and a few network prefixes (i.e. less than a 100) probablly should stick with hardcoded, explicit prefix and as-path filters. Coordinate the occasional updates to the filters with your upstreams (since they should be filtering your announcements on ingress anyway). You are less likely to mess things up, and its simplier to understand if another network engineer needs to debug things later. You also tickle fewer software paths (and potential bugs) through the router code. Large ISPS (more than 500 eBGP neighbors and 5000 prefixes) are going to need some automated and dynamic mechanisms. You should always ingress filter announcements from downstream neighbors and customers with an explicit, positive prefix and AS filter (a bogon filter is not sufficient). ANS was the only major commercial provider I knew which explicitly configured BGP announcement filters for every network prefix from every source. According to studies, about 70% of large ISPs dynamically tag prefixes with community attributes to distinguish between different types of prefixes (e.g. customer, peer, internal, etc). Because community attributes are dynamic, and sometimes subtle, they have been responsible for some huge network leaks. Unfortunately, most vendors' implemenation of eBGP results in the announcement all network prefixes in the BGP table by default. Its up to you to prevent the default behaivor. If you use communities, I would suggest you configure the default to block the network announcement. That way if you accidently misconfigure something else, somewhere else, sometime later, and forget to set the correct community, the network announcement will get dropped. Large ISPs probably also want to use a few insanity filters. Its not generally practical to customize hardcoded filters across a large network. So they tend to be limited to just the perpetually insane. If you are a medium sized ISP, you are in the awkard stage. Stick with the simple stuff until you have a good reason to change to more complicated methods.
In a message written on Fri, May 16, 2003 at 08:00:00PM -0400, Sean Donelan wrote:
Large ISPS (more than 500 eBGP neighbors and 5000 prefixes) are going to
MFN / AboveNet qualifies as a "large ISP" by your definition, yet:
sufficient). ANS was the only major commercial provider I knew which explicitly configured BGP announcement filters for every network prefix from every source. According to studies, about 70% of large ISPs
We prefix-list filter all of our customers. We have from time to time made an exception due to route limits, or people limits, but we still exceed 99% of our customers are fully prefix-list filtered on all inbound announcements. It's not that hard. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, 16 May 2003, Leo Bicknell wrote:
In a message written on Fri, May 16, 2003 at 08:00:00PM -0400, Sean Donelan wrote:
Large ISPS (more than 500 eBGP neighbors and 5000 prefixes) are going to
MFN / AboveNet qualifies as a "large ISP" by your definition, yet:
sufficient). ANS was the only major commercial provider I knew which explicitly configured BGP announcement filters for every network prefix from every source. According to studies, about 70% of large ISPs
We prefix-list filter all of our customers. We have from time to time made an exception due to route limits, or people limits, but we still exceed 99% of our customers are fully prefix-list filtered on all inbound announcements. It's not that hard.
I said *EVERY* network prefix from *EVERY* source. I didn't limit it to just customers. ANS also filtered peers.
In a message written on Fri, May 16, 2003 at 08:10:22PM -0400, Sean Donelan wrote:
I said *EVERY* network prefix from *EVERY* source. I didn't limit it to just customers. ANS also filtered peers.
Mea Culpa. Of course, we see where that got ANS. I'd be content if even half the provides out there filtered half their customers. That would be a quantum leap forward from today. I can think of more than a few "Tier 1" ISP's that allow a filter of "as-path ^custasn.*$" and call that a filter. *sigh* -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Friday, May 16, 2003, at 20:00 Canada/Eastern, Sean Donelan wrote:
Small ISPs with only a few eBGP neighbors (i.e. less than a dozen) and a few network prefixes (i.e. less than a 100) probablly should stick with hardcoded, explicit prefix and as-path filters. Coordinate the occasional updates to the filters with your upstreams (since they should be filtering your announcements on ingress anyway). You are less likely to mess things up, and its simplier to understand if another network engineer needs to debug things later.
Having being involved in cleaning up the networks of many small ISPs (by your definition of small) after they have been deployed by people long since departed, I completely disagree with your last sentence. Maybe complexity is in the eye of the beholder, but ISPs which classify the routes they carry according to origin using community string attributes are much easier to debug and understand than those who specify their exit policy using hard-coded prefix and as-path filters all over the place. I don't think "start messy and clean up later" is good advice. Do it right the first time, and grow smoothly without difficult migrations. Joe
On Fri, 16 May 2003, Joe Abley wrote:
I don't think "start messy and clean up later" is good advice. Do it right the first time, and grow smoothly without difficult migrations.
I've found some people can make a mess with any tool you give them. It usually not a problem with the tool. I don't suggest people use powerful tools just for ego gratification. They should use the tool appropriate for the size of the job. Don't use a dynamic routing protocol when a static route will do. Don't use an exterior gateway protocol when you are connected to a single network. Don't use dynamic route prefix tagging when a static filter will do. Don't use route reflectors when a full mesh will do. Don't use the Openview network management suite, when MRTG will do. Don't use a GSR 12000, when a 2600 will do. Each of those tools can be configured "cleanly." When your network outgrows a particular tool, you need to transition to the next tool. Of course, some people fail to transition at the appropriate time and end up pushing a tool past its breaking point. I also don't suggest people use lots of duct tape or Rube Goldberg contraptions on their network. As I said, there are times when there is a reason for using community tagging in your network. Are you suggesting that its a bad idea to make things appear "too easy," and by suggesting more complex configs we'll scare off the bottom rung of network engineers. Maybe. Barry Greene's & Philip Smith's book "Cisco ISP Essentials: A comprehensive guide to the best common practices for Internet service providers" uses static prefix filters almost exclusively in all of its example "best practices" for ISPs. Although the ISP book is a useful reference for network engineers at any size network, the examples work best for networks of a certain size.
On Friday, May 16, 2003, at 23:58 Canada/Eastern, Sean Donelan wrote:
Are you suggesting that its a bad idea to make things appear "too easy," and by suggesting more complex configs we'll scare off the bottom rung of network engineers. Maybe.
Not really; I'm suggesting that a few more minutes worth of thinking at day one will save many more minutes of pain down the road.
Barry Greene's & Philip Smith's book "Cisco ISP Essentials: A comprehensive guide to the best common practices for Internet service providers" uses static prefix filters almost exclusively in all of its example "best practices" for ISPs. Although the ISP book is a useful reference for network engineers at any size network, the examples work best for networks of a certain size.
And presumably for networks which never expect to grow. In my experience the networks that don't grow are also the ones that shrivel and die. I think that the message "community strings are hard" (like its friends "BGP is hard" and "let's turn on RIP") need to stop propagating. It is just not that difficult to do things right the first time, and you don't need to be a bigger network than a pair of 2501s with a small handful of external BGP sessions to see the benefit of it. Joe
On zaterdag, mei 17, 2003, at 17:30 Europe/Amsterdam, Joe Abley wrote:
think that the message "community strings are hard" (like its friends "BGP is hard" and "let's turn on RIP") need to stop propagating. It is just not that difficult to do things right the first time, and you don't need to be a bigger network than a pair of 2501s with a small handful of external BGP sessions to see the benefit of it.
You are saying BGP isn't hard when well-informed people can't even agree on a way to disable unwanted default behavior? Hm... Filtering AS paths and prefixes is relatively well understood, although I hear lots of people fail the CCIE questions on AS path regular expressions. I wouldn't recommend doing it with communities to people who don't have any experience with route maps. And I don't see the point for people who don't have BGP-speaking customers. Apart from that it's mostly a change management issue. The communities mechanism has the advantage you only have to make changes on the routers where the prefixes enter the network (presumably a single customer-facing router) while explicit filters must be updated on all eBGP routers.
On Sat, 17 May 2003, Joe Abley wrote:
I think that the message "community strings are hard" (like its friends "BGP is hard" and "let's turn on RIP") need to stop propagating. It is just not that difficult to do things right the first time, and you don't need to be a bigger network than a pair of 2501s with a small handful of external BGP sessions to see the benefit of it.
As long as you get it right, I'm less concern how you do it. If you are more comfortable using route maps and communities, go ahead and do it that way. If you are more comfortable using prefix filters, go ahead and do it that way. If you are more comfortable using route servers and RPSL, go ahead and do it that way. Its not that difficult to use RPSL, and it would be nice if everyone did it right the first time. But I also recognize if there are several tools to available, different people will have their favorite.
Having being involved in cleaning up the networks of many small ISPs (by your definition of small) after they have been deployed by people long since departed, I completely disagree with your last sentence.
Maybe complexity is in the eye of the beholder, but ISPs which classify the routes they carry according to origin using community string attributes are much easier to debug and understand than those who specify their exit policy using hard-coded prefix and as-path filters all over the place.
I don't think "start messy and clean up later" is good advice. Do it right the first time, and grow smoothly without difficult migrations.
This is very simple - use both: Have standard "I can advertise these prefixes" list on every router. Have standard "I can advertise these AS_PATHs" list on every router. Set communities on the entry for routes that you have accepted. Advertise only routes that have correct community *and* match the standard "I can advertise AS_PATHs" and standard "I can advertise prefixes" lists. Even if you have 1000 routers it is not that difficult because no one ever said that you need to manually update those standard prefix lists an standard AS_PATHs lists. Alex
----- Original Message ----- From: "Sean Donelan" <sean@donelan.com>
If you are a medium sized ISP, you are in the awkard stage. Stick with the simple stuff until you have a good reason to change to more complicated methods.
It seems like it might make sense to use the 'big boy toys' as a small provider so that we make it through the inevitable learning curve where mistakes (while potentially devastating to us) have little possibility of causing major problems for everyone else. At our current size our mistakes are for all intents and purposes invisible to the Internet at large. Mark Radabaugh Amplex (419) 720-3635
participants (14)
-
alex＠yuriev.com -
Brian Wallingford -
Daniel Golding -
Danny McPherson -
Deepak Jain -
Guy Tal -
Iljitsch van Beijnum -
Jay Ford -
Joe Abley -
Leo Bicknell -
Mark Radabaugh -
Richard A Steenbergen -
Sean Donelan -
Stephen J. Wilcox