- Bird-users - Mailing Lists

show route all filter ...
by Mikhail A. Grishin 02 Sep '14

02 Sep '14

Hi, We use special command (see below) to view information regarding prefixes containing particular BGP communities. When such commands applied, we noticed in logs ---- Aug 27 11:50:17 ekt-rsm1 bird: Filter <NULL> did not return accept nor reject. Make up your mind Aug 27 11:50:17 ekt-rsm1 last message repeated 2690 times ---- Could you explain why? Is there any way to avoid such messages and stay at current logging level? Aug 27 11:50:17 ekt-rsm1 bird: CLI connect Aug 27 11:50:17 ekt-rsm1 bird: CLI: show route all filter {if (0,48642) ~ bgp_community then accept;} table master Aug 27 11:50:17 ekt-rsm1 bird: Filter <NULL> did not return accept nor reject. Make up your mind Aug 27 11:50:17 ekt-rsm1 last message repeated 2690 times Aug 27 11:50:17 ekt-rsm1 bird: CLI connection closed -- Best regards, Mikhail A. Grishin <m.grishin(a)msk-ix.ru>

4 3

Multiple routing tables with multiple gateways
by Fernando Frediani 01 Sep '14

01 Sep '14

Hello there, I'm currently writing a project document which consists in a server to be hosted in a Internet Exchange Point, (similar to a route server but with another propose) and one of the things it must do is: When it receives a request coming from an IP range from ISP A it must go out to the internet using the ISP A gateway, when the request comes from ISP B IP range it goes out via that ISP router and so on. Any request originating on the server itself goes out via the Internet Exchange connectivity. I know this can be done using IProute2 and creating multiple routing tables, but I would rather automate it using BIRD, so the ISPs would establish a BGP session to the server, announce their IP range, but in a different way they do with a Route server as they would need also to announce default route, and BIRD would take care to inform the kernel for when the request comes from those IPs it needs to use the specific ISP gateway for that. Would anyone be able to point me to the right direction in terms of BIRD BGP config in order to achieve that, specially with regards the main differences to a Route Server. Thanks Best regards, Fernando

1 0

OSPF Route
by Jason Aeschilman 26 Aug '14

26 Aug '14

I am using bird 1.4.0. I configured OSPF and the routes that bird adds to Linux have a metric of 0. Then I added a static route with the same network and mask and it has a metric of 1. So now a route that OSPF has added has preference over a static route but this is not the behavior I see with quagga or Cisco. With them, the static route has preference. quagga adds routes with metrics (values 11+) relative to OSPF cost while Cisco does not add an OSPF route to the FIB if a matching static route already exists. My expectation, if bird is going to use metric 0, is that it should not add an OSPF route if a static route already exists with the same network and mask. Or if it must add an OSPF route, it should have a metric such that the static route takes precedence. Is it possible to change this behavior in the config? If so, how?

1 0

Log rotation support
by Alexander Demenshin 26 Aug '14

26 Aug '14

Hi, It looks like that there is no log rotation possible when logging to files. Though I can fix it locally, it would be nice to include support for this in the future versions, as log files may be quite large and not everyone is using syslog. It could be done using birdc or some (unused yet) signal. Thank you! -- With best regards, Alexander.

3 4

Reloading static/direct/device/kernel protocols via birdc fails
by Alexander Demenshin 22 Aug '14

22 Aug '14

Hi, When I am attempting to reload kernel, static, direct or device protocol via birdc, I always get message like this "krt_main: reload failed", while in the log file I see just reloading message: <INFO> Reloading protocol krt_main For pipe, bgp and ospf instances there is only "reloading" message. Is this a bug, feature or something else? PS: I need reload to force bird to rescan specific kernel table. Thank you! -- With best regards, Alexander.

2 2

changes somewhere between 1.3.9 and 1.4.0
by Mikhail A. Grishin 22 Aug '14

22 Aug '14

Hi, We found that in 1.4.0 and later versions our approach to see rejected BGP routes for IXP customers stop working. This worked fine in 1.3.9 and earlier versions: --------- [18:44:27]ekt-rsm1% echo 'show route protocol R2854x1' | birdc | wc -l 238 [15:58:45]ekt-rsm1% echo 'show route protocol R2854x1 table T2854x1' | birdc | wc -l 245 ---------- Diffs between this two outputs - rejected routes. At 1.4.0 and later we see the same numbers: [16:00:26]ekt-rsm2# echo 'show route protocol R2854x1 table T2854x1' | birdc | wc -l 245 [16:08:51]ekt-rsm2# echo 'show route protocol R2854x1' | birdc | wc -l 245 Can you tell us, what changed? And how to restore old behavior? -- Wbr, Mikhail MSK-IX

