- Bird-users - Mailing Lists

RFC 5549
by Łukasz Trąbiński 21 Apr '16

21 Apr '16

Hi I can’t find information in google/ docs / sources, Is the bird supports rfc 5549 ? If not (I guess it does not), is there any plans to support rfc 5549 in future?

2 1

Feature request? Setting bgp_med to IGP metric
by Keenan Tims 21 Apr '16

21 Apr '16

Hi all, I am working today to try to have BIRD propagate my calculated IGP metric to an eBGP peer via MED. This is implemented in commercial routers typically with a flag in the BGP configuration (ie. on JunOS you set 'metric-out igp' in the peer configuration), which will propagate to eBGP the calculated IGP metric to the BGP next-hop as MED MED. This allows MED to update dynamically based on changes to the internal path to that exit, and be automatically calculated by the IGP SPF algorithm, assuming you have set your link costs appropriately. My network uses OSPF to propagate interface and loopback routes only, and iBGP for all 'real' routes. While there is a full mesh in iBGP, obviously not all nodes are directly connected, so OSPF costs are used to determine the path to the destination using 'gateway recursive'. The IGP cost may change if e.g. a node goes down, and I would like to facilitate eBGP peers moving their traffic to the optimal node in such cases, as well as leveraging the IGP data to automatically use the correct entry point in the normal case as well. Is there a way to do this in BIRD? I tried a few different parameters that might contain this information, but none were set in an eBGP export filter (igp_metric, preference, ospf_metric1). The only solution I could come up with, even for the normal case, was using a community for 'route learned at', but this requires every router's configuration to include the path cost to every other router, which quickly becomes cumbersome to maintain as the network grows. I think the ideal solution would be to expose the IGP cost in a new attribute (or maybe use igp_metric as it doesn't seem to be set), such that a filter could work with it to set an appropriate bgp_med. Internally it's obviously available, since birdc shows it as part of the preference for BGP routes. I guess the difficulty would be making sure changes propagate through eBGP peerings. Alternatively, a knob could be provided in the peer configuration, perhaps as a special setting for default bgp_med. Or both :). Keenan Tims

1 0

limit the output
by Rohrmann Sascha 13 Apr '16

13 Apr '16

Hi, is it possible to limit the birdc show route output for a certain protocol? I wrote a script which runs in a specific interval and fetches the received BGP routes. Normally the bgp routing table has thounsands of entries. In order to save some cpu power Bird only needs to show me the first 10,15,20 or 25 routes. In SQL there is a "limit" keyword which would be able to fulfil my desire. So... is there smth similar in bird? Thanks in advance.

1 0

iBGP unreachable
by Panda RoboLegs 12 Apr '16

12 Apr '16

Hello, I am new to Bird and I am trying to set up a Looking-Glass. I have configured a iBGP-Session with a route-reflector to gather the needed routes. When I do a "show route". Every route I got via BGP is unreachable. xxx.xxx.xxx.xxx/24 unreachable [bgp_v4 13:32:40 from xxx.xxx.xxx.xxx] * (100/-) [ASxxxxxxi] The Log will give me the following: 2016-04-10 13:32:44 <WARN> Next hop address xxx.xxx.xxx.xxx resolvable through recursive route for xxx.xxx.xxx.xxx/24 When I add a static route via Bird for the unreachable prefix to the next hop the route is resolvable. route xxx.xxx.xxx.xxx/32 via xxx.xxx.xxx.xxx A static default gateway won't do the trick (route 0.0.0.0/0 via xxx.xxx.xxx.xxx;). the routes are still unreachable. Is there any posibility to solve ths problem without adding an IGP or a static route to every next hop? Best regards, Marius

4 6

RE: iBGP unreachable
by Panda RoboLegs 11 Apr '16

11 Apr '16

With "direct" in the BGP configuration the protocoll won't come up With "gateway direct" Bird won't start "Multihop BGP cannot use direct gateway mode" "gateway recursive" won't differ from the original behaviour Date: Mon, 11 Apr 2016 20:43:13 +0500 From: oleynikov_v(a)ufanet.ru To: pandawithrobotlegs(a)outlook.com CC: bird-users(a)network.cz Subject: Re: iBGP unreachable Re: iBGP unreachable Hello You can try using "direct" and "direct gateway" commands in peer coniguration. Sometimes it helps. WBR, duckhawk Вы писали 11 апреля 2016 г., 20:13:22: Hello, I am new to Bird and I am trying to set up a Looking-Glass. I have configured a iBGP-Session with a route-reflector to gather the needed routes. When I do a "show route". Every route I got via BGP is unreachable. xxx.xxx.xxx.xxx/24 unreachable [bgp_v4 13:32:40 from xxx.xxx.xxx.xxx] * (100/-) [ASxxxxxxi] The Log will give me the following: 2016-04-10 13:32:44 <WARN> Next hop address xxx.xxx.xxx.xxx resolvable through recursive route for xxx.xxx.xxx.xxx/24 When I add a static route via Bird for the unreachable prefix to the next hop the route is resolvable. route xxx.xxx.xxx.xxx/32 via xxx.xxx.xxx.xxx A static default gateway won't do the trick (route 0.0.0.0/0 via xxx.xxx.xxx.xxx;). the routes are still unreachable. Is there any posibility to solve ths problem without adding an IGP or a static route to every next hop? Best regards, Marius

1 0

bird 1.5.0 compiled with -fno-strict-aliasing, -fno-strict-overflow causes varied loadavg values while it's constant without these flags
by Bartosz Radwan 11 Apr '16

11 Apr '16

Hi bird users Some time ago 've experiencd some seggfaults issues with bird comiled without -fno-strict-aliasing, -fno-strict-overflow After addition of -fno-strict-aliasing, -fno-strict-overflow i'm observing strange loadavg peaks on my router: http://www.sq9mev.info/bird_cflags_loadavg_change.png The upgrade was done on wednesday and varied loadavg is clearly visible in above graph. I've used 1.5.0 provided by upstream (ftp://bird.network.cz/pub/bird/redhat/bird-1.5.0-1.x86_64.rpm) with the same result (varied loadavg). Next thing i've tried was to cherry pick 54bb032d and 665b8e52 on 1.5.0 and compiling without -fno-strict-aliasing, -fno-strict-overflow This binary causes varied loadavg as well. I've noticed that values of peaks is correlated with kernel scan time parameter. I'm using smaller then default (20s) value of 1s. With scan time set to quite high value of 300s load 1minute load have some peaks, but overall loadavg looks quite constant. 5 minutes scan time seems ok for me - i' not expecting a big amonut of alien routes, and a few of them i have will probably be propagated successfuly with async netlink notifications. My question is - is such a varied loadavg normal with 10s or even 20s scan time? I have several ful view bgp sessions: birdc show route count BIRD 1.5.0 ready. 1263256 of 1263256 routes for 582924 networks I've compared stable and unstable load bird processes with perf tools: http://www.sq9mev.info/stable_unstable.diff.txt I've compared unstable load bird processes during low and high load periods: http://www.sq9mev.info/unstable_near1_near0_perf.diff.txt In "unstable load" versions there is noticable amount of if_find_by_index samples, while it's not at all in "stable" version. Is the varied load with lower kernel scan time price of saver list node removal? Is it more bird issue or should i just try to find the cause in my enviroment? -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Regards Bartosz Radwan

1 0

[PATCH v3 0/2] Add the Babel routing protocol to Bird
by Toke Høiland-Jørgensen 04 Apr '16

04 Apr '16

This is the updated patch to add the Babel protocol to Bird. There are not a huge amount of changes since the last version, but some important bug fixes. Specifically: - Fix protocol reconfiguration logic. - Fix sequence number space calculation. - Fix interface update trigger logic so multiple triggers do no not step on each other. - Enforce a minimum size of RX and TX buffers. - Handle routes being removed by the core that originated from within this instance of Babel, for instance if export filters are changed. - Only trigger updates if rt_notify() actually changes things. - Change default wired hello interval to 4 secs (which is what babeld uses). - Handle non-LL next hop addresses in next hop TLVs. - Make sure to only schedule send events if the socket buffer is empty. Toke Høiland-Jørgensen (2): Teach bvsnprintf() to print 64-bit router IDs. Add the Babel routing protocol (RFC6126). .gitignore | 13 + configure.in | 3 + doc/bird.sgml | 93 +++ lib/bitops.h | 3 +- lib/ip.h | 3 + lib/printf.c | 31 +- nest/proto.c | 3 + nest/protocol.h | 2 +- nest/route.h | 11 +- proto/Doc | 1 + proto/babel/Doc | 2 + proto/babel/Makefile | 5 + proto/babel/babel.c | 1945 ++++++++++++++++++++++++++++++++++++++++++++++++++ proto/babel/babel.h | 349 +++++++++ proto/babel/config.Y | 129 ++++ proto/babel/packet.c | 871 ++++++++++++++++++++++ proto/babel/packet.h | 127 ++++ sysdep/autoconf.h.in | 1 + 18 files changed, 3582 insertions(+), 10 deletions(-) create mode 100644 .gitignore create mode 100644 proto/babel/Doc create mode 100644 proto/babel/Makefile create mode 100644 proto/babel/babel.c create mode 100644 proto/babel/babel.h create mode 100644 proto/babel/config.Y create mode 100644 proto/babel/packet.c create mode 100644 proto/babel/packet.h -- 2.8.0

1 1

[PATCH v3 1/2] Teach bvsnprintf() to print 64-bit router IDs.
by Toke Høiland-Jørgensen 04 Apr '16

04 Apr '16

Using '%lR' seemed like a natural extension to the format specifier. Router IDs are printed as hexadecimal octets separated by : -- this matches the output of babeld. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- lib/ip.h | 2 ++ lib/printf.c | 31 ++++++++++++++++++++++++------- 2 files changed, 26 insertions(+), 7 deletions(-) diff --git a/lib/ip.h b/lib/ip.h index 5389c44..5bc44e0 100644 --- a/lib/ip.h +++ b/lib/ip.h @@ -39,6 +39,8 @@ #define IP6_HEADER_LENGTH 40 #define UDP_HEADER_LENGTH 8 +#define ROUTER_ID_64_LENGTH 23 + #ifdef IPV6 #define MAX_PREFIX_LENGTH 128 diff --git a/lib/printf.c b/lib/printf.c index e4cc300..a067fe9 100644 --- a/lib/printf.c +++ b/lib/printf.c @@ -124,6 +124,7 @@ static char * number(char * str, long num, int base, int size, int precision, * width is automatically replaced by standard IP address width which * depends on whether we use IPv4 or IPv6; |%#I| gives hexadecimal format), * |%R| for Router / Network ID (u32 value printed as IPv4 address) + * |%lR| for 64bit Router / Network ID (u64 value printed as eight :-separated octets) * and |%m| resp. |%M| for error messages (uses strerror() to translate @errno code to * message text). On the other hand, it doesn't support floating * point numbers. @@ -137,9 +138,10 @@ int bvsnprintf(char *buf, int size, const char *fmt, va_list args) unsigned long num; int i, base; u32 x; + u64 X; char *str, *start; const char *s; - char ipbuf[STD_ADDRESS_P_LENGTH+1]; + char ipbuf[MAX(STD_ADDRESS_P_LENGTH,ROUTER_ID_64_LENGTH)+1]; struct iface *iface; int flags; /* flags to number() */ @@ -309,12 +311,27 @@ int bvsnprintf(char *buf, int size, const char *fmt, va_list args) /* Router/Network ID - essentially IPv4 address in u32 value */ case 'R': - x = va_arg(args, u32); - bsprintf(ipbuf, "%d.%d.%d.%d", - ((x >> 24) & 0xff), - ((x >> 16) & 0xff), - ((x >> 8) & 0xff), - (x & 0xff)); + if(qualifier == 'l') { + X = va_arg(args, u64); + bsprintf(ipbuf, "%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x", + ((X >> 56) & 0xff), + ((X >> 48) & 0xff), + ((X >> 40) & 0xff), + ((X >> 32) & 0xff), + ((X >> 24) & 0xff), + ((X >> 16) & 0xff), + ((X >> 8) & 0xff), + (X & 0xff)); + } + else + { + x = va_arg(args, u32); + bsprintf(ipbuf, "%d.%d.%d.%d", + ((x >> 24) & 0xff), + ((x >> 16) & 0xff), + ((x >> 8) & 0xff), + (x & 0xff)); + } s = ipbuf; goto str; -- 2.8.0

1 0

[PATCH master v2] IPv6 ECMP support fixes for linux
by Mikhail Sennikovskii 04 Apr '16

04 Apr '16

Hi Ondrej and all, Here is the second version of the Linux IPv6 ECMP support patch. It encorporates the adjustments, requested by Ondrej, as well as some other modifications/fixes, accompanied by the comments in the code. To save a bit of my time, I've created just one patch against the master for now. Once we agree on the patch, I will create a patch agains int-new right away, since adapting it to int-new is really strait-forward. Also, as we discussed before, I will also create a separate patch to make the nl_parse_multipath use netlink_lp (linpool) instead of xrealloc, once we agree on the current netlink_lp approach that I've introduced. Regards, Mikhail

1 3

Incorrect value of s->pref_routes in nest/proto.c
by Alexander Shikov 01 Apr '16

01 Apr '16

Hello! While experimenting with tables I've noticed that number of preferred routes in 'show protocol all ...' output is shown incorrectly. Configuration is simple: table T_ITCONS; protocol bgp ITCONS { table T_ITCONS; passive; local as MyASN; neighbor 193.25.180.17 as 25372; rs client; prefer older on; import all; export none; } protocol pipe P_ITCONS { table master; mode transparent; peer table T_ITCONS; import where bgp_path.last = 28773; export none; } I got 9 routes in T_ITCONS table, 2 of them are exported to master table: bird> show route 195.78.38.0/23 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS28773i] 188.190.160.0/19 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS28773i] bird> show route table T_ITCONS 109.68.40.0/21 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS25372i] 80.78.63.0/24 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS60359i] 185.102.164.0/22 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS29242i] 185.102.164.0/24 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS29242i] 194.247.174.0/24 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS196831i] 194.247.175.0/24 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS196831?] 193.84.72.0/24 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS39851i] 195.78.38.0/23 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS28773i] 188.190.160.0/19 via 193.25.180.17 on vlan777 [ITCONS 2016-03-31 18:11:33] * (100) [AS28773i] 'show protocol all ITCONS' shows sum of them, i.e. 11 preferred routes and that is incorrect: bird> show protocol all ITCONS name proto table state since info ITCONS BGP T_ITCONS up 2016-03-31 18:11:33 Established Description: IT Consulting LLC Preference: 100 Input filter: ACCEPT Output filter: REJECT Routes: 9 imported, 0 exported, 11 preferred [...] I'm trying to figure out what's happening in nest/rt-table.c. Any help will be kindly appreciated! Thank you! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 http://dtel-ix.net/

2 2