- Bird-users - Mailing Lists

Doing something wrong with VRF's
by Nigel Kukard 28 Sep '23

28 Sep '23

Hi there, I'm wondering if someone could point out what I'm doing wrong here? all my routes are being added to the system main table and not my VRF. I could swear I had this working 100% (I took my config and added vrf "vrf0" to each protocol), i then regenerated my config file using my software, rebooted and its not worked since. I can't seem to find what I broke. Here is my interfaces... the t0p0 and t0p1 are ip6gretap's, dummy0 is just a loopback dummy interface. All are slave to vrf0. lgtm. 4: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether fe:dc:20:04:15:27 brd ff:ff:ff:ff:ff:ff 5: vrf0: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 8a:8e:21:3d:c4:c9 brd ff:ff:ff:ff:ff:ff 8: t0p0@e0p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1430 qdisc fq_codel master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether b2:da:ee:78:04:1f brd ff:ff:ff:ff:ff:ff 9: t0p1@e0p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1430 qdisc fq_codel master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether fa:61:19:72:65:d8 brd ff:ff:ff:ff:ff:ff the output from ip rule is this... lgtm. 1000: from all lookup [l3mdev-table] The routes within the VRF look like this, lgtm ... ip route show vrf vrf0 X/30 dev t0p0 proto kernel scope link src A Y/30 dev t0p1 proto kernel scope link src B Z/27 dev dummy0 proto kernel scope link src C My main routing table looks like this... lgtm, I don't even have the interfaces or anything configured for them in the main table outside the VRF. default via 169.254.1.1 dev e0p0 proto static metric 1000 169.254.1.1 dev e0p0 proto kernel scope link src D metric 256 E dev e0p0 proto kernel metric 256 pref medium F via fe80::1 dev e0p0 proto static metric 300 pref medium G via fe80::1 dev e0p0 proto static metric 300 pref medium fe80::/64 dev e0p0 proto kernel metric 256 pref medium default via fe80::1 dev e0p0 proto static metric 1000 pref medium My bird config is below ... I made sure to add vrf "vrf0" to all protocols. I searched the mailing list and I can't see what I did wrong here. OSPF comes up fine, I can ping inside the VRF fine, but all my routes are being added to the main system table. I cut out the filters, they're not doing anything interesting. Despite BGP being mentioned in the config below, I don't have it configured atm. # Kernel Table ipv4 table t_kernel4; ipv6 table t_kernel6; # Direct Tables: ipv4 table t_direct4; ipv6 table t_direct6; # OSPF Tables ipv4 table t_ospf4; ipv6 table t_ospf6; ... protocol kernel kernel4 { vrf "vrf0"; description "Kernel protocol for IPv4"; metric 600; # Set the BIRD metric to be used when creating kernel routes to fall in line with our OS learn; # Learn routes from the kernel persist; # Dont remove routes on BIRD shutdown merge paths on; # Merge similar BGP paths into a multi-hop ipv4 { table t_kernel4; export all; import all; }; }; protocol kernel kernel6 { vrf "vrf0"; description "Kernel protocol for IPv6"; metric 600; # Set the BIRD metric to be used when creating kernel routes to fall in line with our OS learn; # Learn routes from the kernel persist; # Dont remove routes on BIRD shutdown merge paths on; # Merge similar BGP paths into a multi-hop ipv6 { table t_kernel6; export all; import all; }; }; protocol pipe p_master4_to_kernel4 { vrf "vrf0"; description "Pipe from master4 to t_kernel4"; table master4; peer table t_kernel4; export filter f_master4_kernel4_export; import filter f_master4_kernel4_import; }; protocol pipe p_master6_to_kernel6 { vrf "vrf0"; description "Pipe from master6 to t_kernel6"; table master6; peer table t_kernel6; export filter f_master6_kernel6_export; import filter f_master6_kernel6_import; }; protocol device { vrf "vrf0"; description "Device protocol"; scan time 10; }; protocol direct direct4 { vrf "vrf0"; description "Direct protocol for IPv4"; ipv4 { table t_direct4; export none; import all; }; }; protocol direct direct6 { vrf "vrf0"; description "Direct protocol for IPv6"; ipv6 { table t_direct6; export none; import all; }; }; protocol pipe p_master4_to_direct4 { vrf "vrf0"; description "Pipe from master4 to t_direct4"; table master4; peer table t_direct4; export none; import all; }; protocol pipe p_master6_to_direct6 { vrf "vrf0"; description "Pipe from master6 to t_direct6"; table master6; peer table t_direct6; export none; import all; }; protocol ospf v2 ospf4 { vrf "vrf0"; description "OSPF protocol for IPv4"; ipv4 { table t_ospf4; export filter f_ospf_export; import filter f_ospf_import; }; area 0 { interface "dummy0" { cost 10; ecmp weight 1; stub; }; interface "t0p0" { cost 1000; ecmp weight 1; }; interface "t0p1" { cost 1000; ecmp weight 1; }; }; }; protocol ospf v3 ospf6 { vrf "vrf0"; description "OSPF protocol for IPv6"; ipv6 { table t_ospf6; export filter f_ospf_export; import filter f_ospf_import; }; area 0 { interface "dummy0" { cost 10; ecmp weight 1; stub; }; interface "t0p0" { cost 1000; ecmp weight 1; }; interface "t0p1" { cost 1000; ecmp weight 1; }; }; }; protocol pipe p_ospf4_to_master4 { vrf "vrf0"; description "Pipe from t_ospf4 to master4"; table t_ospf4; peer table master4; export filter f_ospf_master_export; import filter f_ospf_master_import; }; protocol pipe p_ospf6_to_master6 { vrf "vrf0"; description "Pipe from t_ospf6 to master6"; table t_ospf6; peer table master6; export filter f_ospf_master_export; import filter f_ospf_master_import; }; Kind Regards Nigel

