Your Local 'Local Preference' Preferences
Hi, Snazzy subject line huh? ;-) Anyway, Was pondering the impact of path-stuffed networks being announced into the APE combined with operators not actually setting APE learnt routes with a higher local pref. In other words, how many operators out there are not preffing up APE learnt routes? Cheers jamie
jamie.baddeley(a)vpc.co.nz wrote:
Was pondering the impact of path-stuffed networks being announced into the APE combined with operators not actually setting APE learnt routes with a higher local pref.
In other words, how many operators out there are not preffing up APE learnt routes?
Definitely can cause issues - especially with RS learned paths, given they inherently have an extra AS in the AS_PATH. When you can see one path via APE and one via domestic transit with the same AS_PATH length, the domestic transit can win if the local-pref is the same, if people are using the Cisco new-default of longest-up-bgp-session as deterministic, rather than peer-id, in which case APE should win. While I no longer peer; I previously had a local-pref policy of: 200 : customer 175 : private peering 170 : public peering 150 : domestic transit 130 : international transit and just for fun, tagged each route with communities indicating where it was learned from, type, geo area, and so on. This comes in useful. Another fun issue can be people applying inconsistent local-pref policies between IXPs (e.g. WIX & APE), causing all sorts of fun weirdness! YMMV. aj.
On 9-May-2006, at 08:29 , Alastair Johnson wrote:
200 : customer 175 : private peering 170 : public peering 150 : domestic transit 130 : international transit
When building a list like this it can sometimes be useful to consider what happens to a route which (through configuration error) avoids receiving the standard import policy, e.g. through a session that is missing a route-map. Since the default LOCAL_PREF attribute is 100, I always liked to set the LOCAL_PREF on expensive paths below that, e.g. by choosing something like 80 for international transit and 90 for domestic. This has been known to avoid expensive weekends following last-minute- before-the-pub Friday session changes. In any case, having a dummy IBGP peer running OpenBGPd or Quagga or similar which sends alerts when it sees routes with non-standard LOCAL_PREF values can be a handy thing. Joe
Joe Abley wrote:
On 9-May-2006, at 08:29 , Alastair Johnson wrote:
200 : customer 175 : private peering 170 : public peering 150 : domestic transit 130 : international transit
When building a list like this it can sometimes be useful to consider what happens to a route which (through configuration error) avoids receiving the standard import policy, e.g. through a session that is missing a route-map.
Very good point, Joe. I hadn't thought of that, but it does make sense. Of course, we're all using standard peer profiles and group definitions which would NEVER allow this to happen, right? And with every operator practising ITIL change control and release management, it'll never happen. :-)
In any case, having a dummy IBGP peer running OpenBGPd or Quagga or similar which sends alerts when it sees routes with non-standard LOCAL_PREF values can be a handy thing.
Good call. I also had a small route collector participating in my backbone OSPF area to check for anomolous routes (amongst other things). aj.
On Wed, 2006-05-10 at 11:37 +1200, Alastair Johnson wrote:
Joe Abley wrote:
On 9-May-2006, at 08:29 , Alastair Johnson wrote:
200 : customer 175 : private peering 170 : public peering 150 : domestic transit 130 : international transit
When building a list like this it can sometimes be useful to consider what happens to a route which (through configuration error) avoids receiving the standard import policy, e.g. through a session that is missing a route-map.
Very good point, Joe. I hadn't thought of that, but it does make sense.
Of course, we're all using standard peer profiles and group definitions which would NEVER allow this to happen, right?
Well I guess that's the point. Not necessarily standards, but some discussion for sure. Another thing I've also been thinking about is community attributes. Using it to turn on remote blackholing with upstreams is useful, and we saw at NZNOG the approach to communicate enhancements or variations of that. But lowest common denominator suggests that using an agreed set of community attributes (which works for everyone) to convey stuff is something that should be worked on first. So, combining an agreed set of local_pref's and some community attributes might be the basis of building a broader, and faster exchange between participants. Community String Attributes 1000 Route is locally-originated, and should be exported 1000 Route is locally-originated, but should be suppressed towards peers 1002 Route is a blackhole route 1100 Route was learnt from a customer 1200 Route was learnt from a peer 1300 Route was learnt from a backbone 1400 Route was learnt from a transit provider (domestic/international) Local Preference Values 130 - locally-originated 120 - customers 110 - peers 90 - backbone 85 - domestic 80 - international here: http://www.occaid.org/routingpolicy.php Is a really scary example of how carried away one could get, but some of the ideas are interesting.. Especially the geographic stuff. anyway...There's probably a gazillion variations that one could adopt, but one question I have is how much pain would it be for other operators to implement a common convention? I can't recall this sort of thing being discussed on the NOG. cheers jamie
On 10/05/2006, at 10:57 PM, Jamie Baddeley wrote:
Another thing I've also been thinking about is community attributes. Using it to turn on remote blackholing with upstreams is useful, and we saw at NZNOG the approach to communicate enhancements or variations of that. But lowest common denominator suggests that using an agreed set of community attributes (which works for everyone) to convey stuff is something that should be worked on first.
You can most likely advertise blackhole routes to your transit provider(s) today.
So, combining an agreed set of local_pref's and some community attributes might be the basis of building a broader, and faster exchange between participants.
You mean, a 'standard' for use by NZ operators when peering? Would many operators be open to such things? With providers trying to route hot-potato as much as possible, I can see this causing a few.. problems. I'm not a fan of applying local-pref to networks advertised by customers/peers, unless there are knobs (ie. community tags) in place to remove/modify what that local-pref is. Otherwise problems arise when trying to run backup-only links, etc. Some standard filtering templates for 'less clueful' operators would probably be useful here. <..>
Is a really scary example of how carried away one could get, but some of the ideas are interesting.. Especially the geographic stuff.
Most of the large transit providers have similar geographical tags. It's really useful, because it allows them to sell transit to certain locations. Though, has anyone seen that as a product? Note that some of providers don't publish this information, ie. you have to do the NDA dance to get hold of it. None of them (AFAIK) guarantee it. `whois -h whois.radb.net AS3356' tells you what Level3 do. Kudos to them for publishing that info, note that others publish it also. Also note that if your transit providers will re-advertise your prefixes with communities intact, you can take advantage of the Level3 communities even if you're not a direct customer/peer.
anyway...There's probably a gazillion variations that one could adopt, but one question I have is how much pain would it be for other operators to implement a common convention? I can't recall this sort of thing being discussed on the NOG.
Probably not a huge pain, but I'm not sure it adds huge value. It's definitely 'cool', but how often would it actually be used? Definite value (perceived vs. realistic is debatable) for your customers if you are a transit provider, but I'm not sure that it would be used a huge amount for generic peering. Hmm.. I suspect you're probably not the first person to suggest something like this, though. Other than the 'Well-known' attributes defined in RFC1997, has anyone seen a 'standard' or similar that covers some of this stuff that providers could be encouraged to implement? Another note.. how many providers filter communities from incoming advertisements? Do you filter all communities, or just communities that start with your ASN (in ASN:X format, for you pedants out there)? Did you just start filtering since you got this email? :-) Also, do you advertise communities to your peers/transit providers? </ramble> -- Nathan Ward
participants (5)
-
Alastair Johnson -
Jamie Baddeley -
jamie.baddeley＠vpc.co.nz
-
Joe Abley -
Nathan Ward