Multiple ebgp neighbours to the same peer
Hi all, New user here I am trying to get 2 ebgp neighbours on bird to peer with a remote bgp endpoint on frr node. One between 10.100.101.1 <—> 10.100.1.1 and other between 10.100.102.1 <—> 10.100.1.1 ┌──────────────────┐ ┌─────────────┐ 10.100.101.1 │ │ensp5s0 │ │ loop1 * Bird │◄──────────────────────►┘ Frr │ │ 2.0.10 │10.100.1.2 10.100.1.1 │ loop2 * │ │ │ 10.100.102.1 │ │ │ │ └──────────────────┘ └─────────────┘ I find that only the first ebgp neighbour comes up and moves to "Established” state whereas the second ebgp neighbour remains in “Idle” state. However if I restart the bgp neighbour in “Established” state, the other bgp neighbour comes up and moves to “Established” state, but the restarted one remains in Idle state. Is there any limitation that I can’t have 2 neighbours to the same peer? Or do I have to ensure that the 2 neighbours use different tables? I have already disabled rp_filter sysctl -w net.ipv4.conf.all.rp_filter=0 Regards Prem Config ====== log "/var/log/trex/bird.log" all; debug protocols all; router id 10.100.1.2; protocol device { # scan time 10; interface "loop1"; interface "loop2"; interface "enp5s0"; } protocol bgp bgp_peer1 { local 10.100.101.1 as 65001; neighbor 10.100.1.1 as 65500; ipv4 { import all; export all; }; } protocol bgp bgp_peer2 { local 10.100.102.1 as 65002; neighbor 10.100.1.1 as 65500; ipv4 { import all; export all; }; } protocol static bird_cfg_routes { ipv4 { export all; import all; }; route 200.1.1.1/32 via 10.100.2.100; } Logs ==== bird> show protocols Name Proto Table State Since Info device1 Device --- up 13:05:16.761 bgp_peer1 BGP --- up 13:05:21.497 Established bgp_peer2 BGP --- start 13:05:16.761 Idle bird_cfg_routes Static master4 up 13:05:16.761 bird> bird> bird> bird> restart bgp_peer1 bgp_peer1: restarted bird> bird> bird> show protocols Name Proto Table State Since Info device1 Device --- up 13:05:16.761 bgp_peer1 BGP --- start 13:07:13.673 Idle bgp_peer2 BGP --- up 13:07:18.328 Established bird_cfg_routes Static master4 up 13:05:16.761 bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Preferred, scope host) ::1/128 (Preferred, scope host) mgmt0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.121.163/24 (Preferred, scope site) fe80::b203:e9ff:fe02:100/64 (Preferred, scope link) enp5s0 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.1.2/24 (Preferred, scope site) enp6s0 up (index=4) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.2.1/24 (Preferred, scope site) fc00:64:2::1/120 (Preferred, scope site) fe80::b203:e9ff:fe02:102/64 (Preferred, scope link) loop1 up (index=5) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.101.1/24 (Preferred, scope site) fe80::78f9:91ff:fe2c:83ed/64 (Preferred, scope link) loop2 up (index=6) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.102.1/24 (Preferred, scope site) fe80::a4fc:34ff:fefd:11ce/64 (Preferred, scope link) bird> bird> bird> show route all Table master4: 200.1.1.1/32 unicast [bird_cfg_routes 13:05:16.761] * (200) via 10.100.2.100 on enp6s0 Type: static univ bird> Debugs ====== 2023-01-21 13:05:16.761 <TRACE> device1: Initializing 2023-01-21 13:05:16.761 <TRACE> bgp_peer1: Initializing 2023-01-21 13:05:16.761 <TRACE> bgp_peer2: Initializing 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes: Initializing 2023-01-21 13:05:16.761 <TRACE> device1: Starting 2023-01-21 13:05:16.761 <TRACE> device1: Scanning interfaces 2023-01-21 13:05:16.761 <TRACE> device1: State changed to up 2023-01-21 13:05:16.761 <TRACE> bgp_peer1: Starting 2023-01-21 13:05:16.761 <TRACE> bgp_peer1: State changed to start 2023-01-21 13:05:16.761 <TRACE> bgp_peer2: Starting 2023-01-21 13:05:16.761 <TRACE> bgp_peer2: State changed to start 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes: Starting 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes: State changed to up 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes.ipv4 > added [best] 200.1.1.1/32 unicast 2023-01-21 13:05:16.761 <INFO> Started 2023-01-21 13:05:16.762 <TRACE> bgp_peer1: Started 2023-01-21 13:05:16.762 <TRACE> bgp_peer1: Connect delayed by 5 seconds 2023-01-21 13:05:21.495 <TRACE> bgp_peer1: Connecting to 10.100.1.1 from local address 10.100.101.1 2023-01-21 13:05:21.496 <TRACE> bgp_peer1: Connected 2023-01-21 13:05:21.496 <TRACE> bgp_peer1: Sending OPEN(ver=4,as=65001,hold=240,id=0a640102) 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: Got OPEN(as=65500,hold=30,id=192.168.121.230) 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: BGP session established 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: State changed to up 2023-01-21 13:05:21.497 <TRACE> bgp_peer1.ipv4 < added 200.1.1.1/32 unicast 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Got UPDATE 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Got END-OF-RIB 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Sending UPDATE 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Sending END-OF-RIB 2023-01-21 13:05:30.958 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:31.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:38.689 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:41.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:46.842 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:51.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:54.864 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:06:01.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:06:03.759 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:06:11.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:06:11.843 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:06:16.764 <TRACE> device1: Scanning interfaces ... ... ... 2023-01-21 13:07:13.673 <INFO> Restarting protocol bgp_peer1 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Shutting down 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Shutdown requested 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to stop 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: BGP session closed 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Sending NOTIFICATION(code=6.4) 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Down 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to flush 2023-01-21 13:07:13.673 <TRACE> bgp_peer2: Started 2023-01-21 13:07:13.673 <TRACE> bgp_peer2: Connect delayed by 5 seconds 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to down 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Starting 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to start 2023-01-21 13:07:16.761 <TRACE> device1: Scanning interfaces 2023-01-21 13:07:18.326 <TRACE> bgp_peer2: Connecting to 10.100.1.1 from local address 10.100.102.1 2023-01-21 13:07:18.327 <TRACE> bgp_peer2: Connected 2023-01-21 13:07:18.327 <TRACE> bgp_peer2: Sending OPEN(ver=4,as=65002,hold=240,id=0a640102) 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: Got OPEN(as=65500,hold=30,id=192.168.121.230) 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: Sending KEEPALIVE 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: Got KEEPALIVE 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: BGP session established 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: State changed to up 2023-01-21 13:07:18.328 <TRACE> bgp_peer2.ipv4 < added 200.1.1.1/32 unicast 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Got UPDATE 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Got END-OF-RIB 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Sending UPDATE 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Sending END-OF-RIB 2023-01-21 13:07:27.298 <TRACE> bgp_peer2: Sending KEEPALIVE 2023-01-21 13:07:28.329 <TRACE> bgp_peer2: Got KEEPALIVE 2023-01-21 13:07:36.478 <TRACE> bgp_peer2: Sending KEEPALIVE
On Sat, Jan 21, 2023 at 06:05:16PM +0000, Prem Anand wrote:
Hi all, New user here
I am trying to get 2 ebgp neighbours on bird to peer with a remote bgp endpoint on frr node. One between 10.100.101.1 <—> 10.100.1.1 and other between 10.100.102.1 <—> 10.100.1.1
┌──────────────────┐ ┌─────────────┐ 10.100.101.1 │ │ensp5s0 │ │ loop1 * Bird │◄──────────────────────►┘ Frr │ │ 2.0.10 │10.100.1.2 10.100.1.1 │ loop2 * │ │ │ 10.100.102.1 │ │ │ │ └──────────────────┘ └─────────────┘
I find that only the first ebgp neighbour comes up and moves to "Established” state whereas the second ebgp neighbour remains in “Idle” state. However if I restart the bgp neighbour in “Established” state, the other bgp neighbour comes up and moves to “Established” state, but the restarted one remains in Idle state.
Is there any limitation that I can’t have 2 neighbours to the same peer? Or do I have to ensure that the 2 neighbours use different tables?
Hi Yes, there is an explicit lock for remote IP to be assigned to one BGP protocol. You can avoid it by using different IP on Frr side like you use on Bird side, or by using pair of non-standard ports (with the same IP). Thinking about it, the explicit lock seems unnecessary restrictive. If the local IP is defined, then the lock should be for (local IP, remote IP, ports) pair. -- 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, I had the same issue some time before. I agree that this lock is too restrictive. Because in some cases you cannot change remote IP or port. I tried to make 2 multihop sessions to a remote bgp monitoring service. And its IP is fixed for me and cannot be changed. On Sat, Jan 21, 2023, 19:49 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Jan 21, 2023 at 06:05:16PM +0000, Prem Anand wrote:
Hi all, New user here
I am trying to get 2 ebgp neighbours on bird to peer with a remote bgp endpoint on frr node. One between 10.100.101.1 <—> 10.100.1.1 and other between 10.100.102.1 <—> 10.100.1.1
┌──────────────────┐ ┌─────────────┐ 10.100.101.1 │ │ensp5s0 │ │ loop1 * Bird │◄──────────────────────►┘ Frr │ │ 2.0.10 │10.100.1.2 10.100.1.1 │ loop2 * │ │ │ 10.100.102.1 │ │ │ │ └──────────────────┘ └─────────────┘
I find that only the first ebgp neighbour comes up and moves to "Established” state whereas the second ebgp neighbour remains in “Idle” state. However if I restart the bgp neighbour in “Established” state, the other bgp neighbour comes up and moves to “Established” state, but the restarted one remains in Idle state.
Is there any limitation that I can’t have 2 neighbours to the same peer? Or do I have to ensure that the 2 neighbours use different tables?
Hi
Yes, there is an explicit lock for remote IP to be assigned to one BGP protocol. You can avoid it by using different IP on Frr side like you use on Bird side, or by using pair of non-standard ports (with the same IP).
Thinking about it, the explicit lock seems unnecessary restrictive. If the local IP is defined, then the lock should be for (local IP, remote IP, ports) pair.
-- 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, Thanks for your quick reply. I tried after adding another ip address to the interface on the FRR side and can confirm that both my bgp neighbours came up :) Unfortunately, my original intention is to peer this with a Brocade hardware router, that I don’t have control of. So it is difficult for me to add another IP address or bind to a different port. Given that you feel that the explicit lock is restrictive and unnecessary, it would be really helpful, if you could remove that explicit lock when you get some time. Regards Prem
On 21 Jan 2023, at 18:43, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Jan 21, 2023 at 06:05:16PM +0000, Prem Anand wrote:
Hi all, New user here
I am trying to get 2 ebgp neighbours on bird to peer with a remote bgp endpoint on frr node. One between 10.100.101.1 <—> 10.100.1.1 and other between 10.100.102.1 <—> 10.100.1.1
┌──────────────────┐ ┌─────────────┐ 10.100.101.1 │ │ensp5s0 │ │ loop1 * Bird │◄──────────────────────►┘ Frr │ │ 2.0.10 │10.100.1.2 10.100.1.1 │ loop2 * │ │ │ 10.100.102.1 │ │ │ │ └──────────────────┘ └─────────────┘
I find that only the first ebgp neighbour comes up and moves to "Established” state whereas the second ebgp neighbour remains in “Idle” state. However if I restart the bgp neighbour in “Established” state, the other bgp neighbour comes up and moves to “Established” state, but the restarted one remains in Idle state.
Is there any limitation that I can’t have 2 neighbours to the same peer? Or do I have to ensure that the 2 neighbours use different tables?
Hi
Yes, there is an explicit lock for remote IP to be assigned to one BGP protocol. You can avoid it by using different IP on Frr side like you use on Bird side, or by using pair of non-standard ports (with the same IP).
Thinking about it, the explicit lock seems unnecessary restrictive. If the local IP is defined, then the lock should be for (local IP, remote IP, ports) pair.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org <mailto:santiago@crfreenet.org>) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net <http://wwwkeys.pgp.net/>) "To err is human -- to blame it on a computer is even more so."
Hi all, A quick try to fix the problem. But I'm not sure in complete correctness though. On Sat, Jan 21, 2023 at 8:17 PM Prem Anand <h.prem.anand@gmail.com> wrote:
Hi Ondrej, Thanks for your quick reply. I tried after adding another ip address to the interface on the FRR side and can confirm that both my bgp neighbours came up :)
Unfortunately, my original intention is to peer this with a Brocade hardware router, that I don’t have control of. So it is difficult for me to add another IP address or bind to a different port.
Given that you feel that the explicit lock is restrictive and unnecessary, it would be really helpful, if you could remove that explicit lock when you get some time.
Regards Prem
On 21 Jan 2023, at 18:43, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Jan 21, 2023 at 06:05:16PM +0000, Prem Anand wrote:
Hi all, New user here
I am trying to get 2 ebgp neighbours on bird to peer with a remote bgp endpoint on frr node. One between 10.100.101.1 <—> 10.100.1.1 and other between 10.100.102.1 <—> 10.100.1.1
┌──────────────────┐ ┌─────────────┐ 10.100.101.1 │ │ensp5s0 │ │ loop1 * Bird │◄──────────────────────►┘ Frr │ │ 2.0.10 │10.100.1.2 10.100.1.1 │ loop2 * │ │ │ 10.100.102.1 │ │ │ │ └──────────────────┘ └─────────────┘
I find that only the first ebgp neighbour comes up and moves to "Established” state whereas the second ebgp neighbour remains in “Idle” state. However if I restart the bgp neighbour in “Established” state, the other bgp neighbour comes up and moves to “Established” state, but the restarted one remains in Idle state.
Is there any limitation that I can’t have 2 neighbours to the same peer? Or do I have to ensure that the 2 neighbours use different tables?
Hi
Yes, there is an explicit lock for remote IP to be assigned to one BGP protocol. You can avoid it by using different IP on Frr side like you use on Bird side, or by using pair of non-standard ports (with the same IP).
Thinking about it, the explicit lock seems unnecessary restrictive. If the local IP is defined, then the lock should be for (local IP, remote IP, ports) pair.
-- 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 Alexander, Thanks for the quick patch. I did a quick test with your patch and I could bringup both the bgp neighbours. :) I haven’t seen any issue so far with my limited testing Regards Prem
On 22 Jan 2023, at 23:40, Alexander Zubkov <green@qrator.net> wrote:
Hi all,
A quick try to fix the problem. But I'm not sure in complete correctness though.
On Sat, Jan 21, 2023 at 8:17 PM Prem Anand <h.prem.anand@gmail.com <mailto:h.prem.anand@gmail.com>> wrote: Hi Ondrej, Thanks for your quick reply. I tried after adding another ip address to the interface on the FRR side and can confirm that both my bgp neighbours came up :)
Unfortunately, my original intention is to peer this with a Brocade hardware router, that I don’t have control of. So it is difficult for me to add another IP address or bind to a different port.
Given that you feel that the explicit lock is restrictive and unnecessary, it would be really helpful, if you could remove that explicit lock when you get some time.
Regards Prem
On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
Hi all,
A quick try to fix the problem. But I'm not sure in complete correctness though.
Hi That looks more-or-less OK, will merge.
- ipa_equal(x->addr, y->addr); + ipa_equal(x->addr, y->addr) && + ipa_equal(x->addr2, y->addr2);
I think undefined addr2 should work like wildcard, i.e. the condition should be: ipa_equal(x->addr, y->addr) && (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2, y->addr2)); (Undefined local ip will be resolved to some ip and may collide with defined ones.) -- 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, Jan 23, 2023 at 3:06 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
Hi all,
A quick try to fix the problem. But I'm not sure in complete correctness though.
Hi
That looks more-or-less OK, will merge.
- ipa_equal(x->addr, y->addr); + ipa_equal(x->addr, y->addr) && + ipa_equal(x->addr2, y->addr2);
I think undefined addr2 should work like wildcard, i.e. the condition should be:
Maybe. I do not know well how this lock works. If different lock keys can affect another. And in this case it is probably better to fix "local" role for that second address and reflect it in its name.
ipa_equal(x->addr, y->addr) && (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2, y->addr2));
(Undefined local ip will be resolved to some ip and may collide with defined ones.)
-- 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, Jan 23, 2023 at 3:17 PM Alexander Zubkov <green@qrator.net> wrote:
On Mon, Jan 23, 2023 at 3:06 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
Hi all,
A quick try to fix the problem. But I'm not sure in complete correctness though.
Hi
That looks more-or-less OK, will merge.
- ipa_equal(x->addr, y->addr); + ipa_equal(x->addr, y->addr) && + ipa_equal(x->addr2, y->addr2);
I think undefined addr2 should work like wildcard, i.e. the condition should be:
Maybe. I do not know well how this lock works. If different lock keys can affect another. And in this case it is probably better to fix "local" role for that second address and reflect it in its name.
I think even better to call this wildcard_addr, for example. So if something else needs this wildcard feature, it is clear which addr to use in the lock object.
ipa_equal(x->addr, y->addr) && (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2, y->addr2));
(Undefined local ip will be resolved to some ip and may collide with defined ones.)
-- 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, Let's resurrect this question. :) I've made a patch to illustrate what I mean about the wildcard address in the lock object. Regards, Alexander On Tue, Jan 24, 2023 at 8:22 AM Alexander Zubkov <green@qrator.net> wrote:
On Mon, Jan 23, 2023 at 3:17 PM Alexander Zubkov <green@qrator.net> wrote:
On Mon, Jan 23, 2023 at 3:06 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
Hi all,
A quick try to fix the problem. But I'm not sure in complete correctness though.
Hi
That looks more-or-less OK, will merge.
- ipa_equal(x->addr, y->addr); + ipa_equal(x->addr, y->addr) && + ipa_equal(x->addr2, y->addr2);
I think undefined addr2 should work like wildcard, i.e. the condition should be:
Maybe. I do not know well how this lock works. If different lock keys can affect another. And in this case it is probably better to fix "local" role for that second address and reflect it in its name.
I think even better to call this wildcard_addr, for example. So if something else needs this wildcard feature, it is clear which addr to use in the lock object.
ipa_equal(x->addr, y->addr) && (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2, y->addr2));
(Undefined local ip will be resolved to some ip and may collide with defined ones.)
-- 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, Dec 29, 2023 at 09:43:43PM +0100, Alexander Zubkov wrote:
Hi,
Let's resurrect this question. :) I've made a patch to illustrate what I mean about the wildcard address in the lock object.
Hi Thanks, merged: https://gitlab.nic.cz/labs/bird/-/commit/574d7eb241a60622b0573ab1460cb23d968... (with some cosmetic modifications) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Good Morning, Could someone explain[1] to me the use-case(s) why I would need to establish two or more BGP session between the same to peers, please? Thanks in advance! Best, Bernd [1] Or point me to some resources.
Hi, For example if you want to establish several sessions over different pathes. Also my use-case is to export routes to a BGP monitoring system, that have fixed remote IP, but I want to send "views" from my several upstreams, each over a separate session. On Thu, Feb 8, 2024 at 9:47 AM Bernd Naumann <bernd@kr217.de> wrote:
Good Morning,
Could someone explain[1] to me the use-case(s) why I would need to establish two or more BGP session between the same to peers, please?
Thanks in advance! Best, Bernd
[1] Or point me to some resources.
participants (4)
-
Alexander Zubkov -
Bernd Naumann -
Ondrej Zajicek -
Prem Anand