Route Reflector is mandatory to participate in LDP?

[lucho-Networking2021]

Hi everybody how are you? Hope fine. I'm learning a little bit of MPLS,BGP and route reflection with GNS3 and some Cisco IOS. I'm using c7200-adventerprisek9-mz.153-3.XB12.bin for MPLS routers and for CE routers I have c3640-is-mz.124-16.bin

Thing is that I thought I had to configure the route reflector to participate in LDP for it to reflect the routes to its clients but seems I do not need that. I thought he had to knew the topology to reflect the routes. I tried with the router participating in LDP and without participation and both options work fine. PEs keep receiving routes from vpnv4 clients. Can anybody tell me why? or give me an article to read may be? Anything would help me to dig a little bit further.

The Topology file has the diagram and route reflector is Router 8 (R8).

Thanks in advance.

Best Regards,

Luis

[Giuseppe Larosa]

Hello Luis,

in Cisco implementation the route reflector server does not need to be part of the MPLS cloud, because its work is to reflect  i MP BGP  NLRI like vpnv4 routes that are advertised over BGP sessions that in their turn are running over TCP sessions.

In other vendors like Juniper the route reflector server performs a check to verifiy the MPLS paths but Cisco RR server does not perform this check.

Your simulations just confirm this. your understanding is correct.

Hope to help

Giuseppe

[alexals]

Just to share...

I had similar experience with Route-Reflector on MPLS cloud as well. At first thought it should be part of the MPLS cloud but not until I enable mpls ldp sync option under OSPF configuration. It doesn't work and no route exchanges took place. It back to normal after I remove the option and disable mpls ip under the interface facing MPLS cloud.

Alex

[Adam Vitkovsky · Accepted solution]

Hi,

With BGP route-reflection it is crucial to grasp the difference between Control-Plane and Data-Plane(also called Forwarding-Plane).

In most MPLS backbones RRs(route-reflectors) are not part of the Forwarding-Plane.
-that means there’s no data traffic being forwarded through the RRs.
-in this case RRs are dedicated boxes that are used solely to rely prefixes (Control-Plane information) between BGP speakers.
-in order to form BGP (TCP) session with other BGP speakers they need to have IP connectivity to them, so usually RRs are participating in IGP with the rest of the Autonomous System(AS) –though a simple default static route would do the trick as well.
-so RRs only need to run BGP and need to have IP connectivity to other BGP speakers (via IGP) and the only data that are passed through their links are few kbps of BGP updates
-as you can see RRs don’t need to be fast in forwarding of many packets per second,
-however RRs need to have a lot of RAM memory to hold all BGP routes from all BGP speakers
-and also they need powerful CPU to be able to process and relay loads of BGP update messages to/from many peers
-that’s why recently routers dedicated as RRs are being replaced with servers (exchanging fast packet processing found in routers for faster CPU and more RAM found in servers).

For RRs for MPLS VPNs there are few tricks that need to be in place though.

1) Default route-target filtering –this rule says that if you don’t have VRF with a specific import RT then you should not keep the route in your MP-BGP table (to save RAM memory on PE routers cause they only need to keep routes they are interested in).
But RRs which are not part of Data-Plane (i.e. PE acting also as RR) don’t have any VRFs –yet they have to keep all the VPN routes to be able to reflect them.
That is why on RRs this check is disabled automatically.

2) (Junos specific) BGP next-hop resolution in inet.3 table (where the next-hop for a route has also MPLS label associated with it) –if your RR is not running LDP it will not have this table and you need to manualy instruct BGP to use the standard global routing table to validate BGP next-hops with cmd:
set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0

adam