- Bird-users - Mailing Lists

Does Bird supports AS_Trans 23456
by gerta toli 28 Aug '18

28 Aug '18

Hello everyone, Does anyone know or test the AS_Trans 23456 with Bird? We are using Bird and our ASN is 4 byte, but the peer supports only 2bytes ASN. I told them to use the AS23456 to peer with me, but it seems Bird doesnt establish session with the peer and Im showing "bad asn" So does Bird support this feature? Should I configure anything in Bird so it can send the open bgp message with ASN23456 instead my real ASN? thank you, Gerta

3 8

Help with multiple routing tables.
by Grant Taylor 26 Aug '18

26 Aug '18

Hi, I need a second set of eyes on the following config. I feel like I've made a mistake and I'm too tired to see it. - main_rib is Linux kernel table #254 and has all locally attached interfaces. There is no default gateway in kernel table #254. - default_rib is Linux kernel table #253 and only has the default gateway. - I have a series of ip rules that cascade across multiple Linux kernel tables, 254, others, and finally 253. I want BIRD to: 1 Advertise the following routes via RIP: - Locally attached - Default learned from default_rib (253) 2 Learn routes from RIP and update main_rib (254) Currently bird is not doing #2. I'm not completely sure when I want to learn or not. I think "learn" is for BIRD to learn about the routes from the routing table. I don't know if I need to "learn" in the kernel protocol for table 254 or not. I thought the locally attached routes were picked up via the direct protocol. BIRD is learning about the single default route in default_rib (253) and advertising it via RIP to other systems on the network. Any help would be greatly appreciated. Thank you in advance. ipv4 table main_rib; ipv4 table default_rib; protocol device { } protocol kernel { ipv4 { export all; import all; table main_rib; }; kernel table 254; #learn; } protocol kernel { ipv4 { export none; import all; table default_rib; }; kernel table 253; learn; } protocol direct { ipv4; interface "*"; } protocol rip { interface "eth0", "eth1", "eth2", "eth3" { version 2; }; ipv4 { export all; import all; table main_rib; table default_rib; }; } -- Grant. . . . unix || die

3 7

Bird does not export routes with different proto
by Kevin Schmitz 26 Aug '18

26 Aug '18

Hi guys, i tried to announce routes via ospf first time. Till now i use babel to get my routes in my table. Now i want to announce the babel routes trough my ospf as well. But here i see, even if import and export filters are set on all that bird ist not collecting this routes from my kernel table. Is there a reason for it or can i configure this? My Config: router1: #/etc/bird/bird.conf log syslog all; router id 163.172.107.146; protocol direct { interface "lo"; interface "bb-a-ak-ber"; interface "bb-b-ak-ber"; interface "bb-a-ix-dus"; interface "bb-b-ix-dus"; interface "bb-a-fra"; interface "bb-b-fra"; interface "ens18"; }; protocol kernel { device routes; import all; export all; kernel table 200; }; protocol device { scan time 10; }; protocol ospf IGP { import all; export all; area 0 { interface "lo" { stub yes; }; interface "ens18"; }; Routing Table on router1 default via 100.64.2.34 dev bb-a-fra proto bird 10.5.0.1 via 192.168.68.19 dev exit proto babel onlink 10.5.0.2 via 192.168.68.20 dev exit proto babel onlink 10.10.96.0/21 via 192.168.70.2 dev exit-kevin proto babel onlink 10.19.48.0/21 via 192.168.68.4 dev exit proto babel onlink 10.19.96.0/21 via 192.168.68.18 dev exit proto babel onlink 10.158.0.0/18 via 192.168.90.8 dev vpn3 proto babel onlink 10.158.128.0/18 via 192.168.90.8 dev vpn3 proto babel onlink 100.64.2.26 dev bb-a-ak-ber proto bird scope link 100.64.2.28 dev bb-b-ak-ber proto bird scope link 100.64.2.30 dev bb-a-ix-dus proto bird scope link 100.64.2.32 dev bb-b-ix-dus proto bird scope link 100.64.2.34 dev bb-a-fra proto bird scope link 100.64.2.36 dev bb-b-fra proto bird scope link 185.66.193.20 dev lo proto bird scope link 192.168.48.0/24 dev ens18 proto bird scope link 192.168.68.0/24 dev exit proto static scope link 192.168.70.0/24 dev exit-kevin proto static scope link router2 #/etc/bird/bird.conf log syslog all; router id 192.168.47.1; protocol direct { interface "lo"; interface "ens18"; }; protocol kernel { device routes; import all; export all; kernel table 200; }; protocol device { scan time 8; }; protocol ospf IGP { import all; export all; area 0 { interface "lo" { stub yes; }; interface "ens18"; }; } routing table router 2 default via 192.168.48.45 dev ens18 proto bird 10.66.0.0/24 dev lo proto bird scope link 100.64.2.26 via 192.168.48.45 dev ens18 proto bird 100.64.2.28 via 192.168.48.45 dev ens18 proto bird 100.64.2.30 via 192.168.48.45 dev ens18 proto bird 100.64.2.32 via 192.168.48.45 dev ens18 proto bird 100.64.2.34 via 192.168.48.45 dev ens18 proto bird 100.64.2.36 via 192.168.48.45 dev ens18 proto bird 185.66.193.20 via 192.168.48.45 dev ens18 proto bird 192.168.47.1 dev lo proto bird scope link 192.168.48.0/24 dev ens18 proto bird scope link As you can see, there are not all the routes from router1. Thanks in advance! Br, Kevin

2 2

vpn6-mpls routes on BIRD 2
by Chris Herdt 24 Aug '18

24 Aug '18

Thanks to the list for all the help you've given me so far! Another question: I am running BIRD 2.0.2 and peering with a host that is announcing vpn4 mpls and vpn6 mpls routes. The vpn4 mpls routes are working, but all of the vpn6 mpls routes appear as withdrawn routes. I'm not sure why -- I looked at the packet capture in Wireshark and the UPDATE messages containing the IPv6 routes all show zero for Withdrawn Routes Length. Any ideas? Here's the result of 'show protocols all peer1' (addresses changed): bird> show protocols all peer1 Name Proto Table State Since Info peer1 BGP --- up 14:35:04.353 Established BGP state: Established Neighbor address: 192.168.42.1 Neighbor AS: 65321 Neighbor ID: 192.168.42.1 Local capabilities Multiprotocol AF announced: vpn4-mpls vpn6-mpls Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Neighbor capabilities Multiprotocol AF announced: vpn4-mpls vpn6-mpls Route refresh Extended next hop IPv6 nexthop: ipv4 ipv4-mc Graceful restart Restart time: 120 AF supported: vpn4-mpls vpn6-mpls AF preserved: 4-octet AS numbers Session: internal multihop AS4 Source address: 192.168.100.1 Hold timer: 12.954/15 Keepalive timer: 0.005/5 Channel vpn4-mpls State: UP Table: vpntab4 Preference: 100 Input filter: ACCEPT Output filter: REJECT Routes: 9771 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 9771 0 0 0 9771 Import withdraws: 20 0 --- 20 0 Export updates: 9771 9771 0 --- 0 Export withdraws: 0 --- --- --- 0 BGP Next hop: 192.168.100.1 IGP IPv4 table: master4 Channel vpn6-mpls State: UP Table: vpntab6 Preference: 100 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 2785 0 --- 2785 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 BGP Next hop: :: IGP IPv6 table: master6 -- Chris Herdt https://osric.com/chris/

3 4

bug or documentation bug
by Clemens Schrimpe 24 Aug '18

24 Aug '18

Hello - the manual explains a global protocol option: description "text" This is an optional description of the protocol. It is displayed as a part of the output of 'show route all' command. But it doesn’t work (any more?). Tiny thing, just wanted to mention it. Greetings, Clemens

2 1

BFD protocol doesn't send packets after link flap up on switch
by Jakub Nowacki 24 Aug '18

24 Aug '18

