Handling IPv6 BGP routes with :: next-hop
Hello! Yesterday we noticed a strange behavior of Bird 1.6.8 with handling one IPv6 BGP route:
birdc6 show route for 2a09:8387:ffff:: all BIRD 1.6.8 ready. 2a09:8387:ffff::/48 via 2001:7f8:63::f2 on bge0 [SIMTELECOM 2021-08-03 00:07:16] * (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 51972 BGP.next_hop: :: BGP.med: 0 BGP.local_pref: 100 BGP.community: (31210,31210) BGP.ext_community: (rt, 31210, 31210) via 2001:7f8:63::69 on bge0 [DATAGROUP2 2021-07-20 16:07:45] (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3326 51972 BGP.next_hop: 2001:7f8:63::69 fe80::2e21:7201:935e:37ce BGP.med: 510 BGP.local_pref: 100 BGP.community: (3326,3010) (3326,11001) (3326,22050) (3326,50990) (31210,31210) BGP.ext_community: (rt, 31210, 31210) via 2001:7f8:63::60 on bge0 [HE 2021-07-22 00:53:03] (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 6939 3326 51972 BGP.next_hop: 2001:7f8:63::60 fe80::629c:9fff:fe83:8c13 BGP.med: 0 BGP.local_pref: 100 BGP.community: (0,16509) (0,15169) (0,13335) (0,15133) (0,22822) (0,12989) (0,2906) (0,20940) (0,3255) (0,16265) (0,16276) (0,13188) (0,714) (0,32590) (0,48641) (0,49029) (31210,31210) BGP.ext_community: (rt, 31210, 31210) via 2001:7f8:63::f4 on bge0 [DATAGROUP 2021-07-07 11:00:57] (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3326 51972 BGP.next_hop: 2001:7f8:63::f4 fe80::ae4b:c8ff:fe96:67c3 BGP.med: 510 BGP.local_pref: 100 BGP.community: (3326,3010) (3326,11001) (3326,22050) (3326,50990) (31210,31210) BGP.ext_community: (rt, 31210, 31210)
The first (best) route has next-hop '::' and routers of some of our customers started dropping BGP sessions with 'Invalid next-hop' cause. I dumped packets coming from customer 2001:7f8:63::f2 and it is really sending next-hop as '::'. I enabled logging of 'gw' and 'from' route attributes for net 2a09:8387:ffff::/48, and I got the following: Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::f4 ---- from:2001:7f8:63::f4 Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::69 ---- from:2001:7f8:63::69 Aug 3 09:57:11 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::f2 ---- from:2001:7f8:63::f2 Aug 3 09:57:12 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::60 ---- from:2001:7f8:63::60 Thus 'gw' and 'from' variables both contain IPv6 address of the peer. But shouldn't 'gw' contain '::'? Due to that the checks like if gw != from then return false; fail. Please advice, thanks! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/
On Tue, 3 Aug 2021 at 09:13, Alexander Shikov <a.shikov@dtel-ix.net> wrote:
The first (best) route has next-hop '::' and routers of some of our customers started dropping BGP sessions with 'Invalid next-hop' cause.
I dumped packets coming from customer 2001:7f8:63::f2 and it is really sending next-hop as '::'.
I enabled logging of 'gw' and 'from' route attributes for net 2a09:8387:ffff::/48, and I got the following:
Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::f4 ---- from:2001:7f8:63::f4 Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::69 ---- from:2001:7f8:63::69 Aug 3 09:57:11 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::f2 ---- from:2001:7f8:63::f2 Aug 3 09:57:12 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::60 ---- from:2001:7f8:63::60
Thus 'gw' and 'from' variables both contain IPv6 address of the peer. But shouldn't 'gw' contain '::'?
Do you know what equipment the customer uses? (e.g. reverse lookup the IPv6 LL EUI-64 (*ff:fe*) of the customers' equipment and map the MAC to an OUI) Might be a configuration error on the customer side that the gw is not set with both an IPv6 and IPv6 LL address.
Hello! On Tue, Aug 03, 2021 at 15:36:02 +0200, Chriztoffer Hansen wrote:
Do you know what equipment the customer uses? (e.g. reverse lookup the IPv6 LL EUI-64 (*ff:fe*) of the customers' equipment and map the MAC to an OUI)
Might be a configuration error on the customer side that the gw is not set with both an IPv6 and IPv6 LL address.
Customer uses some sort of Hewlett Packard L3-switch. I understand that this is likely misconfiguration. The question was about route attributes. -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/
On Tue, Aug 03, 2021 at 10:13:09AM +0300, Alexander Shikov wrote:
Hello!
Yesterday we noticed a strange behavior of Bird 1.6.8 with handling one IPv6 BGP route:
birdc6 show route for 2a09:8387:ffff:: all BIRD 1.6.8 ready. 2a09:8387:ffff::/48 via 2001:7f8:63::f2 on bge0 [SIMTELECOM 2021-08-03 00:07:16] * (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 51972 BGP.next_hop: :: BGP.med: 0 BGP.local_pref: 100 BGP.community: (31210,31210) BGP.ext_community: (rt, 31210, 31210)
The first (best) route has next-hop '::' and routers of some of our customers started dropping BGP sessions with 'Invalid next-hop' cause.
I dumped packets coming from customer 2001:7f8:63::f2 and it is really sending next-hop as '::'.
I enabled logging of 'gw' and 'from' route attributes for net 2a09:8387:ffff::/48, and I got the following:
Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::f4 ---- from:2001:7f8:63::f4 Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::69 ---- from:2001:7f8:63::69
Thus 'gw' and 'from' variables both contain IPv6 address of the peer. But shouldn't 'gw' contain '::'?
Hello The bgp_next_hop is ::, 'gw' a is different attribute - immediate next hop computed from bgp_next_hop, local routing table and other factors. That is shown after 'via' in 'show route' output. When a route is propagated on a route server or a route reflector, original bgp_next_hop is kept. BTW, bgp_next_hop :: is clearly invalid (without attached link-local bgp_next_hop). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi! On Tue, Aug 03, 2021 at 16:25:09 +0200, Ondrej Zajicek wrote:
The bgp_next_hop is ::, 'gw' a is different attribute - immediate next hop computed from bgp_next_hop, local routing table and other factors. That is shown after 'via' in 'show route' output. When a route is propagated on a route server or a route reflector, original bgp_next_hop is kept.
Dear Ondrej, thank you for pointing on that. I've corrected a checking to filter out invalid route. Now it works like it should. -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/
participants (3)
-
Alexander Shikov -
Chriztoffer Hansen -
Ondrej Zajicek