Hello Mohamed,
Thank you for your response!
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.
I believe this is where we diverge in our understanding. I do not believe that the label would always be needed. It is true that a directly connected neighbor would probably advertise an implicit-null label for a directly connected network, resulting in a POP operation. However, that only means that on the wire, the packet will have no topmost MPLS label. For the data plane, it is irrelevant whether the topmost label was not pushed onto the packet at all or whether the previous topmost label was POPped. In the end, the packet will simply not be equipped with the topmost label.
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.
[ ... cut ... ]
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,
This does not appear to be the case, Mohamed - I have recreated the exact setup as described before. Have a look:
R2#show mpls ip binding
LIB not enabled
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] 500 aggregate/V1
R2#show mpls forwarding-table detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 2000::2/128[V] 500 aggregate/V1
MAC/Encaps=0/0, MRU=0, Label Stack{}
VPN route: V1
No output feature configured
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 detail
2000::3/128, epoch 0, flags rib defined all labels
recursive via 10.0.23.3 label 16
recursive via 10.0.23.0/24
attached to Serial0/0/1
R2#show ip bgp vpnv6 unicast vrf V1 label
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (V1)
2000::2/128 :: 16/nolabel(V1)
2000::3/128 ::FFFF:10.0.23.3
nolabel/16
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
You may see here that because I am not running LDP between my R2 and R3 (no mpls ip is configured between these two routers and I am not exchanging any IPv4 routes via BGP), there is no LIB present and no label mappings are created for any IPv4 prefixes, including the IPv4 prefixes I am using as next hop towards the 6VPE networks. In the IPv6 CEF, the 2000::3/128 prefix clearly has only a single label 16 (learned via BGP) associated, and there is no transport label identified - because it does not exist at all. Yet, the pings are successful - despite the obvious fact that there are no label mappings for IPv4 prefixes. If I use your own words, "there is NO Valid Label Binding in the LFIB table" - and yet the connectivity is established!
This seems to confirm my original opinion - that the IPv6 CEF is currently intentionally implemented to create adjacencies to Null0 if the next hop towards a 6VPE prefix in a VRF is an IPv6 address itself - knowing that IPv6 LDP is not implemented yet so using a single label (the VRF label) would not work in general (having two PEs in a back-to-back configuration like this is rare).
Looking forward to reading your thoughts on this.
Best regards,
Peter
