2

In a setup with two routers and two upstreams, I've stumbled over an issue that for IPv6 routes only, none of the active paths are installed into the forwarding table of one of the routers (called router B below). IPv4 works without issues and the other router works the way as I'd expect it, although they are the same model and configs are very similar.

For example, some route that should be routed over the upstream connected to router B:

miho@ROUTER-B> show route 2a00:1450:4001:80f::200e 

inet6.0: 117422 destinations, 233492 routes (117210 active, 0 holddown, 212 hidden)
+ = Active Route, - = Last Active, * = Both

2a00:1450:4001::/48*[BGP/170] 03:00:15, localpref 100, from <UPSTREAM-B>
                      AS path: 2222 2914 15169 I, validation-state: unverified
                    >  to <UPSTREAM-B> via ae1.0
                    [BGP/170] 01:22:40, localpref 100
                      AS path: 1111 1111 1111 15169 I, validation-state: unverified
                    >  to <ROUTER-A> via ae0.0

miho@ROUTER-B> show route forwarding-table destination 2a00:1450:4001::
Routing table: default.inet6
Internet6:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
2a00:1450:4001::/48 user     1                   indr  1048576 116715
                              <ROUTER-A>         ucst      626     4 ae0.0

Routing table: __master.anon__.inet6
Internet6:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
default            perm     0                    rjct      558     1

(<ROUTER-A>, <ROUTER-B>, <UPSTREAM-A>, <UPSTREAM-B> are placeholders for the real addresses. 1111 is a placeholder for the ASN of upstream A, 2222 for upstream B)

Assuming I correctly read the above output, the best route (and selected as active path) would point to the directly connected router of upstream B. However, the forwarding table points to router A. Looking at the other router, the same destination points towards router B, which is actually the expected behaviour but now causes the packets to ping-pong between those devices until TTL is reached.

Any ideas why the routes aren't installed into the forwarding table?

BGP is operated with a partial view, to avoid an overful FIB — as that would have been my first guess. Also, there is nothing set under forwarding-options (= also no filters that could block the transfer into the forwarding table).


EDIT: in regards to the comment below, here is the output of show route ... extensive. 2a0d:fXXX::/64 is the subnet of router A and B, 2222:2222::/124 the subnet used for upstream B and 9999 the own AS:

miho@ROUTER-B> show route protocol bgp 2a00:1450:4001:80f:: extensive 

inet6.0: 117503 destinations, 233656 routes (117290 active, 0 holddown, 213 hidden)
2a00:1450:4001::/48 (2 entries, 1 announced)
TSI:
KRT queued (pending) change
  2a00:1450:4001::/48 -> {indirect(1048576)}=>{<UPSTREAM-B>}
Page 0 idx 0, (group local-ibgp-6 type Internal) Type 1 val 0x115fd964 (adv_entry)
   Advertised metrics:
     Flags: Nexthop Change
     Nexthop: Self
     Localpref: 100
     AS path: [9999] 2222 2914 15169 I
     Communities: 0:0 2222:888
    Advertise: 00000001
Path 2a00:1450:4001::
from 2222:2222::7
Vector len 4.  Val: 0
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 0
                Address: 0x591ce8c
                Next-hop reference count: 328038
                Source: 2222:2222::7
                Next hop: <UPSTREAM-B> via ae1.0, selected
                Session Id: 0x0
                State: <Active Ext>
                Local AS: 9999 Peer AS:  2222
                Age: 6:04:47 
                Validation State: unverified 
                Task: BGP_2222.2222:2222::7
                Announcement bits (3): 0-KRT 2-BGP_RT_Background 3-Resolve tree 3 
                AS path: 2222 2914 15169 I 
                Communities: 0:0 2222:888
                Accepted
                Localpref: 100
                Router ID: <UPSTREAM-B>
         BGP    Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Address: 0x591cae4
                Next-hop reference count: 338961
                Source: <ROUTER-A>
                Next hop type: Router, Next hop index: 626
                Next hop: <ROUTER-A> via ae0.0, selected
                Session Id: 0x147
                Protocol next hop: <ROUTER-A>
                Indirect next hop: 0x6011a04 1048576 INH Session ID: 0x148
                State: <Int Ext Changed>
                Inactive reason: AS path
                Local AS: 9999 Peer AS: 9999
                Age: 4:27:12    Metric2: 0 
                Validation State: unverified 
                Task: BGP_9999.<ROUTER-A>
                AS path: 1111 1111 1111 15169 I 
                Communities: 1111:1111 1111:64633
                Accepted
                Localpref: 100
                Router ID: <ROUTER-A>
                Indirect next hops: 1   
                        Protocol next hop: <ROUTER-A>
                        Indirect next hop: 0x6011a04 1048576 INH Session ID: 0x148
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: <ROUTER-A> via ae0.0
                                Session Id: 0x147
                2a0d:fXXX::/48 Originating RIB: inet6.0
                  Node path count: 1
                  Forwarding nexthops: 1
                    Next hop type: Interface
                    Nexthop: via ae0.0
5
  • 1
    Do you have a typo in the forwarding table output? Did you mean <ROUTER-A> as the nexthop given this output is from Router B? – ditrapanij Jun 7 at 11:40
  • @ditrapanij Ah, yes, thanks. It's the IP of router A of course. Fixed the question and checked the rest of the output; all placeholders should be correct now. – miho Jun 7 at 11:42
  • 1
    Have you looked at the 'show route ... detail or extensive' output if that reveals some more info ? – Rais Jun 7 at 12:33
  • @Rais: Yes, but I can't see anything suspicious. I've attached the output to the original question, if you want to have a look. In addition, yes, I also checked show log messages if there are any errors, but there aren't any. – miho Jun 7 at 13:00
  • 1
    Or there is actually something. Now that I look at it again: KRT queued (pending) change — don't think that section is supposed to be there. It says something like KRT in-kernel for routes of the other (working) router. – miho Jun 7 at 13:23
1

Thanks to @Rais comment, I checked the output of show route ... extensive again (added to question above too) and spotted that there was some KRT queued (pending) change mentioned.

Running show krt queue then showed:

miho@ROUTER-B> show krt queue 
<< few irrelevant lines removed here >>
High-priority change queue: 0 queued
High-priority add queue: 1 queued
                ADD nhtype Router index 0 (40759)
                    error 'ENOENT -- Item not found'
                    kqp '0x583bcc0'
<< few irrelevant lines removed here >>

Not really helpful on its own, but it caused me to check through all details again and I finally spotted: my upstream sends a different next-hop address than the router address, and that next-hop is outside the subnet used to communicate with the upstream. Fixing that also fixed the stuck routes (turns out we miss-communicated on the subnet size).

1
  • I was about to say the primary reason a route isn't accepted is the destination isn't reachable. – Ricky Jun 7 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.