- Bird-users - Mailing Lists

Bird debian repo now over https only?
by Adam Pribyl 18 Oct '18

18 Oct '18

We have embedded debian instalations using the debian bird package. However the repo url http://bird.network.cz/debian/ is redirected to https. This causes a problems, because our installations do not have https and apt ends with: The method driver /usr/lib/apt/methods/https could not be found. In my opinion the explicit http request should not be automaticaly rewriten to https. Adam Pribyl

7 12

Lost withdrawal message
by oldnick 17 Oct '18

17 Oct '18

Hi! I am observing strange BGP announcement problem. BGP peering is between bird router (version 2.0.2) and cisco router. BIRD 10.0.0.1 <---> 10.0.0.2 Cisco I am announcing prefix 10.10.10.10/32 from bird to cisco. My initial bird configuration is as follows: ################## [root@localhost ~]# cat /etc/bird.conf router id 10.0.0.1; filter filter1 { accept; } protocol kernel { persist yes; learn yes; scan time 10; ipv4 { import none; export none; }; } protocol device { scan time 10; } protocol direct { interface "lo"; ipv4 { import filter filter1; export none; }; } protocol bgp peer1 { local as 65001; neighbor 10.0.0.2 as 65002; hold time 45; ipv4 { import none; export filter filter1; }; } ##################### IP address 10.10.10.10/32 is configured on loopback interface: lo:1: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 10.10.10.10 netmask 255.255.255.255 It works just fine with this configuration. I can see announcement of 10.10.10.10/32 on cisco router: R1#show ip bgp Network Next Hop Metric LocPrf Weight Path *> 10.10.10.10/32 10.0.0.1 0 65001 i Strange thing happens when I make a change to filter1, instead of: filter filter1 { accept; } I change it to: filter filter1 { if ( net = 10.10.10.10/32 ) then { reject; } accept; } Basically I am blocking import of prefix 10.10.10.10/32 into direct protocol and at the same time I am blocking export of prefix 10.10.10.10/32 to peer1 (it is the same filter filter1 both for direct import and for peer1 export). After the change of /etc/bird.conf I am making "birdc configure" and I am expecting to see the withdrawal message on cisco side, but there is none (I checked it with tcpdump). Here is what I can still see on cisco side: R1#show ip bgp Network Next Hop Metric LocPrf Weight Path *> 10.10.10.10/32 10.0.0.1 0 65001 i This is the output of birdc "show route": bird> show route bird> This is the output of birdc "show route export peer1": bird> show route export peer1 bird> So there is no route according to bird, but it seems like bird does not send withdrawal message. Either I am doing something wrong, or it is a bird bug. Appreciate your help. -- Regards, Sergey

2 1

BGP neighbor
by Arvin Gan 15 Oct '18

15 Oct '18

Hi All, I notice that if BGP is directly connected, when BGP started, the bgp_start_locked() is called and using neigh_find2() to lookup the neighbor. In neigh_find2(), bird will loop iface_list and comparing the remote IP address with the IP prefix of interface, checking whether is the subnet. Now, I have a question that why not using route table to find the neighbor ? Since I have one case that make me have some confusion. Test Case: DUT1 DUT2 DUT3 lo interface 2000::1111/128 , interface3 3000:1::8/112 <-----------------------> interface4 3000:1::9/112, lo interface: 2000::2222/128 interface1 2000::1/112 <------>interface2: 2000::1/112 Igor the route table configuration, suppose the route is correct. 1. Anyone known the topology connection is normal or correct ? 2. if yes, create BGP peer with loopback interface 2000::1111, remote IP 2000::2222, directly connection. 3. BGP peer will use 2000::2222 to compare with interface prefix on DUT1, find the neighbor interface2 with prefix 2000::1/112 [interface2 on DUT2] BUT, actually, BGP peer TCP connection is not directly connected, and TCP connection don't using interface2 on DUT2, but using interface3 on DUT2 to connect interface4 of DUT3. Best Regards, Arvin Gan

1 0

OSPF generate default route - again
by Piotr Marciniak 12 Oct '18

12 Oct '18

