Last year, I researched, created and presented training on 6VPE technology for our internal consultants. Passing IPv6 routes and traffic over an IPv4-only MPLS network is a problem. 6VPE solves that problem from a carrier perspective allowing the MPLS carrier to provide dual-stack IPv4 and IPv6 at the LAN side interface of the customer edge devices.
But what if your MPLS provider has not rolled out IPv6 support?
I knew you could use tunnels to solve this problem from a client perspective. Further, configuring static tunnels in a full mesh over MPLS would be an awful management burden so automatic 6to4 tunnels could address that. However, I never pursued it further.
Recently, a question about this came up again and forced me to reconsider. Some research yielded Dynamic Routing Over 6to4 Automatic Tunnels which describes how to enable dynamic routing over 6to4 tunnels using BGP - specifically external BGP (eBGP). However, the article doesn't consider an MPLS backbone. I did some testing and it turns out it's not that hard to adapt this concept to an IPv4-only MPLS backbone.
Assume the following scenario:
- MPLS provider offers IPv4-only MPLS VPN access for customers
- Customer A wants IPv6 access
- Customer A has many remote sites so solution must be scalable
Since Customer A wants IPv6 access and the provider doesn’t offer it, the first step is for Customer A to configure tunnel endpoints on each of the remote sites. Static tunnels such as 6in4 will require n(n - 1) tunnel endpoints – essentially an n^2 problem or management burden. Each new site almost exponentially increases the management burden.
The solution is to configure 6to4 tunnel endpoints on each remote site. 6to4 tunnels are dynamic so only a single tunnel endpoint is needed per remote site. Adding a new site now only adds 1 new tunnel interface – a linear increase.
To enable dynamic routing, the customer edge routers already use BGP to connect to the MPLS backbone. We can use the existing BGP configuration to enable internal (iBGP) sessions between the 6to4 addresses and advertise the IPv6 networks.
To begin, let's configure the 6to4 endpoints on each remote site:
ACE1
interface Tunnel2002 ipv6 address 2002:a01:102::/128 tunnel source Serial1/0 tunnel mode ipv6ip 6to4 ipv6 unicast-routing ipv6 route 2002::/16 Tunnel2002
ACE2
interface Tunnel2002 ipv6 address 2002:a01:106::/128 tunnel source Serial1/0 tunnel mode ipv6ip 6to4 ipv6 unicast-routing ipv6 route 2002::/16 Tunnel2002
ACE3
interface Tunnel2002 ipv6 address 2002:a01:10a::/128 tunnel source Serial1/0 tunnel mode ipv6ip 6to4 ipv6 unicast-routing ipv6 route 2002::/16 Tunnel2002
At this point, the sites have reachability to the newly configured 6to4 addresses but not the IPv6 addresses on the LAN of each remote site. To enable reachability to those networks we need to enable routing.
The easiest way is to add some static routes pointing to the remote 6to4 address for the remote sites' IPv6 networks. For example, on ACE1, the static IPv6 routes to add for the four (4) IPv6 networks on ACE2 and the four (4) IPv6 networks on ACE3 are:
ipv6 route 2001:DB8:A64:6800::/54 2002:A01:106:: ipv6 route 2001:DB8:A64:6C00::/54 2002:A01:10A::
Of course, with static routing we've simply shifted the n^2 problem of tunnel endpoint management to static route management, which could actually be much worse if routes are not hierarchical like the /54 summaries above. Imagine managing several static routes per site on each remote router.
The best solution is dynamic routing and as the previous linked article described, an internal gateway routing protocol will not work as the 6to4 addresses are not on the same subnet. BGP solves this with explicit peering definitions and since the edge routers are already running BGP to the MPLS provider, we can use that configuration.
BGP peers will be configured to the 6to4 addresses so BGP routing traffic will be passed as over the 6to4 tunnels the same way data traffic is passed. We use iBGP since the customer edge routers are all in the same BGP Autonomous System. Finally, we offloaded the configuration burden of an iBGP full mesh by configuring ACE1 as a route reflector ACE2 and ACE3 as route reflector clients.
ACE1
router bgp 65100 neighbor 2002:A01:106:: remote-as 65100 neighbor 2002:A01:10A:: remote-as 65100 address-family ipv6 neighbor 2002:A01:106:: activate neighbor 2002:A01:106:: route-reflector-client neighbor 2002:A01:10A:: activate neighbor 2002:A01:10A:: route-reflector-client network 2001:DB8:A64:6400::/64 network 2001:DB8:A64:6500::/64 network 2001:DB8:A64:6600::/64 network 2001:DB8:A64:6700::/64
ACE2
router bgp 65100 neighbor 2002:A01:102:: remote-as 65100 address-family ipv6 neighbor 2002:A01:102:: activate network 2001:DB8:A64:6800::/64 network 2001:DB8:A64:6900::/64 network 2001:DB8:A64:6A00::/64 network 2001:DB8:A64:6B00::/64
ACE3
router bgp 65100 neighbor 2002:A01:102:: remote-as 65100 address-family ipv6 neighbor 2002:A01:102:: activate network 2001:DB8:A64:6C00::/64 network 2001:DB8:A64:6D00::/64 network 2001:DB8:A64:6E00::/64 network 2001:DB8:A64:6F00::/64
Note that we've made no changes to the PE router - meaning the MPLS provider does not need to support IPv6 at all for this configuration to work. You will need to make sure the provider doesn't do any exotic filtering at the edge or in the MPLS backbone such as blocking IP protocol 41 (IPv6 in IPv4 encapsulation).
At this point, we can test the configuration with some BGP show commands and pings to test connectivity. Without the benefit of a live demo here, rest assured these commands produced the provided output:
ACE1#show bgp ipv6 unicast
BGP table version is 17, local router ID is 10.100.103.1
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:A64:6400::/64
:: 0 32768 i
[...]
*>i2001:DB8:A64:6800::/64
2002:A01:106:: 0 100 0 i
*>i2001:DB8:A64:6900::/64
2002:A01:106:: 0 100 0 i
[...]
*>i2001:DB8:A64:6C00::/64
2002:A01:10A:: 0 100 0 i
*>i2001:DB8:A64:6D00::/64
2002:A01:10A:: 0 100 0 i
ACE1#ping ipv6 2001:db8:a64:6800::1 source 2001:db8:a64:6400::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:A64:6800::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:A64:6400::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 148/205/276 ms
ACE1#ping ipv6 2001:db8:a64:6c00::1 source 2001:db8:a64:6400::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:A64:6C00::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:A64:6400::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/167/204 ms
And there you have it! Dynamic routing of IPv6 over an IPv4-only MPLS network without the MPLS provider supporting IPv6.
Posts
No comments :
Post a Comment