09-07-2012 04:31 AM - edited 03-04-2019 05:30 PM
Hi Guys,
I have v4 mpls working fine but v6 refuses to work correctly.
Looking at the ipv6 routing table for the VRF we can see prefix's coming from the remote PE's
BGP is up in vpnv6 and ipv6 unicast.
Everything seems fine but I just cant seem to ping between the sites.
as mentioned, ipv4 works fine for the same vrf.
Any ideas on where I can start troubleshooting.
Thanks
G
-Graham
Please note: My comments are simply suggestions. I cannot be held liable for any loss of data, life or marbles due to following my instructions.
Got a website? Need some live chat software?
Solved! Go to Solution.
09-07-2012 05:27 AM
Hi Graham,
One thing that immediately caught my attention is the fact that the next hops towards the IPv6 routes are IPv6 addresses themselves. For example:
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 6656:113 (default for vrf TEST)
*>i2A00:ED0:2000:8000::/64
2A00:ED0::3C 0 100 0 ?
Note the next hop - it is 2A00:ED0::3C. In common 6VPE scenarios, this should be an IPv6-mapped IPv4 address, i.e. ::FFFF:X.X.X.X. This IPv4 address is then used to look up the upper label from the LFIB (the IPv4 routing in these networks is supposed to be already working and LDP should take care of disseminating label-to-prefix mappings).
However, to my best knowledge, Cisco does not yet support LDP for IPv6 (anyone feel free to correct me if I am wrong!). This means that while you are capable of looking up the bottom label (visible in the show ip bgp vpnv6 unicast ... labels), you are unable to look up the topmost label that's supposed to carry this packet via an appropriate LSP to the remote PE.
So in order for the 6VPE to actually work, you should configure your BGP neighbors using IPv4 addresses and use those IPv4 addresses in the address-family vpnv6 stanza as neighbor X.X.X.X activate. This will cause BGP to use IPv6-mapped IPv4 addresses as the next hops towards the IPv6 routes in the appropriate VRFs, and enabling the lookup of the topmost label in the IPv4 LFIB.
Does this make any sense? It's a convoluted concept.
Best regards,
Peter
09-07-2012 04:45 AM
Hi Graham,
Please be so kind as to post the following information:
Thank you!
Best regards,
Peter
09-07-2012 05:01 AM
Hey man,
Here you go, Thanks for the quick reply.
Ive omitted the sh ipv6 route ( as it holds the entire internet routing table )
PE1
vrf definition TEST
rd XXXX:113
route-target export XXXX:113
route-target import XXXX:113
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
interface FastEthernet0/1
vrf forwarding TEST
ip address 192.168.123.123 255.255.255.0
duplex auto
speed auto
ipv6 address 2A00:XXXX:2000:C000::1/64
ipv6 enable
!
router bgp XXXX
!
address-family ipv4 vrf TEST
redistribute connected
redistribute static
default-information originate
no synchronization
exit-address-family
!
!
address-family ipv6 vrf TEST
redistribute connected
redistribute static
default-information originate
no synchronization
exit-address-family
!
!
end
sh ip bgp vpnv6 unicast ?
all Display information about all VPN NLRIs
rd Display information for a route distinguisher
vrf Display information for a VPN Routing/Forwarding instance
sh ip bgp vpnv6 unicast vrf TEST
BGP table version is 20, local router ID is 212.125.95.222
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: XXXX:113 (default for vrf TEST)
*>i2A00:ED0:2000:8000::/64
2A00:ED0::3C 0 100 0 ?
*> 2A00:ED0:2000:C000::/64
:: 0 32768 ?
sh ip bgp vpnv6 unicast vrf EST lab
bar023#sh ip bgp vpnv6 unicast vrf TEST labels
Network Next Hop In label/Out label
Route Distinguisher: XXXX:113 (TEST)
2A00:ED0:2000:8000::/64
2A00:ED0::3C nolabel/17
2A00:ED0:2000:C000::/64
:: 1798/nolabel(TEST)
PE2
vrf definition TEST
rd XXXX:113
route-target export XXXX:113
route-target import XXXX:113
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
interface FastEthernet0/1
vrf forwarding TEST
ip address 192.168.123.123 255.255.255.0
duplex auto
speed auto
ipv6 address 2A00:XXXX:2000:C000::1/64
ipv6 enable
!
router bgp XXXX
!
address-family ipv4 vrf TEST
redistribute connected
redistribute static
default-information originate
no synchronization
exit-address-family
!
!
address-family ipv6 vrf TEST
redistribute connected
redistribute static
default-information originate
no synchronization
exit-address-family
!
!
end
sh ip bgp vpnv6 unicast vrf TEST
BGP table version is 20, local router ID is 212.125.95.225
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: XXXX:113 (default for vrf TEST)
*> 2A00:ED0:2000:8000::/64
:: 0 32768 ?
*>i2A00:ED0:2000:C000::/64
2A00:ED0::15 0 100 0 ?
sh ip bgp vpnv6 unicast vrf TEST
BGP table version is 20, local router ID is 212.125.95.225
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: XXXX:113 (default for vrf TEST)
*> 2A00:ED0:2000:8000::/64
:: 0 32768 ?
*>i2A00:ED0:2000:C000::/64
2A00:ED0::15 0 100 0 ?
sh ip bgp vpnv6 unicast vrf TEST labels
Network Next Hop In label/Out label
Route Distinguisher: XXXX:113 (TEST)
2A00:ED0:2000:8000::/64
:: IPv6 VRF Aggr:17/nolabel(TEST)
2A00:ED0:2000:C000::/64
2A00:ED0::15 nolabel/1798
09-07-2012 05:27 AM
Hi Graham,
One thing that immediately caught my attention is the fact that the next hops towards the IPv6 routes are IPv6 addresses themselves. For example:
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 6656:113 (default for vrf TEST)
*>i2A00:ED0:2000:8000::/64
2A00:ED0::3C 0 100 0 ?
Note the next hop - it is 2A00:ED0::3C. In common 6VPE scenarios, this should be an IPv6-mapped IPv4 address, i.e. ::FFFF:X.X.X.X. This IPv4 address is then used to look up the upper label from the LFIB (the IPv4 routing in these networks is supposed to be already working and LDP should take care of disseminating label-to-prefix mappings).
However, to my best knowledge, Cisco does not yet support LDP for IPv6 (anyone feel free to correct me if I am wrong!). This means that while you are capable of looking up the bottom label (visible in the show ip bgp vpnv6 unicast ... labels), you are unable to look up the topmost label that's supposed to carry this packet via an appropriate LSP to the remote PE.
So in order for the 6VPE to actually work, you should configure your BGP neighbors using IPv4 addresses and use those IPv4 addresses in the address-family vpnv6 stanza as neighbor X.X.X.X activate. This will cause BGP to use IPv6-mapped IPv4 addresses as the next hops towards the IPv6 routes in the appropriate VRFs, and enabling the lookup of the topmost label in the IPv4 LFIB.
Does this make any sense? It's a convoluted concept.
Best regards,
Peter
09-07-2012 05:34 AM
Hmm doesnt make much sense..
I have IPv6 neighbors ( as my core is 100% dual stacked )
So i wouldnt want to remove any IPv6 neighbors.
What would I do to get it to fallback to this v4 mapped addresses?
This i smy BGP setup:
sh ip bgp all sum
For address family: IPv6 Unicast
BGP router identifier 212.125.95.222, local AS number 6656
BGP table version is 61635, main routing table version 61635
10325 network entries using 1610700 bytes of memory
10325 path entries using 784700 bytes of memory
6854/6829 BGP path/bestpath attribute entries using 1151472 bytes of memory
25 BGP rrinfo entries using 600 bytes of memory
6588 BGP AS-PATH entries using 190104 bytes of memory
4 BGP extended community entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 3737704 total bytes of memory
BGP activity 71935/61598 prefixes, 93448/83102 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2A00:ED0::5 4 6656 37560 157 61635 0 0 01:46:39 10325
For address family: VPNv4 Unicast
BGP router identifier 212.125.95.222, local AS number xxxx
BGP table version is 36, main routing table version 36
10 network entries using 1560 bytes of memory
19 path entries using 1292 bytes of memory
6854/2 BGP path/bestpath attribute entries using 1151472 bytes of memory
25 BGP rrinfo entries using 600 bytes of memory
6588 BGP AS-PATH entries using 190104 bytes of memory
4 BGP extended community entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 1345156 total bytes of memory
BGP activity 71935/61598 prefixes, 93448/83102 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
212.125.95.21 4 xxxx 13083 199 36 0 0 03:17:28 9
212.125.95.52 4 xxxx 13088 199 36 0 0 03:17:30 9
For address family: VPNv6 Unicast
BGP router identifier 212.125.95.222, local AS number xxxx
BGP table version is 20, main routing table version 20
2 network entries using 360 bytes of memory
2 path entries using 192 bytes of memory
6854/2 BGP path/bestpath attribute entries using 1151472 bytes of memory
25 BGP rrinfo entries using 600 bytes of memory
6588 BGP AS-PATH entries using 190104 bytes of memory
4 BGP extended community entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 1342856 total bytes of memory
BGP activity 71935/61598 prefixes, 93448/83102 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2A00:ED0::A 4 xxxx 150 151 20 0 0 02:15:15 1
bar023#
09-07-2012 05:54 AM
Peter ,, You Rock!!! Absolutely correct statements.
graham,
IPv6 doesnt support LDP natively yet, So even if you are having dual stacked core, the Current implementation doesnt support having IGP Lookup on IPv6 yet, its therfore , a manadatory performs IGP lookup for the 6VPE in the IPv4 next hop.
So, Your neighbor under the VPNv6 address Family should be an IPv4 address of your remote PE or your Route Reflector.
if you look at your previous verfication, you will find that an VPNv6 Label is visible and Carried over BGP, However, the IGP Label to reach the next Hop wasnt not able to be determined and looked up, and the reason is because You should should map IPv4 - To - IPv6 for the 6VPE implementation, Keep in mind that Of Course, the Egress PE performs lookup at the VPNv6 Label and Performs a nother Lookup (IPv6 CEF) to forward a native IPv6 Packet to the Customer Edge (CE Router).
The TOP Label in the mpls core (IGP Label Lookup) is always going to be for an IPv4 Mapped Address.
Let us know if this answers your question,
Regards,
Mohame
09-07-2012 06:06 AM
Hey Guys,
AWESOME STUFF!
IT works!
Fully makes sense now.
I have my vpnv6 address-family configured with v4 addresses and now it works
At first it didnt make sense having vpnv6 carrying v6 prefixes over a v4 peer. Seemed odd.
Anyway, I no activated the V6 neighbors ( so they are ready oneday ) and now just use v4 neighbors in my vpnv6.
Phew.
Awesome stuff!
I thought something was terribly amiss on the core or something. Couldnt for my life figure it out.
Wonderful work Peter! and thanks for clarifying Mohame
Great stuff Very pleased.
Have a great weekend guys
09-07-2012 05:56 AM
Hello Graham,
You would not necessarily need to remove all IPv6 neighbors - for the global routing table (non-VRF), you may retain your IPv6 neighbors as you like in the address-family ipv6 stanza. However, in the address-family vpnv6, you need to refer to your BGP neighbors by their IPv4 loopback address.
I am also thinking about using route-maps to modify the next hop attribute of a VPNv6 route advertised to a peer to ::FFFF:X.X.X.X where X.X.X.X is your own loopback IPv4 address but I doubt that it would work, as I have a feeling that the next hop as advertised in BGP VPNv6 updates is not a plain IPv6 address.
To put it simply, a VPNv6 peering using IPv6 addresses would, to my best knowledge, work only on a direct connection between two routers (back-to-back PEs or ASBRs). If there is a routed infrastructure between two PEs, you need to peer them using IPv4 even if you need to carry VPNv6 routes - because LDP for IPv6 is not implemented yet.
Best regards,
Peter
09-07-2012 06:08 AM
yeha thanks.. I think you helped clear it up in my head what to change
--
AWESOME STUFF!
IT works!
Fully makes sense now.
I have my vpnv6 address-family configured with v4 addresses and now it works
At first it didnt make sense having vpnv6 carrying v6 prefixes over a v4 peer. Seemed odd.
Anyway, I no activated the V6 neighbors ( so they are ready oneday ) and now just use v4 neighbors in my vpnv6.
Phew.
Awesome stuff!
I thought something was terribly amiss on the core or something. Couldnt for my life figure it out.
Wonderful work Peter! and thanks for clarifying Mohame
Great stuff Very pleased.
Have a great weekend guys
09-07-2012 06:11 AM
Peter,
Even in a Back to Back PEs or ASBRs, the VPNv6 peering will not work for an IPv6 neighbor under the BGP address Family.
Its still wont be able to Looked up the TOP Label using an IPv6, it has to be an IPv4, and I am Sure about it. You Can try it on a Lab.
Regards,
Mohamed
09-07-2012 06:22 AM
Hi Mohamed,
I'll probably try it and I am not going to doubt what you say, but my logic tells me that for back-to-back PEs, it should work at least in theory because of Penultimate Hop Popping - the labeled packets would so or so have only the bottom label attached, so they don't need the upper label. It seems that this is also what the Configuration Guide suggests here:
Best regards,
Peter
09-07-2012 08:19 AM
Hello Mohamed,
I have actually made quite an interesting discovery.
I have two routers connected back to back, both having a VRF with a directly connected IPv6 network on a loopback, and a straightforward BGP configuration that peers these neighbors using their IPv6 addresses on the common link.
R2:
hostname R2
!
vrf definition V1
rd 1:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
vrf forwarding V1
no ip address
ipv6 address 2000::2/128
!
interface Serial0/0/1
ip address 10.0.23.2 255.255.255.0
ipv6 address 2000:0:0:23::2/64
mpls bgp forwarding
clock rate 2000000
!
router bgp 1
bgp router-id 2.2.2.2
bgp log-neighbor-changes
neighbor 2000:0:0:23::3 remote-as 1
no neighbor 2000:0:0:23::3 activate
!
address-family vpnv6
neighbor 2000:0:0:23::3 activate
neighbor 2000:0:0:23::3 send-community extended
exit-address-family
!
address-family ipv6 vrf V1
redistribute connected
exit-address-family
R3:
hostname R3
!
vrf definition V1
rd 1:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
vrf forwarding V1
no ip address
ipv6 address 2000::3/128
!
interface Serial0/0/1
ip address 10.0.23.3 255.255.255.0
ipv6 address 2000:0:0:23::3/64
ipv6 ospf 1 area 0
mpls bgp forwarding
!
router bgp 1
no synchronization
bgp router-id 3.3.3.3
bgp log-neighbor-changes
neighbor 2000:0:0:23::2 remote-as 1
no auto-summary
!
address-family vpnv6
neighbor 2000:0:0:23::2 activate
neighbor 2000:0:0:23::2 send-community extended
exit-address-family
!
address-family ipv6 vrf V1
redistribute connected
no synchronization
exit-address-family
The IPv6 routes in the VRFs are exchanged nicely but the pings don't work even though I've enabled mpls bgp forwarding on the interfaces. This confirms what you have originally indicated.
R2#show ipv6 route
IPv6 Routing Table - default - 3 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, ND - Neighbor Discovery, l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C 2000:0:0:23::/64 [0/0]
via Serial0/0/1, directly connected
L 2000:0:0:23::2/128 [0/0]
via Serial0/0/1, receive
L FF00::/8 [0/0]
via Null0, receive
R2#show ipv6 route vrf V1
IPv6 Routing Table - V1 - 3 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, ND - Neighbor Discovery, l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
LC 2000::2/128 [0/0]
via Loopback0, receive
B 2000::3/128 [200/0]
via 2000:0:0:23::3%default, indirectly connected
L FF00::/8 [0/0]
via Null0, receive
R2#ping vrf V1 2000::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2000::3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#show mpls interface
Interface IP Tunnel BGP Static Operational
Serial0/0/1 No No Yes No Yes
After having a close look at the CEF contents on one of these routers, this caught my eye:
R2#show ipv6 cef vrf V1 2000::3/128 internal
2000::3/128, epoch 0, flags rib defined all labels, RIB[B], refcount 4, per-destination sharing
sources: RIB
feature space:
IPRM: 0x00018000
LFD: 2000::3/128 0 local labels
contains path extension list
ifnums: (none)
path 68172C78, path list 68174118, share 1/1, type attached nexthop, for IPv6, flags must-be-labelled
MPLS short path extensions: MOI flags = 0x0 label 17
nexthop 2000:0:0:23::3 Null0 label 17, adjacency Null0
output chain: label 17 Lookup in input interface's mpls table
Note that the adjacency is pointing towards Null0 although the next hop is known in the global routing table and for a directly connected neighbor like this one, no MPLS label is required.
You could say that this Null0 adjacency has been installed because there is no MPLS label known towards the next hop 2000:0:0:23::3. However, this is not the case. Let me add the following configuration to R2 and R3:
R2:
route-map Test
set ipv6 next-hop ::FFFF:10.0.23.2
!
router bgp 1
address-family vpnv6
neighbor 2000:0:0:23::3 route-map Test out
R3:
route-map Test
set ipv6 next-hop ::FFFF:10.0.23.3
!
router bgp 1
address-family vpnv6
neighbor 2000:0:0:23::2 route-map Test out
I am basically manipulating the next hop attributes manually here and I am setting them to the IPv4 addresses of R2 and R3, respectively - something that would be done automatically if we used IPv4 addresses in the BGP peering configuration from the beginning.
Now, on R2:
R2#show ipv6 route vrf V1
IPv6 Routing Table - V1 - 3 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, ND - Neighbor Discovery, l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
LC 2000::2/128 [0/0]
via Loopback0, receive
B 2000::3/128 [200/0]
via 10.0.23.3%default, indirectly connected
L FF00::/8 [0/0]
via Null0, receive
R2#show ipv6 cef vrf V1 2000::3/128 internal
2000::3/128, epoch 0, flags rib defined all labels, RIB[B], refcount 4, per-destination sharing
sources: RIB
feature space:
IPRM: 0x00018000
LFD: 2000::3/128 0 local labels
contains path extension list
ifnums: (none)
path 68172968, path list 68173EE8, share 1/1, type recursive, for IPv6, flags must-be-labelled
MPLS short path extensions: MOI flags = 0x0 label 17
recursive via 10.0.23.3[IPv4:Default] label 17, fib 66D3174C, 1 terminal fib, v4:Default:10.0.23.3/32
path 681729D8, path list 68173F38, share 1/1, type recursive, for IPv4, flags doesnt-source-via, cef-internal
recursive via 10.0.23.0/24<10.0.23.3>[IPv4:Default], fib 66D316C8, 1 terminal fib, v4:Default:10.0.23.0/2410.0.23.3>
path 68172B28, path list 68174028, share 1/1, type connected prefix, for IPv4
MPLS short path extensions: MOI flags = 0x1 label implicit-null
connected to Serial0/0/1, adjacency IP adj out of Serial0/0/1 67A2E220
output chain: label 17 label implicit-null TAG adj out of Serial0/0/1 66E7A6C0
R2#ping vrf V1 2000::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2000::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/2/4 ms
R2#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 2000::2/128[V] 1000 aggregate/V1
R2#show mpls ip binding all
R2#show ip cef 10.0.23.3 detail
10.0.23.3/32, epoch 0, flags attached
1 RR source [active source]
Dependent covered prefix type rr cover 10.0.23.0/24
recursive via 10.0.23.0/24
attached to Serial0/0/1
R2#show ip cef 10.0.23.3 internal
10.0.23.3/32, epoch 0, flags attached, refcount 6, per-destination sharing
sources: RR
feature space:
LFD: 10.0.23.3/32 0 local labels
label switch chain 0x68288650
subblocks:
1 RR source [active source]
Dependent covered prefix type rr cover 10.0.23.0/24
non-eos chain implicit-null
ifnums:
Serial0/0/1(5)
path 681729D8, path list 68173F38, share 1/1, type recursive, for IPv4, flags doesnt-source-via, cef-internal
recursive via 10.0.23.0/24<10.0.23.3>[IPv4:Default], fib 66D316C8, 1 terminal fib, v4:Default:10.0.23.0/2410.0.23.3>
path 68172B28, path list 68174028, share 1/1, type connected prefix, for IPv4
MPLS short path extensions: MOI flags = 0x1 label implicit-null
connected to Serial0/0/1, adjacency IP adj out of Serial0/0/1 67A2E220
output chain: IP adj out of Serial0/0/1 67A2E220
R2#
Note that in this case, the next hop was an IPv6-mapped IPv4 address for which there is no label known, either (I did not configure any LDP). Yet, the IPv6 CEF was now willing to create a correct adjacency and the ping actually worked - even though the IPv4 next hop address does not have any valid MPLS label mapping.
From this, it follow that the direct PE-PE connection with BGP peering using IPv6 addresses will not work to provide a working connectivity between IPv6 VRFs. Yet, it is not because there is no MPLS label mapping towards the IPv6 next hop address but merely because the IPv6 CEF is not willing to create an adjacency towards a VPNv6 route if the next hop is an IPv6 address. The only difference here is indeed the IP address in the next hop attribute: for IPv6 address, Null0 adjacency is inserted into IPv6 CEF. For IPv6-mapped IPv4 address, the adjacency is created correctly.
It seems that the IPv6 CEF is simply not going to create non-Null0 adjacencies towards IPv6 next hops. Probably this limitation will be lifted after true LDP for IPv6 is implemented.
Any thoughts are highly welcome!
Best regards,
Peter
09-07-2012 08:34 AM
I fear I have poked a hornets nest here
Very interesting read Peter!
I find it strange that LDP v6 isnt available after all this time.
If I were to create a 100% IPv6 network I assume this means that MPLS is a no-no until LDP v6 is available.
Im not saying I will make 100% only v6 network but I feel dirty using V4 to transfer V6 routes ( even if its the best / correct way ) to do it.
Will be interesting to see what others think here.
-Graham
09-07-2012 02:19 PM
Hello Graham,
Thank you! It has been an interesting experiment for me, too.
I find it strange that LDP v6 isnt available after all this time.
Yes, in a way, I find it strange as well. However, pure IPv6 networks are very rare today, especially in service provider world where MPLS is usually run. In these networks, IPv4 is practically omnipresent. Therefore, there is no real pressure for IPv6 LDP. The 6PE and 6VPE technologies (you're running 6VPE here) have been specifically designed to overcome the lack of IPv6 LDP by referring to IPv4 next hops and associated MPLS labels.
What's even more important, although the RFC 5036 (LDP, published in October 2007) does discuss the ability of LDP to carry IPv6 label bindings, it is quite terse on the details. There is a draft updating the details (http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-07) but it was first published in November 2010 and it still did not make it to a RFC.
I admit that running IPv4 to have MPLS-supported IPv6 is a quirk. Sadly, there's nothing better available for the moment. Hopefully that changes soon.
Best regards,
Peter
09-13-2012 01:57 AM
Hello Peter,
You have made an excellent experiment, and I have tested this behaviour in a LAB before. You mentioned in the main thread , a label is not needed for a directly IPv6 neighbor, I am not entirely agree. a Label would always be needed, but the point is that the PHP router performs POP operation and forward the Packets to the egress PE. The TOP Label in the Case of IPv4 is created by the Egress PE and POPed by the PHP router.
From my opinion as I illustarted earlier, the reason of this behaviour even for an IPv6 CEF not creating the right adjacency, is because there is NO Valid Label Binding in the LFIB table. The IPv6 directly connected neighbor has no Local LDP binding and the LSR doesnt perofrm what a called unsolicited upstream label distribution for an IPv6 packet. Meaning, R3 doesnt have a Valid Label for the 2000:0:0:23::3, and hence R2 doesnt perform correct POP for this host
In an IPv4, this is different. If you examine the Local Label bindings (LIB Table) for router 3 and router 2, you should find valid Label bindings for each directly connected Prefix, but this is not the case with IPv6. This can also be confirmed with (show mple forwarding table) to validate the correct PoP operation from Router(2), but its not visible as shown in your previous verification. This is my opinion and thought about it.
Regards,
Mohamed
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide