- Bird-users - Mailing Lists

Unreachable next-hop over bgp
by Alex Bligh 17 Aug '11

17 Aug '11

Another bird newbie question I'm afraid. I have the following config: 10.255.199.3 10.255.199.1 [Quagga]----------------------------- [BIRD] 10.255.199.0/24 My bird config and quagga config are at the bottom of this email. Bird is learning a kernel route (6.6.6.6) and advertising it to quagga. This works fine. Quagga is originating a default route (0.0.0.0/32) and advertising it to bird. The advertisement works fine, but I see: bird> show route 6.6.6.6/32 via 10.99.99.2 on dummy [kernel1 18:02] * (10) 0.0.0.0/0 unreachable [MyBGP 18:26 from 10.255.199.1] * (100/-) [i] bird> show route 0.0.0.0/0 all 0.0.0.0/0 unreachable [MyBGP 18:26 from 10.255.199.1] * (100/-) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 10.255.199.1 BGP.local_pref: 100 Bird has marked the route as unreachable. Obviously the route is not unreachable, because it is the next hop (quagga is doing next-hop-self). The only reason for this I can see is because bird is determining reachability on the basis of its FIB only (as opposed to the kernel routing table) and there is no FIB entry for 10.255.199.0/24 (from show route). How are such interface routes meant to get into the FIB? -- Alex Bligh Bird config: protocol kernel { persist; # Don't remove routes on bird shutdown scan time 10; # Scan kernel routing table every 20 seconds import all; export all; learn; # Learn all alien routes from the kernel } # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol bgp MyBGP { local as 65000; neighbor 10.255.199.1 as 65000; export filter { accept; }; import filter { accept; }; next hop self; import all; export all; } Quagga config: router bgp 65000 bgp router-id 10.255.199.1 neighbor 10.255.199.3 remote-as 65000 neighbor 10.255.199.3 next-hop-self neighbor 10.255.199.3 default-originate neighbor 10.255.199.3 soft-reconfiguration inbound Log from Quagga 2011/08/17 18:19:43 BGP: 10.255.199.3 went from Idle to Connect 2011/08/17 18:19:43 BGP: 10.255.199.3 passive open 2011/08/17 18:19:43 BGP: 10.255.199.3 went from Active to OpenSent 2011/08/17 18:19:43 BGP: 10.255.199.3 rcv message type 1, length (excl. header) 26 2011/08/17 18:19:43 BGP: 10.255.199.3 rcv OPEN, version 4, remote-as (in open) 65000, holdtime 240, id 10.99.99.1 2011/08/17 18:19:43 BGP: 10.255.199.3 sending OPEN, version 4, my as 65000, holdtime 180, id 10.255.199.1 2011/08/17 18:19:43 BGP: 10.255.199.3 send message type 1, length (incl. header) 53 2011/08/17 18:19:43 BGP: 10.255.199.3 rcv OPEN w/ OPTION parameter len: 16 2011/08/17 18:19:43 BGP: 10.255.199.3 rcvd OPEN w/ optional parameter type 2 (Capability) len 14 2011/08/17 18:19:43 BGP: 10.255.199.3 OPEN has MultiProtocol Extensions capability (1), length 4 2011/08/17 18:19:43 BGP: 10.255.199.3 OPEN has MP_EXT CAP for afi/safi: 1/1 2011/08/17 18:19:43 BGP: 10.255.199.3 OPEN has Route Refresh capability (2), length 0 2011/08/17 18:19:43 BGP: message index 65 [4-octet AS number] found in position 4 (max is 8) 2011/08/17 18:19:43 BGP: 10.255.199.3 OPEN has 4-octet AS number capability (65), length 4 2011/08/17 18:19:43 BGP: 10.255.199.3 went from OpenSent to Deleted 2011/08/17 18:19:43 BGP: 10.255.199.3 send message type 4, length (incl. header) 19 2011/08/17 18:19:43 BGP: 10.255.199.3 went from OpenSent to OpenConfirm 2011/08/17 18:19:43 BGP: 10.255.199.3 rcv message type 4, length (excl. header) 0 2011/08/17 18:19:43 BGP: 10.255.199.3 went from OpenConfirm to Established 2011/08/17 18:19:43 BGP: 10.255.199.3 send message type 4, length (incl. header) 19 2011/08/17 18:19:43 BGP: 10.255.199.3 send UPDATE 0.0.0.0/0 nexthop 10.255.199.1, origin i, mp_nexthop ::, path 2011/08/17 18:19:43 BGP: 10.255.199.3 rcvd UPDATE w/ attr: nexthop 10.255.199.3, origin i, localpref 100, path 2011/08/17 18:19:43 BGP: 10.255.199.3 rcvd 6.6.6.6/32

