route server appears to be selecting preferred routes and not all routes
We are running bird as a route server to support a small IX. The challenge we are having is that it appears that bird is selecting a preferred route from what is advertised to the route servers and then advertising back out only the preferred route to all members, instead of advertising all routes received for a given network. Included below are relevant configuration snippets, logs, and some show commands. How do I configure bird to keep the routes learned from all peers and advertise those back out to the members and not select a preferred route? In the following example, the following prefix is just one example. It is true for all prefixes learned from as11537. At some point, bird appears to select a preferred route and then only advertise that to as3701. The goal is to have bird advertise 128.164.0.0/16 via 198.32.165.125 and 198.32.165.126 to all IXP members.
From bird:
,---- | # birdc | BIRD 1.6.2 ready. | bird> show route 128.164.0.0/16 | 128.164.0.0/16 via 198.32.165.126 on eth0 [11537:1:Internet2-RE-PORT 16:06:17] * (100) [AS11039i] | via 198.32.165.125 on eth0 [11537:1:Internet2-RE-SUNN 15:31:43] (100) [AS11039i] | bird> show route 128.164.0.0/16 export '3701:1:NERO' | 128.164.0.0/16 via 198.32.165.126 on eth0 [11537:1:Internet2-RE-PORT 16:06:17] * (100) [AS11039i] `---- On the other side of the peering with 3701, this is the only route it sees from the route server: ,---- | # show bgp ipv4 uni 128.164.0.0/16 | Path #3: Received by speaker 0 | Not advertised to any peer | 11537 4901 11039 | 198.32.165.126 from 198.32.165.67 (198.32.165.67) | Origin IGP, metric 10, localpref 1090, valid, external | Received Path ID 0, Local Path ID 0, version 0 | Community: 3701:391 | Origin-AS validity: not-found `---- The following are logs from when peering was reestablished with both as11537 peers. It shows bird choosing 198.32.165.125 as the best path to 128.164.0.0/16. After the peering to 198.32.165.126 is established, bird then chooses it as the preferred path to 128.164.0.0/16. ,---- | 2018-08-17 15:31:42 <TRACE> 11537:1:Internet2-RE-SUNN > added [best] 128.164.0.0/16 via 198.32.165.125 on eth0 | 2018-08-17 15:31:42 <TRACE> 11537:1:Internet2-RE-SUNN < rejected by protocol 128.164.0.0/16 via 198.32.165.125 on eth0 | 2018-08-17 15:31:45 <TRACE> 11537:1:Internet2-RE-PORT < added 128.164.0.0/16 via 198.32.165.125 on eth0 | 2018-08-17 15:31:49 <TRACE> 11537:1:Internet2-RE-PORT > added [best] 128.164.0.0/16 via 198.32.165.126 on eth0 | 2018-08-17 15:31:49 <TRACE> 11537:1:Internet2-RE-SUNN < added 128.164.0.0/16 via 198.32.165.126 on eth0 | 2018-08-17 15:31:49 <TRACE> 11537:1:Internet2-RE-PORT < rejected by protocol 128.164.0.0/16 via 198.32.165.126 on eth0 | 2018-08-17 15:32:05 <TRACE> 3701:1:NERO < added 128.164.0.0/16 via 198.32.165.126 on eth0 `---- Configuration is below. #+BEGIN log "/var/log/bird.log" all; log syslog all; debug protocols { states, routes, filters, interfaces, events }; router id 198.32.165.67; define myasn = 4600; protocol device {}; # This function excludes martians and other odd networks function avoid_martians() prefix set martians; { martians = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 0.0.0.0/32- ]; if net ~ martians then return false; return true; } # BGP peers configuration table master sorted; protocol bgp '3701:1:NERO' { description "NERO, peer 198.32.165.70"; neighbor 198.32.165.70 as 3701; local as 4600; rs client; passive on; add paths tx; secondary; interpret communities off; export all; import keep filtered; import limit 500000 action restart; import filter { if ! ( avoid_martians() ) then reject "prefix is a bogon - REJECTING ", net; # route servers peering with route servers is bad. if ( bgp_path.first != 3701 ) then reject "invalid left-most ASN [", bgp_path.first, "] - REJECTING ", net; # skip if last asn in path not affiliated with peer if ! ( bgp_path.last ~ [ 3701, 4201, 3582, 46159, 10876, 6366, 6377, 62474, 394271, 394826 ] ) then reject "origin ASN [", bgp_path.last, "] not in allowed asnlist - REJECTING ", net; # skip if network not associated with peer asn if ! ( net ~ [ 64.112.160.0/20, 128.193.0.0/16, 128.223.0.0/16, 131.252.0.0/16, 140.211.0.0/16, 157.246.0.0/16, 158.165.0.0/16, 163.41.0.0/16, 163.41.128.0/17, 184.171.0.0/17, 192.68.202.0/24, 192.135.183.0/24, 198.98.8.0/22, 198.98.12.0/24, 198.237.0.0/20, 198.237.32.0/20, 198.237.64.0/19, 198.237.96.0/20, 198.237.120.0/21, 198.237.128.0/20, 199.79.32.0/20, 199.165.177.0/24, 199.201.139.0/24, 204.27.190.0/24, 204.87.204.0/24, 205.167.76.0/23, 207.98.0.0/18, 207.98.64.0/18, 207.98.72.0/21 ] ) then reject "prefix not in configured client prefix list - REJECTING ", net; # add the following communities bgp_community.add((4600,537)); bgp_community.add((4600,4600)); # accept what is left accept; }; } protocol bgp '11537:1:Internet2-RE-PORT' { description "Internet2-RE-PORT, peer 198.32.165.126"; neighbor 198.32.165.126 as 11537; local as 4600; rs client; passive on; add paths tx; secondary; interpret communities off; export filter { if ( bgp_community ~ [ (4600,54101) ] ) then bgp_community.add((11537,140)); accept; }; import keep filtered; import limit 500000 action restart; import filter { if ! ( avoid_martians() ) then reject "prefix is a bogon - REJECTING ", net; # route servers peering with route servers is bad. if ( bgp_path.first != 11537 ) then reject "invalid left-most ASN [", bgp_path.first, "] - REJECTING ", net; # accept all asn from peer # accept all networks from peer # add the following communities bgp_community.add((4600,537)); bgp_community.add((4600,503)); # accept what is left accept; }; } protocol bgp '11537:1:Internet2-RE-SUNN' { description "Internet2-RE-SUNN, peer 198.32.165.125"; neighbor 198.32.165.125 as 11537; local as 4600; rs client; passive on; add paths tx; secondary; interpret communities off; export filter { if ( bgp_community ~ [ (4600,50301) ] ) then bgp_community.add((11537,140)); accept; }; import keep filtered; import limit 500000 action restart; import filter { if ! ( avoid_martians() ) then reject "prefix is a bogon - REJECTING ", net; # route servers peering with route servers is bad. if ( bgp_path.first != 11537 ) then reject "invalid left-most ASN [", bgp_path.first, "] - REJECTING ", net; # accept all asn from peer # accept all networks from peer # add the following communities bgp_community.add((4600,537)); bgp_community.add((4600,541)); # accept what is left accept; }; } #+END Thanks, -- Stephen Fromm Network for Education and Research in Oregon
Hi Stephen, 21 août 2018 00:17 "Stephen Fromm" <stephenf@nero.net> a écrit:
We are running bird as a route server to support a small IX. The challenge we are having is that it appears that bird is selecting a preferred route from what is advertised to the route servers and then advertising back out only the preferred route to all members, instead of advertising all routes received for a given network. Included below are relevant configuration snippets, logs, and some show commands.
How do I configure bird to keep the routes learned from all peers and advertise those back out to the members and not select a preferred route?
It’s a normal behaviour, only the preferred route is announced to other peers. We have the same here: bird> show route 192.175.48.0/24 192.175.48.0/24 via 185.1.89.16 on eth2 [bgp_as112 2018-08-18] * (100) [AS112i] via 185.1.89.12 on eth2 [bgp_quantic 2018-08-18] (100) [AS112i] via 185.1.89.13 on eth2 [bgp_grifon_budic 2018-08-18] (100) [AS112i] bird> show route export bgp_izzycom where net ~ [ 192.175.48.0/24 ] 192.175.48.0/24 via 185.1.89.16 on eth2 [bgp_as112 2018-08-18] * (100) [AS112i] I just displayed one route in my example, but it’s the same for the others. -- Alarig
Hello, that's expected behavior of BGP. There's extension to BGP described in RFC 7911 allowing multiple paths to be advertised to eBGP peers, in Bird you can try "add paths" configuration option (but this also requires capabality support on other side). With regards, Daniel On 8/21/18 12:05 PM, alarig@swordarmor.fr wrote:
Hi Stephen,
21 août 2018 00:17 "Stephen Fromm" <stephenf@nero.net> a écrit:
We are running bird as a route server to support a small IX. The challenge we are having is that it appears that bird is selecting a preferred route from what is advertised to the route servers and then advertising back out only the preferred route to all members, instead of advertising all routes received for a given network. Included below are relevant configuration snippets, logs, and some show commands.
How do I configure bird to keep the routes learned from all peers and advertise those back out to the members and not select a preferred route?
It’s a normal behaviour, only the preferred route is announced to other peers.
We have the same here: bird> show route 192.175.48.0/24 192.175.48.0/24 via 185.1.89.16 on eth2 [bgp_as112 2018-08-18] * (100) [AS112i] via 185.1.89.12 on eth2 [bgp_quantic 2018-08-18] (100) [AS112i] via 185.1.89.13 on eth2 [bgp_grifon_budic 2018-08-18] (100) [AS112i] bird> show route export bgp_izzycom where net ~ [ 192.175.48.0/24 ] 192.175.48.0/24 via 185.1.89.16 on eth2 [bgp_as112 2018-08-18] * (100) [AS112i]
I just displayed one route in my example, but it’s the same for the others.
On Mon, Aug 20, 2018 at 02:59:55PM -0700, Stephen Fromm wrote:
We are running bird as a route server to support a small IX. The challenge we are having is that it appears that bird is selecting a preferred route from what is advertised to the route servers and then advertising back out only the preferred route to all members, instead of advertising all routes received for a given network. Included below are relevant configuration snippets, logs, and some show commands.
How do I configure bird to keep the routes learned from all peers and advertise those back out to the members and not select a preferred route?
Hi As others already wrote, this is the standard BGP behavior. But you have enabled 'add paths tx', so if the peer also has ADD PATH support, it should work - you should check 'show protocols all' to see received capabilities and established mode of BGP session. Also note that you have bot 'secondary' and 'add path tx' options - these options enables different ways how to solve the issue, so you should enable either one. It is possible that enabling both does not work properly. -- 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 (4)
-
alarig＠swordarmor.fr -
Daniel Suchy -
Ondrej Zajicek -
Stephen Fromm