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.