[j-nsp] BGP RR in MPLS VPN
Ihsan Junaidi Ibrahim
ihsan at isp.time.net.my
Sun Feb 11 23:09:02 EST 2007
I've put in the prefix consisting of our loopback IP range into inet.3 and
now the VPNs next-hops are resolvable directly without creating the LSPs to
One thing I'm curious is that the prefix is listed as hidden in inet.3. Is
this the intended behaviour?
From: Ariff Premji [mailto:premji at speakeasy.net]
Sent: Monday, February 12, 2007 10:52 AM
To: Ihsan Junaidi Ibrahim
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] BGP RR in MPLS VPN
Not sure if you've explore this option or not. You dont need to setup LSPs
to your RR. You can place a 0/0 route in inet.3 on the RR so that all
learnt routes appear as resolvable and hence reflected.
Take a look at the RR config at:
On Feb 10, 2007, at 2:16 PM, Ihsan Junaidi Ibrahim wrote:
> Hi all,
> Bringing up an old topic. :)
> I'm having problem creating an LSP on one of my RR to it's own lo0.
> The reason I'm doing this is to propagate our network loopback prefix
> to the rest of the PEs, without creating full mesh of LSPs between the
> PEs and the RRs.
> ihsan at kenanga# show label-switched-path to-self to 10.254.250.2;
> install 10.254.250.0/24;
> And CSPF kept mentioning empty route to the egress.
> ihsan at kenanga# run show mpls lsp ingress name to-self extensive
> Ingress LSP: 17 sessions
> From: 0.0.0.0, State: Dn, ActiveRoute: 0, LSPname: to-self
> ActivePath: (none)
> LoadBalance: Random
> Encoding type: Packet, Switching type: Packet, GPID: IPv4
> Primary State: Dn, No-decrement-ttl
> Will be enqueued for recomputation in 10 second(s).
> 1 Feb 11 06:08:58 CSPF failed: empty route 10.254.250.2
> Created: Sun Feb 11 06:08:55 2007
> Total 1 displayed, Up 0, Down 1
> I was also recommended to create the LSP to another RR and vice- versa
> (to get the prefix installed in inet.3) but I want to avoid that
> because in the event of the dest RR failing (we only have 2 RRs), then
> the NLRI will be marked inactive.
> Any ideas anyone?
>> Hi Guys,
>> What you are looking for is that in order for the l3bgp table to have
>> active routes to pass to the other reflector clients the next hop for
>> all PE¹s in the vpn global table (l3bgp table) must be a LSP learned
>> route. In the traditional sense this would require a full mesh of
>> lsp¹s to the RR and a full mesh of lsp¹s to each PE. A simple work
>> around for this in order to not have lsp¹s going to the RR from each
>> PE is to build a fake LSP on the RR to it¹s own loopback. Then
>> install 0/0 under this LSP then their will be a 0/0 entry in inet.3
>> which will resolve all next-hops for the PE routes in the Global vpn
>> table. Of course this will not actually forward traffic. The sole
>> purpose of this 0/0 is to resolve routes and subsequently allow the
>> RR to advertise the routes to other clients that are now active.
>> I hope this clears things UP...
>> Gary Hauser
>> JNCIE #12, CCIE # 4489
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp