- Bird-users - Mailing Lists

Different export route target for different prefixes of a same VRF
by Ramanathan Selvamani 22 Jun '23

22 Jun '23

Hi Team, I configured l3vpn in BIRD and I was able to see the routes are learnt and advertised based on RT. All the routes in this VRF are advertised with RT (1:11) to neighbors. I have a use case in which I want to apply different RT for different routes belonging to the same VRF. For example, I have the following prefixes in this VRF "vrf2". 101.1.1.0/24 103.1.1.0/24 105.1.1.0/24 I would like to add different "export route target" as below for routes belong to same VRF 101.1.1.0/24 : export RT 1:11 103.1.1.0/24 : export RT 1:20 105.1.1.0/24 : export RT 1:30 Please let me know if there is any way to achieve this with BIRD configuration. protocol l3vpn l3vpn2 { vrf "vrf2"; ipv4 { table vrf2v4; }; ipv6 { table vrf2v6; }; vpn4 { table vpntab4; }; vpn6 { table vpntab6; }; mpls { label policy aggregate; label range vrfrange; }; rd 1:11; import target [(rt, 1, 11)]; export target [(rt, 1, 11)]; } Thanks, Ramanathan

2 2

Best practice Route Reflector
by Oliver Seufer 20 Jun '23

20 Jun '23

Hello, I would like to gather some thoughts on whether I should use a Route Reflector or not, and if I do need one, what would be the best practice. Let's begin with the setup. I have four BGP routers located in two different data centers: * Each router (r1, r2, r3, r4) has an iBGP session established with the other BGP routers. * Two routers (r1 and r2) receive a full table from transit providers. * The other two routers (r3 and r4) receive the best routes (full table) from r1 and r2. * Additionally, r3 and r4 have peering connections with external parties and provide a default route via iBGP to other systems. Schematic representation of the setup data center 1 data center 2 r1 ------------------ r2 \ / ------------------ / \ r3 r4 Under normal conditions, I do not require a Route Reflector in this setup. However, there are situations where r3 can still reach r1 but not r2 and r4. Additionally, r1 can still reach r2. In this specific situation, r3 only receives the best route from r1 and not the learned routes from r2. I am aware that I can use a Route Reflector to address this issue, but I am not entirely certain if it is a suitable solution for my setup. Currently, my plan is to use r1 and r2 as the Route Reflector Cluster (with next hop self), while r3 and r4 would connect as non-Route Reflector clients to r1 and r2. So, the requirement is for r3 and r4 to always receive a full table. Regarding the approach, using a Route Reflector seems like a reasonable solution in this case. However, there might be alternative and potentially better solutions available. Thanks, Oliver

3 2

peering between route reflectors
by Benoit Chesneau 19 Jun '23

19 Jun '23

For redundancy I am thinking to have a router reflector per pop . Each route reflector would peer with each others. The issue is that since each POP has a transit, i have duplicate route and sometimes a loop is created. How can it be prevented?? I tried to put them in the same cluster but it doesn't seem to be enough. Any idea is welcome :) Benoît

3 4

AdminDown is tearing down BGP session
by Sunnat Samadov 19 Jun '23

19 Jun '23

Dear Birds, I am reaching out to seek assistance and guidance from the community regarding an issue we are facing with BIRD, specifically version 2.0.11, which we have been using in our network configuration. Our setup involves configuring BIRD with BGP+BFD, where BIRD initiates the BGP session establishment. However, we have observed an unexpected behavior: after the BIRD daemon successfully establishes the BGP connection, router sends a BFD Admin-down message and requests a new BFD session. This action by router leads to BIRD transitioning to a BFD down state and tearing down the previously established BGP session. According to RFC 5882, upon receiving BFD Admin down the BGP connection should not be terminated. If anyone has encountered a similar situation, your guidance would be invaluable in helping us address this problem. Any suggestions, recommendations, or workarounds would be highly appreciated. Best Regards, Sunnat Samadov

2 3

issue with next hop using freebsd loopback?
by Benoit Chesneau 16 Jun '23

16 Jun '23

I first posted this issue on the freebsd ml but it's probably more an issue to post there. I have the loopbacks `1.1.1.1` and `1.1.1.2` of 2 nodes distributed using OSPF: ``` filter ospfexport { if (source = RTS_DEVICE) then accept; reject; } protocol ospf v2 { tick 2; ipv4 { import all; export filter ospfexport; }; area 0 { stub no; interface "vlan1", "vlan2" { type ptp; cost 5; }; interface "lo1" { stub; }; }; } ``` `1.1.1.1` is set on the loopback: ```# ifconfig lo1lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo1 prefixlen 64 scopeid 0x9 inet 1.1.1.1 netmask 0xffffffff groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> # birdc show route for 1.1.1.1BIRD 2.13 ready. Table master4: 1.1.1.1/32 unicast [ospf1 15:56:43.054] ! I (150/0) [1.1.1.1] dev lo1 ``` The distribution works OK and I can ping each others: ``` # route -n get 1.1.1.2 route to: 1.1.1.2 destination: 1.1.1.2 gateway: 10.3.1.1 fib: 0 interface: vlan2212 flags: <UP,GATEWAY,HOST,DONE,PROTO1> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 9000 1 0 ``` But the IP of the loopback can't be used as BGP next hop in the following configuration: ```protocol bgp rr_par_ipv4 { local 1.1.1.1 as 65001; neighbor 1.1.1.1.2 as 65001; default bgp_local_pref 40; rr client; ipv4 { import all; export all; next hop self; }; }; ``` The source IP used as next hop is not 1.1.1.1 but the IP `10.3.1.2` of vlan1 used for the connection between 2 nodes: ``` # ifconfig vlan1vlan2212: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 options=680703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> ether 50:65:f3:8b:98:71 inet 10.3.1.2 netmask 0xffffff00 broadcast 10.3.1.255 inet6 fe80::5265:f3ff:fe8b:9871%vlan2212 prefixlen 64 scopeid 0xd groups: vlan vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: mlxen0 media: Ethernet autoselect (40Gbase-CR4 <full-duplex,rxpause,txpause>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> ``` **Even if I force the next hop address (using `next hop address`) it still take the IP of the vlan. What's wrong?*** ``` $ bird --versionBIRD version 2.13 $ uname -nmr myhostname 13.2-RELEASE amd64 ``` Benoît

