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

[Tassos Chatzithomaoglou]

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