Routing

Hello all,

I have set up a lab to learn more about RSVP with regards to a topology like below:

Client_1 <-> CE-R1 <-> PE-R1 <-> MPLS CORE <-> PE-R2 <-> CE-R2 <-> Client_2

On each CE and PE there is a single VRF routing instance and I have eBGP between the CE and PE's and iBGP connection between the two PE's.  When I have LDP enabled, everything works, the PE's see the others routes and traffic flows from Client_1 to Client_2 in the VRF.  OSPF sees all the routes inside the MPLS core as well as each routers loopbacks.

So I remove LDP and enable RSVP on the interfaces.  I create an LSP from PE-R1 with an ERO to PE-R2 and see via show mpls lsp extensive that the LSP is up and things are great.  However, you run show route table instance_name hidden extensive and you will see hidden routes from its iBGP peer and the reason is that it using the PE's loopback as the next hop inside the routing instance.

What is RSVP doing when it changes the routing instances next-hop address for a route to the loopback address of the PE router which is in the MPLS core via OSPF?  I can elaborate with configs, etc.  if anyone requests but its weird that LDP works but RSVP doesn't. 

Obviously I am still learning RSVP so I could have missed something.

Thanks,

Troy

Just as a follow up, I found a page that suggest that I add the following to my config:

set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0

With this command on both PE's, I can now see the routes (no longer hidden) but I do not think that is a viable solution.  Correct me if I am wrong, but all this is doing is telling the bgp.l3vpn.0 table to resolve addresses in via the inet.0 table.  This is all fine and dandy but the next-hop address is still pointing to the loopback address on the PE's which belong to the MPLS OSPF area and not the VRF routing instance.

Troy

Hello,

Do you have a router-id explicitly set in the config?

set routing-options router-id X.Y.Z.W

For L3VPN to work properly, the router-id must be equal to the primary IP on lo0.0 interface, which is in turn used as MP-BGP route next-hop.

And lo0.0 must be included into Your IGP (OSPF) but I am sure You have it since You've got L3VPN with LDP working.

This bit 

set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0

 is good for VPNv4 Route reflectors only.

And please post the following printout:

show route table bgp.l3vpn.0 extensive | no-more

HTH

 Thanks

Alex

Alex,

Yes, router-id is configured on all MPLS routers as well as the lo0.0 is advertised into OSPF.  Here is the output you requested:

bgp.l3vpn.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

65000:1:192.168.1.4/30 (1 entry, 0 announced)

                        *BGP            Preference: 170/-101

                                                Route Distinguisher: 65000:1

                                                Next hop type: Unusable

                                                Next-hop reference count 2

                                                State: <Hidden Int Ext>

                                                Local AS: 65000 Peer AS: 65000

                                                Age: 3:33:43

                                                Task: BGP_65000.6.6.6.6+52577

                                                AS path: I

                                                Communities: target:1:1

                                                Import Accepted

                                                VPN Label: 16

                                                Localpref: 100              

                                                Router ID: 6.6.6.6

                                                Secondary Tables: idcoxg.inet.0

                                                Indirect next hops: 1

                                                                        Protocol next hop: 6.6.6.6

                                                                        Push 16

                                                                        Indirect next hop: 0 -

Alex,

After reading http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-10850937.html and learning more about the bgp.l3vpn.0 table, I figured out the problem but I am having to digest it to figure it out.  Since I am using RSVP, I created a label-switched-path with a primary MPLS path form PE-R1 to PE-R2 using strict hops.  The LSP was up because I was using valid MPLS hops.  However, I was using the MPLS next-hop address for my to and from statements instead of the PE loopback interfaces.  Because of this, the bgp.l3vpn.0 was showing the next hop as unusable. 

After altering my LSP to and from statements to the loopback addresses, the bgp.l3vpn.0 correctly saw the next hop and placed the route into the appropriate routing instance based on the community ID.  But then the issue is that, although I can see the routes in the appropriate VRF tables, I was unable to ping the addresses.  I had to add another label-switched-path on the remote PE back to the PE where I am originating the ping before it would work again.

I guess I have more to learn for RSVP!

Thanks for taking the time to help!

---

@Cousintroy wrote:

 But then the issue is that, although I can see the routes in the appropriate VRF tables, I was unable to ping the addresses.  I had to add another label-switched-path on the remote PE back to the PE where I am originating the ping before it would work again.

 

 

 

---

Hi,

The RSVP LSP are unidirectional by default. To receive ICMP Echo Reply back, there must be another RSVP LSP in the return direction.

HTH

Thanks

Alex

Alex,

I does!  As I said before, still need nail down some of the basics of RSVP but I am glad that I was finally able to sit back, research what the various components were telling me and come up with a solution.  You just gave me the final explanation.  Again, thanks.

Troy