cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4875
Views
30
Helpful
18
Replies

MPLS Ipv6 Not working for some reason.

graham smart
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

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

View solution in original post

18 Replies 18

Peter Paluch
Cisco Employee
Cisco Employee

Hi Graham,

Please be so kind as to post the following information:

  • configuration of the BGP process
  • show ip bgp vpnv6 vrf VRFNAME
  • show ip bgp vpnv6 vrf VRFNAME labels
  • show ipv6 route

Thank you!

Best regards,

Peter

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

-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?

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

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#

-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?

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

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

-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?

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

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

-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?

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

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:

http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-0m/ip6-ov-mpls-6vpe.html#GUID-B060A9BB-30D3-4AAA-8196-739D37546DDB

Best regards,

Peter

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/24

      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/24

    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

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

-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?

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

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco