VPN problem with Router reflector

Hi there
I am doing VPN lab with RR. R4, R6 and R7 are PEs and R5 is the RR. The strange thing is all PEs are sending VPN routes to R5, with the next-hop of self. But on R5, all these routes become hidden, even if R5 could reach these next-hops.
Does there any one know the reason? Thanks.

Find more posts tagged with

Comments

hoogen82

Create LSP's from P - PE or have a default route in inet.3 table set to discard to enable R5 to look into its mpls tables.

yren

hoogen82 wrote: »

Create LSP's from P - PE or have a default route in inet.3 table set to discard to enable R5 to look into its mpls tables.

Thank it works. This is something different if using rsvp, instead of ldp as the signaling protocol in the core.

Aldur

yren wrote: »

Thank it works. This is something different if using rsvp, instead of ldp as the signaling protocol in the core.

Basically what happens is that to make vpn routes resolvable the BGP protocol next hop for the route must be resolvable in the inet.3 table.

This normally isn't a problem if you don't have a RR involved. BGP peering is happening from PE to PE router, the RSVP LSPs are created on both PE routers pointing at each other. And so the BGP protocol next hop is going to be resolvable in the inet.3 table simple because of the LSPs that you've created.

Now if you throw an RR in there the same requirement holds true, to make these vpn route resolvable and thus advertisable, the BGP protocol next hop for these routes must be resolvable in the inet.3 table. Since there are no ingress RSVP LSPs on the RR this can cause a problem since by default there won't be anything in the inet.3 table.

The reason why this works by default if LDP is turned on in the core vs RSVP is because by turning on LDP you are effectively making every router an ingress and an egress LSP, filling your RR's inet.3 table with all the PE loopbacks, thus making all of the vpn routes from the PEs resolvable.

yren

Thank you so much, Aldur!