[c-nsp] wrong next-hop in 6VPE on ASR9k used as RR

[Tassos Chatzithomaoglou]

After 2 months, i managed to get a DE answer:

IOS-XR decided it's best to display the actual next hop which is a v4 nexthop and is also registered with the v4 RIB for tracking purposes, rather than what is transported in the NLRI and matches the output of everything else. So the behaviour is indeed expected and works 'by design'.


I guess IOS dev teams also believe that their behavior is indeed expected and works 'by design'.
I really don't know who to believe....

--
Tassos

Tassos Chatzithomaoglou wrote on 19/08/2013 00:17:
> Quite interestingly, everything work fine.
>
> ASR1k (PE) sends an IPv4-mapped IPv6 NH to ASR9k (RR), which displays it as an IPv4 NH; the ASR9k then sends it to a CRS (RR) which also displays it as an IPv4 NH; The CRS then sends it to another ASR1k (PE), which displays it as IPv4-mapped IPv6 NH. And everything works fine between the two ASR1k (VPEs).
>
> Does anyone have any similar output from an IOS-XR platform (acting as RR to VPNv6 prefixes) to share?
> Is it something expected?
>
> --
> Tassos
>
> Tassos Chatzithomaoglou wrote on 14/8/2013 19:39:
>> Been stuck for over an hour on the following:
>>
>> On a ASR9k (4.1.2) acting as RR i 'm getting IPv4 next-hops instead of IPv4-mapped ones, although the 6VPE router (ASR001, 15.1(3)S3) seems to set the next-hop as it should.
>>
>>
>> PE (ASR001, 15.1(3)S3)
>> ----------------------
>> BGP(5): (base) 10.10.253.161 send UPDATE (format) [1241:109]2a02:2148:2:10::10/127, next ::FFFF:10.10.253.164, label 2689, metric 0, path Local, extended community RT:1241:109
>>
>>
>> RR (ASR9k, 4.1.2)
>> -----------------
>> bgp[1047]: [rtr]: UPDATE from 10.10.253.164 contains nh 10.10.253.164/32, gw_afi 0, flags 0x0, nlri_afi 8
>> bgp[1047]: [rtr]: NH-Validate-Create: addr=10.10.253.164/32, len=24, nlriafi=8, nbr=10.10.253.164, gwafi=0, gwlen=4, gwaddrlen=32::: nhout=0x5dd73910, validity=1, attrerror=0x0000
>> bgp[1047]: [rtr]: UPDATE from 10.10.253.164 contains NLRIs for IPv4-Unicast AF which is not configured and/or not negotiated under the neighbor
>> bgp[1047]: [rtr]: UPDATE from 10.10.253.164 contains nh 10.10.253.164/32, gw_afi 0, flags 0x0, nlri_afi 8
>> bgp[1047]: [rtr] (vpn6u): Received UPDATE from 10.10.253.164 with attributes:
>> bgp[1047]: [rtr] (vpn6u): nexthop 10.10.253.164/32, origin ?, localpref 100, metric 0, extended community RT:1241:109
>> bgp[1047]: [rtr] (vpn6u): Received prefix 2ASN:1241:109:2a02:2148:2:10::10/127 (path ID: none) with MPLS label 2689 from neighbor 10.10.253.164
>>
>> which leads to this:
>>
>>    Network            Next Hop            Metric LocPrf Weight Path
>> Route Distinguisher: 1241:109
>> *>i2a02:2148:2:10::10/127
>>                       10.10.253.164            0    100      0 ?
>>
>>
>>
>> When using another 6VPE/RR pair (both ASR001, 15.1(3)S3), next-hop is fine.
>>
>> PE (ASR001, 15.1(3)S3)
>> ----------------------
>> BGP(5): (base) 10.10.231.4 send UPDATE (format) [1241:141]2A02:2148:10:20::20/127, next ::FFFF:10.10.253.165, label 4169, metric 0, path 65141, extended community RT:1241:141
>>
>>
>> RR (ASR001, 15.1(3)S3)
>> ----------------------
>> BGP: nbr_topo global 10.10.253.165 VPNv6 Unicast:base (0x7FB919BC17D0:1) rcvd Refresh Start-of-RIB
>> BGP: nbr_topo global 10.10.253.165 VPNv6 Unicast:base (0x7FB919BC17D0:1) refresh_epoch is 2
>> BGP(5): 10.10.253.165 rcvd UPDATE w/ attr: nexthop ::FFFF:10.10.253.165, origin ?, localpref 100, metric 0, merged path 65141, AS_PATH , extended community RT:1241:141
>>
>> which leads to this:
>>
>>    Network          Next Hop            Metric LocPrf Weight Path
>> Route Distinguisher: 1241:141
>> *>i2A02:2148:10:20::20/127
>>                     ::FFFF:10.10.253.165
>>                                              0    100      0 65141 ?
>>
>> Before going into sniffing the packets on the ASR9k and/or opening a SR, any ideas why ASR9k thinks it's IPv4-Unicast AF? Is "nlri_afi 8" something to worry about?
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>