I keep hearing bitching about how broken the BGP path selection process as 1) defined in the protocol spec and 2) as implemented by vendors, is. It's probably a good idea to bring this out in to the open. If you have specific complaints about how broken path selection is, please speak your piece now. Thanks! ----------------------------------------------------------------------------- Bryan S. Blank bryan@supernet.net (443)394-9529 tele (410)995-2191 page (410)802-6998 emer
Bryan,
I keep hearing bitching about how broken the BGP path selection process as 1) defined in the protocol spec and 2) as implemented by vendors, is.
Well this is a yet-another-knob-request. I have for a while now thought it would be useful to have an attribute which is kept local to the AS, and is if you like an "exit-penalty". This could be added to your IGP distance at the decision stage process. It's difficult to combine internal IGP metrics (especially if you use next-hop-self style peerings internally so lose the distance on the interface itself) *and* add make intelligent use of different quality interconnects (especially if these are interfaces on the same router). Consider the case where you are prepared to send traffic from SOME parts of the country "around the long way" to avoid a particularly crappy interconnect, point, but not from ALL parts of the country. On your point (2) I reckon Cisco implements the standard pretty well (i.e. where it diverges it's for reasonable reasons), or at least it does when you've switched on "bgp deterministic-med" which gives you a good indication of how MED decisions are taken without this knob switched on. -- Alex Bligh GX Networks (formerly Xara Networks)
On your point (2) I reckon Cisco implements the standard pretty
Until they broke it in 12.0 version -:). I do not know if it is Features, futures or bugs - but they changed paths selection abd did it less determinated in last versions...
well (i.e. where it diverges it's for reasonable reasons), or at least it does when you've switched on "bgp deterministic-med" which gives you a good indication of how MED decisions are taken without this knob switched on.
-- Alex Bligh GX Networks (formerly Xara Networks)
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
participants (3)
-
Alex Bligh
-
Alex P. Rudnev
-
Bryan S. Blank