Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: NSP

wrong next-hop in 6VPE on ASR9k used as RR

 

 

Cisco nsp RSS feed   Index | Next | Previous | View Threaded


achatz at forthnetgroup

Aug 14, 2013, 9:39 AM

Post #1 of 3 (446 views)
Permalink
wrong next-hop in 6VPE on ASR9k used as RR

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?

--
Tassos

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


achatz at forthnetgroup

Aug 18, 2013, 2:17 PM

Post #2 of 3 (402 views)
Permalink
Re: wrong next-hop in 6VPE on ASR9k used as RR [In reply to]

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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


achatz at forthnetgroup

Oct 10, 2013, 2:49 AM

Post #3 of 3 (332 views)
Permalink
Re: wrong next-hop in 6VPE on ASR9k used as RR [In reply to]

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
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Cisco nsp RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.