IPv6 - MPLS migration with 6PE

In our recent CCDE study group meeting, we covered 6PE (IPv6 Provider Edge). This method integrates IPv6 into an IPv4 MPLS network. Yet, we were unsure of its operation and use. To clarify, I set up an EVE-NG environment and ran a lab test.

The key point is that 6PE setups do not use VRFs on PE routers. Instead, they place all CEs in the global routing table. VRFs help isolate customer traffic. This setup prevents unauthorized interference. In L3VPN networks, people usually combine VRFs with MPLS and MP-BGP.

But why would you use 6PE in your MPLS network?

• Your core MPLS network is running IPv4 only, and you cannot change it that easy.

• You might not need traffic segmentation.

• You deliver internet service via global routing table to the customers

So for a better understanding, let's check the lab topology.

We have our IPv4 MPLS network, which uses OSPFv2 as underlay routing and LDP for label exchange. On top, we're running BGP between the loopback IPs of the PE routers.

P-Router config (P1 as an example)

mpls label range 10000 10999

!

interface Ethernet0/0  ip address 172.16.0.9 255.255.255.252  mpls ip ! interface Ethernet0/1  ip address 172.16.0.2 255.255.255.252  mpls ip ! interface Ethernet0/2  ip address 172.16.0.6 255.255.255.252  mpls ip ! router ospf 1  network 172.16.0.0 0.0.0.255 area 0

You can see that the P router config is pretty easy. Lets see the PE router config now.

PE-Router config (PE1 as an example)

interface Loopback0  ip address 1.1.1.1 255.255.255.255 ! interface Ethernet0/0  ip address 172.16.0.1 255.255.255.252  mpls ip ! router ospf 1  network 1.1.1.1 0.0.0.0 area 0  network 172.16.0.0 0.0.0.3 area 0

We should have reachability between the loopback IPs of the PE routers. So let's continue with our BGP configuration on the PE nodes.

PE-Router BGP config (full meshed)

router bgp 65000  bgp log-neighbor-changes  no bgp default ipv4-unicast  neighbor PE peer-group  neighbor PE remote-as 65000  neighbor PE update-source Loopback0  neighbor 2.2.2.2 peer-group PE  neighbor 3.3.3.3 peer-group PE  neighbor 4.4.4.4 peer-group PE  !  address-family ipv6   neighbor PE send-community both   neighbor PE send-label   neighbor 2.2.2.2 activate   neighbor 3.3.3.3 activate   neighbor 4.4.4.4 activate  exit-address-family

Important here is the "send-label" command in the neighbor statement. So, BGP will exchange the assigned labels for the IPv6 prefixes between the PE routers. Next, it's to create the PE-CE BGP connection. You could do any other form of routing between these two devices and redistribute into BGP. We also need to set the next-hop to the PEs' interface IP address via route-map.

PE-Router (PE1)

ipv6 unicast-routing ! route-map IPv6_NEXT-HOP permit 10  set ipv6 next-hop 2001:24:1:1::2 ! interface Ethernet0/2  no ip address  ipv6 address 2001:24:1:1::2/64 ! interface Ethernet0/3  no ip address  ipv6 address 2001:73:1:1::2/64 ! router bgp 65000  neighbor 2001:24:1:1::1 remote-as 100  !  address-family ipv6   neighbor 2001:24:1:1::1 activate   neighbor 2001:24:1:1::1 route-map IPv6_NEXT-HOP out

CE-Router (CustomerA-Site1)

ipv6 unicast-routing ! interface Loopback0  no ip address  ipv6 address 2001:24:1:2::1/64 ! interface Ethernet0/0  no ip address  ipv6 address 2001:24:1:1::1/64 ! router bgp 100  bgp router-id 10.10.10.10  bgp log-neighbor-changes  no bgp default ipv4-unicast  neighbor 2001:24:1:1::2 remote-as 65000 !  address-family ipv6   network 2001:24:1:1::/64   network 2001:24:1:2::/64   neighbor 2001:24:1:1::2 activate   neighbor 2001:24:1:1::2 allowas-in  exit-address-family

So now we've been able to ping between the two CE nodes of the customer.

