[j-nsp] load balancing in Route reflector scenario

[Keegan Holley]

2011/8/10 Humair Ali <humair.s.ali at gmail.com>

> just to clarify ,
>
> you have :
>
> PE2 with 2 link , 1 to RR1 (let's call it link 1)  and 1 to RR2 (link 2)
> PE3 with 2 link , 1 to RR1 (let's call it Link 3) and 1 to RR2  (link4)
>
> you could set local pref to link to PE2 to 150 (RR1 to PE2 will be
> preferred), and link 2 (PE2 to RR2) as standard 100
> then set link 3 standard 100 (PE3 to RR1)  but set link 4 with 150  (RR2 to
> PE3 will be preferred)
>

local pref isn't link specific and neither are the BGP peerings.  In other
words if you have two links to the same RR you would normally only have one
peering.  If you had multiple, you would still only choose a single route
advertised by a single route reflector even though you are changing the
local pref several times.

>
> then RR1 has prefered path via PE2 (via link 1 high local pref), RR2 have
> prefered path via PE3( via link 4 high local pref) , Each RR may advertise
> both route to PE1
>

The route reflector isn't in the forwarding path most of the time. So the
PE's learn each other's routes through the route reflectors but forward
directly to each other or to other P routers.


On 10 August 2011 21:06, Stefan Fouant <sfouant at shortestpathfirst.net>wrote:
>
> > Have you tried the advertise-inactive knob on the RR? I can't guarantee
> > that this will work but it just might also advertise the route towards
> PE3
> > as well.
> >
> > Of course, if this works, then you would need to enable multipathing on
> PE1
> > accordingly.
> >
> > Stefan Fouant
> > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
> > Technical Trainer, Juniper Networks
> > http://www.shortestpathfirst.net
> > http://www.twitter.com/sfouant
> >
> > Sent from my iPad
> >
> > On Aug 10, 2011, at 2:44 PM, biwa net <biwa2go at gmail.com> wrote:
> >
> > > Dear All
> > >
> > > I have a setup where I need to load balancing routes received from 2 RR
> > in
> > > IPV4 environment (not VPN-IPV4)
> > >
> > > I have my  PE (let's called PE1) connected to 2 RR (cluster), my
> > destination
> > > subnet eg: 10.1.1.1/24 is behind 2 PE (PE-2 and PE3) which are also
> > client
> > > of the same 2RR
> > >
> > > PE-2 and PE3 are sending the same route 10.1.1.1/24 to the RR ,  which
> > as
> > > per normal behavior is selecting the best route to PE1  ,
> > >
> > > My issue is that RR is always advertising the route 10.1.1.1/24through
> > PE2
> > > (due to lower router id) as best path and I would like to load balanced
> > it
> > > through PE2 and PE3
> > >
> > > Anyone can recommend a way to load balance ?
> > >
> > > Unfortunately I dont have a lab to test any solution and there are live
> > > traffic on this ,so all I can do is guessing is whether the below 2
> > option
> > > would work or not.
> > >
> > > 2 option I have
> > >
> > > 1.So here I am trying to thinking about testing the multipath command
> > under
> > > the RR configuration  to see if I am receiving routes from both PE or
> not
> > ,
> > >
> > > 2.  try to put all devices them in routing instance VRF , with the BGP
> > > configuration under it (both RR and client) , and RD configured in the
> > VRF
> > > (but not putting any vpn family under bgp) so that it stays IPV4 routes
> ,
> > > maybe I could cheat the RR to believe these are 2 differentes routes
> due
> > to
> > > the RD, but dont know if this works or not .
> > >
> > > anyone has had similar issue and found a workaround ?
> > >
> > > does the 2 option above actually work or not ?
> > >
> > > thanks for any input
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
>
> --
> Humair
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>