3 6

GTSM (TTL security)/RFC 5082 support?
by Henrique de Moraes Holschuh 16 Aug '11

16 Aug '11

Is anyone currently working on adding GTSM support to bird? It should be possible to support it for both Linux and FreeBSD where available as a kernel-level supported socket option, and I am considering trying my hand at it as a way to get to know the bird codebase a bit better before we decide to deploy it at work... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh

3 9

Activate back learning from user-defined routes in kernel protocol?
by Benjamin Cama 14 Aug '11

14 Aug '11

Hi, I am currently evaluating BIRD, and stumbled on some difficulty, which looks quite similar to the one encountered by Łukasz here: http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg01039.ht… In my case, it's l2tpns [1] that generates additional routes on a tun interface, and that get ignored by BIRD. As Ondrej showed, the reason why BIRD does that is because Linux IPv6 supposedly don't distinguish between “native” device routes and user defined one. And, as the comment tells us, the best way to fix that is to set the protocol on the added routes to something correct when adding them (which wouldn't be static in my case, but rather something else like “l2tp” on a custom proto #). I'm working on patching l2tpns to do that. Still, I wondered why this comment was here, because on my linux 3.0 box, “native” routes are actually set as “proto kernel”. I tested on a 2.6.32, and it's also the case. But no luck on a 2.6.26. So, I searched in the kernel git, and found the culprit : commit 4f72427998b105392e60bae7a6798a0c96fe4f0a which can be viewed here http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h… This dates back to may 2009, and coincidentally was done to please quagga ;-) And it appeared juste before 2.6.30. On the BIRD side, it's commit ff2857b03db854f99902766ad842aaa5fa29ec3c that included the workaround to ignore all PROTO_BOOT routes. See here https://git.nic.cz/redmine/projects/bird/repository/revisions/ff2857b03db85… And it actually happened after the kernel charge, in february 2010! So, I was wondering if you would consider getting back to the “old” behavior of not ignoring PROTO_BOOT routes on kernel >= 2.6.30? It would be quite a change, still, and it may look strange that BIRD behave differently on kernel before and after 2.6.30. But it would help people like me who struggled to get their routes taken into account, just to find after a painful search that it's because of a kernel “bug”. I don't know what's the right answer to this, but I wanted to inform you of this change in Linux's behavior, in case you didn't notice it. Regard, Benjamin [1] http://sourceforge.net/projects/l2tpns/

2 1

bird filter fails after upgrade from 1.3.1 -> 1.3.2
by Matthew Whittaker-Williams 08 Aug '11

08 Aug '11

Hi, I am having some issues with a filter of mine since my last upgrade to 1.3.2. Aug 6 00:00:04 bird: filters, line 72: AS path expected Aug 6 00:00:04 bird: filters, line 72: AS path expected filter national int set asnums; { # Exceptions asnums = [ 286, 47377, 8514, 5430, 6848, 3300]; # Failes on this line below: if ( bgp_path.last ~ asnums) then { accept; } else { reject; } } Changing it to : if bgp_path.last ~ [ 286, 47377, 8514, 5430, 6848, 3300 ] then { accept; } Then its all fine, has the way on setting int changed? Thanks Kind regards, Matthew

2 1

Merging bird and bird6
by Alexander V. Chernikov 07 Aug '11

07 Aug '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list! Are there any plans to move from different daemons to single one? - From user point of view: We will live with both v4+v6 for the next 10+ years, having all dynamic routing in single place with single CLI is much more convenient. - From developer point of view: At the moment all code is based on ip_addr address type which is defined to be v4 OR v6 at compile time. FIBs API assume the same: IPv4 OR IPv6. Speaking about advanced (mostly MPLS-related) features (VPNv4, LDP, MP-BGP in general) - they all need fibs which are not bound to specific address family. At the moment developer has to implement such tables himself. using different processes for different AF makes some MP-BGP aspects very hard to implement. Protocols interaction is also bound to fibs. Even calling protocol hooks is bound to ip_addr and prefix. For example, I'm stuck in sending MPLS labels into kernel at the moment. Of course, I can add a custom hook to kernel protocol but than I will have to support another custom patch which should be avoided. Maybe it is time to start a discussion? I can supply patches if there is any chance for review/commit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4UzxwACgkQwcJ4iSZ1q2lJJQCfWNRQZF8/8Rtk1PmYVLZ2MhZl BJMAoKI1aYjuvafYnGP1rePFIZ7X1+ub =2/AD -----END PGP SIGNATURE-----

4 14

birdc: using command output in scripts
by Alexander V. Chernikov 31 Jul '11

31 Jul '11

Hello list! It is more or less useful to see 'BIRD X.X.X ready.' after cli starts. However, birdc is sometimes used in non-interactive way (like 'birdc configure' or 'birdc show route table XXXX for YYY'). Getting such string (in STDOUT, as other data) with command output is inconvenient. This behavior can be fixed with very trivial patch. Can someone consider getting it added to the tree?

2 1

"include" global option?
by Aris Lambrianidis 31 Jul '11

31 Jul '11

Greetings Ondrej and all, I was wondering whether an "include" general option could be implemented as to segment large BIRD configuration files to smaller parts, a lá BIND. This should be trivial to implement I suppose, and could really help with scripting and clarity. Thank you for your time, --Aris Lambrianidis

4 5

All protocols restarting on configure soft
by Stephen Holmes 28 Jul '11

28 Jul '11

BIRD Masters, BIRD 1.2.5 I recently updated my route server configuration to include a new set of BGP export filters when one peer wants to exclude routes to another peer. The filter is only applied to those selecting to exclude one another. When I pushed the new config with only two BGP sessions having the added filers, the rest untouched, and two new pipes were added, BIRD restarted all PIPE/BGP sessions after a 'configure soft'. Is this the expected behavior? Without export filter: protocol bgp RXXXXX { local as myas; neighbor xx.xx.xx.xx as XXXXX; import filter bgp_in_ASXXXXX; export all; route limit 500; table TXXXXX; rs client; start delay time 30; } With export filter: protocol bgp RYYYY { debug { filters }; local as myas; neighbor yy.yy.yy.yy as YYYY; import filter bgp_in_ASYYYY; export filter bgp_out_ASYYYY; route limit 1000; table TYYYY; rs client; start delay time 30; } Much Appreciated, Stephen

1 2

init script
by Ryan Whelan 27 Jul '11

27 Jul '11

Looking through the source, I don't see any init scripts for controlling the starting and stopping of Bird. Before I write something, I wanted to check if they already existed and I'm just missing them. Thanks

4 4

Advertising interface addresses via OSPF
by Ryan Whelan 27 Jul '11

27 Jul '11

I have 3 Linux machines connected to one another by point-to-point links. With the end point of each tunnel using a tun device, there are a total of 6 tun devices used on across the 3 machines. 2 per machine. Using OSPF, Bird is not advertising the addresses on the tun devices to the other nodes. This causes an issue because each device is unaware of the addresses on the tun devices on tunnels it is not connected to. In other words, node 'C' is unaware of the addresses on the tunnel between nodes 'A' and 'B'. Thats an issue because if the link between 'A' and 'B' fails, 'A' will get the routes 'B' knows about thru 'C', but 'B' does not know the tun address of 'A' thats connected to 'C' so all the traffic 'C' routes from 'A' to 'B' comes from an address 'B' can't route back too. (Sorry its so hard to follow) I've been able to alleviate it by adding a `stubnet` for each tun device on each machine, but I'm afraid that will become increasingly difficult to maintain as the number of nodes increases. Is there another way? I've been unsuccessful at getting bird to import (and advertise) the routes associated with the tun devices. (using the 'device' protocol I can get bird to import them, but ospf doesn't advertise them to the other nodes)

2 6