Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

IPv6 in IPv4/MPLS in a Nutshell


Published on

All what you need know to tackle IPv6 over IPv4/MPLS: 6PE and 6VPE on CISCO Routers.

All what you need know to tackle IPv6 over IPv4/MPLS: 6PE and 6VPE on CISCO Routers.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. IPv6 Over MPLS on CISCO Routers 1. Introduction When MPLS convinced most Service Providers to switch to MPLS because of services like MPLS-VPN, IPv6 was just a little baby protocol. No sane Service Providers would have build its backbone with IPv6. But beginning of Y2K, IPv6 was requested mostly in Asia and it would have been impossible to say to a SP who just build and debug its IPv4/MPLS Backbone to switch or build a new IPv6 Backbone. So CISCO decided to develop 6PE. To provide an IPv6 Service to MPLS/IPv4 Backbone customer. At CISCO it was quite funny because MPLS people did not want to allocate resource on 6PE as IPv6 was considered a very LOW priority project and IPv6 people did not want neither because MPLS was evil for them and solution was to build an IPv6 Backbone period. So a small team was hired around a former IBMer designer who leaved IBM with a colleague. Problem, they had absolutely NO experience in MPLS and also they were needing a guy to do the dev-test of this new feature for them. A few bugs on MPLS had generated multiple huge crysis and this time CISCO wanted to over-test any IPv6 over MPLS solution before releasing any feature and this is when I joined the team. I was writing the test plan, the test scripts automation and was troubleshooting problems when I was finding something. I wrote about a dozen of scripts to test features, performances and other things and each time I was doing it for IPv6, I was also doing it for IPv4 to show that behavior was consistent. I worked mostly dedicated on 6PE and 6VPE for about 4 years until the CISCO USA MPLS team realized that there was good business and a lot of interest for these two features. Then it was decided that US MPLS Team should overtake it and I traveled to Boston area and transfer my knowledge of the scripts I designed. I cannot help thinking that the USA guy I worked with did the same with Bangalore one day! 2. 6PE There was already 2 scripts to do the functional testing of 6PE when I took it over. 6PE was designed by people in France. François le Faucheur designed the Architecture. François is one of the best Architect of CISCO and is the author of many RFCs about QoS on
  • 2. MPLS-TE and a lot more. 6PE was very similar to MPLS-VPN but the VPN routes were IPv6 routes and there was no VRF concepts. IPv6 routes were going into the Global Routing Table. In the first 6PE IOS version the egress 6PE was advertising an Aggregate label in a 16 labels pool for any IPv6 destination. When a packet arrives in a router with this label, it tells the router to remove the MPLS label and to call CEF, the IPv4 or IPv6 Forwarding plane to take the routing decision. This was a double look-up which was no good for performances but had accelerated the time to market. And 16 labels were advertise instead of only one to enable load-balancing on the P routers. Problem is that some CISCO distributed hardware platforms did not support this behavior and CISCO had to review its code to allocate a label per destination. The featurette was called Fast 6PE! Then 6PE assigned a label for each IPv6 route which must be reached by remote nodes. This label is assigned by MP-BGP and get into the CEFv6, the CISCO forwarding data plane, forwarding entry. With CISCO MPLS, MPLS-VPN, 6PE or 6VPE, label imposition is done by CEF. CEF will not be involved any further as the LFIB will be responsible for switching the packet until the egress 6PE which switch the packet using the label that it has allocated from MP-BGP and announced to remote 6PEs, most of the time via a Route Reflector. So when the ingress 6PE imposes the labels to the IPv6 packet, the interior label is allocated from the MP-BGP Label information.
  • 3. The external label is imposed by LDP and the Internal Routing Protocol together. The other option was to modify the Routing Protocol to distribute the label. This option had much better performances and not the drawbacks of LDP but considering that too much protocols would have to be changed if MPLS was really Multiprotocol, the M of MPLS they decided to have a separate protocol for label distribution. This was TDP which became LDP. LDP could have been used to distribute the interior label too. Now that it is clear that MPLS will never be Multiprotocol and that the two routing protocols to change are OSPF and ISIS, the option to distribute labels with Routing Protocol is coming back as it would give superior performances and better convergence in some scenario where Routing Protocols converge much faster than LDP and that user traffic is black holed during this time. You need to have an IPv4 MPLS backbone with LDP. RSVP can be used instead if you decide to use PE to PE MPLS-TE which is not really scalable if you have a lot of PEs. There are many options combining LDP and MPLS-TE with RSVP but I will not get into this here as I want to keep it simple. 6PE configuration on CISCO routers is very straightforward. You just need to configure an IPv6 IPv6 address-family in the BGP section with the /32 IPv4 loopback address of your Route Reflector configured as a neighbor or the other 6PE in a lab with only 2 6PEs. Then you need to add the command “neighbor X.X.X.X send­label” and your 6PE is configured. Minimum back to back routers 6PE relevant Configuration: Router A ip cef mpls ip int lo0   description used for BGP peering. MUST be a /32   ip address int Fa0/0   ip address   mpls ip int fa0/1   ipv6 address 2001:db8:100:111::1/64 router ospf 1   network area 0 router bgp 100
  • 4.   neighbor remote­as 100   neighbor update­source lo0   address­family ipv6     neighbor activate     neighbor send­label Router B ip cef mpls ip int lo0   description used for BGP peering. MUST be a /32   ip address int Fa0/0   ip addresss   mpls ip int fa0/1   ipv6 address 2001:db8:100:112::1/64 router ospf 1   network area 0 router bgp 100   neighbor remote­as 100   neighbor update­source lo0   address­family ipv6     neighbor activate     neighbor send­label 3. 6VPE The concept of VPN exists in IPv6 with the Scoped Address Architecture that we use for IPv6 Link-Local and Multicast addresses. The Admin scope used in multicast is very similar to the concept of a VRF as you can define random scopes where each one will have its own Routing table and Forwarding Information base. Also in IPv6 we already have 40 bits to keep private addresses unique with the capability to
  • 5. record them in a central database to make sure your local address unique address. So there is no risk of overlapping if one day you merge your IPv6 network with somebody else. Adding another 64 bits in the MP-BGP table for the RD to make a vpnv6 address-family unique does not help anything for IPv6! But 6VPE idea was to add IPv6 in the VRF to have consistent dual-stacked VRFs and was requested by customers. Scoped Address architecture infrastructure was customized for an IPv6 VRF to be actually a Scoped zone for IPv6. You can see this with the VRF route next-hop sitting in another zone, the Global Routing table. It has the % sign which in IPv6 indicates a zone in an address. For instance fe80::948:f087:2561:def0%Ethernet0 where Ethernet0 is the zone name given to this link-local address. Microsoft Windows uses numbers to identify zones. MPLS was supposed to be multiprotocol but even the CISCO CLI to define VRF was really designed for IPv4, the command was “ip vrf <VRF name>” . There was no room to configure anything else but IPv4 in the VRF. So a new command was introduced. This was “vrf 
  • 6. definition <VRF Name>”. For instance, this is a dual stacked VRF. All the VRF will have the same RD, 10:11 while each address-family will have its own RT policy. Here ipv6 address family import a RT, 170:200 which may be imported by all the IPv6 VRF as it may contain shared resources. vrf definition acme rd 10:11 address­family ipv4   route­target both 100:1 address­family ipv6   route­target export 100:1   route­target import 100:1   route­target import 170:200 You need to place a command to configure that an interface is in a VRF: “vrf forwarding  <vrf­name>” Then the other commands still apply to MP-BGP which have to advertise IPv6 VRF Routes with a Route Descriptor (RD) and Route-Targets (RT) Extended Community Attributes configured for Export. Despite the IPv6 very long address, the Route Distinguisher (RD) is still needed as there is only one BGP table and 6VPE gives each customer the illusion to have its own dedicated network and can apply any addressing plan even the most stupids! MPLS-VPN was great for IPv4 as most customers were using the same private RFC1918 Addresses but in IPv6 the private addresses have 40 bits to make them unique and can be centrally managed. So MPLS-VPN is only there to provide a consistent dual-stack environment for customers testing. Example of lab 6VPE related configuration basic commands. For the sake of simplicity in this configuration the two CEs from the same VRF have different AS numbers but it is possible with additional configuration to keep the same AS number for all the sites of the same VRF. The egress 6VPE will replace the original AS number with twice the backbone number so the CE will accept the BGP update. Otherwise if a BGP CE which receives a BGP update with its own AS in it BGP would reject it as a routing loop prevention mechanism. 6VPE1 vrf definition acme rd 10:11
  • 7. address­family ipv6   route­target export 100:1   route­target import 100:1 ! int lo0    ip address int fa0/0   vrf forwarding acme   ipv6 address 2001:db8:100:100::1/64 int Gig0/0   mpls ip   ip address ! router ospf 1   network ! router bgp 100   neighbor remote­as 100   neighbor update­source lo0   address­family vpnv6     neighbor activate     neighbor send­label      address­family ipv6 vrf acme     neighbor 2001:db8:100:100:2 remote­as 68747     neighbor 2001:db8:100:100:2 activate     redistribute connected 6VPE2 vrf definition acme rd 11:11 ! address­family ipv6   route­target export 100:1   route­target import 100:1 !
  • 8. int lo0    ip address int fa0/0   vrf forwarding acme   ipv6 address 2001:db8:100:101::1/64 int Gig0/0   mpls ip   ip address ! router ospf 1   network ! router bgp 100   neighbor remote­as 100   neighbor update­source lo0   address­family vpnv6     neighbor activate     neighbor send­label      address­family ipv6 vrf acme     neighbor 2001:db8:100:101:2 remote­as 68748     neighbor 2001:db8:100:101:2 activate     redistribute connected CE1 int lo0    ip address 2001:db8:100:115::1/128 int fa0/0   ipv6 address 2001:db8:100:100::2/64   ipv6 router rip fred enable ! router bgp 68747   neighbor 2001:db8:100:100:1 remote­as 100   address­family ipv6     neighbor 2001:db8:100:100:1 activate     redistribute connected