Changing VPNv4 route attributes within the MPLS/VPN network

John (not a real name for obvious reasons) sent me an interesting challenge after attending my Enterprise MPLS/VPN Deployment webinar (register here). He’s designed an MPLS/VPN network approximated by the following diagram:

The two data centers are advertising the default route into the MPLS/VPN network and he’d like some PE-routers to prefer Data Center 1, while the others should prefer Data Center 2 (and all PE-routers have to receive both default routes for redundancy reasons).

He was already aware of the need for two different Route Distinguishers (due to a VPNv4 route reflector sitting somewhere in the MPLS/VPN network) but couldn’t get the top-side PE-routers to prefer one default route over the other.

After considering all sorts of crazy ideas, I’ve settled on what seems to be the simplest solution: modify inbound VPNv4 BGP updates on the top-side PE-routers. I was almost positive it should work (after all, a VPNv4 update is a BGP update like any other), but wondered whether John would need to attach standard BGP communities to the default routes or whether he could use extended BGP communities (route targets) already attached to them.

Years ago, route map support for extended BGP communities was dismal, but obviously IOS got fixed in the meantime – it was quite easy to match on route targets attached to incoming VPNv4 BGP updates and use them to modify local preference (or MED or BGP weight, whichever happens to be your personal favorite). Here’s the configuration taken from a top-side PE-router (I’m always using BGP templates; if you don’t like them, just apply the options directly to the BGP neighbors).

router bgp 65000
 template peer-policy MPLSVPN
  route-map ChoosePreferredVPNv4Routes in
  send-community both
 exit-peer-policy
 !
 template peer-session MPLSVPN
  remote-as 65000
  update-source Loopback0
 exit-peer-session
 !
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.1.3 inherit peer-session MPLSVPN
 neighbor 10.0.1.4 inherit peer-session MPLSVPN
 !
 address-family vpnv4
  neighbor 10.0.1.3 activate
  neighbor 10.0.1.3 send-community extended
  neighbor 10.0.1.3 inherit peer-policy MPLSVPN
  neighbor 10.0.1.4 activate
  neighbor 10.0.1.4 send-community extended
  neighbor 10.0.1.4 inherit peer-policy MPLSVPN
!
ip extcommunity-list standard PreferredRT permit rt 65000:123
!
route-map ChoosePreferredVPNv4Routes permit 10
 match extcommunity PreferredRT
 set local-preference 200
!
route-map ChoosePreferredVPNv4Routes permit 20

After deploying the route map on all the PE-routers (and changing the route target matched in the PreferredRT extended community list on half of them), John has to add a single route target to the VRFs defined on the Data Center PE-router to make routes sent through that PE-router more preferred than the others.

13 comments:

  1. Renan Nepomuceno10 February, 2011 14:29

    Hi Ivan,

    Why not use using Soo from from the two Datacenter PE which will be advertise into the MPLS cloud and then using an import map on the receiving PE. From the receiving PE an import map statement must be configured to prefer which Soo will be chosen while leaving the one as a backup default route

    ReplyDelete
  2. You can also run those communities through a regex and create a single uniform routing policy for all route on all routers. The same applies to standard communities in any BGP implementation. For example: deterministic routing in multicarrier L3VPN where you're the CE.

    In the above, you could just as easily have the network "customers" stamp standard communities on the DC CE routers and let them deterministically route their own traffic without having to bother the MPLS operators.

    ReplyDelete
  3. SOO would also work, in fact I'm assuming the SOO is already being set to avoid routing loops on the data center sites. On the other hand, every prefix has a RT (route-target) so it's an easy win.

    One interesting challenge would be to control the PE choice of which default to follow based on announces of the CEs attached to the PE. But this is tricky and would not work in all cases.

    ReplyDelete
  4. Even if the CE stamps the default using different communities you would need to add configuration to the PEs to prefer on default over the other. Or am I missing something.

    Probably the easiest way to achieve independence from the PEs would be to set up your own (customer) mesh of LSPs using the carrier's underlying MPLS network and avoid the PE's decision. Something like RSVP-TE over L3VPN over MPLS. I never tried anything like that so it's just a thought (just made a quick search on google and looks like someone is already proposing this over IETF...)

    ReplyDelete
  5. Whatever attribute attached to the VPNv4 BGP route would work as long as it's recognizable by the route maps use for inbound BGP filters on the PE-router.

    "PE default based on CE signals" - interesting concept. Would need some serious EEM hacking to make it work; probably not worth it.

    ReplyDelete
  6. #1 - You're absolutely correct. The IP forwarding decision is made by the PE-router - as soon as the CE sends an IP packet to the PE, it has no influence on its forwarding any more. The default route selection must be made by the PE-router.

    #2 - You don't need TE. Carrier's Carrier architecture would work just fine.

    ReplyDelete
  7. I have a "similar" scenario, but do not have control of the configs on the PE... I have default route originating in multiple places, I want to control which one is preferred and choose one of the others as a secondary. I am trying to "steer" it with as-path depth but it seems that only one default route will be taken in regardless of length. This does not seem to be the same behavior displayed by other "non default" routes. Can't believe I'm the only one doing this, there must be a guide somewhere to help me fix this?

    ReplyDelete
  8. Never mind... I think I found my answer. I need the provider to reconfigure the PE's as you explain above, no other way that I can see. Hopefully AT&T will play nice. :-D

    ReplyDelete
  9. Could you show how you set could and would recommend setting the additional route target extcommunity on the datacenter PE routers?

    for example: Is this being done on the data center PEs by:
    - route-map of some kind?
    - just adding an additional export <additional:rt_value> which is then matched in route-map on the PE routers which the remote offices are attached to?


    In a similar problem, suppose you have not preferred, but conflicted routes such that in one acquisition integration, 192.168.1.0/24 is used for service A in Region A, while in a different, since integrated, acquisition company, 192.168.1.0/24 is used for service B in Region B. Suppose there is not alot of appetite for solutions to resolve using re-IP, and suppose you must make the routes for things in Region A which conflict with Region B available in their respective regions, but not in other...

    It seems like adding a RT value to the exported routes could be used as a marker (tag, community) to then be used in a route-map in the other regions to mark the know conflicted routes and prevent their import in the other regions where the conflict occurs...

    What do you think?

    Sam </additional:rt_value>

    ReplyDelete
  10. You can either use an additional export RT or an export-map. You'll find more details in my "MPLS and VPN Architectures" book. As for specific design problems, I'm always available for consulting engagements, as is our Professional Services team.

    ReplyDelete
  11. Hi Jeffrey,

    Correct. The only way for you to be able to select which default route will be accepted is through the SP (in your case AT&T). Typically you can just ask you're account team with AT&T that this kind of scenario is what you would like to happen. I often dealt this often with AT&T
    ;)

    ReplyDelete
  12. Hi All,

    Please can anyone explain to me regarding the common service : when do we use Fusion router/Firewall and when can we use a shared VRF ?

    I have seen some design when there is a common service like Datacenter or Internet and there was a Fusion Firewall (with ebgp) ? I would say that it's easiest to use a common export/import VRF ?

    ReplyDelete
    Replies
    1. As usual: it depends.

      Common Services VPN doesn't allow users of the common services to see each other. For more details on various MPLS/VPN customer topologies, check out my MPLS/VPN books.

      I'm also available for short online consulting sessions if you need help with your specific design challenge.

      http://www.ipspace.net/ExpertExpress

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.