redistribution

Sat Nov 3 19:47:00 UTC 2001

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