Any ideas on the below? Alex On 8 Aug 2014, at 20:05, Alex Bligh <alex@alex.org.uk> wrote:
When I start bird using 1.4.0-1 (Ubuntu Trusty) I see the error:
warnings.log:Aug 8 13:47:03 node-10-157-128-41 bird: /etc/bird/bird.conf, line 62: Multihop BGP cannot use direct gateway mode
This error did not occur on 1.3.4-1 with the same config on Ubuntu Precise.
The config I am using is pasted below, as is the output of 'ip addr show'.
Line 62 of the config is the closing bracket of a BGP protocol definition. The neighbour statement is on line 29: neighbor 10.157.192.1 as 65000
You will note that interface evrr-000000 has IP address 10.157.192.41/20, and the peer is IP address 10.157.192.1. This should thus not be a multihop session. The output of 'ip route show' (also below) confirms this.
It is an iBGP session (in that both ends have the same address) but I am deliberately hoping to use gateway direct, i.e. want to put the advertised next hop straight into the RIB without doing a recursive lookup. Specifically if something else on the same /20 gets advertised as a next hop, I still want to send the traffic to the advertising router.
The documentation says:
For received routes, their gw (immediate next hop) attribute is computed from received bgp_next_hopattribute. This option specifies how it is computed. Direct mode means that the IP address frombgp_next_hop is used if it is directly reachable, otherwise the neighbor IP address is used. Recursive mode means that the gateway is computed by an IGP routing table lookup for the IP address from bgp_next_hop. Recursive mode is the behavior specified by the BGP standard. Direct mode is simpler, does not require any routes in a routing table, and was used in older versions of BIRD, but does not handle well nontrivial iBGP setups and multihop. Recursive mode is incompatible with sorted tables. Default: direct for direct sessions, recursive for multihop sessions.
From this, gateway direct should be the default for a direct session in any case. It would appear to me that bird is somehow misidentifying the session as a multihop session.
Removing 'gateway direct' fixes the error (but obviously not the behaviour).
This is running in an network container if that's of any interest.
Any ideas?
(apologies for a potential dupe - I sent this to what I think must have been an old list email address)
-- Alex Bligh
root@node-10-157-128-41:/# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: dummy2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 5a:17:eb:e4:7b:10 brd ff:ff:ff:ff:ff:ff inet6 fe80::5817:ebff:fee4:7b10/64 scope link valid_lft forever preferred_lft forever 3: dummy: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 12:7f:06:13:e8:91 brd ff:ff:ff:ff:ff:ff inet 10.99.99.1/24 scope global dummy valid_lft forever preferred_lft forever inet6 fe80::107f:6ff:fe13:e891/64 scope link valid_lft forever preferred_lft forever 12: evrr-000000: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether ee:19:d3:6f:24:1b brd ff:ff:ff:ff:ff:ff inet 10.157.192.41/20 scope global evrr-000000 valid_lft forever preferred_lft forever inet6 fc00:41c8:10:1dd::29/64 scope global valid_lft forever preferred_lft forever inet6 fe80::ec19:d3ff:fe6f:241b/64 scope link valid_lft forever preferred_lft forever
root@node-10-157-128-41:/# ip route show 10.99.99.0/24 dev dummy proto kernel scope link src 10.99.99.1 10.157.192.0/20 dev evrr-000000 proto kernel scope link src 10.157.192.41
1 # Configure logging 2 log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; 3 log stderr all; 4 5 router id 10.157.192.41; 6 7 # Import kernel routes. These come in with RTS_INHERIT 8 protocol kernel evrkernel { 9 persist; # Don't remove routes on bird shutdown 10 scan time 10; # Scan kernel routing table every 20 seconds 11 import all; 12 export all; 13 learn; # Learn all alien routes from the kernel 14 } 15 16 # This pseudo-protocol watches all interface up/down events. 17 protocol device { 18 scan time 10; # Scan interfaces every 10 seconds 19 } 20 21 # Import all directly connected routes. These come in with RTS_DEVICE 22 protocol direct evrdirect { 23 interface "-evrr-000000", "evrr-*"; 24 export all; 25 } 26 27 protocol bgp evrbgp1 { 28 local as 65000; 29 neighbor 10.157.192.1 as 65000; 30 31 gateway direct; 32 export filter { 33 # RTS_INHERIT means routers from the kernel 34 if net = 10.157.192.0/20 then reject; 35 if net = 0.0.0.0/8 then reject; 36 if (source = RTS_INHERIT) || (source = RTS_DEVICE) then { 37 # Add no-export 38 bgp_community.add((65535, 65281)); 39 # Add no-advertise 40 bgp_community.add((65535, 65282)); 41 42 bgp_local_pref = 100; 43 44 accept; 45 } 46 reject; 47 }; 48 import filter { 49 if net = 0.0.0.0/0 then accept; 50 reject; 51 }; 52 next hop self; 53 54 # timers 55 hold time 12; 56 startup hold time 12; 57 keepalive time 4; 58 connect retry time 6; 59 start delay time 1; 60 error wait time 2, 16; 61 error forget time 16; 62 } 63 64 protocol bgp evrbgp2 { 65 local as 65000; 66 neighbor 10.157.192.2 as 65000; 67 68 gateway direct; 69 export filter { 70 # RTS_INHERIT means routers from the kernel 71 if net = 10.157.192.0/20 then reject; 72 if net = 0.0.0.0/8 then reject; 73 if (source = RTS_INHERIT) || (source = RTS_DEVICE) then { 74 # Add no-export 75 bgp_community.add((65535, 65281)); 76 # Add no-advertise 77 bgp_community.add((65535, 65282)); 78 79 bgp_local_pref = 100; 80 81 accept; 82 } 83 reject; 84 }; 85 import filter { 86 if net = 0.0.0.0/0 then accept; 87 reject; 88 }; 89 next hop self; 90 91 # timers 92 hold time 12; 93 startup hold time 12; 94 keepalive time 4; 95 connect retry time 6; 96 start delay time 1; 97 error wait time 2, 16; 98 error forget time 16; 99 } 100
-- Alex Bligh