Hello everyone,
In this document, I am going to represent how Route Target Constraint (RTC) can highly reduce the number of routes advertised by route reflector to route reflector clients in MPLS VPN environment. The configuration is very simple but the result is very effective.
Prerequisite: basic MPLS VPN configuration.
By default, route reflectors advertise all routes to the route reflector clients even though clients do not have the corresponding VRFs. By applying Route Traget Constraint, RRs only send wanted routes to the clients. Wanted means that clients have corresponding VRFs so they can install the routes in the routing table. RTC is a capability in BGP. When BGP comes up, a client sends its route-target information to RRs so route-reflectors know which routes they need to advertise to the clients. I am using the following topology for my presentation.
As you see in the topology, R3 has VRFs red and green but R3 has only VRF red. The following picture shows VRF configuration on R1.
VRF configuration on R3. R3 has been configured with only VRF red.
If we check the routes advertised by route reflector(R2) to R3 which is a route reflector client, we see that R2 is advertising 172.16.31.0/24 to R3. 172.16.31.0/24 is in VRF green and R3 has not been configured with VRF green. For R3, 172.16.31.0/24 is an unwanted route.
R3 receives 172.16.31.0/24 and denies it because it does not have the corresponding VRF to import it. (it does not have Route-target import equal to the route target of the route it receives)
As you see in the picture, route target of 172.16.31.0/24 is 200:200. Because R3 does not have route target import 200:200, it denies the route. In some IOS clients even do do not deny the routes. They keep the routes in the BGP table because denying these routes in the RFC is optional.
Now we apply RTC to R2 and R3. The configuration is simple. We need to copy whatever under the address family VPNv4 below address family Rtfilter.
Default originate is automatically generated on R2. It is different from default originate in IGPs. on RRs, It just means that Route reflector clients need to send all the routes to me(RR) and I will select which routes needs to be advertised to clients based on the Route Target information I receive.
The configuration on route reflector clients is the same. In our case R3.
After RTC configuration, R2 does not send unwanted route to R3 as you see in the following picture. We do not see 172.16.31.0/24 in the advertisement anymore.
R2 still has 172.16.31.0/24 in its BGP table.
As you noticed, the configuration is very simple; however, it can highly reduce the size of BGP table in RR clients and the number of advertisements in a large MPLS environment. Just make sure your IOS support RTC before applying this feature.
I hope this document is helpful for you and wish you the best.