Hello everyone, Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor. Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links? Is there a added benefit to using next hop self in this situation? Any feedback is much appreciated, either for the question specifically or whatever else you got 😊, L3VPN's or underlying technology that has to have that. Thanks
On an IX, without next-hop-self peer A leaking peer B's routes they receive to C will have C send direct to B on the IX (assuming flat layer 3 addressing, and not multiple little /30s or /96s everywhere or something - do any exchanges do that?) This may seem more efficient than sending C's traffic to A to get to B (pumping up the IX's usage graphs) but B may not have peering agreements with C. Setting next-hop-self avoids this. An 'advantage' in some views. Not related to n-h-s in an igp specifically, but an interesting (mis)use case. /kc On Fri, Dec 01, 2017 at 03:06:34PM +0000, craig washington said:
Hello everyone,
Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor.
Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links?
Is there a added benefit to using next hop self in this situation?
Any feedback is much appreciated, either for the question specifically or whatever else you got ????, L3VPN's or underlying technology that has to have that.
Thanks
-- Ken Chase - math@sizone.org Guelph Canada
I'd like to add that one major advantage is limiting next-hops, thus labels in your network. This is not just theoretical concern but there are plenty of practical networks using practical hardware where you simply cannot expose all next-hops to every node. On 1 December 2017 at 17:30, Ken Chase <math@sizone.org> wrote:
On an IX, without next-hop-self peer A leaking peer B's routes they receive to C will have C send direct to B on the IX (assuming flat layer 3 addressing, and not multiple little /30s or /96s everywhere or something - do any exchanges do that?)
This may seem more efficient than sending C's traffic to A to get to B (pumping up the IX's usage graphs) but B may not have peering agreements with C.
Setting next-hop-self avoids this. An 'advantage' in some views. Not related to n-h-s in an igp specifically, but an interesting (mis)use case.
/kc
On Fri, Dec 01, 2017 at 03:06:34PM +0000, craig washington said:
Hello everyone,
Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor.
Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links?
Is there a added benefit to using next hop self in this situation?
Any feedback is much appreciated, either for the question specifically or whatever else you got ????, L3VPN's or underlying technology that has to have that.
Thanks
-- Ken Chase - math@sizone.org Guelph Canada
-- ++ytti
Hi For the MPLS L3VPN the answer is that the next hop attribute needs to be an address from the default VRF and if the peering is happening in a VRF context, there is no address from the default VRF you could use as next hop other than self. This can be rather inconvenient as there are advantages to have the real next hop. For example fast rerouting works better when all defective routes can be removed in one go because the next hop was removed by the IGP instantly invalidating the affected routes. Regards, Baldur Den 01/12/2017 kl. 16.06 skrev craig washington:
Hello everyone,
Question, what are the true benefits to using the next-hop self feature, doesn't matter what vendor.
Most information I see is just to make sure you have reach-ability for external routes via IBGP, but what if all your IBGP knows the eBGP links?
Is there a added benefit to using next hop self in this situation?
Any feedback is much appreciated, either for the question specifically or whatever else you got 😊, L3VPN's or underlying technology that has to have that.
Thanks
participants (4)
-
Baldur Norddahl -
craig washington -
Ken Chase -
Saku Ytti