CustomerA-Site1#ping 2001:24:2:2::1 source loop 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:24:2:2::1, timeout is 2 seconds: Packet sent with a source address of 2001:24:1:2::1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Let's dive into the BGP table

PE1#sh bgp ipv6 unicast BGP table version is 21, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,                r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,                x best-external, a additional-path, c RIB-compressed,                t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found      Network          Next Hop            Metric LocPrf Weight Path  r>   2001:24:1:1::/64 2001:24:1:1::1           0             0 100 i  *>   2001:24:1:2::/64 2001:24:1:1::1           0             0 100 i  *>i  2001:24:2:1::/64 ::FFFF:3.3.3.3           0    100      0 100 i  *>i  2001:24:2:2::/64 ::FFFF:3.3.3.3           0    100      0 100 i  r>   2001:73:1:1::/64 2001:73:1:1::1           0             0 200 i  *>   2001:73:1:2::/64 2001:73:1:1::1           0             0 200 i  *>i  2001:73:2:1::/64 ::FFFF:4.4.4.4           0    100      0 200 i  *>i  2001:73:2:2::/64 ::FFFF:4.4.4.4           0    100      0 200 i

We can see that the BGP table holds all routes of all the different customers in the global routing table. We'll look into a possible solution later on. Now let's have a more detailed look at the labels. Labels are used to transport our IPv6 packets from PE to PE. We are using two different labels.

• BGP label for the IPv6 prefix on the other PE

• IGP label to transport the packet to the loopback of the other PE
  
  

BGP label

PE1#sh bgp ipv6 unicast  2001:24:2:2::/64    BGP routing table entry for 2001:24:2:2::/64, version 13 Paths: (1 available, best #1, table default)   Advertised to update-groups:      3            Refresh Epoch 19   100     ::FFFF:3.3.3.3 (metric 31) from 3.3.3.3 (3.3.3.3)       Origin IGP, metric 0, localpref 100, valid, internal, best       Community: 4259840001       mpls labels in/out nolabel/3010       rx pathid: 0, tx pathid: 0x0

IGP label

PE1#sh mpls ldp bindings 2.2.2.2 32   lib entry: 2.2.2.2/32, rev 19 local binding:  label: 1007 remote binding: lsr: 172.16.0.9:0, label: 10003

To make it easier to understand, I created a dedicated label range on each MPLS router.

PE1 1000 - 1999
PE2 2000 - 2999
PE3 3000 - 3999
PE4 4000 - 4999

P1 10000 - 10999
P2 20000 - 20999

So let's check the labeled packets on the wire by capturing the packets on the links between MPLS routers.

We can observe that the inner label is the BGP label (in our case 3010), which is sent from PE3 to PE1 via BGP. It's preserved from PE1 to PE3.

The outer label is the "transport" or IGP label. From a numerical view, we see that PE1 is sending a packet with label 10008. P1 announced the label by LDP and is the label used for 3.3.3.3 (next-hop from BGP point of view).

Capture from PE1 to P1

Capture from P1 to P2

Capture from P2 to PE3

This mechanism lets us send IPv6 packets over an IPv4 MPLS network. The P-routers do not need IPv6. They also do not need to understand the labels that PE-routers exchanged via BGP.

Keep in mind that everything is happening in the global routing table. There is no segmentation on vrf basis. Overlapping IPv6 address spaces would be a problem. In case you're already using MPLS for L3VPN you would need an additional link (physical or subinterface) between CE-PE. This link would peer in the global routing table to be able to use 6PE between CE and PE.

A possible use-case would be to offer customers IPv6 internet connectivity on the existing MPLS network.

You can still limit customers to their own IPv6 prefixes. You can do this with regular BGP tagging and filtering.

Filtering on PE1 for Customer 1

ip community-list 1 permit 4259840001 ! route-map TAG-CUSTOMER1 permit 10  set community 4259840001 ! route-map IPv6_NEXT-HOP permit 10  match community 1  set ipv6 next-hop 2001:24:2:1::2 ! router bgp 65000  address-family ipv6   neighbor 2001:24:2:1::1 route-map TAG-CUSTOMER1 in   neighbor 2001:24:2:1::1 route-map IPv6_NEXT-HOP out

If you have interesting 6PE use-cases or more info, I'd love to hear from you in the comments.