WG: Problems configuring multihop BGP setup
I'am sorry, the ascii graphic was somehow wrapped a bit strangely. Here is a better version of it (now using the correct AS-Numbers): +-----------------+ | AS 60007 | |10.70.0.1/16| | | +-------+--------+ | 172.16.18.1/30 | | 172.16.18.2/30 +-------+--------+ | AS 60002 | |10.20.0.1/16| | | +-------+--------+ | 172.16.96.1/30 | | 172.16.96.2/30 +-------+--------+ | AS 60005 | |10.50.0.1/16| | | +-----------------+ On 22-07-2021 15:43, Rainer Kulow wrote:
Hello bird community,
I am trying to establish complete connectivity using BGP in the following setup containing three AS with direct links:
172.16.18.1/30 172.16.18.2/30 172.16.96.1/30 172.16.96.2/30 +--------------+ +--------------+ +--------------+ | AS 60007 +---------------------------+ AS 60002 +---------------------------+ AS 60005 | +--------------+ +--------------+ +--------------+ 10.70.0.1/16 10.20.0.1/16 10.50.0.1/16
The goal is that every address from one of the /16 networks can reach all addresses in the other /16 networks.
My current setup (here for the middle AS, the others are configured analogously): AS 60002 has three network cards, one with 172.16.18.2, one with 172.16.96.1 and one 10.20.0.1.
log syslog all; router id 10.20.0.1;
# interface scan every 10s protocol device { scan time 10; }
# no automaic generated direct routes to all network interfaces protocol direct { disabled; }
# synchronize BIRD routing tables with the OS kernel protocol kernel { ipv4 { import all; export all; }; merge paths on; }
# static IPv4 routes protocol static static1{ ipv4; route 10.20.0.0/16 via 10.20.0.1; }
# BGP peers template bgp bgp_peer{ local as 60002; multihop;
ipv4 { import filter { if proto = "static1" then reject; accept; }; export all; next hop self; };
}
protocol bgp a_b from bgp_peer { description "BGP a-b"; neighbor 172.16.18.1 as 60007; }
protocol bgp b_c from bgp_peer { description "BGP b-c"; neighbor 172.16.96.2 as 60005; }
If I delete "multihop" and "next hop self" from the template, I get all routes, but can only ever ping the closest AS. With "multihop" I also get all routes, but the routes to other AS are marked as unreachable. I would be glad if someone could tell me how to realize this multihop scenario. It would also be interesting that the solution scales, so that I can hang, for example, more AS in the chain above.
Thanks in advance, Best regards, Rainer
Hello, Why do you want your BGP sessions to be multihop? If you have direct links, it is better if they are direct. From the first sight, you have "protocol direct" disabled. This may cause your routes to be "unreachabe" and that is why they are not propagated correctly. On Thu, Jul 22, 2021 at 4:13 PM Rainer Kulow <rainer.kulow@online.de> wrote:
I'am sorry, the ascii graphic was somehow wrapped a bit strangely.
Here is a better version of it (now using the correct AS-Numbers):
+-----------------+ | AS 60007 | |10.70.0.1/16| | | +-------+--------+ | 172.16.18.1/30 | | 172.16.18.2/30 +-------+--------+ | AS 60002 | |10.20.0.1/16| | | +-------+--------+ | 172.16.96.1/30 | | 172.16.96.2/30 +-------+--------+ | AS 60005 | |10.50.0.1/16| | | +-----------------+
On 22-07-2021 15:43, Rainer Kulow wrote:
Hello bird community,
I am trying to establish complete connectivity using BGP in the following setup containing three AS with direct links:
172.16.18.1/30 172.16.18.2/30 172.16.96.1/30 172.16.96.2/30 +--------------+ +--------------+ +--------------+ | AS 60007 +---------------------------+ AS 60002 +---------------------------+ AS 60005 | +--------------+ +--------------+ +--------------+ 10.70.0.1/16 10.20.0.1/16 10.50.0.1/16
The goal is that every address from one of the /16 networks can reach all addresses in the other /16 networks.
My current setup (here for the middle AS, the others are configured analogously): AS 60002 has three network cards, one with 172.16.18.2, one with 172.16.96.1 and one 10.20.0.1.
log syslog all; router id 10.20.0.1;
# interface scan every 10s protocol device { scan time 10; }
# no automaic generated direct routes to all network interfaces protocol direct { disabled; }
# synchronize BIRD routing tables with the OS kernel protocol kernel { ipv4 { import all; export all; }; merge paths on; }
# static IPv4 routes protocol static static1{ ipv4; route 10.20.0.0/16 via 10.20.0.1; }
# BGP peers template bgp bgp_peer{ local as 60002; multihop;
ipv4 { import filter { if proto = "static1" then reject; accept; }; export all; next hop self; };
}
protocol bgp a_b from bgp_peer { description "BGP a-b"; neighbor 172.16.18.1 as 60007; }
protocol bgp b_c from bgp_peer { description "BGP b-c"; neighbor 172.16.96.2 as 60005; }
If I delete "multihop" and "next hop self" from the template, I get all routes, but can only ever ping the closest AS. With "multihop" I also get all routes, but the routes to other AS are marked as unreachable. I would be glad if someone could tell me how to realize this multihop scenario. It would also be interesting that the solution scales, so that I can hang, for example, more AS in the chain above.
Thanks in advance, Best regards, Rainer
Hello, Thank you very much for your response. Actually, this is just an extracted example from a larger setup to show the problem in a simpler way. Therefore, the use of BGP seems perhaps a bit superfluous here. In fact, you were absolutely right with your guess. Using protocol direct { ipv4; } everything works as desired. Thanks, Rainer On 22-07-2021 18:23, Alexander Zubkov wrote:
Hello,
Why do you want your BGP sessions to be multihop? If you have direct links, it is better if they are direct. From the first sight, you have "protocol direct" disabled. This may cause your routes to be "unreachabe" and that is why they are not propagated correctly.
On Thu, Jul 22, 2021 at 4:13 PM Rainer Kulow <rainer.kulow@online.de> wrote:
I'am sorry, the ascii graphic was somehow wrapped a bit strangely.
Here is a better version of it (now using the correct AS-Numbers):
+-----------------+ | AS 60007 | |10.70.0.1/16| | | +-------+--------+ | 172.16.18.1/30 | | 172.16.18.2/30 +-------+--------+ | AS 60002 | |10.20.0.1/16| | | +-------+--------+ | 172.16.96.1/30 | | 172.16.96.2/30 +-------+--------+ | AS 60005 | |10.50.0.1/16| | | +-----------------+
On 22-07-2021 15:43, Rainer Kulow wrote:
Hello bird community,
I am trying to establish complete connectivity using BGP in the following setup containing three AS with direct links:
172.16.18.1/30 172.16.18.2/30 172.16.96.1/30 172.16.96.2/30 +--------------+ +--------------+ +--------------+ | AS 60007 +---------------------------+ AS 60002 +---------------------------+ AS 60005 | +--------------+ +--------------+ +--------------+ 10.70.0.1/16 10.20.0.1/16 10.50.0.1/16
The goal is that every address from one of the /16 networks can reach all addresses in the other /16 networks.
My current setup (here for the middle AS, the others are configured analogously): AS 60002 has three network cards, one with 172.16.18.2, one with 172.16.96.1 and one 10.20.0.1.
log syslog all; router id 10.20.0.1;
# interface scan every 10s protocol device { scan time 10; }
# no automaic generated direct routes to all network interfaces protocol direct { disabled; }
# synchronize BIRD routing tables with the OS kernel protocol kernel { ipv4 { import all; export all; }; merge paths on; }
# static IPv4 routes protocol static static1{ ipv4; route 10.20.0.0/16 via 10.20.0.1; }
# BGP peers template bgp bgp_peer{ local as 60002; multihop;
ipv4 { import filter { if proto = "static1" then reject; accept; }; export all; next hop self; };
}
protocol bgp a_b from bgp_peer { description "BGP a-b"; neighbor 172.16.18.1 as 60007; }
protocol bgp b_c from bgp_peer { description "BGP b-c"; neighbor 172.16.96.2 as 60005; }
If I delete "multihop" and "next hop self" from the template, I get all routes, but can only ever ping the closest AS. With "multihop" I also get all routes, but the routes to other AS are marked as unreachable. I would be glad if someone could tell me how to realize this multihop scenario. It would also be interesting that the solution scales, so that I can hang, for example, more AS in the chain above.
Thanks in advance, Best regards, Rainer
On Thu, Jul 22, 2021 at 10:04:29PM +0200, Rainer Kulow wrote:
Hello,
Thank you very much for your response. Actually, this is just an extracted example from a larger setup to show the problem in a simpler way. Therefore, the use of BGP seems perhaps a bit superfluous here.
In fact, you were absolutely right with your guess. everything works as desired.
Hello Yes, there is the option 'gateway', which controls how immediate next hops are computed from bgp_next_hop attributes. It uses different defaults for direct or multihop sessions: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#bgp-gateway For multihop, recursive mode is used and bpg_next_hop is resolved through local / IGP routes, so you need such routes in the routing table (e.g. from Direct or OSPF protocols).
If I delete "multihop" and "next hop self" from the template, I get all routes, but can only ever ping the closest AS.
IMHO it should work without 'multihop' and 'next hop self' and that would be the natural approach. My first guess why you can ping only the closest AS is that you do not propagate /30 connecting networks, just /16 networks, and trying ping from the router is uses src IP from the /30 connecting range (unless explicitly forced to use different one using -I option), so the destination router cannot answer ping back because it is missing the non-local /30 route. -- 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."
Thank you for the detailed explanation. I understand, since "multihop" was specified, it tried to resolve the gateway recursively - which didn't work because the matching routes were missing in the routing table. When I deleted "multihop", the next hop was taken directly from "bgp_next_hop", which does not need lookup from the route table. This was at least possible for the next AS, for the further ones logically not anymore. All right, thanks a lot! On 23-07-2021 02:32, Ondrej Zajicek wrote:
On Thu, Jul 22, 2021 at 10:04:29PM +0200, Rainer Kulow wrote:
Hello,
Thank you very much for your response. Actually, this is just an extracted example from a larger setup to show the problem in a simpler way. Therefore, the use of BGP seems perhaps a bit superfluous here.
In fact, you were absolutely right with your guess. everything works as desired.
Hello
Yes, there is the option 'gateway', which controls how immediate next hops are computed from bgp_next_hop attributes. It uses different defaults for direct or multihop sessions:
https://bird.network.cz/?get_doc&v=20&f=bird-6.html#bgp-gateway
For multihop, recursive mode is used and bpg_next_hop is resolved through local / IGP routes, so you need such routes in the routing table (e.g. from Direct or OSPF protocols).
If I delete "multihop" and "next hop self" from the template, I get all routes, but can only ever ping the closest AS.
IMHO it should work without 'multihop' and 'next hop self' and that would be the natural approach. My first guess why you can ping only the closest AS is that you do not propagate /30 connecting networks, just /16 networks, and trying ping from the router is uses src IP from the /30 connecting range (unless explicitly forced to use different one using -I option), so the destination router cannot answer ping back because > it is missing the non-local /30 route.
-- 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."
On Fri, Jul 23, 2021 at 05:29:54PM +0200, Rainer Kulow wrote:
Thank you for the detailed explanation. I understand, since "multihop" was specified, it tried to resolve the gateway recursively - which didn't work because the matching routes were missing in the routing table.
When I deleted "multihop", the next hop was taken directly from "bgp_next_hop", which does not need lookup from the route table. This was at least possible for the next AS, for the further ones logically not anymore.
It should work even for the further ones, becase when EBGP router forwards a route to a different, it changes the bgp_next_hop to itself. So if you have AS1 - AS2 - AS3, then AS2 forwards route from AS1 to AS3, changes the bgp_next_hop to itself, so AS3 sees route to AS1 with bgp_next_hop to a router from AS2. -- 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)
-
Alexander Zubkov -
Ondrej Zajicek -
Rainer Kulow