6PE/6VPE
6PE is defined in RFC 4798.
6VPE is defined in RFC 4659.
- 6PE
- customer's IPv6 prefixes are inside the global routing table
- IPv6 labels/prefixes are exchanged using Labeled IPv6 over IPv4 iBGP between the PEs
- 6VPE
- customer's IPv6 prefixes are inside a VRF
- IPv6 labels/prefixes are exchanged using VPNv6 over IPv4 iBGP between the PEs
6PE
6PE is a technology that allows IPv6 customers to communicate with each other over an IPv4 MPLS Provider without any tunnel setup, by having the customer IPv6 prefixes using a IPv4-mapped IPv6 address as next-hop inside the Provider's network and using IPv4 LSPs between the 6PEs.
In 6PE, labels must be exchanged between the 6PEs for their IPv6 prefixes, which means that a labeled IPv4 iBGP session must be activated under the IPv6 address family (in IOS) or the labeled IPv6 capability must be activated for the IPv4 peer 6PE (in IOS-XR).
IOS
router bgp 100
no bgp default ipv4-unicast
neighbor 6PE-IPv4 remote-as 100
neighbor 6PE-IPv4 update-source Loopback0
neighbor CE-IPv6 remote-as X
!
address-family ipv6
neighbor 6PE-IPv4 activate
neighbor 6PE-IPv4 send-label
neighbor CE-IPv6 activate
IOS-XR
router bgp 100
address-family ipv6 unicast
allocate-label all
!
neighbor 6PE-IPv4
remote-as 100
update-source Loopback0
address-family ipv6 labeled-unicast
!
neighbor CE-IPv6
remote-as X
address-family ipv6 unicast
The 6PE routers are dual-stack: IPv6 towards the CE and IPv4 towards the MPLS core.
You don't need to set the "next-hop-self" in the labeled IPv4 iBGP session for the IPv6 prefixes, because that happens automatically while creating the IPv4-mapped IPv6 address.
MP_REACH_NLRI attribute
- AFI = 2 (IPv6)
- SAFI= 4 (labels)
- Prefix =X:X:X:X::X
- Label = X
- next-hop = ::FFFF:IPv4-ADDRESS
The IPv4 address which is encoded into the next-hop must be present in the IPv4 routing table and a LSP must exist to this destination. If the above conditions are not both met, the IPv6 prefix is declared inaccessible.
R5#sh bgp ipv6 unicast 2001::1:1:1:1/128
BGP routing table entry for 2001::1:1:1:1/128, version 4
Paths: (1 available, no best path)
Not advertised to any peer
1
::FFFF:2.2.2.2 (inaccessible) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
If a 6PE receives unlabeled IPv6 prefixes, then the 6PE marks these prefixes as unreachable in the IPv6 routing table, so that packets to this destination get dropped and not sent into MPLS core.
If RRs are to be used for 6PE connectivity, then they also must have labeled BGP enabled.
Control Plane
- CEs and 6PEs run eBGP (or IGP) in order to exchange IPv6 prefixes
- 6PEs run iBGP+Label in order to exchange labels and IPv6 prefixes
- Provider routers run IGP+LDP in order to exchange all their internal BGP IPv4 next-hops and their labels
6PE Example
Assume the following network:
R1-R2-R3-R4-R5-R6
where
IPv6 Customer
6PE Provider (with 6PE routers and IPv4 routers)
Then the following would happen for an IPv6 packet originating at R1 and terminating at R6.
- R1 (IPv6)
- next-hop is R2 (IPv6 link-local)
- R2 (IPv4/IPv6 6PE)
- next-hop is R5 (IPv4 loopback)
- Transport label is 26, IPv6 label is 28
- R3 (IPv4)
- next-hop is R5 (IPv4 loopback)
- Transport label is 25, IPv6 label is 28
- R4 (IPv4)
- next-hop is R5 (IPv4 loopback)
- Transport label is removed, IPv6 label is 28
- R5 (IPv4/IPv6 6PE)
- next-hop is R6 (IPv6 link-local)
- IPv6 label is removed, IPv6 destination reached in next-hop
- R6 (IPv6)
- IPv6 destination reached
The IPv6 label in 6PE can be considered like the VPN label in MPLS VPN.
The customer routers could be IPv4/IPv6, having IPv4 traffic being forwarded as usual and IPv6 traffic over 6PE.
Use extended traceroute if you want to source from an IPv6 address.
R1#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001::6:6:6:6
Source address: 2001::1:1:1:1
...
Tracing the route to 2001::6:6:6:6
1 2001:10:1:2::2 44 msec 72 msec 32 msec
2 ::FFFF:10.2.3.3 [MPLS: Labels 26/28 Exp 0] 1 msec 1 msec 1 msec
3 ::FFFF:10.3.4.4 [MPLS: Labels 25/28 Exp 0] 1 msec 1 msec 1 msec
4 2001:10:5:6::5[MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec
5 2001:10:5:6::6 1 msec 1 msec 1 msec
Although all traceroute answers are given by the closest interface to the source ip, in some software releases in the last 6PE router the traceroute answer is given by the IPv6 address on the PE-CE link.
You can use "no mpls ip propagate-ttl" on the first-hop 6PE if you want to hide the ::FFFF: IPv4 hops.
1 2001:10:1:2::2 44 msec 72 msec 32 msec
2 2001:10:5:6::5[MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec
3 2001:10:5:6::6 1 msec 1 msec 1 msec
Verification in every hop
Customer IPv6 router
R1#sh ipv6 route 2001::6:6:6:6
Routing entry for 2001::6:6:6:6/128
Known via "bgp 1", distance 20, metric 0, type external
Route count is 1/1, share count 0
Routing paths:
FE80::C805:17FF:FEC8:1C, FastEthernet0/0
MPLS label: nolabel
Last updated 00:31:05 ago
Provider 6PE router
R2#sh bgp ipv6 unicast 2001::6:6:6:6/128
BGP routing table entry for 2001::6:6:6:6/128, version 3
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
20
::FFFF:5.5.5.5(metric 4) from 5.5.5.5(5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
mpls labels in/out nolabel/28
IOS-XR doesn't display the "::FFFF:" in front of the IPv4 next-hop (How Multi is MP-BGP in IOS-XR - Part #2).
IPv6 label is 28
R2#sh mpls forwarding-table 5.5.5.5 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
27 26 5.5.5.5/32 0 Fa0/0.23 10.2.3.3
MAC/Encaps=18/22, MRU=1500, Label Stack{26}
CA071AC40000CA0517C80000810000178847 0001A000
No output feature configured
Transport label is 26
R2#sh ipv6 cef 2001::6:6:6:6/128 detail
2001::6:6:6:6/128, epoch 0, flags rib defined all labels
recursive via 5.5.5.5 label 28
nexthop 10.2.3.3 FastEthernet0/0.23 label 26
Transport label is 26, IPv6 label is 28
You can follow the next-hop or the labels (like in CsC), but let's follow the next-hop on this example.
Provider IPv4 Router
R3#sh mpls forwarding-table 5.5.5.5 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
26 25 5.5.5.5/32 16342 Fa0/0.34 10.3.4.4
MAC/Encaps=18/22, MRU=1500, Label Stack{25}
CA0113200000CA071AC40000810000248847 00019000
No output feature configured
Transport label is 25, IPv6 label is 28
Provider IPv4 Router
R4#sh mpls forwarding-table 5.5.5.5 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
25 Pop Label 5.5.5.5/32 16125 Fa0/0.45 10.4.5.5
MAC/Encaps=18/18, MRU=1504, Label Stack{}
CA0214D00008CA01132000008100026B8847
No output feature configured
Transport label is removed, IPv6 label is 28
Provider 6PE router
R5#sh mpls forwarding-table 2001::6:6:6:6/128 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
28 No Label 2001::6:6:6:6/128 \
2244 PO2/0 point2point
MAC/Encaps=4/4, MRU=4474, Label Stack{}
0F0086DD
No output feature configured
R5#sh bgp ipv6 unicast 2001::6:6:6:6/128
BGP routing table entry for 2001::6:6:6:6/128, version 3
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
20
2001:10:5:6::6 (FE80::C803:14FF:FED0:8) from 2001:10:5:6::6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, external, best
mpls labels in/out 28/nolabel
R5#sh bgp ipv6 unicast labels
Network Next Hop In label/Out label
2001::6:6:6:6/128
2001:10:5:6::6
28/nolabel
R5#sh ipv6 route 2001::6:6:6:6/128
Routing entry for 2001::6:6:6:6/128
Known via "bgp 100", distance 20, metric 0, type external
Route count is 1/1, share count 0
Routing paths:
FE80::C803:14FF:FED0:8, POS2/0
MPLS label: nolabel
Last updated 00:43:37 ago
IPv6 label is removed, IPv6 destination reached in next-hop
6VPE
6VPE is a technology that allows IPv6 VPN customers to communicate with each other over an IPv4 MPLS Provider without any tunnel setup, by having the customer VPNv6 prefixes using a v4-mapped IPv6 address as next-hop inside the provider's network and using IPv4 LSPs between the 6VPEs.
In 6VPE, labels must be exchanged between the 6VPEs for their VPNv6 prefixes, which means that the VPNv6 address-family must be activated on the IPv4 iBGP session between the 6VPEs.
IOS
router bgp 100
no bgp default ipv4-unicast
neighbor 6VPE-IPv4 remote-as 100
neighbor 6VPE-IPv4 update-source Loopback0
!
address-family vpnv6
neighbor 6VPE-IPv4 activate
neighbor 6VPE-IPv4 send-community extended
exit-address-family
!
address-family ipv6 vrf VPN
neighbor CE-IPv6 remote-as X
neighbor CE-IPv6 activate
exit-address-family
IOS-XR
router bgp 100
address-family vpnv6 unicast
!
neighbor 6VPE-IPv4
remote-as 100
update-source Loopback0
address-family vpnv6 unicast
!
vrf VPN
rd 100:1
address-family ipv6 unicast
!
neighbor CE-IPv6
remote-as x
address-family ipv6 unicast
The 6VPE routers are dual-stack: IPv6 towards the CE (inside a VRF) and IPv4 towards the MPLS core.
MP_REACH_NLRI attribute
- AFI = 2 (IPv6)
- SAFI= 128 (.)
- Prefix =X:X:X:X::X
- Label = X
- next-hop = ::FFFF:IPv4-ADDRESS
The IPv4 address which is encoded into the next-hop must be present in the IPv4 routing table and a LSP must exist to this destination. If the above conditions are not both met, the IPv6 prefix is declared inaccessible.
If RRs are to be used for 6VPE connectivity, then they also must have the VPNv6 address-family enabled.
Control Plane
- CEs and 6VPEs run eBGP (or IGP) in order to exchange IPv6 prefixes
- 6VPEs run VPNv6 iBGP in order to exchange labels and VPNv6 prefixes
- Provider routers run IGP+LDP in order to exchange all their internal BGP IPv4 next-hops and their labels
In IOS, if you enable the VPNv6 address-family on an existing VPNv4 peering, you might need to reset the whole BGP session for VPNv6 to come up.
6VPE Example
Assume the following network:
R1-R2-R3-R4-R5-R6
where
IPv6 VPN Customer
6VPE Provider (with 6VPE routers and IPv4 routers)
Then the following would happen for an IPv6 packet originating at R1 and terminating at R6.
- R1 (IPv6)
- next-hop is R2 (IPv6 link-local)
- R2 (IPv4/IPv6 6VPE)
- next-hop is R5 (IPv4 loopback)
- Transport label is 18, VPNv6 label is 28
- R3 (IPv4)
- next-hop is R5 (IPv4 loopback)
- Transport label is 25, VPNv6 label is 28
- R4 (IPv4)
- next-hop is R5 (IPv4 loopback)
- Transport label is removed, VPNv6 label is 28
- R5 (IPv4/IPv6 6VPE)
- next-hop is R6 (IPv6 link-local)
- VPNv6 label is removed, IPv6 destination reached in next-hop
- R6 (IPv6)
- IPv6 destination reached
Use extended traceroute if you want to source from a specific IPv6 address.
R1#trace 2001:6:6:6::6
Type escape sequence to abort.
Tracing the route to 2001:6:6:6::6
1 2001:10:1:2::2 1 msec 1 msec 1 msec
2 ::FFFF:10.2.3.3 [MPLS: Labels 18/28 Exp 0] 1 msec 1 msec 1 msec
3 ::FFFF:10.3.4.4 [MPLS: Labels 25/28 Exp 0] 1 msec 1 msec 1 msec
4 2001:10:5:6::5 [AS 100] [MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec
5 2001:10:5:6::6 [AS 100] 1 msec 1 msec 1 msec
Although all traceroute answers are given by the closest interface to the source ip, in some software releases in the last 6VPE router the traceroute answer is given by the IPv6 address on the PE-CE link.
You can use "no mpls ip propagate-ttl" on the first-hop 6VPE if you want to hide the ::FFFF: IPv4 hops.
1 2001:10:1:2::2 1 msec 1 msec 1 msec
2 2001:10:5:6::5 [AS 100] [MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec
3 2001:10:5:6::6 [AS 100] 1 msec 1 msec 1 msec
Verification in every hop
Customer IPv6 router
R1#sh ipv6 route 2001::6:6:6:6
Routing entry for 2001::6:6:6:6/128
Known via "bgp 1", distance 20, metric 0, type external
Route count is 1/1, share count 0
Routing paths:
FE80::C805:EFF:FE2C:1C, FastEthernet0/0
MPLS label: nolabel
Last updated 01:47:39 ago
Provider 6VPE router
R2#sh bgp vpnv6 unicast vrf VPN 2001::6:6:6:6/128
BGP routing table entry for [100:1]2001::6:6:6:6/128, version 6
Paths: (1 available, best #1, table VPN)
Advertised to update-groups:
3
1
::FFFF:5.5.5.5 (metric 4) from 5.5.5.5 (5.5.5.5)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:1
mpls labels in/out nolabel/28
IOS-XR doesn't display the "::FFFF:" in front of the IPv4 next-hop (How Multi is MP-BGP in IOS-XR - Part #2).
VPNv6 label is 28
R2#sh mpls forwarding-table 5.5.5.5 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
19 18 5.5.5.5/32 0 Fa0/0.23 10.2.3.3
MAC/Encaps=18/22, MRU=1500, Label Stack{18}
CA070D4C0000CA050E2C0000810000178847 00012000
No output feature configured
Transport label is 18
R2#sh ipv6 cef vrf VPN 2001::6:6:6:6 detail
2001::6:6:6:6/128, epoch 0, flags rib defined all labels
recursive via 5.5.5.5 label 28
nexthop 10.2.3.3 FastEthernet0/0.23 label 18
Transport label is 18, VPNv6 label is 28
You can follow the next-hop or the labels (like in CsC), but for easiness let's follow the labels this time.
Provider IPv4 Router
R3#sh mpls forwarding-table labels 18 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
18 25 5.5.5.5/32 45876 Fa0/0.34 10.3.4.4
MAC/Encaps=18/22, MRU=1500, Label Stack{25}
CA0119D80000CA070D4C0000810000248847 00019000
No output feature configured
Transport label is 25, VPNv6 label is 28
Provider IPv4 Router
R4#sh mpls forwarding-table labels 25 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
25 Pop Label 5.5.5.5/32 45343 Fa0/0.45 10.4.5.5
MAC/Encaps=18/18, MRU=1504, Label Stack{}
CA0217AC0008CA0119D800008100026B8847
No output feature configured
Transport label is removed, VPNv6 label is 28
Provider 6VPE router
R5#sh mpls forwarding-table labels 28 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
28 No Label 2001::6:6:6:6/128[V] \
2820 PO2/0 point2point
MAC/Encaps=4/4, MRU=4474, Label Stack{}
0F0086DD
VPN route: VPN
No output feature configured
R5#sh bgp vpnv6 unicast vrf A 2001::6:6:6:6/128
BGP routing table entry for [100:1]2001::6:6:6:6/128, version 6
Paths: (1 available, best #1, table VPN)
Advertised to update-groups:
1
1
2001:10:5:6::6 (FE80::C803:17FF:FEAC:8) from 2001:10:5:6::6 (6.6.6.6)
Origin incomplete, metric 0, localpref 100, valid, external, best
Extended Community: RT:100:1
mpls labels in/out 28/nolabel
Use prefix/size to verify when doing bgp lookups.
R5#sh ipv6 route vrf VPN 2001::20:20:20:20/128
Routing entry for 2001::6:6:6:6/128
Known via "bgp 100", distance 20, metric 0, type external
Route count is 1/1, share count 0
Routing paths:
FE80::C803:17FF:FEAC:8, POS2/0
MPLS label: nolabel
Last updated 02:08:07 ago
VPNv6 label is removed, IPv6 destination reached in next-hop
IPv6 prefixes over an IPv4 PE-CE BGP session
Usually when doing 6PE or 6VPE, the BGP session between the PE and the CE (which is used for exchanging the IPv6 prefixes) is IPv6 based.
If you want to exchange IPv6 prefixes over an IPv4 PE-CE BGP session, then you must change the IPv6 next-hop in the PEs in both directions (and then reset the session) Otherwise you might have the control plane showing everything is fine, but most probably data plane won't work.
IOS
R2#sh bgp vpnv6 unicast all
BGP table version is 1, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 26:65001 (default for vrf VPN)
* 2001:10:2:8::/64 ::FFFF:10.2.8.8 0 0 65001 i
R2#sh bgp vpnv6 unicast all 2001:10:2:8::/64
BGP routing table entry for [26:65001]2001:10:2:8::/64, version 0
Paths: (1 available, no best path)
Not advertised to any peer
65001
::FFFF:10.2.8.8 (inaccessible) from 10.2.8.8 (10.8.8.8)
Origin IGP, metric 0, localpref 100, valid, external
Extended Community: RT:26:65001
IOS
router bgp X
address-family ipv6 vrf VPN
neighbor CE-IPv4 route-map SET-IPV6NH-IN-ROUTEMAP in
neighbor CE-IPv4 route-map SET-IPV6NH-OUT-ROUTEMAP out
exit-address-family
!
route-map SET-IPV6NH-IN-ROUTEMAP permit 10
set ipv6 next-hop CE-IPv6
!
route-map SET-IPV6NH-OUT-ROUTEMAP permit 10
set ipv6 next-hop PE-IPv6
In general:
- PE=>CE (out)
- set ipv6 next-hop PE-IPv6
- PE<=CE (in)
- set ipv6 next-hop CE-IPv6
After applying the route-map and resetting the session:
IOS
R2#sh bgp vpnv6 unicast all 2001:10:2:8::/64
BGP routing table entry for [26:65001]2001:10:2:8::/64, version 14
Paths: (1 available, best #1, table VPN)
Advertised to update-groups:
4
65001
2001:10:2:8::8 from 10.2.8.8 (10.8.8.8)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:26:65001
mpls labels in/out 27/nolabel
In IOS-XR, you won't even get an IPv4 BGP session up, if there are no IPv6 addresses configured on the PE-CE connection.
The default order of IPv6 next-hop operation is the following:
- use the IPv6 address defined in the route-map of the session
- use the IPv6 address used for peering (directly connected interface or loopback)
- use an IPv4-mapped IPv6 address
Also, sometimes in the CE you must enable ebgp-multihop for the PE session (2 hops at least), otherwise the remote IPv6 routes won't be installed in the CE's BGP table and you'll be getting messages "DENIED due to: non-connected MP_REACH NEXTHOP" (enable "debug bgp ipv6 unicast updates" to see these). This is probably a bug, since the next-hop (PE) is actually connected to the CE router.
A correct output of "sh bgp vpnv6 unicast" from a PE will include:
- IPv6 routes from the directly connected CE
- The next hop shown must be the directly connected CE IPv6 address (i.e. 2001:10:2:8::8)
- IPv6 routes from other PEs
- The next hop shown must be the remote PE IPv4 address (in v4-mapped IPv6 address format like.::FFFF:1.1.1.1 in IOS, or just 1.1.1.1 in IOS-XR)
IOS
R2#sh bgp vpnv6 unicast all
BGP table version is 23, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 26:65001 (default for vrf X)
*>i2001:10:1:7::/64 ::FFFF:1.1.1.1 0 100 0 65001 i
*> 2001:10:2:8::/64 2001:10:2:8::8 0 0 65001 i
IOS-XR
GSR#sh bgp vpnv6 unicast
BGP router identifier 19.19.19.19, local AS number 26
...
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 26:65001 (default for vrf VPN)
*>i2001:10:1:7::/64 1.1.1.1 0 100 0 65001 i
*> 2001:10:20:20::/64 2001:10:19:20::20
0 0 65001 i
When doing the opposite and trying to exchange IPv4 prefixes over an IPv6 BGP session, you have to set manually the IPv4 next-hop
IOS-XR requires to enable the VPNv6 address-family before enabling the IPv6 address-family under a VRF.
Hints
If you get issues with IPv6 next-hops being inaccessible when they point to eBGP interfaces (while they shouldn't), try to shut/no shut the interface.
Before
R2#sh bgp ipv6 unicast 2001:10:1:7::/64
BGP routing table entry for 2001:10:1:7::/64, version 0
Paths: (1 available, no best path)
Not advertised to any peer
26 26
2001:10:19:20::19 (FE80::C802:15FF:FE18:8) (inaccessible) from 10.19.20.19 (19.19.19.19)
Origin IGP, localpref 100, valid, external
After
R2#sh bgp ipv6 unicast 2001:10:1:7::/64
BGP routing table entry for 2001:10:1:7::/64, version 6
Paths: (1 available, best #1, table default)
Not advertised to any peer
26 26
2001:10:19:20::19 from 10.19.20.19 (19.19.19.19)
Origin IGP, localpref 100, valid, external, best
This is probably another bug.
Hi Tassos,
ReplyDeleteGreat Blog. Very impressive work.!
I was trying to simulate 6VPE with IOS on one end as PE and XR as another PE. I found a strange behavior when XR was learning the route from its CE2 (IOS)
Topology: GNS3
lo0 2002::7 IOS (CE1) --- IOS (PE1) --- MPLS cloud --- XR (PE2) --- IOS (CE2) lo0 2002::8
Version:
RP/0/0/CPU0:R5-PE2#sh ver
Thu Oct 30 00:37:25.604 UTC
Cisco IOS XR Software, Version 5.1.1[Default]
Copyright (c) 2014 by Cisco Systems, Inc.
<--- on XR
RP/0/0/CPU0:R5-PE2#sh cef vrf B ipv6
Thu Oct 30 00:11:22.721 UTC
::/0
drop default handler
2002::7/128
recursive ::ffff:1.1.1.2
2002::8/128
recursive ::ffff:10.5.8.8 (?) <<<<<<<<<<< a question mark for the route learned from CE2
2002:10:5:8::/64
connected GigabitEthernet0/0/0/0.58
2002:10:5:8::5/128
receive GigabitEthernet0/0/0/0.58 <<<<<<<< connected route towards CE2
2002:10:5:8::8/128
2002:10:5:8::8 GigabitEthernet0/0/0/0.58
<--- CEF on XR
RP/0/0/CPU0:R5-PE2#sh cef vrf B ipv6 2002::8/128
Thu Oct 30 00:11:28.940 UTC
2002::8/128, version 22, drop adjacency, internal 0x4000001 0x0 (ptr 0xacba4628) [1], 0x0 (0x0), 0x400 (0xacc2b984)
Updated Oct 29 23:55:58.154
Prefix Len 128, traffic index 0, precedence n/a, priority 3
via ::ffff:10.5.8.8, 0 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0x0 0x0]
next hop VRF - 'Unknown', table - 0xe0000003 <<<<<<<<<<<<<< unknown ?
unresolved
local label 16006
labels imposed {None}
RP/0/0/CPU0:R5-PE2#
<--- ping doesn’t work too
RP/0/0/CPU0:R5-PE2#ping vrf B 2002::8 count 5 source 2002:10:5:8::5 verbose
Wed Oct 29 23:56:27.082 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002::8, timeout is 2 seconds:
.UUUU
Success rate is 0 percent (0/5)
RP/0/0/CPU0:R5-PE2#
<--- now change the NH on R8-CE2 for BGP updates towards R5-PE2
neighbor 10.5.8.5 route-map SET-NH out
route-map SET-NH permit 10
set ipv6 next-hop 2002:10:5:8::8
R8-BGP-CE2#
<--- after clearing the session, we see the below:
RP/0/0/CPU0:R5-PE2#sh cef vrf B ipv6
Thu Oct 30 00:15:59.382 UTC
::/0
drop default handler
2002::7/128
recursive ::ffff:1.1.1.2
2002::8/128
recursive 2002:10:5:8::8
<--- ping works
RP/0/0/CPU0:R5-PE2#ping vrf B 2002::8 count 5 source 2002:10:5:8::5 verbose
Thu Oct 30 00:16:11.551 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002::8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/11/19 ms
RP/0/0/CPU0:R5-PE2#
I am unable to understand this behavior on why XR was not able to resolve the NH when received as the v4 mapped format.
Secondly, even if the NH was not resolved, the route was sent to the other PE..!!
Have you seen this issue in your lab?
Hi Tassos,
ReplyDeleteThe PE XR config of the 6VPE case
neighbor 6VPE-IPv4
remote-as 100
update-source Loopback0
address-family vpnv6 unicast
!
should it now also include address-family ipv4 unicast
Thanks