Route Reflector as forwarding plane as well on L3vpn

[Mery]

Hi,

I am testing a MPLS L3vpn  scenario with a Route Reflector in the middle to reflect vpnv4 routes between PEs. But not only reflecting the routes also to participate in forwarding plane as well. For this I forced to change the next hop to Route Reflector ip address and I see the routes in the vrf with the next hop as RR ip address but the forwarding plane doesnt work. I cant ping between CE-s in the vrf. Should be this doable? I have enabled mpls between PE to RR as well 

Im doing this so I want to concentrate everything (control and dataplane) on RR 

thanks 

Mery

[Jaderson Pessoa]

Hello

What is the structure of test that you are using? Could you share your configuration/topology to us??

[Mery]

Sure thank you. This is the configuration on RR

ip vrf blue
rd 2:2
route-target export 2:2
route-target import 2:2

router bgp 65110
neighbor 2.2.2.2 remote-as 65110
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 65110
neighbor 3.3.3.3 update-source Loopback0

address-family vpnv4

neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community both
neighbor 2.2.2.2 next-hop-self all
neighbor 2.2.2.2 route-reflector-client
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community both
neighbor 3.3.3.3 next-hop-self all
neighbor 3.3.3.3 route-reflector-client
exit-address-family
!
address-family ipv4 vrf blue
redistribute connected
exit-address-family

PE are non cisco devices and they are being configured just simple for mpls and l3vpn as PE router. On PE I see the routes in the vrf with the next hop of 1.1.1.1 thats RR, but cant ping through RR, so the path would be CE1 - PE1 - RR - PE2 - CE2

Attach is the diagram.

Thank you,

Mery

[loris.marcellini]

Is there any chance you could post a ping test to 1.1.1.1 and a show ip
route on both PEs?

[Mery]

Yes sure. Actually the BGP sessions are up so I have reachability to RR, anyway pasting here the output

PING 1.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 1.1.1.1: bytes=56 Sequence=1 ttl=63 time=11 ms
Reply from 1.1.1.1: bytes=56 Sequence=2 ttl=63 time=11 ms
Reply from 1.1.1.1: bytes=56 Sequence=3 ttl=63 time=12 ms

pe1 > display ip routing-table 1.1.1.1
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface

1.1.1.1/32 OSPF 10 2 D 10.10.10.137 GigabitEthernet0/2/1.21

pe2 > display ip routing-table 1.1.1.1
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface

1.1.1.1/32 OSPF 10 1 D 10.10.10.153 GigabitEthernet0/2/2.211

Thanks

[Harold Ritter]

This will not work, as you are breaking the end to end LSP by forcing next hop self on the RR. Why do you need to force the traffic through the RR anyhow?

Regards,

[Mery]

Cause these PE-s  have limited number of LSP. So for a topology like 200 PEs they will not support it and I thought to concentrate the traffic on RR-s(cisco routers) so at least they would have to build one LSP to RR only and not to each of PE

Thanks,

[Adam Vitkovsky]

Do not use next-hop-self on rout-reflector even if it’s in path -just leave the next hop as is -i.e. pointing at egress PE.

Treat the RR as any other P-router and just make the RR has a route and a label for the next-hop.

If your Pes can hold the routes to each other loopbacks they can hold mpls labels as well.

If you’re worried about the fib scalability then advertise just loopbacks in your igp.

adam