BGP nexthop-self vs. EIGRP redistribution
...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? -- Philip L.
On Tuesday 17 March 2009 12:20:08 am phil@mindfury.net 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. And while IGP/BGP redistribution may be possible, we tend to avoid it as much as possible. Cheers, Mark.
Mark Tinka wrote:
On Tuesday 17 March 2009 12:20:08 am phil@mindfury.net 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
On Tuesday 17 March 2009 12:33:30 am Pete Templin wrote:
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.
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 Mon, 16 Mar 2009, Jack Bates 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?
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.
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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
participants (5)
-
Jack Bates -
Mark Tinka -
Pekka Savola -
Pete Templin -
phil＠mindfury.net