not listening on 179 but iface up
Dear bird gurus, :) I'm currently setting up a new iBGP-(only)-member. It is configured to connect to 2 internal peers: -------------------- protocol bgp wiesbaden1 from bgp_ibgp_wi { # lotuswurzel neighbor 10.56.0.23 as wi_as; }; protocol bgp wiesbaden2 from bgp_ibgp_wi { # kaschu neighbor 10.56.0.208 as wi_as; }; -------------------- and these 2 peers are configured to connect vice-versa. They don't connect. Additionally bird on the new member doesn't listen on port 179. I first tried it to listen explicitly on two of the hosts IP addresses (is this possible, by the way?) and now removed the explicit "listen" - so that it should now listen on 0.0.0.0:179, right? It doesn't. :( I found hints that bird may postpone opening the socket, if the network interfaces are not yet up. But at least 4 interfaces _are_ up, including the two where the iBGP peers are connected directly. Any ideas? Cheers, Kai -- "Das ist Demokratie, wenn man sich aussuchen darf, wer einen verarscht." (Hagen Rether) D-55118 Meenz fast: kai_pf (aT] web(dot)de ++ PGP Key fingerprint B567 C43E 99D1 7709 7D64 3BF8 2DE8 1092 0EEF D58E ++ -----BEGIN GEEK CODE BLOCK----- VERSION: 3.12 GCS/IT/CM d- s:- a+>-----(?) C++$ UL++(++++$) P+++ L++ E-(+) W--(+) N !w---($) !O !M V? PS+ PE-() Y+ PGP(+) t R*@ tv--@ b+>++ DI++ G e+++(*) h? y? ------END GEEK CODE BLOCK------
On Sat, Aug 29, 2015 at 07:00:21PM +0200, Kai wrote:
Dear bird gurus, :)
I'm currently setting up a new iBGP-(only)-member. It is configured to connect to 2 internal peers: -------------------- protocol bgp wiesbaden1 from bgp_ibgp_wi { # lotuswurzel neighbor 10.56.0.23 as wi_as; };
protocol bgp wiesbaden2 from bgp_ibgp_wi { # kaschu neighbor 10.56.0.208 as wi_as; }; -------------------- and these 2 peers are configured to connect vice-versa.
Hi What is your bgp_ibgp_wi configuration?
They don't connect. Additionally bird on the new member doesn't listen on port 179. I first tried it to listen explicitly on two of the hosts IP addresses (is this possible, by the way?)
No, only the second statement is used.
and now removed the explicit "listen" - so that it should now listen on 0.0.0.0:179, right?
Yes
It doesn't. :(
Did you try to restart BIRD or just reconfigure BIRD? 'listen' option cannot be changed by reconfiguring (it is reported in logs).
I found hints that bird may postpone opening the socket, if the network interfaces are not yet up. But at least 4 interfaces _are_ up, including the two where the iBGP peers are connected directly.
This is relevant only for single hop BGPs (like EBGPs)
Any ideas?
What 'show protocols' report for these protocols? -- 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."
Dear Ondrej, Thank you for your thoughts and comments. A colleague had the key idea and solved the issue. In short: even in this situation a "protocol device"-statement is crucial. For me this is not that intuitive, so I didn't reckon that bird would only listen on iterfaces it discovered via a "protocol device". Maybe there should be a more prominent hint in the manual, that a config without "protocol device" makes no sense in most situations (if this really is the case)? Maybe even a warning in the log file? Anyway, as you asked, I will include some replies below. :) Cheers, Kai
Gesendet: Montag, 07. September 2015 um 21:10 Uhr Von: "Ondrej Zajicek" <santiago@crfreenet.org> An: Kai <kai_pf@gmx.de> Cc: bird-users <bird-users@network.cz> Betreff: Re: not listening on 179 but iface up
On Sat, Aug 29, 2015 at 07:00:21PM +0200, Kai wrote:
Dear bird gurus, :)
I'm currently setting up a new iBGP-(only)-member. It is configured to connect to 2 internal peers: -------------------- protocol bgp wiesbaden1 from bgp_ibgp_wi { # lotuswurzel neighbor 10.56.0.23 as wi_as; };
protocol bgp wiesbaden2 from bgp_ibgp_wi { # kaschu neighbor 10.56.0.208 as wi_as; }; -------------------- and these 2 peers are configured to connect vice-versa.
Hi
What is your bgp_ibgp_wi configuration?
template bgp bgp_ibgp_wi { local wi_addr_wi as wi_as; table icvpn_wi; import filter ebgp_icvpn_import_filter; export none; direct; gateway direct; }; The complete (small) config is online: https://github.com/freifunk-mwu/gateway-configs/blob/master/aubergine/etc/bi... (with the "protocol device" now)
They don't connect. Additionally bird on the new member doesn't listen on port 179. I first tried it to listen explicitly on two of the hosts IP addresses (is this possible, by the way?)
No, only the second statement is used.
and now removed the explicit "listen" - so that it should now listen on 0.0.0.0:179, right?
Yes
It doesn't. :(
Did you try to restart BIRD or just reconfigure BIRD? 'listen' option cannot be changed by reconfiguring (it is reported in logs).
Yes, I restarted.
I found hints that bird may postpone opening the socket, if the network interfaces are not yet up. But at least 4 interfaces _are_ up, including the two where the iBGP peers are connected directly.
This is relevant only for single hop BGPs (like EBGPs)
Any ideas?
What 'show protocols' report for these protocols?
-- 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 Thu, Sep 10, 2015 at 10:16:18AM +0200, Kai wrote:
Dear Ondrej,
Maybe there should be a more prominent hint in the manual, that a config without "protocol device" makes no sense in most situations (if this really is the case)? Maybe even a warning in the log file?
You are right. 'protocol device' is necessary in almost every case. I guess there is one case where it is not needed - regular (multihop) IBGP-only route reflector. But in your case you have option 'direct', so your IBGP sessions are single-hop and wait for interface with proper prefix to appear. You are right, this should be emphasized in the manual. -- 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)
-
Kai -
Ondrej Zajicek