3 4

A funny story with limited benefit that someone else may learn from someday...
by Jake 22 Sep '23

22 Sep '23

For 20 years in the industry, I’ve misunderstood an element of BGP. My understanding was that “multihop” was used any time you might receive a route from a thing, but be given destinations for other things. In some cases, that mean routers multiple hops away, yes. But in my incorrect understanding, it also meant route-servers at Internet Exchanges (which are considered directly connected. So for all of my time at this job and last, I set nearly everything in Quagga/zebra/BIRD to multihop…and it worked. But…recently something in Linux changed, it seems…where the algorithm used to recursively try to solve routes when “multihop” was used now completely ignores directly-connected interfaces, maybe...? So…when BIRD did it’s reconfig…all of a sudden it was unable to resolve the route lookups for anything labeled “multihop”. This resulted in every route received over a multihop BGP session with a route-server at an IXP being marked "!", unreachable, reject. Thus, removing the line “multihop” from all of our route-server peers fixed the issue, routes were again received and added to the kernel properly, and life went on. Maybe nobody else out there has the same misunderstanding I did, and nobody will ever experience this again...but if posting here in my embarrassment helps one of you down the line, I suppose it was all worth it. -jake

1 0

Path Attribute Attack
by Michael Lambert 18 Sep '23

18 Sep '23

As outlined in https://kb.cert.org/vuls/id/347067, there is an attack that uses specially crafted Path Attributes in a BGP UPDATE message to disrupt peering sessions. I don’t recall seeing any discussions of this attack on this list. Is BIRD susceptible? Thanks, Michael

4 3

BGP best path algorithm in RR environment
by Mazur, Dariusz 14 Sep '23

14 Sep '23

Hello Bird Users, Have a question about bgp best path algorithm in Route Refletector environment and possible fix: Topology ( we use only iBGP with multiply RR): r01a.tor ----- r01.leaf.105---r01.spine----r01.leaf108-----r09a.tor I announce the same block 172.232.0.0/19 from both tors r01.leaf108 receives 172.232.0.0/19 from r01.spine and r09a.tor, and treat them as equal path (multipath). All BGP attributes are equal except of BGP originator id and cluster-list r01.leaf108.ord02.fab> show route for 172.232.0.0/19 all 172.232.0.0/19 unicast [192.168.226.56__r01.spine101 2023-09-06] * (100) [AS4250527481?] via 192.168.226.56 on vlan.101 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 4250527481 BGP.next_hop: 192.168.226.56 BGP.med: 0 BGP.local_pref: 400 BGP.atomic_aggr: BGP.aggregator: 23.192.121.225 AS4250527481 BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107) BGP.originator_id: 23.205.212.134 BGP.cluster_list: 23.205.212.8 23.205.212.112 unicast [192.168.198.35__r09b.tor108 2023-09-06] (100) [AS4250827489?] via 192.168.198.35 on vlan.218 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 4250827489 BGP.next_hop: 192.168.198.35 BGP.med: 0 BGP.local_pref: 400 BGP.atomic_aggr: BGP.aggregator: 23.213.15.233 AS4250827489 BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107) Looks like Bird does not check cluster_list length to determine better route, is it intentional? Can you suggest any possible fix to prefer route from r09a.tor using cluster-list or anything what is local for router (local pref is not option because all routers are in the same asn and use iBGP) Thanks, Dariusz

3 5

reset rx_limit/in_limit when routing table rt_count becomes less than these limits
by Bala Sajja 31 Aug '23

31 Aug '23

Hi, Currently I see channel rx_limit/in_limit are reset during protocol reconfiguration or reload. Is it possible to call channel_reset_limit while withdrawing routes, when table route count becomes less than configured rx_limit/in_limit ? Regards, Bala.

1 1

BGP: connect delay timer vs connect retry timer
by Bala Sajja 29 Aug '23

29 Aug '23

Hi, It seems where BGP connect retry timer to be kicked in use cases also, connect delay timer gets kicked in. In the below function, though bgp_setup_conn(p, conn) sets connect_timer to connect retry timer, later it's over written by bgp_start_timer(conn->connect_timer, delay) which sets connect_timer to connect delay timer. Is this right ? Could we make the connect retry timer work properly ? bgp_active(struct bgp_proto *p) { int delay = MAX(1, p->cf->connect_delay_time); struct bgp_conn *conn = &p->outgoing_conn; BGP_TRACE(D_EVENTS, "Connect delayed by %d seconds", delay); bgp_setup_conn(p, conn); bgp_conn_set_state(conn, BS_ACTIVE); bgp_start_timer(conn->connect_timer, delay); } Regards, Bala.

2 3

Bird is bringing down bgp connection upon receiving Admin Down
by Sunnat Samadov 29 Aug '23

29 Aug '23

Hi birds, This is the detailed explanation of the previously raised issue. We are using BIRD https://gitlab.nic.cz/labs/bird/-/tags/v2.0.11. And there is an issue with respect to BFD + BGP as described below. When Peer device ( Cisco ASR router) sends an BFD admin down, Bird is bringing down the BGP connection which is using BFD mode ON, which is not correct. The expected behavior is upon receiving BFD admin down from peer device, Bird should fall back to the Normal BGP mode of working. As per the comment mentioned on Bird forum, We could see the same (expected behavior) is to be claimed as ways of working for Bird: That is expected. Only a BFD transition from Up to Down is supposed to shutdown the BGP or OSPF session, while general unavailability of BFD (or permanent AdminDown state) on the neighbor is not an obstacle for BGP or OSPF. See RFC 5882 for details. BFD implementation in 1.4.0 (narkive.com)<https://bird-users.network.narkive.com/3REbA0Wz/bfd-implementation-in-1-4-0…> Steps: 1. Setup Bird config as (single hop / directly connected to router): [protocol device { } protocol bgp { local 10.0.10.22 as 64512; neighbor 10.0.10.6 as 65001; hold time 3; graceful restart off; setkey off; ipv4 { import all; export filter { if proto = "static1" then reject; accept; }; }; bfd on; } protocol bfd { interface "eth0" { min rx interval 100 ms; min tx interval 100 ms; idle tx interval 300 ms; multiplier 3; }; neighbor 10.0.10.6; neighbor 10.0.10.8; neighbor 10.0.10.10; }] 1. Make sure BGP and BFD session are up between bird and DCGW/router. 2. From router bring down the BFD session alone. 3. On Bird end we observe BGP session was brought down upon receiving BFD admin down. Which is not expected behaviour as per RFC. As per rfc5882#section-3.2<https://datatracker.ietf.org/doc/html/rfc5882#section-3.2> Therefore, a system SHOULD NOT indicate a connectivity failure to a client if either the local session state or the remote session state (if known) transitions to AdminDown, so long as that client has independent means of liveness detection (typically, control protocols). Attached PCAP : 128.0.0.3 is the router IP address and 128.0.0.53 is the Bird IP. Br, Sunnat Samadov

2 3

Pending bird patches and discussions for proto/babel
by Daniel Gröber 28 Aug '23

28 Aug '23

Hello birds, I just thought I'd put together an overview of as yet unresolved proto/babel patches and discussions to stimulate some activity :) Toke's RTT series: - lib/timer: Add current_time_now() function for immediate timestamp - babel: Add support for the RTT extension - babel: Add route metric smoothing My route selection revamp: - [v5] Babel: Replace internal route selection by bird's nest - [DRAFT] Babel: Implement route daming with fixed delay (s/daming/damping/) Toke's first two patches are ready for merging, but the third (metric smoothing) is contested since it conflicts with my route selection patch in its current form and if adapted it conflicts with my scalability goals for babel instead. Possibly premature optimization admittedly ;) Initially Toke was playing with the idea of exposing the smoothed metric to route filters in a followup patch. Me and Juliusz oppose this, for different reasons and the consensus is to not do that. My stance is that we could choose to merge smoothing as long as we don't expose it's implementation internals (the smoothed metric) to users. This way we can replace it with a more performant approach later. That being said since RTT metric is a new feature anyway I would prefer we just go with my route damping approach, mark RTT as experimental and get some more wider testing through a released version. Lastly my v5 route selection patch should also be ready, all threads of discussion should be resolved and there are no known bugs. However I've not received any testing reports, hint, hint peeps °>° --Daniel

4 8

hardware preference
by Ömür Yavuz 25 Aug '23

25 Aug '23

Hello community, I don't know if there is any obstacle for me to ask this kind of question. Everything is fine in terms of software, but can I get a hardware suggestion that millions of packages will pass through live with the servant? Do you have experience with an intel cpu and chelsio t4 nic or intel x5xx series? Which enterprise level devices can I use as hardware? ____________________________________________ Ömür Yavuz

4 3

[PATCH] adding custom options in radv protocol, strict ipv6 regex
by Alexander Zubkov 25 Aug '23

25 Aug '23

Hi, Currently one can use only a predefined set of advertised options in radv protocol, that are supported by bird's configuration. It would be convenient to be able to specify other possible options at least manually as a blob so one should not wait until it is supported in the code, released, etc. This idea is inspired by presentation by Ondřej Caletka at CSNOG, in which he noticed the lack of either PREF64 option or possibility to add custom options in various software. Attached patch [radv-custom.patch] makes it possible to define such options with the syntax: other type <num> <bytestring> I can also prepare a patch for documentation if it is to be merged. But it does solve the question with PREF64 completely. Because currently bytestring minimal length is 16 bytes, but for PREF64 we need to provide a 14-byte blob. And for minimal RA option, it have to be as short as 6 bytes. So another patch [bytestring-short.patch] allows bytestrings to be as short as 6 bytes, when colon-notation is used: "01:02:03:04:05:06". And I kept the minimum size of 16 bytes without colons, because it can conflict with some symbol names. The main concern is that a 6-byte bytestring conflicts with the MAC address representation. Bird does not have the type for it currently, but who knows, it might need it in the future. So we might need some new syntax for bytestring in that case. Or it can be postponed to later time. In this case introduction of MAC-address lexems would break configs that use 6-byte bytestrings (if we want to care much about those). It is also not possible to define a 8-byte bytestring, because it conflicts with IPv6 address, but we are introducing short bytestrings for RA here, and 8-byte bytestrings are not strictly required for that, because possible option sizes are 8, 16, ... with payloads 2 bytes less: 6, 14, ... So if one needs a 8-byte payload, he can easily pad it with extra zeroes ":00" with the same on-the-wire result. But still, this gives one more reason for an additional syntax for bytestrings. There also was possbility to explicitly allow only 6, 7, 9 and greater lengths of bytestrings. Or to move IPv6 regex definition before bytestring definition to make it more preferrable. I choose the second variant, but IPv6 regex is too loose now and match many things far from IPv6 notation. So I decided to provide a more strict regex definition for IPv6 addresses. Of course it is ugly, but I think it could be helpful anyway, because it does not conflict with other similar lexems, including MAC addresses. As a downside for this, in case of some typo in IPv6 address, there will not be a meaningful error about bad IPv6 address. So I added an additional regex there, to catch lexems with hex digits and at least 2 colons to show more meaningful error for that. But I'm not sure about it. If those changes for bytestrings are OK too, I also can prepare further patch for documentation. Have a nice day, Alexander Zubkov

4 44