How is BGP potentially injecting information into the IGP? The only way that should be happening is if you are doing BGP -> IGP redistribution, in which case I'd surely hope you aren't doing IGP -> BGP as well.

you are an isp in a small country with half a dozen other isps. the biggest isp in the country has half a dozed prefixes. you all meet at an exchange point and each has an external international exit through an upstream. you want to redistribute the bgp routes learned at the exchange point into your dynamic igp so, when the ix is working, local traffic goes directly there as opposed to tromboning through your default exit. one then also wants to receive from one's upstream transit (or inject) a bgp default route into one's igp, and then one wants to inject one's internal routes into the bgp exports to both the exchange and the upstream. if one's network is at all likely to partition, that means one wants to redistribute one's igp into those two bgp sessions, heavily acled of course. randy

...

you want to redistribute the bgp routes learned at the exchange point into your dynamic igp so, Even in a small country (perhaps a poor country), with old equipment, etc. is this nowadays ever better than carrying it in iBGP?

external ----- expensive ------ agggregation ------- exchange transit link router point | | | | some cust2 custs if you don't, then traffic from cust2 to customers of exchange peers will trombone across the expensive link. randy

Randy Bush wrote (on Nov 03):

...

if you don't, then traffic from cust2 to customers of exchange peers will trombone across the expensive link.

and back again, and back again, and ...

Only if you're mad enough to try to run BGP across a network with forwarding devices in the middle that don't. Even a monetary argument for this weak. Routing decisions in a routing domain need to be deterministic otherwise you risk the loops you mention. In a small network you may be able to get away with it. I personally have better things to worry about and I am sure most people do too. IGP's rarely make the same decisions as EGP's. They don't have the same data to base their decisions on. Chris. -- == chris@easynet.net T: +44 845 333 0122 == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122

Randy,

...

...

...

you want to redistribute the bgp routes learned at the exchange point into your dynamic igp so, Even in a small country (perhaps a poor country), with old equipment, etc. is this nowadays ever better than carrying it in iBGP?

external ----- expensive ------ agggregation ------- exchange transit link router point | | | | some cust2 custs

if you don't, then traffic from cust2 to customers of exchange peers will trombone across the expensive link.

and back again, and back again, and ...

Must be being very thick here. Firstly I don't understand the trombone / routing loop issue as if 'external transit' is the prefered exit from aggregation router, it must have an external route itself, (rather than hearing it from aggregation router) which means it must be preferring external transit. So the 'problem' here would be that traffic from cust2 trombones in the sense of going via external transit, then hopping back over some other link and off to the customer. It doesn't loop. The alternate interpretation is that traffic from both custs & custs 2 exits via the exchange point, which is presumably undesirable in your application. Secondly Presuming the effect that you want is (say) to allow cust2 to get to exchange point peers directly, but 'some custs' not to use expensive link to get there, but to use external transit, then: Tag the routes on entry from anywhere (external transit, custs, cust 2, exchage point) with communities, and alter the localpref on the IBGP peering across the expensive link, so only to the right of the link are the exchange point routes localpreffed better than the external transit. For a simple configuration (2 routers) you can simplify this in the obvious manner. For a complex config (i.e. multiple routers to the left and right), run confeds (which minimizes the number of BGP sessions over expensive link and is thus a good idea anyway) & apply your route map to only the inter-confed BGP sessions. (*) I am assuming that this is a BGP exchange point (I know there are others), and there is a relatively normal setup (loopback peerings, next hop self, etc.). My point is that flexibility in terms of maintaining finely grained traffic control whilst maintaining loop detection seem to be rather better in BGP than your IGP du-jour. If you make the IGP solution only slightly more complex (put in 3 expensive links in a triangle) it becomes hard to distinguish between customer routes and peer routes, one of which (if remote) you probably do want traversing expensive link(s), the other you may not. Much nicer than using redist into IGP, no? (*)=there is very little you cannot do with confeds that you would get from having multiple AS's; & we know this problem could be solved (in an ugly manner) that way. -- Alex Bligh Personal Capacity

Randy wrote:

o for many reasons, it is likely the middle router will be an igp, not bgp speaker o hence very careful redistribution of ebgp to igp, and of igp to bgp is useful

IMHO it's much cleaner and easier to setup BGP on the router in the middle. If it's able to carry the routes via IGP it will also be able to do it via IBGP. -- Arnold