> The way I'm thinking of doing this is by redist'ing
> connected and static routes into iBGP via a route-
> map that sets community 'no-export' to make sure
> we don't leak the more specific prefixes, but I
> am looking for arguments for and against setting
> next-hop-self on iBGP peerings - the most obvious
> argument that I can see in favour is that of not
> having to carry external next-hops around in the
> IGP - but I am sure there must be a disadvantage
> to not knowing what the external next-hop was,
> although I am not sure what it might be.
IMO, the greatest benefit of this model is that
external instability (e.g. a customer link flapping)
will no longer trigger IGP instability, load the LSDB
with tons of gunk, trigger zillions of SPF runs, etc..
throughout the entire routing domain (or area).
Setting NEXT_HOP to 'self' also affords you the ability
to not carry external NEXT_HOPs if you chose, thereby
alleviate the chance being prey to theft of network
services (e.g. stealing network services by tunneling
across your network between NAPs isn't unheard of).
As for the 'no-export' & redistribution thing, I'd
propose a slightly more failsafe model. That is,
explicitly deny external advertisement of more specific
'internal' prefixes as a matter of standard policy
on all external peerings.
Then again, an even more fail-safe model is to only
allow specific communities to be advertised externally
.. obviously a separate set for peers & transit customers.
This allows you to avoid problems that occur when a
new routers in inadvertently not configured to send
communities to a peer.
Finally, as for the redistribution, if things are
allocated even semi-sanely you could use network
statements for the aggregate of the link addressing
subnets, then avoid redistribution altogether.
Anyways, IMO, allowing external elements to impact
internally stability is a very bad idea. I agree
that you should move to a BGP model instead.
As well, so is redistribution, but that's another
rathole altogether...
-danny
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:22 EDT