Exchanging IPv6 Prefixes over IPv4 BGP session IOS-XR

Another notable (good) difference that I've noticed on IOS-XR is how it handles prefixes for a specific AFI/SAFI (IPv6 Unicast in this case), exchanged over a different AFI/SAFI session (IPv4 unicast). 

With regular IOS, we end up with next hop addressess that look like this: 

 

R22#show bgp ipv6 unicast  

BGP table version is 3, local router ID is 10.20.20.20

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

 

     Network          Next Hop            Metric LocPrf Weight Path

 *   2001:10:1:7::/64 ::FFFF:10.19.20.19

 

And as can be seen, unless we change this NH , then these exchanged prefixes will not be considered for best path. 

 

With IOS-XR, this happens automatically! 

 

 

RP/0/0/CPU0:RT1#show run router bgp

Wed Sep 25 18:44:05.717 UTC

router bgp 1

 address-family ipv4 unicast

  network 1.1.1.1/32

 !

 address-family ipv6 unicast

  network 2001::1/128

 !

 neighbor 10.1.12.2

  remote-as 2

  address-family ipv4 unicast

   route-policy PASS in

   route-policy PASS out

  !

  address-family ipv6 unicast

   route-policy PASS in

   route-policy PASS out

 

 

As can be seen, the session is established using an IPv4 unicast session. Then IPv6 prefixes are exchanged over that session. On the other side, another IOS-XR box properly decodes what the next hop is supposed to be =) 

 

RP/0/0/CPU0:RT2#show bgp ipv6 unicast

Wed Sep 25 18:45:34.291 UTC

BGP router identifier 192.168.1.2, local AS number 2

Status codes: s suppressed, d damped, h history, * valid, > best

              i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network            Next Hop            Metric LocPrf Weight Path

*> 2001::1/128        2001:10:1:12::1          0             0 1 i

*> 2001::2/128        ::   

 

From this quick example, I have seen that IOS-XR router advertising the prefix actually sends the proper IPv6 next hop. This way, it's not up to the receiving router to "decipher" what the correct next hop should be. My IOS-XR router (RT1) is doing the advertisement and properly setting the NH attribute when it sends the route to RT2:

 

RP/0/0/CPU0:RT1#show bgp ipv6 unicast neighbors 10.1.12.2 advertised-route$

Wed Sep 25 18:49:18.846 UTC

Network            Next Hop        From            AS Path

2001::1/128        2001:10:1:12::1 Local           i

 

If I look on a regular IOS router and check out "show bgp ipv6 unicast neigh x.x.x.x advertised" I will see that the NH attribute is set to "::"...the other side is going to have a fun time trying to decode this. 

 

XR2#show bgp ipv6 unicast neighbors 10.19.20.19 advertised-routes 

     Network          Next Hop            Metric LocPrf Weight Path

 *>  2001:10:19:20::/64

                       ::                       0         32768 i

 *>  2001:10:20:20::/64

                       ::                       0         32768 i

 

 

 

+1 on IOS-XR for doing this!

 

Pablo

 

