Best practices for redundant iBGP/eBGP route distribution? [bird 2.0.7]
Good morning, I was wondering, what is the best practice is for running 2 data centers, each with one uplink and a dark fiber in between them? I think it's pretty much a standard situation, but will show our setup and assumptions as well: upstream 1 upstream 2 | | dc1--darkfiber----dc 2 Additional each DC has 2 routers: dc1: dc2: |---router1 ------- router 1 | / | / | /--------/ | router2---------router2 | | |---------------------| (both routers are connected to each other and both routers are connected to each upstream) The objective is to stay online in each DC as long as possible, so in theory: - upstream 1 can die or - upstream 2 can die or - the darkfiber can die And in each of the situations, both DCs should still be reachable from outside and both be reaching itself. Question 1: Is "direct;" is the right protocol for all links? As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations. Question 2: Is "next hop self ebgp;" the correct answer to the Invalid NEXT_HOP attribute? This way we rewrote routes from upstreams and generally speaking it seems to work. However, this still fails iBGP routes: router1.dc1 cannot reach a network in dc2 that is configured to be statically routed to another host in dc2. My assumption is that this is the problem of the "gateway direct" resolution, even though the documentation kind of indicates that this should be resolved via the next hop of the dc2. Originally I'd have thought that not even "next hop self ebgp" is required, as the next hop attribute is coming from the peering router, so the route should be directly reachable. Question 3: Is "not direct" (aka multiphop) the right thing for iBGP? So our dcs are directly connected vi layer 2, but the default for iBGP is multihop. If we omit the "direct" keyword, the result is that no routes are in the end imported from the other DC and that we get various warnings like the following in syslog: Dec 16 00:58:35 router2 daemon.warn bird: Next hop address 2a0a:e5c0:1:8::5 resolvable through recursive route for 2a0a:e5c0:1:8::/64 So at this stage it's a bit unclear to me, how proper iBGP redistribution / next hop resolution should work with bird. Question 4: How to (not) announce umbrella networks? So both data centers are reachable within the 2a0a:e5c0::/29 prefix and all routers have a statement route 2a0a:e5c0::/29 unreachable; in the static protocol. However if the dark fiber goes down, it is not clear that / how the upstreams should / will propagate the smaller (per DC) /48s. If we remove the full /29 announcement, we might run into the problem that a packet is being sent out through one upstream and returns back to us and thus creates a routing loop. While the last question is eBGP specific, the main question of this thread still is: how do you correctly distribute internal and external routes via iBGP in your DCs? Thanks for any hints in the right direction. Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
Follow up on
Question 1: Is "direct;" is the right protocol for all links?
As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations.
the routers have import/export all statements, but I see the following behaviour: dc1: bird> show route for 2a0a:e5c1:111:111:6aa6:5bc:535a:8e21 Table master6: 2a0a:e5c0::/29 unreachable [place5_v6 2019-12-06] * (200) bird> show route 2a0a:e5c1:100::/40 Network not found bird> dc2: bird> show route all for 2a0a:e5c1:111:111:6aa6:5bc:535a:8e21 Table master6: 2a0a:e5c1:100::/40 unicast [place6_v6 23:55:06.876] * (200) via 2a0a:e5c0:2:2:0:84ff:fe41:f24d on bond0.12 Type: static univ bird> The address 2a0a:e5c0:2:2:0:84ff:fe41:f24d is part of dc2 and I *assume* the route not being visible is related to this log message: Dec 16 01:30:12 router2 daemon.err bird: router1_place6_ungleich_ch_v6: Invalid NEXT_HOP attribute (it would be great if bird would actually lok the NEXT_HOP attribute, too) -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
Follow up 2: it seems that bird1.6 behaves differently to bird 2.0.7: bird> show route all for 2a0a:e5c1:111:111:6aa6:5bc:535a:8e21 2a0a:e5c1:100::/40 via 2a0a:e5c0:1:8::6 on bond0.8 [router2_place6_ungleich_ch_v6 2019-12-03] * (100) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 2a0a:e5c0:2:2:0:84ff:fe41:f24d BGP.local_pref: 500 bird> (this is from the 2nd router pair, still running bird 1.6) Is it possible that the nexthop resolution algorithm changed in bird2 vs bird1? -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
On Mon, Dec 16, 2019 at 01:43:09AM +0100, Nico Schottelius wrote:
Follow up 2:
it seems that bird1.6 behaves differently to bird 2.0.7:
bird> show route all for 2a0a:e5c1:111:111:6aa6:5bc:535a:8e21 2a0a:e5c1:100::/40 via 2a0a:e5c0:1:8::6 on bond0.8 [router2_place6_ungleich_ch_v6 2019-12-03] * (100) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 2a0a:e5c0:2:2:0:84ff:fe41:f24d BGP.local_pref: 500 bird>
(this is from the 2nd router pair, still running bird 1.6)
Is it possible that the nexthop resolution algorithm changed in bird2 vs bird1?
Yes, in BIRD 1 direct mode, there was a fallback that uses IP address of BGP peer as gateway if BGP NEXT_HOP failed to resolve. We removed this fallback in BIRD 2. -- 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."
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Mon, Dec 16, 2019 at 01:43:09AM +0100, Nico Schottelius wrote:
Follow up 2:
it seems that bird1.6 behaves differently to bird 2.0.7:
bird> show route all for 2a0a:e5c1:111:111:6aa6:5bc:535a:8e21 2a0a:e5c1:100::/40 via 2a0a:e5c0:1:8::6 on bond0.8 [router2_place6_ungleich_ch_v6 2019-12-03] * (100) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 2a0a:e5c0:2:2:0:84ff:fe41:f24d BGP.local_pref: 500 bird>
(this is from the 2nd router pair, still running bird 1.6)
Is it possible that the nexthop resolution algorithm changed in bird2 vs bird1?
Yes, in BIRD 1 direct mode, there was a fallback that uses IP address of BGP peer as gateway if BGP NEXT_HOP failed to resolve.
We removed this fallback in BIRD 2.
Ha, that explains a lot! I am still puzzled though, because the description of bird2 on the topic of gateway direct seems to imply that this is still the case. Is there any way to restore the 1.6 behaviour? Best, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
On Mon, Dec 16, 2019 at 03:40:18PM +0100, Nico Schottelius wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Mon, Dec 16, 2019 at 01:43:09AM +0100, Nico Schottelius wrote:
Follow up 2:
it seems that bird1.6 behaves differently to bird 2.0.7:
bird> show route all for 2a0a:e5c1:111:111:6aa6:5bc:535a:8e21 2a0a:e5c1:100::/40 via 2a0a:e5c0:1:8::6 on bond0.8 [router2_place6_ungleich_ch_v6 2019-12-03] * (100) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 2a0a:e5c0:2:2:0:84ff:fe41:f24d BGP.local_pref: 500 bird>
(this is from the 2nd router pair, still running bird 1.6)
Is it possible that the nexthop resolution algorithm changed in bird2 vs bird1?
Yes, in BIRD 1 direct mode, there was a fallback that uses IP address of BGP peer as gateway if BGP NEXT_HOP failed to resolve.
We removed this fallback in BIRD 2.
Ha, that explains a lot! I am still puzzled though, because the description of bird2 on the topic of gateway direct seems to imply that this is still the case.
That is mistake in docs.
Is there any way to restore the 1.6 behaviour?
No, it just hides misconfigurations. If you use 'next hop self' then there should not be difference between BGP NEXT_HOP and peer IP address and it would work even in cases where both IPv4 and IPv6 routes are propagated over one BGP session. -- 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 Mon, Dec 16, 2019 at 01:24:23AM +0100, Nico Schottelius wrote:
Good morning,
I was wondering, what is the best practice is for running 2 data centers, each with one uplink and a dark fiber in between them?
I think it's pretty much a standard situation, but will show our setup and assumptions as well:
upstream 1 upstream 2 | | dc1--darkfiber----dc 2
Additional each DC has 2 routers:
dc1: dc2: |---router1 ------- router 1 | / | / | /--------/ | router2---------router2 | | |---------------------|
(both routers are connected to each other and both routers are connected to each upstream)
Hi I assume that routers from DC1 use IBGP connection to routers in DC2, and only routers from DC2 have EBGP connection to upstream 2 (and vice versa).
The objective is to stay online in each DC as long as possible, so in theory:
- upstream 1 can die or - upstream 2 can die or - the darkfiber can die
And in each of the situations, both DCs should still be reachable from outside and both be reaching itself.
If you want to survive splitting AS (when darkfiber dies), you need to use and announce separate address range in each DC (or you need some backup inter-DC connection, like GRE tunnel). If you announce 2a0a:e5c0::/29 on both sides, then you get traffic for both sides on both DC.
Question 1: Is "direct;" is the right protocol for all links?
As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations.
Generally, BGP assumes you already have all internal routes - either from OSPF, or equivalent static/direct routes. These are necessary for recursive next hop resolution, but can be avoided in direct next hop resolution. If you do not use IGP, then direct IBGP sessions may have some advantages, namely they can react to link-down events. Note that direct/multihop session and direct/recursive gateway resolution are two options, although the second by default depends on the first. So it is e.g. possible to configure direct session with recursive resolution.
Question 2: Is "next hop self ebgp;" the correct answer to the Invalid NEXT_HOP attribute?
If you use direct next hop resolution, then received NEXT_HOP is supposed to be directly reachable, ideally on the same interface. So in this case you should use 'next hop self;'. Variant 'next hop self ebgp;' is more for cases where you use recursive resolution, but your IGP/internal routes do not cover border/inter-AS links.
Question 3: Is "not direct" (aka multiphop) the right thing for iBGP?
As i wrote above, you would need static/direct/IGP routes for internal networks (e.g. from 'direct' protocol).
So our dcs are directly connected vi layer 2, but the default for iBGP is multihop. If we omit the "direct" keyword, the result is that no routes are in the end imported from the other DC and that we get various warnings like the following in syslog:
Dec 16 00:58:35 router2 daemon.warn bird: Next hop address 2a0a:e5c0:1:8::5 resolvable through recursive route for 2a0a:e5c0:1:8::/64
You probably do not want to export your internal routes (2a0a:e5c0:1:8::/64) through IBGP.
Question 4: How to (not) announce umbrella networks?
So both data centers are reachable within the 2a0a:e5c0::/29 prefix and all routers have a statement
route 2a0a:e5c0::/29 unreachable;
in the static protocol. However if the dark fiber goes down, it is not clear that / how the upstreams should / will propagate the smaller (per DC) /48s.
If we remove the full /29 announcement, we might run into the problem that a packet is being sent out through one upstream and returns back to us and thus creates a routing loop.
You should split your range to say /32 per DC and declare each separately in each DC. Then these /32 ranges would be announced by IBGP from one DC to the other, so routers in both DCs would announce both ranges to EBGP. If dark fiber goes down, IBGP is broken and each DC would announce only its /32 range. -- 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."
Hello Ondrej, Ondrej Zajicek <santiago@crfreenet.org> writes:>
I assume that routers from DC1 use IBGP connection to routers in DC2, and only routers from DC2 have EBGP connection to upstream 2 (and vice versa).
correct, it is an identical setup on both sides.
The objective is to stay online in each DC as long as possible, so in theory:
- upstream 1 can die or - upstream 2 can die or - the darkfiber can die
And in each of the situations, both DCs should still be reachable from outside and both be reaching itself.
If you want to survive splitting AS (when darkfiber dies), you need to use and announce separate address range in each DC (or you need some backup inter-DC connection, like GRE tunnel). If you announce 2a0a:e5c0::/29 on both sides, then you get traffic for both sides on both DC.
Thanks, I was fearing that. We will probably need to renumber some things, as both DCs have addresses (historically) from a single /44
Question 1: Is "direct;" is the right protocol for all links?
As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations.
Generally, BGP assumes you already have all internal routes - either from OSPF, or equivalent static/direct routes. These are necessary for recursive next hop resolution, but can be avoided in direct next hop resolution.
To put a bit more detail into this: we have a transfer/peering vlan that utilises 2a0a:e5c0:1:8::/64. So every router/switch/whatever-needs-to-speak-bgp is in this network. Because every speaker is in this network, my assumption is that it should be possible to (recursive) resolve every route. Am I wrong on this?
If you do not use IGP, then direct IBGP sessions may have some advantages, namely they can react to link-down events.
Note that direct/multihop session and direct/recursive gateway resolution are two options, although the second by default depends on the first. So it is e.g. possible to configure direct session with recursive resolution.
Can you elaborate a bit more on the effects? i.e. if looking only at the effects of the first setting (direct/multihop) without the adjusted defaults or only at the second setting (direct/recursive), what are the exact outcome of the 4 combinations direct/gateway direct direct/gateway recursive multihop/gateway direct multihop/gateway recursive ?
Question 2: Is "next hop self ebgp;" the correct answer to the Invalid NEXT_HOP attribute?
If you use direct next hop resolution, then received NEXT_HOP is supposed to be directly reachable, ideally on the same interface. So in this case you should use 'next hop self;'.
I am puzzled by this statement a bit, because of the following documentation on the bird website: " gateway direct|recursive For received routes, their gw (immediate next hop) attribute is computed from received bgp_next_hop attribute. This option specifies how it is computed. Direct mode means that the IP address from bgp_next_hop is used if it is directly reachable, otherwise the neighbor IP address is used. " So if I read it here correct, in the direct/direct configuration, the gateway should be the peer's IPv6 address, if the next hop address is not directly reachable. However this is *not* what I experience in the bird 2.0.7 setup. However this *is* what I experience in the bird 1.6 setup. There is another problem which renders "next hop self" tricky: as all routers are paired with every other router, we are hiding the origin, i.e. we announce networks from the dc1 in dc2 and this results in routing from dc1->dc2->dc1.
Variant 'next hop self ebgp;' is more for cases where you use recursive resolution, but your IGP/internal routes do not cover border/inter-AS links.
That sounds a bit similar to the actual situation we have.
Question 3: Is "not direct" (aka multiphop) the right thing for iBGP?
As i wrote above, you would need static/direct/IGP routes for internal networks (e.g. from 'direct' protocol).
So our dcs are directly connected vi layer 2, but the default for iBGP is multihop. If we omit the "direct" keyword, the result is that no routes are in the end imported from the other DC and that we get various warnings like the following in syslog:
Dec 16 00:58:35 router2 daemon.warn bird: Next hop address 2a0a:e5c0:1:8::5 resolvable through recursive route for 2a0a:e5c0:1:8::/64
You probably do not want to export your internal routes (2a0a:e5c0:1:8::/64) through IBGP.
This is actually directly the result from the "direct" protocol that we tried to implement as you described :-) I just reconfigured the test routers to use the combination direct/gateway recursive and it seems to mostly work, however there is at least one route that it does not resolve: a route that the router in dc2 routes to another (non-bgp) router. It is shown as unreachable in dc1, while it clearly can be reached and routed in dc2. The setup is router2.place5 (2a0a:e5c0:1:8::4) | (bgp, routing) router1.place6 (2a0a:e5c0:1:8::4) | 2a0a:e5c0:2:2:0:84ff:fe41:f24d (reachable via 2a0a:e5c0:2:2::/64 router1.place6) | 2a0a:e5c1:111::/48 network dc1 (=place5): -------------------------------------------------------------------------------- [14:56] router2.place5:~# ping 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d PING 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d (2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d): 56 data bytes ping: sendto: Host is unreachable [15:07] router2.place5:~# bird> show route all for 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d Table master6: 2a0a:e5c1:100::/40 unreachable [router1_place6_ungleich_ch_v6 14:57:01.575 from 2a0a:e5c0:1:8::5] * (100) [i] Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 2a0a:e5c0:2:2:0:84ff:fe41:f24d BGP.local_pref: 500 dc2 (=place6): -------------------------------------------------------------------------------- [15:11] router1.place6:~# ping -c2 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d PING 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d (2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d): 56 data bytes 64 bytes from 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d: seq=0 ttl=62 time=50.923 ms 64 bytes from 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d: seq=1 ttl=62 time=130.140 ms --- 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 50.923/90.531/130.140 ms [15:12] router1.place6:~# bird> show route all for 2a0a:e5c1:111:111:a2af:bdff:fe2a:7b2d Table master6: 2a0a:e5c1:100::/40 unicast [place6_v6 23:55:06.876] * (200) via 2a0a:e5c0:2:2:0:84ff:fe41:f24d on bond0.12 Type: static univ bird> -------------------------------------------------------------------------------- Shouldn't this resolve via direct/gateway recursive mode? Best, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
On Mon, Dec 16, 2019 at 03:18:33PM +0100, Nico Schottelius wrote:
Question 1: Is "direct;" is the right protocol for all links?
As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations.
Generally, BGP assumes you already have all internal routes - either from OSPF, or equivalent static/direct routes. These are necessary for recursive next hop resolution, but can be avoided in direct next hop resolution.
To put a bit more detail into this: we have a transfer/peering vlan that utilises 2a0a:e5c0:1:8::/64. So every router/switch/whatever-needs-to-speak-bgp is in this network.
Both IBGP and EBGP? Or do you have your upstream links in separate networks?
Because every speaker is in this network, my assumption is that it should be possible to (recursive) resolve every route. Am I wrong on this?
Yes, if you have direct route 2a0a:e5c0:1:8::/64 in BIRD routing table (e.g. from direct protocol).
If you do not use IGP, then direct IBGP sessions may have some advantages, namely they can react to link-down events.
Note that direct/multihop session and direct/recursive gateway resolution are two options, although the second by default depends on the first. So it is e.g. possible to configure direct session with recursive resolution.
Can you elaborate a bit more on the effects?
i.e. if looking only at the effects of the first setting (direct/multihop) without the adjusted defaults or only at the second setting (direct/recursive), what are the exact outcome of the 4 combinations
direct/gateway direct direct/gateway recursive multihop/gateway direct multihop/gateway recursive
direct / multihop specifies connection / TCP behavior for BGP session. In first case connection is tightly bound to interface and is single-hop, while in the multihop case it is regular routed TCP connection. Does not have direct effect on next hop resolution. gateway option specifies behavior of next hop resolution.
Question 2: Is "next hop self ebgp;" the correct answer to the Invalid NEXT_HOP attribute?
If you use direct next hop resolution, then received NEXT_HOP is supposed to be directly reachable, ideally on the same interface. So in this case you should use 'next hop self;'.
I am puzzled by this statement a bit, because of the following documentation on the bird website:
" gateway direct|recursive
For received routes, their gw (immediate next hop) attribute is computed from received bgp_next_hop attribute. This option specifies how it is computed. Direct mode means that the IP address from bgp_next_hop is used if it is directly reachable, otherwise the neighbor IP address is used. "
So if I read it here correct, in the direct/direct configuration, the gateway should be the peer's IPv6 address, if the next hop address is not directly reachable. However this is *not* what I experience in the bird 2.0.7 setup. However this *is* what I experience in the bird 1.6 setup.
This seeems like a bug in documentation (left from BIRD 1). The "otherwise the neighbor IP address is used." shold not be here.
There is another problem which renders "next hop self" tricky: as all routers are paired with every other router, we are hiding the origin, i.e. we announce networks from the dc1 in dc2 and this results in routing from dc1->dc2->dc1.
No, because IBGP does not propagate routes received from IBGP.
Variant 'next hop self ebgp;' is more for cases where you use recursive resolution, but your IGP/internal routes do not cover border/inter-AS links.
That sounds a bit similar to the actual situation we have.
The difference probably does not matter in your case. Depends on which routes do you propagate using IBGP. If you propagate static route 2a0a:e5c1:111::/48 with next hop on different network through IBGP with 'next hop self ebgp' and direct mode, then BGP NEXT_HOP would be original next hop and unresolvable on the other side.
Question 3: Is "not direct" (aka multiphop) the right thing for iBGP?
As i wrote above, you would need static/direct/IGP routes for internal networks (e.g. from 'direct' protocol).
So our dcs are directly connected vi layer 2, but the default for iBGP is multihop. If we omit the "direct" keyword, the result is that no routes are in the end imported from the other DC and that we get various warnings like the following in syslog:
Dec 16 00:58:35 router2 daemon.warn bird: Next hop address 2a0a:e5c0:1:8::5 resolvable through recursive route for 2a0a:e5c0:1:8::/64
You probably do not want to export your internal routes (2a0a:e5c0:1:8::/64) through IBGP.
This is actually directly the result from the "direct" protocol that we tried to implement as you described :-)
You should configure IBGP to not propagate routes from 'direct' protocol.
I just reconfigured the test routers to use the combination direct/gateway recursive and it seems to mostly work, however there is at least one route that it does not resolve: a route that the router in dc2 routes to another (non-bgp) router. ... It is shown as unreachable in dc1, while it clearly can be reached and routed in dc2. ...
Shouldn't this resolve via direct/gateway recursive mode?
You would need static/IGP route for 2a0a:e5c0:2:2::/64 in DC1 router directed to 2a0a:e5c0:1:8::5. Perhaps you have one received from IBGP, but that is not allowed for recursive route resolution. BIRD allows just one level of indirection in recursive mode (so it should not be really called 'recursive'). So in short, BIRD assumes that full set of routes for all your local networks from IGP/static/direct are available on all your BGP routers as a base level and on top of that recursive next hops from IBGP are resolved. Or alternatively, 'gateway direct' and 'next hop self' are used to avoid recursive next hop resolution. -- 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."
Ondrej Zajicek <santiago@crfreenet.org> writes:
[...] If you do not use IGP, then direct IBGP sessions may have some advantages, namely they can react to link-down events. [...]
Do you *not* consider iBGP an IGP? Because this would explain why the paragraph regarding recursive doesn't work for us: "Recursive mode means that the gateway is computed by an IGP routing table lookup for the IP address from bgp_next_hop." -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
On Mon, Dec 16, 2019 at 04:45:25PM +0100, Nico Schottelius wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
[...] If you do not use IGP, then direct IBGP sessions may have some advantages, namely they can react to link-down events. [...]
Do you *not* consider iBGP an IGP? Because this would explain why the paragraph regarding recursive doesn't work for us:
No, IGPs are protocols like OSPF, which are designed for exchanging of internal routing information. OTOH, IBGP is designed for internal distribution of external routing information. BIRD even allows you to use different routing table for internal routes (and for next hop resolution of BGP routes - IGP routing table) and for external ones. But it uses the same by default. -- 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 (2)
-
Nico Schottelius -
Ondrej Zajicek