Hi, I have multihop BGP peering with BFD setup on it. One of the peers is a switch that runs Linux. I've run into situation where after link flap on interface that switch connects to BFD protocol after successfully detecting that flap BFD session cannot reestablich because switch side stops sending BFD packets. I'm suspecting that this is due to switch behavior that removes IP address of link when it goes down (BGP and BFD are using interface ip address to connect). Bird is trying to bind to IP address that is no longer available and that causes the issue. Logs below show following events 1. Correct BFD packet exchange 2. Link flaps at 14:07:38 3. Link is back up, starts receiving BFD packets from peer and state changes from Down to Init at 14:07:45. Note that no BFD packets are being generated, where they should be. 4. Removing 'bfd;' line and reconfiguring at 14:08:31 5. Adding 'bfd; line and reconfiguring at 14:08:47 which successfully restart BFD. 2018-08-24 14:07:37 <TRACE> bfd1: CTL received from 172.30.2.1 [Up A] 2018-08-24 14:07:37 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <TRACE> bfd1: CTL received from 172.30.2.1 [Up A] 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <TRACE> bfd1: CTL received from 172.30.2.1 [Up A] 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <ERR> bfd1: Socket error: Invalid argument 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <ERR> bfd1: Socket error: Invalid argument 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <ERR> bfd1: Socket error: Invalid argument 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <ERR> bfd1: Socket error: Invalid argument 2018-08-24 14:07:38 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:07:38 <ERR> bfd1: Socket error: Invalid argument 2018-08-24 14:07:38 <TRACE> bfd1: Session to 172.30.2.1 expired 2018-08-24 14:07:38 <TRACE> bfd1: Session to 172.30.2.1 changed state from Up to Down 2018-08-24 14:07:38 <TRACE> bgp_gw_rs_1: BFD session down 2018-08-24 14:07:38 <TRACE> bfd1: Session to 172.30.2.1 removed 2018-08-24 14:07:38 <ERR> bfd1: Socket error: bind: Cannot assign requested address 2018-08-24 14:07:38 <TRACE> bfd1: Session to 172.30.2.1 added 2018-08-24 14:07:44 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] 2018-08-24 14:07:44 <TRACE> bfd1: Session to 172.30.2.1 changed state from Down to Init 2018-08-24 14:07:45 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] 2018-08-24 14:07:46 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] 2018-08-24 14:07:46 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] 2018-08-24 14:07:47 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] ... 2018-08-24 14:08:30 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] 2018-08-24 14:08:31 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] 2018-08-24 14:08:31 <TRACE> bfd1: Session to 172.30.2.1 removed 2018-08-24 14:08:31 <TRACE> bfd1: Reconfigured 2018-08-24 14:08:47 <TRACE> bfd1: Session to 172.30.2.1 added 2018-08-24 14:08:47 <TRACE> bfd1: Session to 172.30.2.1 reconfigured 2018-08-24 14:08:47 <TRACE> bfd1: Reconfigured 2018-08-24 14:08:47 <TRACE> bfd1: CTL received from 172.30.2.1 [Down A] 2018-08-24 14:08:47 <TRACE> bfd1: Session to 172.30.2.1 changed state from Down to Init 2018-08-24 14:08:47 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Init A] 2018-08-24 14:08:47 <TRACE> bfd1: CTL received from 172.30.2.1 [Up PA] 2018-08-24 14:08:47 <TRACE> bfd1: Session to 172.30.2.1 changed state from Init to Up 2018-08-24 14:08:47 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up FA] 2018-08-24 14:08:47 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up PA] 2018-08-24 14:08:47 <TRACE> bfd1: CTL received from 172.30.2.1 [Up FA] 2018-08-24 14:08:47 <TRACE> bfd1: CTL received from 172.30.2.1 [Up A] 2018-08-24 14:08:47 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] 2018-08-24 14:08:47 <TRACE> bfd1: CTL received from 172.30.2.1 [Up A] 2018-08-24 14:08:47 <TRACE> bfd1: Sending CTL to 172.30.2.1 [Up A] Kuba Nowacki

1 1

show route command syntax
by Chris Herdt 23 Aug '18

23 Aug '18