2 1

Unknown LSA type from x.x.x.x
by Eric Cables 22 Aug '14

22 Aug '14

Running BIRD v1.4.4 I'm seeing a lot of these error messages: bird: Unknown LSA type from x.x.x.x Is this anything to worry about? I don't see any issues affecting BIRD, but it is filling up log files. -- Eric Cables

2 1

explicitly setting rte->next = null
by Nic Cave-Lynch 22 Aug '14

22 Aug '14

Hi People I've been trying to find a segfault in a custom protocol I've been writing. I've finally tracked it down to a situation where bgp protocol, in bgp_rte_update, is calling rte_get_temp but not setting -> next to null, leaving it at whatever was left in RAM when the memory was allocated. Later, I see it's not null and try to access the ->next and eventually trigger a segfault. I've looked at the code and I can't see any reason why ->next shouldn't be set to null. So, does anyone know if this is going to cause problems later? The attached patch implements my change. I wonder if it might be better to explicitly set the rte pointed to by rte_get_temp to zero before using and returning it. I didn't want to make that change in case there are really good reasons why not. Cheers Nic C-L

2 2

Constants can't contain other constants?
by Michael Fincham 21 Aug '14

21 Aug '14

Hi everyone, I'm presently investigating BIRD as a (much appreciated!) replacement for Quagga and running in to some behaviour that isn't clear from reading the documentation. I'm looking at ways to consistently template BGP communities received from / sent to peers across multiple routers, and have attempted this: define test_international = (test_asn, 90); define test_national = (test_asn, 100); define test_ix = (test_asn, 200); define test_bilat = (test_asn, 300); define test_customer = (test_asn, 400); define test_infrastructure = (test_asn, 500); define test_send_to_transit = [test_blackhole]; define test_send_to_ix = []; define test_send_to_customer = [ test_international, test_national, test_ix, test_bilat, test_customer, test_infrastructure ]; With a view to later making a call to 'filter' in the BGP export filter facing the test customer: bgp_community.filter(test_send_to_customer); However loading this configuration in BIRD produces an error: bird> configure Reading configuration from /etc/bird/bird.conf /etc/bird/template/common.conf, line 84: Number expected Line 84 being the line shown above "define test_send_to_transit = [test_blackhole];". This suggests to me that one cannot define a constant including another existing constant in this manner? If so, is the best approach instead to define constants for individual communities and use re-usable 'functions' to group them logically? Suggestions heartily appreciated :) -- Michael

2 3

BGP Keepalive timer wedging
by Chris Caputo 20 Aug '14

20 Aug '14

At the Seattle IX we are using BIRD 1.4.4 for our native (non-VM) route servers. With one particular IPv4 peer, on two different route servers, I am seeing "Keepalive timer" count down to zero and then becoming wedged/stalled. Tcpdump fails to show a keepalive message being sent, while it does show them being received from the peer. We are using the default timer values. 2014-08-20 00:30:08 <TRACE> ex: Incoming connection from 206.81.80.xx (port 25663) accepted 2014-08-20 00:30:08 <TRACE> ex: Sending OPEN(ver=4,as=33108,hold=240,id=xxxxxxxx) 2014-08-20 00:30:09 <TRACE> ex: Got OPEN(as=xxxxx,hold=180,id=xxxxxxxx) 2014-08-20 00:30:09 <TRACE> ex: Sending KEEPALIVE 2014-08-20 00:30:09 <TRACE> ex: Got KEEPALIVE 2014-08-20 00:30:09 <TRACE> ex: BGP session established 2014-08-20 00:30:09 <TRACE> ex: Connected to table master 2014-08-20 00:30:09 <TRACE> ex: State changed to feed In the above, "Sending KEEPALIVE" does correspond to an outgoing keepalive packet, per tcpdump. Actually, two are sent on session startup, and then no more. "show protocols all ex" shows: Hold timer: 126/180 Keepalive timer: 0/60 etc.: Hold timer: 119/180 Keepalive timer: 0/60 with Hold timer getting updated over time, but the Keepalive timer doesn't change after it has its initial countdown to zero. The peer eventually signals "ex: Received: Hold timer expired" once it goes 180 seconds without a BGP update, since it also hasn't gotten any keepalive messages. I've looked at the code and haven't found a problem. The other 64 similarly configured peers on the route server are working fine. Has anyone seen this or have any suggestions? Thanks, Chris Seattle Internet Exchange

2 2