Comments

  • Forgot to add that on the IOS side, if we are not allowed to just run a new session over IPv6, then the fix is just to use a route-map and change the NH to the IPV4 address of the next hop!

    This always confuses me. If I change the NH to the V4 address of the interface it works for me. I get the hex converted representation of the address though:

     

    route-map NEXT_HOP permit 10

     set ip next-hop 10.19.20.19

    !

    router bgp 65001

     address-family ipv6

      neighbor 10.19.20.19 activate

      neighbor 10.19.20.19 route-map NEXT_HOP in

    !

    !

    XR2#show bgp ipv6 unicast 

    BGP table version is 7, local router ID is 10.20.20.20

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

                  r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

                  x best-external, a additional-path, c RIB-compressed, 

    Origin codes: i - IGP, e - EGP, ? - incomplete

    RPKI validation codes: V valid, I invalid, N Not found

     

         Network          Next Hop            Metric LocPrf Weight Path

     *>  2001:10:1:7::/64 A13:1413::FFFF:A13:1413

                                                                  0 26 26 i

     *>  2001:10:2:8::/64 A13:1413::FFFF:A13:1413

                                                                  0 26 26 i

     *>  2001:10:7:7::/64 A13:1413::FFFF:A13:1413

                                                                  0 26 26 i

     *>  2001:10:8:8::/64 A13:1413::FFFF:A13:1413

     

    If we convert this to decimal, this is what we get:

    10.19.20.19::FFFF:10.19.20.19

     

    It sure is the correct NH, and it works!

     

    Pablo

     

  • I ran into this very issue a while back when doing IPv4/IPv6 BGP peerings using an already established IPv4 BGP neighbor connection.

    Yes in XR, it just works.  In IOS, it will send the incorrect next-hop and it needs to be set on the IOS side.  You can also just set the "ipv6 next-hop" as well. (if you want it to make a little more sense).  

    I ran into a problem with a customer peering with this, and tried to fix it on the ingress on the XR side.  I tried changing the the IPv6 prefixes they were sending me with the incorrect hop.  XR will NOT allow you to change the NH for prefixes you receive, at least not to an IPv6 next-hop.  I'm a little baffled as to why exactly and even opened a TAC case on it, but apparently, that's "by design".

     

  • With IOS-XR, this happens automatically! 

    Another reason why I LOVE XR code!

    -Warjack

  •  You can also just set the "ipv6 next-hop" as well. (if you want it to make a little more sense).  

    I tried doing this first since this made more sense to me. However, it did not work. The NH was changed properly with the route-maps, however, the prefix was not considered for best-path because it showed up as "inaccessible". 

    I guess this varies from version to version...I was running some recent code (15.2S). I don't get why it shows up as inaccessible though. The NH is clearly accessible! I was setting the NH to the directly connected IPv6 address, the same NH that IOS-XR properly sets...but for whatever reason it just does not like it. 

    Setting it to the IPv4 NH with the route-maps is what worked for me. 

    Another interesting thing to try is to run the BGP session over native IPv6 (peer using directly connected IPv6 addresses on the links). Then activate AFI/SAFI IPv4 unicast. This creates the same interesting issue, where the NH address set on the updates is not properly resolved. 

     

    Pablo

  • I tried doing this first since this made more sense to me. However, it did not work. The NH was changed properly with the route-maps, however, the prefix was not considered for best-path because it showed up as "inaccessible". 

    It does work, we've been doing it in production for a while.  The only thing different is I believe the customer side has a /32 static route to our routers loopback. (they have multiple paths)  So they're setting the NH to our IPv6 loopback address.

    On the our side (the XR side) I could not set the IPv6 NH on prefixes they were sending to us; which baffles me.

    -v10d

     

  • CAn't get this to work myself between two IOS routers. Any ideas?

    R2(config-router-af)#do sho bgp ipv6 uni summ                
    BGP router identifier 2.2.2.2, local AS number 12
    BGP table version is 2, main routing table version 2
    1 network entries using 152 bytes of memory
    1 path entries using 76 bytes of memory
    1/0 BGP path/bestpath attribute entries using 124 bytes of memory
    1 BGP AS-PATH entries using 24 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
    BGP using 472 total bytes of memory
    BGP activity 13/6 prefixes, 17/10 paths, scan interval 60 secs

    Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
    10.1.2.1        4           12      41      40        2    0    0 00:33:12        1
    R2(config-router-af)#do sho bgp ipv6 uni 2001:10:1:1::/64    
    BGP routing table entry for 2001:10:1:1::/64, version 0
    Paths: (1 available, no best path)
      Not advertised to any peer
      Local
        A01:201::FFFF:A01:201 (inaccessible) from 10.1.2.1 (1.1.1.1)
          Origin IGP, metric 0, localpref 100, valid, internal
    R2(config-router-af)#do sho run | s V6      
      neighbor 10.1.2.1 route-map NEXT_HOP_V6 in
    route-map NEXT_HOP_V6 permit 10
     set ip next-hop 10.1.2.1

  • R2(config-router-af)#do sho run | s V6      
      neighbor 10.1.2.1 route-map NEXT_HOP_V6 in
    route-map NEXT_HOP_V6 permit 10
     set ip next-hop 10.1.2.1

     

    I'm not going to say it will work by setting an IPv4 next-hop.  To me that seems like a bad assumption.  If it works, so be it.  But to me it doesn't make sense.  I know for a fact that it works by setting an IPv6 next-hop.

    -v10d

  • I think I tried with v6 too but will have another look. thanks.

  • I think I tried with v6 too but will have another look. thanks.

     

    Keep in mind I had a problem when going from IOS to XR.  I could not change the IPv6 next-hop in XR for prefixes learned from IOS.  (at least not in XR 4.1.0).  Opening a Cico TAC case on it resulted in "thats by design".   It does work changing the next-hop in IOS before sending it to XR, so I assume it works that way from IOS to IOS.

    I have not tried changing in on the receiver side between IOS to IOS.  So your results may show the same results as XR, or not.

    -v10d

  • Is this 6PE ? For me it worked like a charm.

  • You will need to use v6 next-hop using "set ipv6 next-hop" command. I think in IOS-XR, you might get BGP to accept the v6 routes over v4 using v4 next-hop, but I wonder how traffic is going to flow. My guess is, you can't. So setting v6 addresses on interface and next-hop makes sense.

    Regards,

    AB.

  • So whats the consensus here? Doesnt work with ipv4 next hop on IOS?  I tried it again this morning and I can't get the next hop accessible. I also can't use ipv6 next-hop cos the whole purpose is I dont have a v6 address on the far side.

  • So whats the consensus here? Doesnt work with ipv4 next hop on IOS?  I tried it again this morning and I can't get the next hop accessible. I also can't use ipv6 next-hop cos the whole purpose is I dont have a v6 address on the far side.

     

    I don't believe it will work and that wouldn't even make sense.  My solution for setting the IPv6 next-hop obviously assumes you have a reachable v6 next-hop. (dual stacked neighbors, but with a single BGP transport connection between them)  If you're trying to forward to V6 destinations but have no V6 next hop you're going to have to use somethingl ike 6PE or 6VPE.

    -v10d

  • So whats the consensus here? Doesnt work with ipv4 next hop on IOS?  I tried it again this morning and I can't get the next hop accessible. I also can't use ipv6 next-hop cos the whole purpose is I dont have a v6 address on the far side.

    I don't think this is even at all possible is there is no IPv6 running between PE-CE. Is this what you meant when you said "I dont have a v6 address on the far side"?

     For me, running on IOS 15.2.4, the ONLY thing that worked was setting the IPv4 next hop. I think this is because the session is established over IPv4. IOS-XR handles this beautifully though and sets the NH to the IPv6 address even though the session is running over IPv4 (PE-CE link would HAVE to be running IPv6 as well...dual stacked on both sides).

     If you're trying to forward to V6 destinations but have no V6 next hop you're going to have to use somethingl ike 6PE or 6VPE.

    Running 6PE or 6VPE would not help if there is no v6 running between PE-CE.

     

  • I bet there is some inconsistency here. If I set ip next-hop it doesn't work, as follows:

     

    R1(config)#do sh bgp vpnv6 un all

    BGP table version is 11, local router ID is 19.19.19.19

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

                  r RIB-failure, S Stale, m multipath, b backup-path, x best-external

    Origin codes: i - IGP, e - EGP, ? - incomplete

     

       Network          Next Hop            Metric LocPrf Weight Path

    Route Distinguisher: 26:65001 (default for vrf ABC)

    *>i2001:10:1:7::/64 ::FFFF:1.1.1.1           0    100      0 65001 i

    *>i2001:10:2:8::/64 ::FFFF:2.2.2.2           0    100      0 65001 i

    *>i2001:10:7:7::/64 ::FFFF:1.1.1.1           0    100      0 65001 i

    *>i2001:10:8:8::/64 ::FFFF:2.2.2.2           0    100      0 65001 i

    *  2001:10:19:20::/64

                        A13:1414::FFFF:A13:1414

                                                 0             0 65001 i

    *  2001:10:20:20::/64

                        A13:1414::FFFF:A13:1414

                                                 0             0 65001 i

     

    R1(config)#do sh bgp vpnv6 un all 2001:10:19:20::/64

    BGP routing table entry for [26:65001]2001:10:19:20::/64, version 6

    Paths: (1 available, no best path)

      Not advertised to any peer

      65001

        A13:1414::FFFF:A13:1414 (inaccessible) from 10.19.20.20 (10.20.20.20)

          Origin IGP, metric 0, localpref 100, valid, external

          Extended Community: RT:26:65001

     

    R1(config)#do sh run | se router bgp|route-map

    address-family ipv6 vrf ABC

      no synchronization

      neighbor 10.19.20.20 remote-as 65001

      neighbor 10.19.20.20 activate

      neighbor 10.19.20.20 as-override

      neighbor 10.19.20.20 route-map NEXT_HOP in

     exit-address-family

    route-map NEXT_HOP permit 10

     set ip next-hop 10.19.20.20

     

    What worked for me was using set ipv6 next-hop:

     

    XR1(config-router-af)#do sh bgp vpnv6 un all

    BGP table version is 11, local router ID is 19.19.19.19

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

                  r RIB-failure, S Stale, m multipath, b backup-path, x best-external

    Origin codes: i - IGP, e - EGP, ? - incomplete

     

       Network          Next Hop            Metric LocPrf Weight Path

    Route Distinguisher: 26:65001 (default for vrf ABC)

    *>i2001:10:1:7::/64 ::FFFF:1.1.1.1           0    100      0 65001 i

    *>i2001:10:2:8::/64 ::FFFF:2.2.2.2           0    100      0 65001 i

    *>i2001:10:7:7::/64 ::FFFF:1.1.1.1           0    100      0 65001 i

    *>i2001:10:8:8::/64 ::FFFF:2.2.2.2           0    100      0 65001 i

    *> 2001:10:19:20::/64

                        2001:10:19:20::20

                                                 0             0 65001 i

    *> 2001:10:20:20::/64

                        2001:10:19:20::20

                                                 0             0 65001 i

     

     address-family ipv6 vrf ABC

      no synchronization

      neighbor 10.19.20.20 remote-as 65001

      neighbor 10.19.20.20 activate

      neighbor 10.19.20.20 as-override

      neighbor 10.19.20.20 route-map NEXT_HOP in

     

    route-map NEXT_HOP permit 10

     set ipv6 next-hop 2001:10:19:20::20

     

     

     

  • I found a handy-dandy command that I did not know about before! It helps out with this exact issue that we are having.

     

    R3(config-router)#no bgp default ipv?

    ipv4-unicast  ipv6-nexthop  

     

    I actually stumbled upon it when doing "no bgp default ipv4-unicast". 

     

    The command is "no bgp default ipv6-nexthop"

     

    Here is the command reference for it:

     

    http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_01.html#wp2440923

     

    Hope it helps!

     

    Pablo

Sign In or Register to comment.