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