1 3

Bad Peer AS with 4B AS issue
by Łukasz Jarosz 15 Jun '23

15 Jun '23

Hello, I have an issue with connectivity towards provider's router (out of my control). I setup BGP session as usual: protocol bgp [redacted] { local [redacted] as [redacted]; neighbor [redacted] as [redacted]; ipv4 { table bgp; next hop self; import filter bgp_in; export filter bgp_out; }; } I think worth mentioning is that I have 4B AS whilst my peer has 2B AS. All I get is this error: BGP state: Idle Neighbor address: [redacted] Neighbor AS: [redacted] Error wait: 48.720/60 Last error: Received: Bad peer AS I checked pcap dumps and they seem reasonable. BIRD open is followed by peer OPEN with piggybacked NOTIFICATION message. Based on MAC address my peer is Juniper, but that is just my guess. I am running BIRD 2.0.2 (unfortunately straightforward upgrade is not exactly possible). Anyone bumped into similiar issue or can give me any pointers? Best regards, Łukasz Jarosz

2 3

BIRD 1 End Of Life Reminder
by Maria Matejka 15 Jun '23

15 Jun '23

Dear BIRD Users, we'd like to remind you that BIRD 1 is reaching its end of life on 31 Dec 2023. Based on our existing materials, we have prepared a short guide to upgrade to version 2 which you can also print out for your convenience (see the attachment). Please note that the upgrade may take some time; it's better to upgrade sooner than later. If you need some help, let us know. Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

Feature Request: Preference in bird
by Marek Küthe 15 Jun '23

15 Jun '23

Hello, I noticed that when you "mix" routing protocols, it can be useful to change the "preference", but unfortunately there is little documentation in bird about this and no way to view it. Is it possible to view the preference using "birdc"? Is it possible to include the default values (in https://gitlab.nic.cz/labs/bird/-/blob/v2.0.12/nest/route.h#L748-755) in the documentation? Greetings Marek Küthe -- Marek Küthe m.k(a)mk16.de er/ihm he/him

4 7

BIRD show bgp summary for cli
by Roman Bulakh 14 Jun '23

14 Jun '23

Hi, we use BIRD in our environment, and it would be very nice to have some command like `show bgp summary` in juniper. This command show information about peer IP, peer AS, last update, prefixes received/best/exported and last state. Example: bird> show bgp summary Peer AS Last state change Prfx rcvd/best/export State X.X.X.X asXXXX 2021-01-27 6786/6785/109000 Established Y.Y.Y.Y asYYYY 2020-12-16 0/0/0 Passive BGP Error: Hold timer expired The are patch created for BIRD 1.3.4 and 1.3.6, but it would be good to have this in upstream software, without rebuilding and patching. as I understand it, no functionality should be affected by these changes, this is only a visual update for cli. Old patches describes at pages: https://marc.info/?l=bird-users&m=132155489919052&w=2 http://trubka.network.cz/pipermail/bird-users/attachments/20120228/a1499be7… https://bird-users.network.narkive.com/Px6EH3yl/bird-1-3-6-show-bgp-summary…

4 3

Default table selection with 'show route' in bird 2.13
by Alexander Shikov 14 Jun '23

14 Jun '23

Hello! While testing bird 2.13 with a bunch of non-default tables, including separate tables for flow specifications, I've found the output of 'show route' without additional parameters a bit annoying: # birdc show route BIRD 2.13 ready. Table FLOW4: flow4 { dst 109.68.40.15/32; proto 17; dport 123; } [FLOWSPEC 2023-06-08] * (200) So I had to add additional "table all" parameter to get route from non-default IPv4 table: # birdc show route table all BIRD 2.13 ready. Table master4: Table master6: Table IP4: 109.68.40.15/32 unicast [RS0 2023-06-07 from 193.25.180.255] * (100) [AS25372i] via 193.25.180.17 on bxe0 [...] Table FLOW4: flow4 { dst 109.68.40.15/32; proto 17; dport 123; } [FLOWSPEC 2023-06-08] * (200) Second example: -- default behavior: # birdc show route 109.68.40.15/32 BIRD 2.13 ready. Network not found # birdc show route 109.68.40.15/32 table all BIRD 2.13 ready. Table IP4: 109.68.40.15/32 unicast [RS0 2023-06-07 from 193.25.180.255] * (100) [AS25372i] via 193.25.180.17 on bxe0 ^^ have to always add 'table all' -- changed behavior looks more logical to me: # birdc show route 109.68.40.15/32 BIRD 2.13 ready. Table IP4: 109.68.40.15/32 unicast [RS0 12:31:26.621 from 193.25.180.255] * (100) [AS25372i] via 193.25.180.17 on bge1 Thus in my opinion, when no tables specified, it's reasonable to select not just default tables but all tables with routes. Such behavior should be closer to other vendors, at least JunOS. Attached patch changes default table selection. Have a nice day! -- Alexander Shikov Technical Staff, Digital Telecom IX http://dtel-ix.net/

1 0