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
--On 17 August 2011 18:38:09 +0100 Alex Bligh <alex@alex.org.uk> wrote:
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?
2 further bits of information: 1. bird version 1.3.2-1 (Ubuntu Oneiric) 2. gateway-direct fixes this, but I don't understand why. If a direct lookup succeeds, then surely a recursive lookup must always succeed? -- Alex Bligh
W dniu 2011-08-17 19:45, Alex Bligh pisze:
--On 17 August 2011 18:38:09 +0100 Alex Bligh <alex@alex.org.uk> wrote:
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?
2 further bits of information:
1. bird version 1.3.2-1 (Ubuntu Oneiric)
2. gateway-direct fixes this, but I don't understand why. If a direct lookup succeeds, then surely a recursive lookup must always succeed?
That changed in bird 1.3.0 iirc - add 'gateway direct' to your BGP configuration in bird (it is set to recursive by default in iBGP, and for some reason, it is not working in trivial iBGP setups, always marking routes as unreachable :)). Regards -- Adrian
Adrian, --On 17 August 2011 19:47:59 +0200 Adrian Czapek <adrian.czapek@rybnet.pl> wrote:
That changed in bird 1.3.0 iirc - add 'gateway direct' to your BGP configuration in bird (it is set to recursive by default in iBGP, and for some reason, it is not working in trivial iBGP setups, always marking routes as unreachable :)).
Ah OK thanks. I can add it (and have) but I couldn't work out how bird was failing to find the nexthop in the FIB in a recursive lookup but not a direct lookup (i.e. what the "some reason" is). You would have thought the first case in a recursive lookup would be to try the direct case! -- Alex Bligh
On Wed, Aug 17, 2011 at 06:45:24PM +0100, Alex Bligh wrote:
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).
Yes, that is exactly the reason.
How are such interface routes meant to get into the FIB?
Short answer is to use 'direct' protocol to populate BIRD routing table by device routes. See the discussion in FAQ (in 'IBGP does not work after upgrade to BIRD 1.3'): https://git.nic.cz/redmine/projects/bird/wiki/FAQ
2 further bits of information:
1. bird version 1.3.2-1 (Ubuntu Oneiric)
2. gateway-direct fixes this, but I don't understand why. If a direct lookup succeeds, then surely a recursive lookup must always succeed?
No, these are two different mechanisms: - recursive lookup tracks BIRD routing table. - direct lookup just examines interface address ranges. And there are more minor differences (like recursive mode uses just the NEXT_HOP address, while direct mode fallbacks to BGP peer address if address from NEXT_HOP is not a neighbor) -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
--On 17 August 2011 20:27:05 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
How are such interface routes meant to get into the FIB?
Short answer is to use 'direct' protocol to populate BIRD routing table by device routes.
Perfect, thanks. It might be worth noting for your docs that if you are writing a filter, these come in as RTS_DIRECT (obvious), but kernel routes come in as RTS_INHERIT (not obvious that 'INHERIT' means 'KERNEL', an RTS_KERNEL synonym would be nice). -- Alex Bligh
On Wed, Aug 17, 2011 at 07:53:34PM +0100, Alex Bligh wrote:
--On 17 August 2011 20:27:05 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
How are such interface routes meant to get into the FIB?
Short answer is to use 'direct' protocol to populate BIRD routing table by device routes.
Perfect, thanks.
It might be worth noting for your docs that if you are writing a filter, these come in as RTS_DIRECT (obvious), but kernel routes come in as RTS_INHERIT (not obvious that 'INHERIT' means 'KERNEL', an RTS_KERNEL synonym would be nice).
You are right, this is cryptic. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
participants (3)
-
Adrian Czapek -
Alex Bligh -
Ondrej Zajicek