Hello, I’ve spent some time trying to find any option to make our border BGP router to announce itself as defaul router by OSPF to our network switches. No luck. This discussion was rised fe. 5 years ago but with no answer (https://bird-users.network.narkive.com/AD6KOk8b/ospf-generate-default-route) All docs end examples I found touch only redistribute aspect of the problem. I think it is not optimal for such implementations. OK – let draw simple example. Step 1. Let’s have just 2 border backbone BGP routers with a few peers and full tables. Let’s name them just simple BGP1 and BGP2. Of course they talk one to another by iBGP as well. In fact – they know everything about Internet, so they do not need any 0/0 routes – external or static. If any peer fails – they will just recalculate tables and everything will work fine. Step 2. Let’s imagine the internal network build on some switches and small routers. As they are just local and have limited resources – they do not need and can’t work on iBGP with BGP1/2. OSPF if pretty enough for them. Let’s imagine they have names like OSPF10-20. Does not matter how they are connected. But for further discussion let’s imagine OSPF10 has direct connection with both BGP1/2. Step 3. In my example OSPF10 establishes sessions with BGP1/2. All OSPF local networks will be shared – but there would be no information about all Internet. So internal OSPF routers - as they do not have full knowledge about internet - in short – need to get default route from BGP1/2. Step 4. In configs published on Internet it is easy to get examples of export filters for redistributing default gw, like: if net = 0.0.0.0/0 then {ospf_metric2 = 100; accept;} else reject; or if source = RTS_STATIC then accept; else reject; Unfortunatelly published system requires that 0/0 will be set somwhere out of OSPF Bird config. In fact – 0/0 can be set by protocol static section or received from other source and redistributed to OSPF. All discussions I found end at this point. Step 5. In some discussions people try to ask how in Bird set equivalent to commonly known Cisco “redistribute default originate always”? But mostly answers say – “why you do not want to set it by “protocol static” or so?”. Let me put answer simple, but a bit in different way then in discusssions I found – BGP router needs no such directive at all. So any staticaly added “route 0/0 via” in protocol static should not be done at all. Why? For any static route you need fixed destination. We may play with some options but if this static destination gets unreachable – our OSPF default gw (and in effect all communication with Internet) is down. You can see it on your birdc if you add any fake destination or... destination disconnects – like port dow. bird> sh route export ospf1 0.0.0.0/0 unreachable [static_ospf 2018-09-18] * (200) Step 6. Redistributionto local OSPF routers of “external” default gw on border BGP router – should not be an option. Problem is simple – again we need a source of such 0/0. But we get none from our Internet BGP peeers. Step 7. Theoretically we may imagine that in my example OSPF10 will act as ‘default originate always’ router and forwards packets by static route to BGP1... What a waste. How to secure redundancy supported by BGP2? Step 8. For now – I may only set protocol static for any reachable IP on both BGP1/2, use above redistribution OSPF examples and pray – destination interfaces will not get down. Not good, don’t you think? Conclussion. BGP router is sometimes in fact a border router for “local” protocols like OSPF. Bird should have an option to announce itself by OSPF and only OSPF – as it is default gw for other OSPF routers. This announcement should be based on simple rule that Bird may know from other protocols (like BGP but not only), what to do with package received as default gw. But Bird not always may share this knowledge. Again – Bird can know all Internet prefixes from BGP sessions but can’t export it to simple switches in local network. This is why Bird should have an option to act as default gw regardless it has default gw set or received in other protocols. So please – let me know. How can I make “default originate always” in OSPF without redistributing 0/0 established in other sources. Best wishes, --- Zboj (Piotr Marciniak) zboj /at\ mnc dot pl

3 3

[PATCH 2.x branch] Makefile.in: fix installation with --disable-client
by Thomas Petazzoni 11 Oct '18

11 Oct '18

The configure.ac script initializes the CLIENT variable this way: CLIENT=birdcl if client enabled CLIENT=$CLIENT birdc fi This means that checking if @CLIENT@ is empty to decide whether birdc should be installed or not doesn't work, and causes a failure at installation time when --disable-client is passed. Instead, check if the birdc binary has been produced or not to decide whether it should be installed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> --- Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.in b/Makefile.in index c8168bbe..fea3683e 100644 --- a/Makefile.in +++ b/Makefile.in @@ -171,7 +171,7 @@ install: all $(INSTALL) -d $(DESTDIR)/$(sbindir) $(DESTDIR)/$(sysconfdir) $(DESTDIR)/@runtimedir@ $(INSTALL_PROGRAM) $(exedir)/bird $(DESTDIR)/$(sbindir)/bird $(INSTALL_PROGRAM) $(exedir)/birdcl $(DESTDIR)/$(sbindir)/birdcl - if test -n "@CLIENT@" ; then \ + if test -f $(exedir)/birdc ; then \ $(INSTALL_PROGRAM) $(exedir)/birdc $(DESTDIR)/$(sbindir)/birdc ; \ fi if ! test -f $(DESTDIR)/@CONFIG_FILE@ ; then \ -- 2.14.4

2 1

Public survey: PThread support on target systems
by Jan Maria Matejka 10 Oct '18

10 Oct '18

Dear users! Please answer a simple question: **Do you run BIRD on anything that has no or broken pthread support?** Why I do ask: We're currently doing large code changes to allow parallel execution of BIRD code. It is much pain to keep all the #if-ed code for cases when pthreads are off. Therefore we'd like to hard require pthreads and drop all the no-pthreads code. Please consider whether your answer should go to the list. (especially if it is simply "no, you can drop the no-pthreads code") I'll wait for at least a fortnight for your answers before concluding anything. Thank you for your answers! Maria

1 1

[Bird2] Doubt about Route Server function and iBGP
by heisenbug at xpto 08 Oct '18

08 Oct '18

Hello Guys, On bird1.6, I have deployed our Route Servers using the below architecture to split the load from the control plane: Customer1 <-> RS1[pid0] <-> iBGP <-> RS2[pid1] <-> Customer2 And is working fine as RS until now [not inserting local AS on AS-PATH and not changing NH]. I'm planing to migrate to Bird2.0.2 with some new features, but when I do the same on Bird2.0.2, I have the AS from iBGP inserted on AS-PATH, just to let me know, this is an expected behavior on Bird2? I have tested in a lot of ways, but still the same results. []s

2 6

BFD on Linux
by Ondrej Zajicek 02 Oct '18

02 Oct '18

Hi Forwarding a mail about source ports of BFD on Linux. ----- Forwarded message from "SHAW, JASON via RT" <bird-support(a)network.cz> ----- Date: Fri, 28 Sep 2018 19:37:05 +0200 Subject: BFD on Linux From: "SHAW, JASON via RT" <bird-support(a)network.cz> Hi. We're using Bird 2.0 for a project here at AT&T and I wanted to reach out and let you know that we've identified a potential alternate approach to adjusting /proc/sys/net/ipv4/ip_local_port_range on Linux systems to support BFD. Our Linux configuration uses a port range via: net.ipv4.ip_local_port_range = 1024 65000 As you are already aware, the BFD RFC states that "The source port MUST be in the range 49152 through 65535.". With the above configuration our BFD source port for any given BFD session, as selected by the Linux kernel, was sometimes in the "allowed" range and sometimes not. Cisco's implementation of BFD in our architecture enforces that source port range and drops BFD packets while the Juniper implementation (on the a different adjacent element in our architecture) does not. As a result, we were running BFD with the Juniper element successfully but had to disable it on the Cisco side. Our solution is to use iptables SNAT rules to solve the issue where our Linux system is running BGP with the Cisco neighbor on two separate interfaces eth3.181 and eth4.182. I selected port 65535 as it is a) the top of the range specified by the RFP and b) outside of the range specified in net.ipv4.ip_local_port_range we have configured. On vlan 181 (eth3.181) our local IP is 172.26.4.7 and the Cisco box is 172.26.4.6. Similarly, on vlan 182 (eth4.182) our IP is 172.26.5.7 and the Cisco box is 172.26.5.6. We run BGP using bird with this addressing scheme. I added the following two rules on our Linux hosts: iptables -A POSTROUTING -t nat -d 172.26.4.6 -p udp --dport 3784 -j SNAT --to-source 172.26.4.7:65535 iptables -A POSTROUTING -t nat -d 172.26.5.6 -p udp --dport 3784 -j SNAT --to-source 172.26.5.7:65535 A subsequent tcpdump on either eth3.181 or eth4.182 shows that all BFD packets are always sourced with a port # of 65535, regardless of what is assigned by the Linux kernel. Moreover, the Cisco box accepts these BFD packets and we're able to get BFD sessions up successfully. The same port # can be used on both sides, as they're separate source IPs on separate networks. Hopefully this helps somebody else and is a useful documentation addition. _______________ Jason Shaw Principal Member of Technical Staff Wireless Network Architecture and Design AT&T js7558(a)att.com<mailto:js7558@att.com> ----- End forwarded message ----- -- 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

MPLS LDP
by Danny Wensley 28 Sep '18

28 Sep '18

Hi all, I was wondering if anyone knows about improvements to MPLS support, specifically when it's going to be further integrated into BGP and when LDP will be added? Thanks, Danny.

3 3

IPv6 next-hop with incorrect link-local address received
by Sebastian Neuner 27 Sep '18

27 Sep '18

Hi all, we currently have an issue, where Bird kind of misses the right config option to fix. So we have a Cisco (XR) router peering with Bird on a Linux server. It's an eBGP-Session though a /127 link. We're announcing a prefix from the Cisco to bird, which has a foreign next-hop (i.e. not in this /127). Cisco apparently misinterprets RFC2545 (or has a bug, I'm still discussing this with TAC) and adds the peering interfaces link-local address. So now the next-hop in the BGP update looks like this: > Next hop network address (32 bytes) > Next Hop: xxxx:xxxx:c02::28 > Next Hop: fe80::28a:96ff:fecc:c10 The GUA next-hop is correct and points to a VM on the server (i.e. not on the /127). The link-local next-hop points to the Cisco. Unfortunately, this is the one, bird uses to install the route in the kernel. Am I missing something? Can I work around this somehow? Or would it make sense for bird to have a switch for that? Similar to "missing lladdr ignore" which works outbound, it could be something like "next hop lladdr ignore"? Best regards, Sebastian

3 5