- Bird-users - Mailing Lists

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

Primary route confusion
by Kenth Eriksson 24 Sep '18

24 Sep '18

Hi! The primary route in BIRD, marked by '*', confuses me. Consider the following two default routes as displayed by BIRD (2.0.2) and the Linux kernel (4.14.51+). bird> show route Table master4: 0.0.0.0/0 unicast [ospf1 19:54:43.687] * E1 (110/350) [172.20.4.41] via 172.20.4.41 on p1-1-1-1-2 unicast [kernel1 19:47:39.563] (40) via 172.20.0.1 on eth1 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 172.20.4.41 0.0.0.0 UG 32 0 0 p1-1-1-1-2 BIRD shows that the OSPF route with administrative distance of 110 is primary, and not the kernel route with administrative distance of 40. When BIRD pushes the OSPF route to the kernel, it uses the metric 32 by default, whereas the default kernel route has metric 0. Both routes are installed to the FIB, but the kernel will elect the route via eth1. Why is not the default route over eth1 shown as primary in BIRD? Can we control if BIRD pushes the OSPF route into the kernel here? The kernel already has a more preferred default route. Thanks, Kenth

3 5

Log length problem
by Mattia Milani 22 Sep '18

22 Sep '18

Hello everyone, I'm writing you because I recognize a strange problem when i log something, and I don't know if it is a bug or something wanted to work in this way. For a project i need to log some complex information, so i create a string with the info that I need and after that i log it with the command: log(L_INFO "...); But when the length of the string go over 1000 (I get the size with strlen) it is not printed on the log file. I was thinking to split the string to go over the problem, or there is another way? Thanks everyone Mattia

1 0

BGP-LS
by Fabien VINCENT (Bird-Users) 21 Sep '18

21 Sep '18

Dear List, Do you know if Bird supports BGP-LS AFI 16388 / SAFI 71 ? If yes, where can I found documentation ? If no, any plan for this ? Thanks ! -- Fabien VINCENT @beufanet

2 1