Introduction

In any decent sized service provider or even an enterprise network running
MPLS VPN, it will most likely be using Route Reflectors (RR). As described in
a previous post iBGP fully meshed does not really scale. By default all
PEs will receive all routes reflected by the RR even if the PE does not
have a VRF configured with an import matching the route. To mitigate this
ineffecient behavior Route Target Constraint (RTC) can be configured. This
is defined in RFC 4684.

Route Target Constraint

The way this feature works is that the PE will advertise to the RR which RTs
it intends to import. The RR will then implement an outbound filter only sending
routes matching those RTs to the PE. This is much more effecient than the default
behavior. Obviously the RR still needs to receive all the routes so no filtering
is done towards the RR. To enable this feature a new Sub Address Family (SAFI) is
used called rtfilter. To show this feature we will implement the following topology.

RTC

The scenario here is that PE1 is located in a large PoP where there are already plenty
of customers. It currently has 255 customers. PE2 is located in a new PoP and so far only
one customer is connected there. It’s unneccessary for the RR to send all routes to PE2
for all of PE1 customers because it does not need them. To simulate the customers I wrote
a simple bash script to create the VRFs for me in PE1.

PE2 will not import these due to that the RT is not matching any import statements in
its only VRF that is currently configured. If we debug BGP we can see lots of messages
like:

In this case we have 255 routes but what if it was 1 million routes? That would be
a big waste of both processing power and bandwidth, not to mention that the RR would
have to format all the BGP updates. These are the benefits of enabling RTC:

  • Eliminating waste of processing power on PE and RR and waste of bandwidth
  • Less VPNv4 formatted Updates
  • BGP convergence time is reduced

Currently the RR is advertising 257 prefixes to PE2.

Implementation

Implementing RTC is simple. It has to be supported on both the RR and the PE though.
Add the following commands under BGP:

RR:

PE2:

The BGP session will be torn down when doing this! Now to see how many routes the RR is
sending.

No prefixes! To see the rt filter in effect use this command:

Now we add an import under the VRF in PE2 and one route should be sent.

Works as expected. From the output we can see that the AS is 65000, the extended
community type is 2 and the RT that should be exported is 1:1 and 1:256.

Conclusion

Route Target Constraint is a powerful feature that will lessen the load on both your
Route Reflectors and PE devices in an MPLS VPN enabled network. It can also help
with making BGP converging faster. Support is needed on both PE and RR and the BGP
session will be torn down when enabling it so it has to be done during maintenance
time.

Scaling PEs in MPLS VPN – Route Target Constraint (RTC)
Tagged on:             

13 thoughts on “Scaling PEs in MPLS VPN – Route Target Constraint (RTC)

  • September 23, 2013 at 1:50 pm
    Permalink

    I think that you are missing a line in your script. The network statements should be under “address-family ipv4 unicast vrf $i”

    so:

    echo “router bgp 65000”
    echo “address-family ipv4 unicast vrf $i”
    echo “network 10.0.$i.0 mask 255.255.255.0”

    I know this has little relevance to the topic, but just saw this and it caught my attention…nice write up Dan!

    Pablo

    Reply
    • September 23, 2013 at 6:16 pm
      Permalink

      Thanks Pablo!

      I copied the code from before I edited it. My script had this line otherwise I wouldn’t have the routes. Editing the post now.

      Reply
  • September 23, 2013 at 8:42 pm
    Permalink

    Good jobb Dan,

    I am not sure but i think we need to have the following command on each router under rtfilter SAFI.

    “neighbor x.x.x.x send-community extended”

    Thanks

    Murad

    Reply
    • September 23, 2013 at 9:24 pm
      Permalink

      Thanks!

      It’s activated when we enter the command nei x.x.x.x activate.

      Reply
  • September 24, 2013 at 2:51 am
    Permalink

    What Version of IOS did you use for the lab? 🙂

    Reply
  • September 24, 2013 at 1:42 pm
    Permalink

    Good effort , here RT constraint is also known as RT filter as I know. And from the design point of view , ORF also could do the job but ORF is limited to directly connected neighbor.
    Thanks

    Reply
    • September 24, 2013 at 2:09 pm
      Permalink

      True,

      The issue with ORF would be that it is a static effort and needs manual configuration to keep it update.

      Reply
  • September 25, 2013 at 10:21 am
    Permalink

    Do we need MP-BGP connectivity between P1 and RR?

    Thanks

    Reply
  • September 25, 2013 at 11:05 am
    Permalink

    Murad;

    No you don’t . Idea here is to avoid BGP at all from internal nodes. BGP free core idea. But even you don’t use rtfilter address family , it is not related with this capability. Whenever you use MPLS , intermediate nodes will not see the inner packet which is encapsulated with the MPLS header. Here for transport Daniel used MPLS but you can use GRE , RSVP , l2tpv3 so on. Hopefully this helps.

    Reply
  • September 25, 2013 at 3:24 pm
    Permalink

    Oergun,

    That’s right. I think we even don’t need connection between P1 and RR altogether but i am not sure about it.

    Thanks

    Reply
  • September 25, 2013 at 4:15 pm
    Permalink

    Murad,

    For this topology short answer you would need it. Since PE1 and PE2 does not have a physical link to the RR , your only physical connection to the RR is from P router. Also in this topology since it is at centralized location , control plane updates or keepalives doesn’t have to go through sub optimal. But of course general idea with the MPLS is , you have BGP free core and label look up rather than destination based IP look up , you either don’t have to hold BGP information in the core and also intermediate router doesn’t consult to their FIB. ( They just look up to LFIB ). One thing is very important when you design RR in your topology , is it for IP or VPN ? . You generally also want to separate them to avoid fate-sharing right ?. For IP, physical topology should follow the physical topology or logical topology should follow physical topology depends on what is the business and technical requirements and constraints. Optimality or reducing the cost to follow logical topology.If you don’t follow this basic rule you most likely can create permanent loop , attention ! I am even not say micro loop.

    But with VPN RR , you don’t have to follow this rule since you are doing label look up to reach to BGP next-hop. Since here Daniel discuss MPLS-VPN , this RR is used for VPN and , if you would have P2 lets say , you would not have to connect P2 to the RR . ( I believe you would want to hear this 🙂 ).

    Orhan ERGUN

    Reply
  • September 25, 2013 at 7:44 pm
    Permalink

    Thanks Orhan,

    Good explanation! yes that’s right. I just wanted to clear some confusion.
    Thanks again.

    Murad

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: