[j-nsp] How to load balance across multiple EBGP exit points when LDP is enabled ?
Tony Redstone
tony.redstone at googlemail.com
Wed Apr 7 20:33:36 EDT 2010
Hello,
Consider the following scenario:
Rtr D --ebgp-- Provider Z
/
Rtr A ---- Rtr B ---- Rtr C
\
Rtr E --ebgp-- Provider Z
1) all routers are in OSPF area 0.0.0.0
2) LDP is enabled on all interfaces
3) Routers D & E are performing next-hop-self on their ibgp sessions
I would like to be able to load share traffic from router A out across
both provider Z EBGP sessions.
If routers D & E have an IBGP session to router A, not a problem - it
just works.
However, if router A does not have direct IBGP sessions with routers D
& E and instead only sees one path via a route reflector (eg perhaps
router C), then router A will only send traffic toward this single
path. Because LDP is enabled, router A has labelled the traffic and
therefore when it gets to router C, no load sharing occurs, it simply
continues label switching towards the next-hop that router A
originally labelled it for.
Methods I have thought of but none of which I'm particularly keen on are:
1) Disable LDP.
problem: can't run MPLS applications.
2) Don't set next-hop-self on routers D & E. Requires carrying
external subnets in IGP and ensuring labels aren't generated.
problem: external interface flaps now flood my area 0.
problem: traffic blackholing could occur if I have two different
routers connected to the same public peering network and one loses
it's BGP sessions but it's interface stays up.
3) Set an egress ldp policy toward routers downstream from C so that
they don't get labels for D & E loopbacks.
problem: limits where I can run my MPLS applications.
4) Set next-hop to a different self IP on routers D & E. Ensure they
aren't LDP labelled. (kind of the inverse of using separate loopback
IPs for LDP)
problem: more loopbacks to configure and manage and network
design not so transparent (summary: design and maintenance overhead)
What is the best way to try to resolve this ?
Thankyou for any input.
Tony
More information about the juniper-nsp
mailing list