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. 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.
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
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.
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.
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...)
"PE default based on CE signals" - interesting concept. Would need some serious EEM hacking to make it work; probably not worth it.
#2 - You don't need TE. Carrier's Carrier architecture would work just fine.
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>
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
;)
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 ?
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