I'm using BIRD v2.0.2. I have successfully peered with another host and am receiving iBGP routes. bird> show route count 0 of 0 routes for 0 networks in table master4 0 of 0 routes for 0 networks in table master6 9763 of 9763 routes for 9763 networks in table vpntab4 0 of 0 routes for 0 networks in table vpntab6 Total: 9763 of 9763 routes for 9763 networks in 4 tables I can use 'show route all' to see all the routes (IP addresses replaced): bird> show route all Table vpntab4: 192.168.100.0:24 192.168.42.199/32 unreachable [peer1 13:22:47.245 from 192.168.12.3] * (100/-) [AS65321i] Type: BGP univ BGP.origin: IGP BGP.as_path: 65321 BGP.next_hop: 192.168.100.0 BGP.local_pref: 100 BGP.originator_id: 192.168.100.0 BGP.cluster_list: 192.168.12.3 192.168.100.1 BGP.ext_community: (rt, 65123, 65555) BGP.mpls_label_stack: 54321 etc. However, I can't seem to figure out the syntax to retrieve a specific route. E.g.: bird> show route for 192.168.42.199/32 Network not found Thanks in advance. -- Chris Herdt https://osric.com/chris/

2 2

NETCONF Support
by knet solutions 22 Aug '18

22 Aug '18

Hi, How do i configure the BIRD via Netconf?. Any native implementation or workaround? thanks suresh -- *Regards, * *Knet solutions.* website: http://knetsolutions.in/ Facebook Page : https://www.facebook.com/sdntraining/ youtube channel: https://www.youtube.com/channel/UCTD6X9_oDqIYs_xpE7moFnQ

1 0

RE: BGP resolvable issue
by Arvin Gan 22 Aug '18

22 Aug '18

Ping, anyone known it ?:) Thanks Arvin From: Arvin Gan Sent: Monday, August 13, 2018 5:42 PM To: bird-users(a)network.cz Subject: BGP resolvable issue Hi all, In RFC4271, If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or if it would become unresolvable if the route was installed in the routing table, the BGP route MUST be excluded from the Phase 2 decision function. Actually, BGP protocol is implemented this option. I notice that resolvable is checked with "rt->attrs->dest == RTD_UNICAST" , that mean the check is depend on the reachability of route for NEXT_HOP. However, NEXT_HOP is a host address, not a subnet address, the resolvable checking in VRF is depending on ARP/NDP result for NEXT_HOP, if NEXT_HOP cannot be resolved for MAC, it should be unresolved. The description of RFC4271 for "resolvable", I am confused whether it includes only route reachable, not includes host address reachable, does anyone clearly understand it? My test case: BGP4----------------------------------------------------------BGP4 peer set next hop:1560::28 BGP4 peer route table : 1560::/64 unicast [direct2 09:03:52.007] * (250) dev A6IF1 --------------------------------------------------------the address of interface is 1560::15/64 ,generate direct route unicast [bgp4 09:24:36.872 from 1560::26] (200) [?] via 1560::28 on A6IF1 -------------------------------------------------------the route is resolved in BGP4 peer based in brid, but the address the interface of BGP4 peer is 1560::15, not 1560::28, NDP is not successful. Thanks Arvin

2 2

bird2: channel down in direct protocol
by Alarig Le Lay 21 Aug '18

21 Aug '18

Hi, I would like to import interfaces routes in my bird instance, so I wrote this into my configuration: protocol direct { ipv6; } But the channel is down when I look thought birdc: bird> show protocols all direct1 Name Proto Table State Since Info direct1 Direct --- up 17:42:58.641 Channel ipv6 State: DOWN Table: master6 Preference: 240 Input filter: ACCEPT Output filter: REJECT And of course, I have routes on my interfaces: samis ~ # ip -6 r sh 2a00:5884::/64 dev eth1 proto kernel metric 256 pref medium 2a00:5884:0:5::/64 dev brlxc proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium fe80::/64 dev brlxc proto kernel metric 256 pref medium default via fe80::204:92:100:1 dev eth1 metric 3 pref medium I don’t see anything in the documentation to force a channel to be up. What am I missing? Cheers, -- Alarig

2 6