Resolve a BGP next-hop with another BGP route
Hello, It seems that bird can’t resolve the next-hop in that case. But there is no issue when the next-hop is announced by OSPF. bird> show route all for 45.91.127.1 Table master4: 45.91.127.0/24 unreachable [ibgp_hv02_ipv4 16:16:24.927 from 89.234.186.40] * (100/-) [i] Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.116 BGP.local_pref: 100 unreachable [ibgp_nominoe_ipv4 16:01:40.402 from 89.234.186.33] (100/-) [i] Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.116 BGP.med: 150 BGP.local_pref: 100 BGP.originator_id: 89.234.186.40 BGP.cluster_list: 89.234.186.33 bird> show route all for 89.234.186.116 Table master4: 89.234.186.116/32 unicast [ibgp_hv02_ipv4 16:21:11.352] * (100/0) [i] via 89.234.186.40 on enp3s0f1.33 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.40 BGP.local_pref: 100 unicast [ibgp_nominoe_ipv4 16:20:22.754 from 89.234.186.33] (100/0) [i] via 89.234.186.40 on enp3s0f1.33 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.40 BGP.med: 150 BGP.local_pref: 100 BGP.originator_id: 89.234.186.40 BGP.cluster_list: 89.234.186.33 But cisco works well: asbr01#sh ip route 45.91.127.1 Routing entry for 45.91.127.0/24 Known via "bgp 204092", distance 200, metric 150, type internal Last update from 89.234.186.116 00:07:07 ago Routing Descriptor Blocks: * 89.234.186.116, from 89.234.186.40, 00:07:07 ago Route metric is 150, traffic share count is 1 AS Hops 0 MPLS label: none asbr01#ping 45.91.127.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 45.91.127.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms asbr01# asbr01#sh ip route 89.234.186.116 Routing entry for 89.234.186.116/32 Known via "bgp 204092", distance 200, metric 150, type internal Last update from 89.234.186.40 01:13:29 ago Routing Descriptor Blocks: * 89.234.186.40, from 89.234.186.40, 01:13:29 ago Route metric is 150, traffic share count is 1 AS Hops 0 MPLS label: none Am I missing something? Regards, -- Alarig
On Sun, Sep 29, 2019 at 08:49:57PM +0200, Alarig Le Lay wrote:
Hello,
It seems that bird can’t resolve the next-hop in that case. But there is no issue when the next-hop is announced by OSPF.
Hello Yes. Technically it is not because the other route is also BGP, but because the other route is also recursive / also has indirect next hop. BIRD implements only one level of indirection. Is this a problem? Which use cases require more levels of indirections? -- 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 Ondrej, On 30/09/2019 01:52, Ondrej Zajicek wrote:
On Sun, Sep 29, 2019 at 08:49:57PM +0200, Alarig Le Lay wrote:
Hello,
It seems that bird can’t resolve the next-hop in that case. But there is no issue when the next-hop is announced by OSPF.
Hello
Yes. Technically it is not because the other route is also BGP, but because the other route is also recursive / also has indirect next hop. BIRD implements only one level of indirection.
Is this a problem? Which use cases require more levels of indirections?
I think so. In this case it’s legit for me. I have some hypervisors with few VMs (less than 100), so I’m routing each /32 IPv4 and /48 IPv6 addresses to each tap and doing BCP38 directly on the node. Those routes are advertised to my edges by BGP. (I will certainly do it differently when my FIB will be full of very specific routes, but for now it’s working very well) One of my customers wanted an additional range routed to his VM. So I added it to our routing system (which does `ip route add ${range} via ${vm}` at startup hook) and as such, the next-hop is the VM itself. The bird on the node learns the route well, I added the community to advertise the prefix to my upstreams, and as soon as the VM is shut down, I don’t receive any traffic on the range anymore. But, the bird on one of my edges does not resolve the next-hop and as such blackholes the traffic. As a workaround I added a 'next hop self', but design wise, I don’t need it here. (I don’t need it on the other parts of my network either :p) Regards, -- Alarig
On 30 September 2019 01:52:22 CEST, Ondrej Zajicek
Yes. Technically it is not because the other route is also BGP, but because the other route is also recursive / also has indirect next hop. BIRD implements only one level of indirection.
Is this a problem? Which use cases require more levels of indirections?
"The BGP Tunnel Encapsulation Attribute" is one example:
7. Recursive Next Hop Resolution > Suppose that:
o a given packet P must be forwarded by router R1;
o the path along which P is to be forwarded is determined by BGP UPDATE U1;
o UPDATE U1 does not have a Tunnel Encapsulation attribute;
o the next hop of UPDATE U1 is router R2;
o the best path to router R2 is a BGP route that was advertised in UPDATE U2;
o UPDATE U2 has a Tunnel Encapsulation attribute.
Then packet P MUST be sent through one of the tunnels identified in the Tunnel Encapsulation attribute of UPDATE U2. See Section 5 for further details.
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-13#section-7 /Mikma
On Mon, Sep 30, 2019 at 07:28:22PM +0200, mikma.bird@lists.m7n.se wrote:
On 30 September 2019 01:52:22 CEST, Ondrej Zajicek
Yes. Technically it is not because the other route is also BGP, but because the other route is also recursive / also has indirect next hop. BIRD implements only one level of indirection.
Is this a problem? Which use cases require more levels of indirections?
"The BGP Tunnel Encapsulation Attribute" is one example:
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-13#section-7
Hi That is an interesting draft, thanks. I read the old RFC 5512 and the sparate SAFI seemed to me as overengineered. It is true that applying and merging encapsulation attributes when recursive next hops are resolved would be another complexity to next hop resolution. We already have there code for MPLS, so some generic mechanism would be needed. -- 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."
participants (3)
-
Alarig Le Lay -
mikma.bird＠lists.m7n.se -
Ondrej Zajicek