- Bird-users - Mailing Lists

announcing BGP prefixes from the same AS at different sites?
by Thomas Johnson 10 Sep '14

10 Sep '14

I am trying to sort out a chicken-and-egg problem is probably more of a network design question than bird-specific. I am using bird to announce prefixes from two geographically-separate locations (A and B). I am announcing different prefixes at each, but with the same AS. The problem I am having is how to get these locations to add each other's routes. At location A, I have a pair of bird routers (X and Y), each connected to a different provider. Both routers announce the prefixes for this site over eBGP. These routers have an iBGP session between them. At location B, there is a single router (Z), connected to one ISP. It announces its own prefixes upstream. Since both sites announce with the same AS, they don't import the other's prefixes. An iBGP full-mesh seems to be the _correct_ solution, but I am having trouble getting this implemented correctly. If I configure the inter-site iBGP sessions to connect between the addresses on the WAN interfaces, I get partial success. At site A, router X correctly adds routes for site B. Router Y establishes a connection to router Z (site B), but adds the B prefixes as unreachable. The difference is that the Y->Z BGP connection (A->B direction) is routed via router X (shorter AS path via X ISP). My configuration files for this setup are below. If I attempt to establish the inter-site iBGP between the loopbacks on the routers, I have no success, since the loopback addresses fall with the subnets I announce at each site. Is there some bit of configuration I am missing? Am I going about this the wrong way? Any thoughts are appreciated. # # router Y # site A # protocol bgp bgp_he { local as 12345; neighbor 1.1.2.69 as 6939; # Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_he; } protocol bgp ibgp_border { local 6.9.5.212 as 12345; neighbor 6.9.5.213 as 12345; multihop 2; import filter { accept; }; export filter { if source != RTS_BGP then { reject; } if proto = "ibgp_border" then { reject; } accept; }; } protocol bgp ibgp_1b { local 1.1.2.70 as 12345; neighbor 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; } protocol ospf { # *snip* } # # router X # site A # protocol bgp bgp_cogent { local as 12345; neighbor 3.8.1.105 as 174; # Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_cogent; } protocol bgp ibgp_border { local 6.9.5.213 as 12345; neighbor 6.9.5.212 as 12345; multihop 2; # Send all routes learnt via BGP import filter { accept; }; export filter { if source != RTS_BGP then { reject; } if proto = "ibgp_border" then { reject; } accept; }; } protocol bgp ibgp_1b { local 3.8.1.106 as 12345; neighbor 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; } protocol ospf { # *snip* } # # router Z # site B # template bgp ibgp_A { debug all; local 7.4.2.132 as 12345; multihop 10; import filter { accept; }; export filter { if proto = "static_bgp" then accept; if proto = "standby_bgp" then accept; if proto = "portable_bgp" then accept; reject; }; } protocol bgp ibgp_Y from ibgp_A { neighbor 1.1.2.70 as 12345; }; protocol bgp ibgp_X from ibgp_A { neighbor 3.8.1.106 as 12345; }; template bgp B { # Set our local AS. local as 12345; # Export exactly what prefixes we want advertised. No surprises. export filter { if proto = "static_bgp" then accept; if proto = "standby_bgp" then accept; if proto = "portable_bgp" && net.len <= 24 then accept; reject; }; # Import filtered routes from upstream. import filter bgp_in_B; } protocol bgp bgp_B from B { neighbor 7.4.2.130 as 1212; };

3 4

bgp router with multi asn's - neighbor config ?
by Kai 08 Sep '14

08 Sep '14

G'day! For the configuration we want to set up, I couldn't find any details in the docs, the wiki or the list archive. So please allow me to ask my questions here (questions see below). desired setup: We want to establish a router ('A') announcing two different ASNs (as1,as2) to it's neighbours. In fact we want to setup three routers A, B and C, all of them corporately announcing as1 and as2. I'd guess the config on router A should include some lines like these: protocol bgp { local as <as1>; neighbor X as as9; (...) } protocol bgp { local as <as2>; neighbor X as as9; (...) } X being one of the neighbours and announcing as9. Question 1: Is this basically the correct approach? Question 2: What would be the correct config on router X (A's neighbour) in this setup? Would it look like: protocol bgp { local as <as9>; neighbor A as as1; (...) } protocol bgp { local as <as9>; neighbor A as as2; (...) } Question 3: Does anyone have a pointer to a text/tutorial/whatever that explains in detail what config is needed for this kind of setup? Best regards, Kai -- "Das ist Demokratie, wenn man sich aussuchen darf, wer einen verarscht." (Hagen Rether) D-65203 Wiesi fast: kai_pf (aT] web(dot)de ++ PGP Key fingerprint B567 C43E 99D1 7709 7D64 3BF8 2DE8 1092 0EEF D58E ++ -----BEGIN GEEK CODE BLOCK----- VERSION: 3.12 GCS/IT/CM d- s:- a+>-----(?) C++$ UL++(++++$) P+++ L++ E-(+) W--(+) N !w---($) !O !M V? PS+ PE-() Y+ PGP(+) t R*@ tv--@ b+>++ DI++ G e+++(*) h? y? ------END GEEK CODE BLOCK------

4 6

Bird keep routes from older bird process
by Antoine Habran 05 Sep '14

05 Sep '14

Hello, Sorry for my english, I hope you will understand me. I'm using "Bird" for his OSPF implementation and I have a technical question. I need to keep the routes learned from OSPF after any "Bird" stop or crashes. This can be done with the "persist" option into the kernel configuration block in the bird.conf file. But when I start "Bird" after a stop or a crash of the service, all routes was forgotten. It is possible to tell "Bird" to not erase kernel routes from older "Bird" process? Thanks in advance -- Antoine Habran https://doc.habran.eu

2 1

Re: bgp router with multi asn's - neighbor config ?
by Leo Vandewoestijne 04 Sep '14

04 Sep '14

On Thu, 04 Sep 2014, Ondrej Zajicek wrote: > > listen bgp address 10.0.1.102 port 179; > > listen bgp address 10.0.2.102 port 179; > > I don't think you should have two 'listen bgp' options. AFAIK there is > only one listening BGP socket in BIRD, but it is OK to have it listen on > 0.0.0.0 (default value). Incoming sessions are dispatched based on their > source addresses. > Oh yes, that's true. In fact in FreeBSD defining two addresses now breaks it; I'm not sure if that's because I started to use version 10, or if something changed in Bird. And so I stopped doing that around January 2014. Before that, in 9 with a current version of Bird, it worked fine. -- Leo

1 0

Multiple routing tables with multiple gateways
by Fernando Frediani 04 Sep '14

04 Sep '14

Hello there, I'm currently writing a project document which consists in a server to be hosted in a Internet Exchange Point, (similar to a route server but with another propose) and one of the things it must do is: When it receives a request coming from an IP range from ISP A it must go out to the internet using the ISP A gateway, when the request comes from ISP B IP range it goes out via that ISP router and so on. Any request originating on the server itself goes out via the Internet Exchange connectivity. I know this can be done using IProute2 and creating multiple routing tables, but I would rather automate it using BIRD, so the ISPs would establish a BGP session to the server, announce their IP range, but in a different way they do with a Route server as they would need also to announce default route, and BIRD would take care to inform the kernel for when the request comes from those IPs it needs to use the specific ISP gateway depending on the IP range. Would anyone be able to point me to the right direction in terms of BIRD BGP config in order to achieve that, specially with regards the main differences to a Route Server. Thanks Best regards, Fernando

2 3

Does radv protocol (re)scan interfaces on IPv6?
by Alex Bligh 04 Sep '14

04 Sep '14

I am trying to isolate an issue with the radv protocol running on IPv6 I have possibly the world's simplest radv configuration: protocol radv evrradv { interface "-evrr-000000", "evrr-*" { max ra interval 4; }; } The idea here is that the router provides radv information on all interfaces with names starting evrr- except evrr-000000. What I am seeing is that if I add another interface, radv does not appear to work. A reload produces: # birdc6 reload evrradv BIRD 1.3.4 ready. evrradv: reload failed This doesn't help A restart produces: # birdc6 restart evrradv BIRD 1.3.4 ready. evrradv: restarted This fixes things, and radv appears to work. I am quite sure this used to work with the same software a little while ago, but it may be that I'm going mad. Should radv pick up creation and deletion of new interfaces? Might this be something related to the ordering of applying the IP address and taking the interface up or something? How is this meant to work? This is an old version of bird (1.3.4), but initial tests indicate the same is happening on a relatively recent version (I'll attempt to reproduce this further). I don't really want to restart bird6's radv protocol every time I add an interface as this is quite frequent. -- Alex Bligh

2 3

Gateway on routed network problem (aka: Received route with strange next-hop)
by Alexander Demenshin 04 Sep '14

04 Sep '14

Hi, I've a static protocol which has routes like: route 10.0.0.0/24 via "uplink"; route 192.168.0.0/24 via 10.0.0.1; Obviously, this does not work in Bird, though this is perfectly valid and accepted by the Linux kernel (as long as "uplink" is up). When adding this route manually (ip route), I see in the log file messages like: KRT: Received route 192.168.0.0/24 with strange next-hop 10.0.0.1 I've found why this is so (from http://permalink.gmane.org/gmane.network.bird.user/2042) "BIRD generally assumes tha that gateway of routes is a direct neighbor according to IP addresses on interfaces, not according to routing tables." Well, now the question - *why* Bird assumes so and how to remove this assumption? In my situation, "uplink" is actually ethernet, not any kind of PtP interface, and I really want to avoid adding local IP which is in gateway's network (in some cases this is simply impossible due to tiny transfer networks and multiple gateways). Is there any easy fix for this? I feel that only few lines could be changed to allow this, but I don't know the code well (yet). Thank you! -- With best regards, Alexander.

2 2

BFD implementation in 1.4.0
by Aleksey Berezin 02 Sep '14

02 Sep '14

Hi there! Firstly, sorry for my French ;) Recently I tried to test BFD implementation in 1.4.0 BIRD release. Case is "OSPF ECMP with less-second failover". On one side - Extreme Networks switches, other side - several boxes with Debian and BIRD, of course. So, I find out several annoying things. First thing: BIRD BFD implementation uses non-RFC5881 source UDP port for outgoing packets. Here some tcpdump: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 20:34:21.355747 <BIRD_BOX_MAC> > <EXTREME_SW_MAC>, ethertype 802.1Q (0x8100), length 70: vlan <vlan>, p 0, ethertype IPv4, (tos 0xc0, ttl 255, id 20806, offset 0, flags [none], proto UDP (17), length 52) <BIRD_BOX_IP>.39156 > <EXTREME_SW_IP>.3784: BFDv1, length: 24 Control, State Init, Flags: [none], Diagnostic: No Diagnostic (0x00) Detection Timer Multiplier: 5 (5000 ms Detection time), BFD Length: 24 My Discriminator: 0x8a82eb8a, Your Discriminator: 0x00000002 Desired min Tx Interval: 1000 ms Required min Rx Interval: 10 ms Required min Echo Interval: 0 ms =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I saw many messages in switch logs: > <Warn:BFD.RxPktInv> Received BFD an invalid packet on VLAN <vlan> Error:Invalid UDP src port Number BFD session between BIRD and Extreme Networks switch can't be established. So, src port for outgoing BFD-packet from BIRD is 39156, when RFC5881 contains: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 4. Encapsulation BFD Control packets MUST be transmitted in UDP packets with destination port 3784, within an IPv4 or IPv6 packet. The source port MUST be in the range 49152 through 65535. =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ok, fixing (only for test purposes): =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= root@debian-1:~# sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 61000 root@debian-1:~# sysctl -w net.ipv4.ip_local_port_range="49152 65535" net.ipv4.ip_local_port_range = 49152 65535 root@debian-1:~# sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 49152 65535 =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= After this BFD session was estabilished. Of course, net.ipv4.ip_local_port_range tuning seems to be not usable in production environment, and need to be fixed in BIRD, I think. Just because some network hardware vendors interprets RFC's exactly as written ;) But now - second thing: 'protocol bfd' block in bird.conf useless. Here part of config: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= protocol bfd FOR_OSPF { interface <BIRD_BOX_IP>/32 { interval 50 ms; min rx interval 50 ms; # presence of this string by the docs does not matter min tx interval 50 ms; # presence of this string by the docs does not matter multiplier 3; }; neighbor <EXTREME_SW_IP> dev "<BIRD_BOX_IP>" local <BIRD_BOX_IP>; # presence of this string by the docs does not matter }; protocol ospf OSPF1 { ... area 0.0.0.0 { interface <BIRD_BOX_IP>/32 { ... bfd; }; }; ... }; =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= And what I see with tcpdump: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 13:09:05.433336 <BIRD_BOX_MAC> > <EXTREME_SW_MAC>, ethertype 802.1Q (0x8100), length 70: vlan <vlan>, p 0, ethertype IPv4, (tos 0xc0, ttl 255, id 6662, offset 0, flags [none], proto UDP (17), length 52) <BIRD_BOX_IP>.62698 > <EXTREME_SW_IP>.3784: BFDv1, length: 24 Control, State Up, Flags: [none], Diagnostic: No Diagnostic (0x00) Detection Timer Multiplier: 5 (500 ms Detection time), BFD Length: 24 My Discriminator: 0x35e75227, Your Discriminator: 0x00000007 Desired min Tx Interval: 100 ms Required min Rx Interval: 10 ms Required min Echo Interval: 0 ms =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= There is no any configured intervals and multiplier. Just default values. I think this is not correct. Maybe I misconfigure BIRD? Please advise. Thanks for attention.

4 13

export filter that checks for existance of another route?
by Paul J R 02 Sep '14

02 Sep '14

Hi All, First time post, i've been playing with bird for some time, but there is one thing i cant figure out how to do and that is use the existence of a specific route as part of a filter. for example, if the filter is processing a route to 4.3.2.0/24, check if a route to 1.2.3.4/32 (exact) exists, if so then accept, otherwise reject. Is this something that is possible? or do route filters only have the ability to check against the information thats sent to the filter itself? Thanks in advance, PJR.

3 3

Limit on kernel table number
by Alexander Demenshin 02 Sep '14

02 Sep '14

Hi, It seems that there is a limit on maximum kernel table number (in kernel protocol), in particular I couldn't use number 1000 while this is perfectly acceptable by the Linux kernel. Is there any specific reason for this limitation? Thank you! -- With best regards, Alexander.

3 3