Page MenuHomeVyOS Platform
Create Task
Maniphest T3453

IPv6 routes from BGP are not inserted into FIB
Closed, InvalidPublicBUG
Actions

Description

  • We receive the full IPv6 table from our ISP
  • The RIB contains ~100K routes but none of them are injected into FIB

Here is the setup:

r2# show protocols bgp | strip-private
 bgp XXXXXX {
     neighbor xxxx:xxxx:ffff::1 {
         address-family {
             ipv6-unicast {
                 prefix-list {
                     import DEFAULT-ROUTE-IPV6
                 }
                 route-map {
                     import NO-EXPORT-IN
                 }
                 soft-reconfiguration {
                     inbound
                 }
             }
         }
         ebgp-multihop 2
         password xxxxxx
         update-source xxxx:xxxx:b001:9ef:5400:03ff:fe48:1774
     }
     parameters {
         router-id xxx.xxx.128.17
     }
 }

here are routes received from BGP peer (routes are shown as IGP even though they are not and none of them is marked as valid)

r2:~$ show ipv6 bgp neighbors 2001:19f0:ffff::1 routes
BGP table version is 0, local router ID is 23.153.128.17, vrf id 0
Default local pref 100, local AS 396142
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
   2001:4:112::/48  2001:19f0:ffff::1
                                                           0 64515 65534 20473 6939 112 i
   2001:200::/32    2001:19f0:ffff::1
                                                           0 64515 65534 20473 3356 2914 2500 2500 i
   2001:200:900::/40
                    2001:19f0:ffff::1
                                                           0 64515 65534 20473 6939 2516 7660 7660 7660 i
...

here is the prefix count:

r2:~$ show ipv6 bgp neighbors 2001:19f0:ffff::1 prefix-counts
Prefix counts for 2001:19f0:ffff::1, IPv6 Unicast
PfxCt: 107885

Counts from RIB table walk:

              Adj-in: 107889
              Damped: 0
             Removed: 0
             History: 0
               Stale: 0
               Valid: 0
             All RIB: 107885
       PfxCt counted: 107885
             Useable: 107885

there are 3 filtered routes:

r2:~$ show ipv6 bgp neighbors 2001:19f0:ffff::1 filtered-routes
BGP table version is 0, local router ID is 23.153.128.17, vrf id 0
Default local pref 100, local AS 396142
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> ::/0             2001:19f0:ffff::1
                                                           0 64515 i
*> 2001:19f0:b000:8088::33/128
                    2001:19f0:ffff::1
                                             0             0 64515 ?
*> 2001:19f0:ffff::1/128
                    2001:19f0:ffff::1
                                             0             0 64515 ?

Total number of prefixes 3

and here is the FIB:

r2:~$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

K>* ::/0 [0/1024] via fe80::fc00:3ff:fe48:1774, eth0, 00:28:57
C>* 2001:19f0:b001:9ef::/64 is directly connected, eth0, 00:28:58
S>* 2606:6d00:19f:a800::/56 [1/0] is directly connected, eth0, 00:28:56
C>* 2620:18:6000:bb00::/64 is directly connected, dum0, 00:29:00
C * fe80::/64 is directly connected, eth0, 00:28:57
C>* fe80::/64 is directly connected, lo, 00:29:00
C * fe80::/64 is directly connected, dum0, 00:29:00

As you can see, there is no BGP routes present at all

Details

Version
VyOS 1.3.0-rc3
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

dtoux created this task.Apr 2 2021, 7:17 AM
dtoux added a comment.Apr 2 2021, 8:08 AM

I think the presence of the kernel default route may be the problem. It comes from RA through autoconf option on the interface. I will do some more testing.

c-po subscribed.Apr 2 2021, 8:24 AM

show ipv6 route lists you the forwarding path - FIB
show ipv6 bgp or show ipv6 route bgp will show you the rib

K>* ::/0 [0/1024] via fe80::fc00:3ff:fe48:1774, eth0, 00:28:57

your kernel route has an administrative distance of 0 which outwiegths the default BGP distance of 200

dtoux added a comment.EditedMay 1 2021, 5:26 AM

Hmm, all other routes have longer prefixes, so they should take precedence. As far as I understand the priority is prefix length (longest first) -> admin distance -> metric. So, your explanation contradicts this unless I miss something.

c-po added a comment.May 1 2021, 7:10 AM

I see no connected network in your FIB for 2001:19f0:ffff::1 I guess that's the reason.

I do not see any problem with 1.3.0-rc3 on IPv6 BGP

BGP table version is 18072790, local router ID is 194.145.151.251, vrf id 0
Default local pref 100, local AS 12817
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i2001::/32        2001:1578:200:ffff::a
                                                  400      0 6939 i
*>i2001:4:112::/48  2001:1578:200:ffff::a
                                                  400      0 6939 112 i
*>i2001:200::/32    2001:1578:200:ffff::a
                                                  400      0 6939 2914 2500 2500 i
dtoux added a comment.May 2 2021, 12:02 AM

The 2001:19f0:ffff::1 is the neighbour, it is accessible via the Kernel route and I'm able to pull routes from it. The setup is multihop. But I think you are on something. I think the peer should return the gateway as the next hop and not itself. I'm experimenting with Vultr and their setup is questionable, so this is just one more thing that they messed up. Anyhow, thanks for your help. Feel free to close the ticket.

c-po closed this task as Invalid.May 2 2021, 10:59 AM
syncer moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.Nov 6 2021, 11:43 AM
syncer edited projects, added VyOS 1.3 Equuleus (1.3.0); removed VyOS 1.3 Equuleus.Aug 29 2022, 12:16 PM
syncer moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus (1.3.0) board.