...which is better?
We recently ran into what looks like an implementation flaw in our network
design. After moving two GbE connections with Savvis (same edge device on
both ends) into EBGP-multihop, we were encountering problems with iBGP
churn.
The network design is two buildings in the same AS, each building has two
core switches, which are in a full iBGP mesh, and acting as
route-reflectors for four border switches. Two border switches are in one
building, the other two in the other building. The layout is shown here:
http://img17.imageshack.us/img17/6562/bgplayout.jpg
EIGRP is being used as the IGP, now border4 is the the newest switch to
have been installed, and in it's EIGRP configuration, static and connected
routes were being redistributed. The other border switches, however were
not redistributing. They were using next-hop-self in their iBGP
announcements to the cores. We ended the iBGP churn issue by changing
border4 to use next-hop-self to cores 3 and 4.
My question is, which is the correct method of implementing this? Should
we be redistributing static and connected routes on our borders into IGP,
and not using next-hop-self? Or should we not redistribute and use
next-hop-self?
I always recommend setting the NEXT_HOP attribute to 'self'
for all iBGP sessions at the (peering) edge, and using your
IGP to provide reachability to all Loopback addresses in the
network. This scales quite well.
And while IGP/BGP redistribution may be possible, we tend to
avoid it as much as possible.
Cheers,
Mark.
Mark Tinka wrote:
My question is, which is the correct method of
implementing this? Should we be redistributing static
and connected routes on our borders into IGP, and not
using next-hop-self? Or should we not redistribute and
use next-hop-self?
I always recommend setting the NEXT_HOP attribute to 'self' for all iBGP sessions at the (peering) edge, and using your IGP to provide reachability to all Loopback addresses in the network. This scales quite well.
Any NANOGers running an MPLS network and choosing instead to redistribute the relevant connected routes from the peering edge into their network (either via IGP or BGP), thereby allowing label switching all the way to the PE (and therefore out a particular interface)? Next-hop-self seems to trigger penultimate hop popping, resulting in an IP lookup on the PE.
pt
Have you considered an explicit-null label value advertised
by the LER?
Is your goal preservation of QoS information?
Cheers,
Mark.
phil@mindfury.net wrote:
...which is better?
Neither (both) is better, depending on the scenario. This is especially true when mixing in MPLS and other features.
My question is, which is the correct method of implementing this? Should
we be redistributing static and connected routes on our borders into IGP,
and not using next-hop-self? Or should we not redistribute and use
next-hop-self?
next-hop-self seems to remain more stable overall. In some scenarios I believe it is even required (just as not using it is required in other scenarios). For your deployment, I'd say you are open to choose either, and next-hop-self would be the more stable of the two. The largest issue with NOT using next-hop-self that I have seen is the effect it has when that IGP route for the next hop disappears. BGP tends to be more graceful about removing routes via iBGP then handling routes locally when they are suddenly unreachable via IGP.
Another benefit of next-hop-self is the fact that the IGP doesn't have to be overly enlarged when you have a large network (injecting hundreds or thousands of links into IGP). With OSPF/ISIS in a flat (single area) topology utilizing MPLS across the core, you would prefer stability in the link state database. Each edge network you place in IGP increases the chances of a database change, and in critical outages, they increase the number of changes that must be made.
-Jack
On smaller networks (where IGP size is not an issue), I could see some benefit for redistributing connected to IGP and preserving the next-hop for those interfaces which have a backup route through some other interface. I.E: if the connected interface goes down, everyone knows immediately that the nexthop is unusable, and you can start using better working routes immediately, rather than waiting for the routes being BGP WITHDRAWn.
Loopback and n-h-s seems to always make sense for those interfaces which are singlehomed to that router (no redundancy) -- otherwise you may want to consider which one is best.