October 2014 - Bird-users

Suggestions to achieve multiple VRFs?
by Michael Fincham 22 Oct '14

22 Oct '14

Hi all, Presently I am testing a network design consisting of BIRD routers running a fairly unexciting "OSPF on linknets and loopback interfaces, iBGP mesh" type network. I am interested in suggestions for sensible ways to split a network of BIRD routers like this in to multiple VRFs - for instance to define a "management" VRF alongside the standard inet table. It seems simple to set up multiple routing tables on any given router and to learn routes in to those tables, however I am interested in suggestions for ways to distribute that routing information, as there seem to be several mechanisms that could be used. I'd like to avoid running multiple linknets and OSPF instances over my linknets if possible. -- Michael

2 3

Re: bird's not forwarding point-to-point routes via OSPF
by Noel Burton-Krahn 16 Oct '14

16 Oct '14

Thanks Ondrej, In our case, we're assigning peer point-to-point addresses on veth interfaces that we use for LXC containers. So they're essentially mini subnets with two interfaces. I didn't expect bird to treat peer addresses differently, so it took a few hours to figure out exactly what the problem was and how to work around it. So, I'd vote for either always allowing peer addresses, or adding a configuration option to make that behaviour more explicit. We'll work around that for now by adding a second /32 IP address to each interface. Cheers, -- Noel On Thu, Oct 16, 2014 at 7:42 AM, Ondrej Zajicek <santiago(a)crfreenet.org> wrote: > On Wed, Oct 15, 2014 at 11:00:03AM -0700, Noel Burton-Krahn wrote: > > Is there something about point to point addresses that could keep bird > > from forwarding them? I'm assigning a point-to-point address to a > > veth pair like so: > > > > ip link add veth1 type veth peer name veth2 > > ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev veth1 > > ip addr add 10.0.0.2/32 peer 10.0.0.1/32 dev veth2 > > > > Neither of those addresses get forwarded via OSPF to other hosts. > > They *do* get forwarded if I add the addresses without a peer like > > this: > > > > ip addr add 10.0.0.1/32 dev veth1 > > > > Now I've added the same address (10.0.0.1/32) to veth twice, and bird > > is forwarding a route for that address to OSPF peers. > > > > Is there a way for bird to accept the "peer" address? I tried "learn" > > in the kernel but that didn't help. > > .. also .. > > On Fri, Oct 10, 2014 at 12:05:30PM +0200, Thomas Goldberg wrote: > > Hello, > > > > we've OSPF running over a openvpn ptp tunnel and some problems with > > the routes injected by bird (v1.4.5). > ... > > Shouldn't bird inject routes like this on the corresponding router > > (without having to learn them via the direct protocol)? > > 10.176.3.29/32 dev lo [o_internal 2014-10-09 00:00:00] * I (150/0) > [10.176.3.29] > > Hello > > This is IMHO the same issue. It is an intentional behavior, BIRD does not > inject local address for links with peer addresses, mainly based on idea > that links with such addresses are just variants of 'unnumbered' ptp > links and these addresses are just general 'loopback' addresses and are > usually also used on other interfaces (like the explicit loopback > interface) [*]. > > Also note that it is usually simpler to add wanted addresses (using > explicit loopback interface or using 'stubnet' option) in use cases where > they should be propagated than remove unwanted addresses in use cases > where they should not be propagated. > > But in retrospect i am not sure if this behavior was really a good idea. > Perhaps automatic adding of host routes should be configurable and > enabled by default for peer addresses to ensure that all addresses on > OSPF-enabled interfaces are reachable in OSPF area. > > Any comments (esp. arguments for or against it) to this issue? > > > > [*] i.e. configuration like: > > ip addr add 10.0.0.1/32 dev lo / dummy0 > ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev eth0 > ip addr add 10.0.0.1/32 peer 10.0.0.3/32 dev eth1 > ip addr add 10.0.0.1/32 peer 10.0.0.4/32 dev eth2 > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santiago(a)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." >

1 0

All structures for network packets must have __attribute__((packed))
by Maksim Tamarsky 16 Oct '14

16 Oct '14

All structures for network packets must have __attribute__((packed)) We already speak about this problem 2 years ago. On my platform i have bad structure alignment in ospf and i need make this fix. ospf.h .............. struct immsb { #ifdef CPU_BIG_ENDIAN u8 padding:5; u8 i:1; u8 m:1; u8 ms:1; #else u8 ms:1; u8 m:1; u8 i:1; u8 padding:5; #endif }*__attribute__((packed))*; union imms { u8 byte; struct immsb bit; }*__attribute__((packed))*; ....... -- RU: Тамарский Максим Александрович Инженер-программист ООО Эн-Эс-Джи г.Москва, Кирпичная 39/41 оф.1302 Почтовый адрес: 105187 Россия, Москва ул.Вольная, д.35, оф.NSG Тел./факс: +7 495 727-19-59 Web-сайт: http://www.nsg.ru EN: Maksim Tamarsky Software Engineer NSG Ltd. 35 Volnaya Street, 105187 Moscow, Russia +7 495 727-19-59 http://www.nsg.ru

2 1

Multiple OSPF instances on one interface
by Tore Anderson 16 Oct '14

16 Oct '14

Hi, I'm trying to run two instances of OSPFv3 on a single interface, one in stub mode, the other in normal broadcast mode. It doesn't seem to work, in one of the protocols the interface ends up being marked "down". I don't see why that would be, since one of the instances is in stub mode, there should be no conflict between the two instances. bird6.conf on my test node contains the following ospf stanzas: protocol ospf main_igp_topology { area 10 { interface "eth0" { stub yes; }; }; } protocol ospf customer_anycast { area 20 { interface "eth0" { type broadcast; }; }; } After starting BIRD6, eth0 in the "customer_anycast" instnace is marked down, but looks fine in "main_igp_topology": root@kvmtest:~# birdc6 show ospf interface main_igp_topology BIRD 1.4.5 ready. main_igp_topology: Interface eth0 (IID 0) Type: broadcast Area: 0.0.0.10 (10) State: waiting (stub) Priority: 1 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designed router (ID): 0.0.0.0 Designed router (IP): :: Backup designed router (ID): 0.0.0.0 Backup designed router (IP): :: root@kvmtest:~# birdc6 show ospf interface customer_anycast BIRD 1.4.5 ready. customer_anycast: Interface eth0 (IID 0) Type: broadcast Area: 0.0.0.20 (20) State: down <---- why? Priority: 1 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designed router (ID): 0.0.0.0 Designed router (IP): :: Backup designed router (ID): 0.0.0.0 Backup designed router (IP): :: Disabling "main_igp_topology" immediately brings "customer_anycast" to life (at this point I can see in tcpdump that OSPFv3 hellos start being being trasmitted): root@kvmtest:~# birdc6 disable main_igp_topology BIRD 1.4.5 ready. main_igp_topology: disabled root@kvmtest:~# birdc6 show ospf interface customer_anycast BIRD 1.4.5 ready. customer_anycast: Interface eth0 (IID 0) Type: broadcast Area: 0.0.0.20 (20) State: waiting <---- looking better! Priority: 1 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designed router (ID): 0.0.0.0 Designed router (IP): :: Backup designed router (ID): 0.0.0.0 Backup designed router (IP): :: The use case is that of a server LAN that needs to be allowed to dynamically advertise certain host routes to service addresses for anycast / fail-over purposes. I would then proceed to import those host routes into my IGP, which is the OSPFv3 instance that runs in stub mode (after ensuring the announced routes fall within a permitted prefix). I have used RIPng instead of OSFPv3 for the "customer_anycast" role before, but it is very slow to react to failures and is rather limited in other ways too. So I was hoping replace it with OSPFv3, hopefully with BFD for super-fast failure detection. Tore

2 1

bird's not forwarding point-to-point routes via OSPF
by Noel Burton-Krahn 16 Oct '14

16 Oct '14

Is there something about point to point addresses that could keep bird from forwarding them? I'm assigning a point-to-point address to a veth pair like so: ip link add veth1 type veth peer name veth2 ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev veth1 ip addr add 10.0.0.2/32 peer 10.0.0.1/32 dev veth2 Neither of those addresses get forwarded via OSPF to other hosts. They *do* get forwarded if I add the addresses without a peer like this: ip addr add 10.0.0.1/32 dev veth1 Now I've added the same address (10.0.0.1/32) to veth twice, and bird is forwarding a route for that address to OSPF peers. Is there a way for bird to accept the "peer" address? I tried "learn" in the kernel but that didn't help. TIA, -- Noel

2 1

RIP not doing "triggered update" following route deletion
by Tore Anderson 15 Oct '14

15 Oct '14

I've noticed that BIRD doesn't withdraw (i.e., advertising them with metric 16) RIP routes when they disappear from the routing table. This means that the neighbour router ends up waiting for the route to time out before ceasing to send traffic to the BIRD router, rather than doing so immediately. I'm running v1.4.0 with a bird.conf containing: log syslog { info, remote, warning, error, auth, fatal }; router id 192.0.2.1; protocol device {} protocol direct {} protocol rip { interface "*" { mode nolisten; ttl security on; }; import none; export all; } To reproduce the issue, look at "tcpdump -v port 520" while doing: 1) ip address add 192.0.2.2/32 dev lo -> a triggered update appears (advertising 192.0.2.2/32) 2) ip address delete 192.0.2.2/32 dev lo -> a triggered update doesn't appear (it should have) For what it's worth, step #2 does increase the RIP protocol's "Export withdraws" counter. This issue also applies to RIPng/bird6. AFAICT, not sending these triggered updates immediately is a standards violation. Quoting RFC 1812 F.2: «A router MUST send a triggered update when routes are deleted or their metrics are increased.» Also see RFC 2453 section 3.10.1. Tore

2 3

BIRD on FreeBSD
by Eric Nghia Nguyen Duy 13 Oct '14

13 Oct '14

Dear all BIRD users, At this moment we are looking into deploy BIRD of FreeBSD so we would like to have some opinion from someone already did it. It should be pretty straight forward but if there is any concerns/issue/experience that anyone want to share, it would be appreciated. -- Best Regards, Eric Nghia Nguyen-Duy NOC engineer www.ams-ix.net eric(a)ams-ix.net

7 11

OSPF stubnets of PtP interfaces
by Thomas Goldberg 10 Oct '14

10 Oct '14

Hello, we've OSPF running over a openvpn ptp tunnel and some problems with the routes injected by bird (v1.4.5). OSPF is running in PtP mode on the tun0 interface of each router. The problem is that bird doesn't inject any routers for the local interface IP as intra-area route into OSPF itself. We've to inject them as external route via import of routes learned by a direct protocol (d_local). This is how the end result looks: Router A: interface config: 17: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/none inet 10.176.3.29 peer 10.176.3.30/32 scope global tun0 bird routes: 10.176.3.30/32 dev tun0 [d_local 2014-10-07 16:13:46] * (240) 10.176.3.29/32 via 10.176.3.30 on tun0 [o_internal 2014-10-09 17:45:44] * E1 (150/100) [10.176.3.30] Router B: interface config: 13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.176.3.30 peer 10.176.3.29/32 scope global tun0 bird routes: 10.176.3.29/32 dev tun0 [d_local 2014-10-09 17:45:43] * (240) 10.176.3.30/32 via 10.176.3.29 on tun0 [o_internal 2014-10-09 17:40:51] * E1 (150/100) [10.176.3.29] Shouldn't bird inject routes like this on the corresponding router (without having to learn them via the direct protocol)? 10.176.3.29/32 dev lo [o_internal 2014-10-09 00:00:00] * I (150/0) [10.176.3.29]

2 1

Re: OSPF route selection
by Olivier Benghozi 09 Oct '14

09 Oct '14

On 9 oct. 2014 à 12:54, Ondrej Zajicek <santiago(a)crfreenet.org> wrote : > On Wed, Oct 08, 2014 at 01:28:43PM +0200, Olivier Benghozi wrote: >> it should be noted that the RFC 2328 explains in its annex C.1 that the "RFC1583Compatibility" flag must be "Set to enabled by default". > > Thanks, i never noticed that. And some codes don't even allow to switch it off (Ericsson/Redback...) :-/ >> The critical thing is having that configuration consistant across the >> network (default values sometimes suck), and understanding what is done >> (if set to off, the particular loop case design must be avoided). > > This is probably a typo, but the loop case must be avoided when > RFC1583Compatibility is enabled, not when it is turned off. Right, if set to On :)

1 0

Version 1.4.4
by Ondrej Filip 07 Oct '14

07 Oct '14

Dear Bird users, the new version is out: Version 1.4.4 o Extended OSPF multipath support. o Default router preference for RAdv. o Significant changes in socket layer. o Important bugfix in BGP. o Several minor bugfixes. Ondrej

7 9