March 2013 - Bird-users - Mailing Lists

IS-IS
by kveri new 01 Jun '15

01 Jun '15

Hello, I would like to implement IS-IS as a part of my master thesis. Are there any apparent problems which would prevent successful implementation, political and/or technical? Also I would like to hear opinions of the authors. Implementation timeframe is 2013 (if we live past 21th). Regards, Martin Čechvala Faculty of Informatics and Information Technologies Slovak Technical University

7 8

BGP syslog
by Jimmy Halim 05 Sep '13

05 Sep '13

Hi guys, Can I confirm with you guys that syslog is only logging the event for BGP Notification errors only? I mean, it does not log the BGP session up and down event? Thanks in advance! Cheers, Jimmy

7 26

Bird RIP does not send some packages
by Aleksey Chudov 13 May '13

13 May '13

Hello, I ran into a situation that Bird RIP does not send some packages. Bird configuration file /etc/bird.conf log syslog all; debug protocols all; protocol device { scan time 5; } protocol direct { interface "*"; } protocol kernel { persist; scan time 5; export filter { if source = RTS_RIP then { if rip_metric > 15 then reject; if net ~ 10.0.0.0/8 then accept; if net ~ 192.168.0.0/16 then accept; } reject; }; } protocol rip { period 5; timeout time 20; garbage time 30; interface "gre*" { mode multicast; }; export filter { if net ~ 10.64.0.0/20 then accept; reject; }; } Log messages from Bird daemon Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1 And tcpdump for the same period 18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44 18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 Are there any ideas why this is happening? Best regards, Aleksey

3 14

Re: BGP MD5 with Juniper Router
by Ondrej Filip 11 Apr '13

11 Apr '13

On 26.3.2013 12:40, Kay Rechthien wrote: > Hey, > On 08.03.2013, at 16:21, Ondrej Filip <feela(a)network.cz> wrote: > >> On 8.3.2013 09:38, Rashed Alwarrag wrote: >>> Dear birds Experts >> >> Hi Rashed! >> >>> >>> we have a BGP peer between Bird server and Juniper devices , we >>> mentioned that in our Juniper router wrong MD5 password log appear as >>> below >>> >>> kernel: %KERN-4: tcp_auth_ok: Packet from 192.168.0.10:179 >>> <http://192.168.0.10:179> wrong MD5 digest >>> >>> when we capture the BGP update we mentioned that the bird server is >>> sending to the router the update with an unexpected MD5 key and The >>> router ignore this update then again the bird server retransmit the >>> same update with correct MD5 >> >> Are you using Linux or BSD? >> >> Ondrej > > we have the issue also here. Our Routeservers are running latest Ubuntu. > the issue is visible at cisco and juniper routers clearly. there are like ~10 bad packets per day and they don't affect the bgp session but they create a log entry every time at the routers. > Can you send us the output of this command: "ethtool -k <interface>" (posibly 'ethtool -k eth0") This usually helps: /usr/sbin/ethtool -K eth0 tso off /usr/sbin/ethtool -K eth0 gso off /usr/sbin/ethtool -K eth0 sg off > best regards > kay > >

3 5

MBGP: eBGP multihop session incorrect gw attribute value when resolving nexthop
by Sergey Popovich 28 Mar '13

28 Mar '13

I do not know is there is really BUG and should be reported in special manner or our configuration weakness, so I consider to ask before. Deploying BIRD for IPv6 recently on one of the our new Access Server we spot problem: routes not installed by kernel protocol in kernel's routing table. Multihoop MBGP session successfuly established with our RSs (OpenBGP) and route information exchanged in both directions: (confirmed by birdc6 'show route export as65001_rs1' and birdc6 'show route protocol as65001_rs1'). Routing information received from RSes received with correct nexthop (confirmed by birdc6 'show route protocol as65001_rs1 all' and network packet analyzer) But BIRD's `gw` attribute is set to :: (contrary to non :: (not link-local) nexthop received from RSes!) Our configuration follows ========================= We have an Access Server on which we plan to use dual-stack configuration and two Route Servers based on OpenBGP to establish multihop eBGP session with. Configuration for both BGPv4 and MBGP differs only in session network protocol (BGPv4 - over IPv4, MBGP - over IPv6) and small set of filter rules (especially address family dependent). BIRD's version also equal (1.3.9). So far we have no such problem for BGPv4 (IPv4 configuration). Here's BIRD's configuration summary comes ----------------------------------------- ### ## Direct ### protocol direct direct254 { # These routes are not installed in kernel by "kernel254" protocol # (they already installed by kernel (proto kernel)). # # Import these routes to BIRD's internal table to let BIRD correctly # resolve recursive nexthops and late install (by kernel254) into # kernel routing table. interface "bond0.*"; } ### ## Static ### # Install in kernel routing table to route MBGP session packets # to RSes protocol static static254 { # RS1 & RS2 route <rs1_ipv6_address>/128 via <gw_ipv6_to_rs>; route <rs2_ipv6_address>/128 via <gw_ipv6_to_rs>; } ### ## Kernel ### protocol kernel kernel254 { persist no; scan time 120; learn yes; device routes no; kernel table ipt_main; import filter { # Import only routes marked as static if krt_source != ipp_static then reject; accept; }; export all; } ### ## BGP ### # Common BGP session template template bgp bgp_templ { capabilities yes; advertise ipv4 yes; enable route refresh yes; enable as4 yes; start delay time 10; connect retry time 60; startup hold time 30; keepalive time 10; hold time 30; ### This is default for multihop ### gateway recursive; } # RS server filter fl_import_from_as65001 { # Apply ingress route policy here ### ### This is quick (and wery dirty!) workaround for problem: ### Explicitely overwrite `gw' attribute with nexthop value. ### ### Tested and found working. Should be considered as temporary. ### if gw = :: then gw = bgp_next_hop; accept; } filter fl_export_to_as65001 { # Apply egress route policy here accept; } template bgp bgp_templ_rs from bgp_templ { multihop 4; local <our_ipv6_address> as 65002; import filter fl_import_from_as65001; export filter fl_export_to_as65001; } # as65001, rs1 protocol bgp as65001_rs1 from bgp_templ_rs { neighbor <rs1_ipv6_address> as 65001; } # as65001, rs2 protocol bgp as65001_rs2 from bgp_templ_rs { neighbor <rs2_ipv6_address> as 65001; } Detailed problem investigation ============================== This problem probably comes from bgp_set_next_hop() in proto/bgp/packets.c. For IPv6 we have allocating an array of nexthops (with index 0 for NEXT_HOP from packet (or zero if none) and 1 for Link-Local), but it seems in bgp_attach_next_hop() in proto/bgp/packets.c we might set nexthop[1] with IPA_NONE in case no LL address received in update (which is in case of multihop configuration). It seems we need additionally (only?) check for ipa_nonzero(nexthop[1]) in bgp_set_next_hop() as this done in bgp_format_next_hop() and bgp_create_update() in proto/bgp/attrs.c. -- SP5474-RIPE Sergey Popovich

2 1

BGP MD5 with Juniper Router
by Rashed Alwarrag 26 Mar '13

26 Mar '13

Dear birds Experts we have a BGP peer between Bird server and Juniper devices , we mentioned that in our Juniper router wrong MD5 password log appear as below kernel: %KERN-4: tcp_auth_ok: Packet from 192.168.0.10:179 wrong MD5 digest when we capture the BGP update we mentioned that the bird server is sending to the router the update with an unexpected MD5 key and The router ignore this update then again the bird server retransmit the same update with correct MD5 is this issue is expected in bird server or is there any known bug/PR for this issue in Bird *Rashed Alwarrag *

4 5

Review my BGP configuration
by Andre Nathan 25 Mar '13

25 Mar '13

Hello I have just put my first bird router up in production. Everything is working fine, but I wonder if there are any modifications that I can do to my configuration to optimize it and/or adhere best practicess. My prefix is, in the configuration bellow, a.b.0.0/23, but I want to export it as two separate /24 prefixes, a.b.0.0/24 and a.b.1.0/24. Aditional information: Router ID: x.y.z.w Local AS: 1234 Neighbor ID: w.z.y.x Neighbor AS: 4321 The neighbor router is not directly connected to my router, so I'm using multihop. The part that is bugging me about this configuration is the need for a kernel protocol black list filter. Is there a cleaner way to do this? Bellow is my bird.conf: # Protocol kernel: the black list is so that the routes for # the two /24 reject routes from the static protocol are not # added to the kernel routing table. This kinda smells fishy. # Is there a way around this? filter kernel_filter prefix set KERNEL_BLACKLIST; { KERNEL_BLACKLIST = [ a.b.0.0/24, a.b.1.0/24 ]; if net ~ KERNEL_BLACKLIST then { reject; } accept; } protocol kernel { scan time 20; export filter kernel_filter; } protocol device { scan time 10; } # Prefixes to be exported to BGP, plus a route to the BGP neighbor: protocol static mynetwork { route a.b.0.0/24 reject; route a.b.1.0/24 reject; route w.z.y.x/32 via w.z.y.1; } # The file below contains a single definition: define BGP_MED=200. # This is used when, due to failover, the iBGP peer becomes the # preferred router. A script is executed changing the MED value to # 100 and bird is reloaded. The iBGP peer (which has MED 100) will # analogously be modified to 200, and thus become the preferred # router from my provider's router's point of view. include "/etc/bird-med.conf" # BGP export filter: export my prefixes. filter ebgp_out prefix set EXPORT_WHITELIST; { EXPORT_WHITELIST = [ a.b.c.0/23, a.b.c.0/24, a.b.c.1/24 ]; if net ~ EXPORT_WHITELIST then { bgp_med = BGP_MED; accept; } reject; } # BGP import filters: reject RFC1918 stuff. filter ebgp_in prefix set IMPORT_BLACKLIST; { IMPORT_BLACKLIST = [...]; if net ~ IMPORT_BLACKLIST then { printn "Discarding received route to "; print net; reject; } accept; } # # BGP sessions # protocol bgp eBGP { description "eBGP"; local as 1234; source address x.y.z.w; neighbor w.z.y.x as 4321; multihop 2; default bgp_local_pref 200; export filter ebgp_out; import filter ebgp_in; } protocol bgp iBGP { description "iBGP"; local as 1234; source address x.y.z.w; neighbor x.y.z.k as 262672; next hop self; gateway direct; default bgp_local_pref 100; } Thanks in advance, Andre

3 23

bird 1.3.9 - show bgp summary command
by Javor Kliachev 24 Mar '13

24 Mar '13

2 1

Pipe collision detected - how to merge tables?
by Dan Rimal 21 Mar '13

21 Mar '13

Hello, I have problem with pipe collision detected with bird.. i would like to have separate routing table for tranzit bgp peers and another table for internet exchange peers, but i need merge routes from this two tables to master table.. but there is problem with Pipe collision detected, because there is a lot of the same routes from both tables. Is there any way how to merge tables with aware of localpref or something like this? Maybe protocol preference? Regards, Dan

1 1

bird is in use by cloudflare
by Allan Pinto 07 Mar '13

07 Mar '13

hit hackernews today http://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p -- Thanx and regd's. Allan. http://tamahatta.com

1 1