- Bird-users - Mailing Lists

[PATCH] fletcher checksum: this MIGTH help w.r.t the endian problem.
by Joakim Tjernlund 23 Apr '10

23 Apr '10

Not tested at all. --- proto/ospf/lsalib.c | 21 ++------------------- 1 files changed, 2 insertions(+), 19 deletions(-) diff --git a/proto/ospf/lsalib.c b/proto/ospf/lsalib.c index 35f02dc..b8fd97d 100644 --- a/proto/ospf/lsalib.c +++ b/proto/ospf/lsalib.c @@ -180,29 +180,12 @@ buf_dump(const char *hdr, const byte *buf, int blen) #define MODX 4102 #define LSA_CHECKSUM_OFFSET 15 -/* FIXME This is VERY uneficient, I have huge endianity problems */ void lsasum_calculate(struct ospf_lsa_header *h, void *body) { u16 length = h->length; - // log(L_WARN "Checksum %R %R %d start (len %d)", h->id, h->rt, h->type, length); - htonlsah(h, h); - htonlsab(body, body, length - sizeof(struct ospf_lsa_header)); - - /* - char buf[1024]; - memcpy(buf, h, sizeof(struct ospf_lsa_header)); - memcpy(buf + sizeof(struct ospf_lsa_header), body, length - sizeof(struct ospf_lsa_header)); - buf_dump("CALC", buf, length); - */ - (void) lsasum_check(h, body); - - // log(L_WARN "Checksum result %4x", h->checksum); - - ntohlsah(h, h); - ntohlsab(body, body, length - sizeof(struct ospf_lsa_header)); } /* @@ -250,8 +233,8 @@ lsasum_check(struct ospf_lsa_header *h, void *body) c0 %= 255; c1 %= 255; } - - x = ((length - LSA_CHECKSUM_OFFSET) * c0 - c1) % 255; + /* the (int) cast is need to ensure % is signed */ + x = (int)((length - LSA_CHECKSUM_OFFSET) * c0 - c1) % 255; if (x <= 0) x += 255; y = 510 - c0 - x; -- 1.6.4.4

1 0

Re: OSPF performance/SPF calculations
by Joakim Tjernlund 23 Apr '10

23 Apr '10

> > Ondrej Zajicek <santiago(a)crfreenet.org> wrote on 2010/04/21 20:15:07: > > On Wed, Apr 21, 2010 at 09:41:47AM +0200, Joakim Tjernlund wrote: > > > I am using Quagga ATM but I had a quick look at BIRD and I got a few > > > observations. > > > > Hello. Thank you for your tips and notes. > > > > > The LSA/checksum code seem very inefficient. > > > LSAs are built allocating/reallocing bits > > > of memory. This is slow and will case memory fragmentation. > > > > You mean lsab_alloc() in originate_rt_lsa_body()? > > This allocation is just a sequential allocation in a persistent memory buffer, > > therefore it is very efficient (in most cases just increase of lsab_used counter) > > and there si no memory fragmentation (all is done inside a persistent memory buffer). > > Yes, you do realloc on small amounts of memory. Also, receives LSAs > seems to be impl. differently so you need handle these somewhat > differently. > > > > > The fletcher checksum is very slow as it has extra tests in the hot path and also > > > flips endian in the LSA back and forth. > > > > Do you have some suggestions for a better algorithm, or just a better > > implementation? Yes, the problem with flipping endianity is known. > > I do not studied this part of the code yet (the checksum algorithm). > > Yes, but not at the moment. The endian problem should be addressed when you > build the lsa. > > > > > > I can't work out how the SPF next hop works(calc_next_hop). I tried to > compare it with > > > Quagga's ospf_nexthop_calculation() but the structure is too different. The reason > > > for me looking into this was to see how much work it would be to add > > unnumbered ppp links > > > but as I can't work out how nexthop is working I didn't get very far. > > > > The current code is different from what RFC says. For direct neighbors > > (on both ptp and non-ptp networks), we just use IP address taken from > > the source address of the HELLO packet of the neighbor (stored in > > neighbor structure returned by find_neigh_noifa()). > > > > This works well [*] for both broadcast and ptp links (numbered or > > unnumbered), but is broken on NBMA networks. I have some not-yet-commited > > changes to calc_next_hop() that on broadcast and NBMA networks uses the > > standard way (taking IP address from the router LSA) and the source address > > from HELLO packet as a nexthop is used just for PTP links. > > Such behavior is also suggested by RFC 5340 (for OSFPv3). > > > > [*] Regardless of how the other side is implemented. > > > > > I have impl. unnumbered ppp link for Quagga that works really well but this work > > > hasn't been accepted into Quagga yet since Quagga development has stalled. > > > I could show you how I did it Quagga though. > > > > The development state of Quagga is sad. Do you implement it in a different > > way than in BIRD? I wonder whether there is any other possible way to get > > next hop address for unnumbered ptp links than from source address > > of HELLO packet. > Yep, now it gets tricky. It took me quite some time to figure out what to > do. The secret is that you never use search for the interface using IP addresses > in the LSA's. Instead you record what interface created what entry in in your > own Router LSA. Based on the position of on entry in your own router > LSA you can lookup the interface that created that entry. Once > you know the interface, the reset is easy. > > One way to impl. this is to build an array of interface pointers when > you construct the Router LSA: > RLSA Array > Item 0 ptr to ppp0 > Item 1 ptr to ppp0 > Item 2 ptr to eth0 > ... > Item n ptr to if n > > Now you can easily find the interface if you pass on the position of the > the entry in the RLSA you are processing to the nexthop calculation. > > I have a few patches to Quagga that does this somewhere, they are all > on the Quagga mailing list and a few of them are also in my personal > git repo at the Quagga site. > > Jocke Found two different impl. I did for Quagga. Figured you could use them to get an idea.

1 0

New release 1.2.2
by Ondrej Filip 18 Apr '10

18 Apr '10

Hi! New version is ready, completely prepared by Santiago, good job. :-) Version 1.2.2 (2010-04-10) o Much better BSD kernel support (IPv6, alien routes, ...). o Deep OSPF socket changes, fixes OSPFv2/v3 behavior on BSD. o OSPFv2 in Linux now supports more non-stub IP prefixes on one physical iface. o Export of device routes to the kernel is more restricted. o Routes with strange scope not allowed in BIRD routing tables. o New filterable route attributes bgp_originator_id, bgp_cluster_list and ospf_router_id. o Restricted read-only CLI (option -r). o Pattern matching for 'show protocols' command. o BGP protocol details in 'show protocols all' command. o Configurable syslog name (and default on IPv6 changed). o Statistic counters for pipes were fixed. o Many bugfixes in BGP, OSPF, filters, ... All distro packages will follow soon. Ondrej

5 5

Socket: Broken pipe
by Stefan Jakob 18 Apr '10

18 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear List, does anyone know what ird> show protocol R123 name proto table state since info R123 BGP Ttablename start 2010-04-16 09:36:35 Idle Socket: Broken pipe mean? Rgds, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLyDouAAoJEJDQtqadNP/lrqQH/A1KAe2opON2YY4dsrd5p+Jv 6pa4x+q10EGFf/f/podPpr3qK8UcvQu2ynRpYSKE6+ypHm5kQjcvCZptk6l637fF VQnGXC7eiO0IU7fxAG/78A5Oy+5skFEzZxiLfgqapgDZ8E6d1oVD1LdB94AHsKhs S4/fFd/bLCD9bFHBcBvko6tttf9a4n7ovnfCNkm25KULggod3uiOafkIE108Hwyx BkNbQtvWk3oyPZWb2LxfihgPIp/nsAA9Tq7WrvnXukQZFM+AgGGTbYmcJxUBFpnY YbdcuvfVJrI7y48HeduwAPGblLjK5oU3RNAhDgbhmKHTCfB23qEOksjfZ9+kpns= =Wpr+ -----END PGP SIGNATURE-----

2 3

DEB Packages of BIRD 1.2.2
by Peter Lieven 15 Apr '10

15 Apr '10

Hi all, is there a schedule for BIRD 1.2.2 packages for Ubuntu/Debian? Thanks for this great piece of software! Peter # Kind Regards/Mit freundlichen Gruessen # # PEERING GmbH - Devision ECIX # Lindenallee 27, 14050 Berlin, Germany # # Geschaeftsfuehrer: Stefan Wahl, Peter Lieven # Amtsgericht Charlottenburg, HRB 97752B, USt-Id-Nr: DE2746301838 # # Web: http://www.ecix.de/ # Phone: +49 30 81495450 # Fax: +49 30 81495459

3 4

Very simple bird.conf
by Chris Webb 14 Apr '10

14 Apr '10

I'm trying to replace a quagga daemon doing an extremely simple bgp peering with an upstream with bird 1.2.2. I have it working, but I'm not sure it's quite set up correctly. My config is router id 91.203.57.1; protocol device { } protocol direct { } protocol kernel { import all; export all; } protocol bgp { local as 44934; neighbor 84.45.39.149 as 25577; import all; export where net = 91.203.56.0/23; } I'll need additional internal peerings later, but I just want to get the simplest possible config correct first! When I do birdc show protocols all, it includes: bgp1 BGP master up 10:56 Established Preference: 100 Input filter: ACCEPT Output filter: <NULL> Routes: 311380 imported, 1 exported, 311380 preferred Route change stats: received rejected filtered ignored accepted Import updates: 334136 0 0 7828 326308 Import withdraws: 1756 0 --- 0 1756 Export updates: 326310 326308 1 --- 1 Export withdraws: 1756 --- --- --- 0 BGP state: Established Session: external Neighbor AS: 25577 Neighbor ID: 84.45.90.246 Neighbor address: 84.45.39.149 Nexthop address: 84.45.39.149 Source address: 84.45.39.150 Neighbor caps: refresh Hold timer: 153/180 Keepalive timer: 33/60 I think this means I've got the export filter wrong somehow and am trying to re-export the routes I get in from my upstream. (Perhaps they're going bgp -> kernel -> bgp?) Best wishes, Chris.

3 5

BIRD in OpenWRT - patch
by Ondrej Zajicek 12 Apr '10

12 Apr '10

Hello Here is a patch for building BIRD in OpenWRT buildsystem. I hope it will be merged to OpenWRT soon. (package names are bird4, birdc4, bird6 and birdc6, not just bird). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

2 7

Why filter not work for two cases?
by Владислав Гришин 10 Apr '10

10 Apr '10

My network. Bird is used as border router on the standalone server. I have a two upstream ISPs from which I accept full view + default route over eBGP. I have a one downstream ISP to which I announce full view + default route. Into my AS a IGP protocol is OSPF. The L3 switch Cisco 3550 is used on a network. Bird IP is 10.10.1.2, Cisco 3550 IP is 10.10.1.3. To BGP downstream I plan to announce a default route which is exported from the bird static protocol, for stability. For OSPF neighbors I plan to announce a default route which is received from the upstream ISPs, since for each operator in the future there will be a server. Now the default route in routing table is imported only from upstreams, route to 0.0.0.0/0 network is not present in static protocol of bird. Оutput of birdc bird> show route where source=RTS_BGP && net = 0.0.0.0/0 0.0.0.0/0 via 93.191.9.205 on eth2.701 [bgpfiord 2010-05-09 19:37:35] * (100) [AS28917i] via 82.138.44.129 on eth2.51 [bgpcomcor 2010-05-09 19:37:31] (100) [AS8732i] bird> bird> show route where net = 0.0.0.0/0 0.0.0.0/0 via 93.191.9.205 on eth2.701 [bgpfiord 2010-05-09 19:37:35] * (100) [AS28917i] via 82.138.44.129 on eth2.51 [bgpcomcor 2010-05-09 19:37:31] (100) [AS8732i] bird> The filter which exports a default route from routing table to OSPF protocol looks as follows ... filter export_default_route_from_bgp_to_ospf { if ( source = RTS_BGP && net = 0.0.0.0/0 ) then { print "net accepted:", net; ospf_metric1 = 48; accept; } reject; } ... Default route is present в LSA_DB of OSPF bird. See output of birdc bird> show ospf lsadb Global Type LS ID Router Age Sequence Checksum 0005 0.0.0.0 10.10.1.2 41 80000001 a16c 0005 11.11.11.12 10.10.1.3 1880 80000037 9f88 0005 12.12.12.12 10.10.1.3 1880 80000037 7ba9 0005 13.13.13.12 10.10.1.3 1880 80000037 57ca Area 0.0.0.0 Type LS ID Router Age Sequence Checksum 0001 10.10.1.2 10.10.1.2 125 80000129 19a8 0001 10.10.1.3 10.10.1.3 93 8000018a cf76 0002 10.10.1.3 10.10.1.3 94 80000006 7ed6 bird> Console output of 3550 3550-L3-S1#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 65500", distance 110, metric 49, candidate default path, type extern 1 Last update from 10.10.1.2 on Vlan550, 00:00:39 ago Routing Descriptor Blocks: * 10.10.1.2, from 10.10.1.2, 00:00:39 ago, via Vlan550 Route metric is 49, traffic share count is 1 3550-L3-S1# Default route is present в LSA_DB of OSPF Cisco 3550. Now I add a command in a configuration of the static protocol protocol static { ... route 0.0.0.0/0 via "lo"; ... } I softly restart bird and see the following bird> show route where source=RTS_BGP && net = 0.0.0.0/0 0.0.0.0/0 via 93.191.9.205 on eth2.701 [bgpfiord 2010-05-09 19:37:35] (100) [AS28917i] via 82.138.44.129 on eth2.51 [bgpcomcor 2010-05-09 19:37:31] (100) [AS8732i] bird> bird> show route where net = 0.0.0.0/0 0.0.0.0/0 dev lo [static1 2010-05-09 20:12:32] * (254) via 93.191.9.205 on eth2.701 [bgpfiord 2010-05-09 19:37:35] (100) [AS28917i] via 82.138.44.129 on eth2.51 [bgpcomcor 2010-05-09 19:37:31] (100) [AS8732i] bird> Default route is not present в LSA_DB of OSPF bird. Оutput of birdc bird> show ospf lsadb Global Type LS ID Router Age Sequence Checksum 0005 11.11.11.12 10.10.1.3 246 80000038 9d89 0005 12.12.12.12 10.10.1.3 246 80000038 79aa 0005 13.13.13.12 10.10.1.3 246 80000038 55cb Area 0.0.0.0 Type LS ID Router Age Sequence Checksum 0001 10.10.1.2 10.10.1.2 519 80000129 19a8 0001 10.10.1.3 10.10.1.3 487 8000018a cf76 0002 10.10.1.3 10.10.1.3 488 80000006 7ed6 bird> In result OSPF neighbor Cisco 3550 does not receive default route from bird. 3550-L3-S1#show ip route 0.0.0.0 % Network not in table 3550-L3-S1# Сlause "source = RTS_BGP && net = 0.0.0.0/0" in filter export_default_route_from_bgp_to_ospf and clause "source=RTS_BGP && net = 0.0.0.0/0" in the "show route" command is same. Why the default route is not exported to OSPF protocol from bird routing table after adding route 0.0.0.0/0 via "lo"; in bird.config of static protocol? Why filter export_default_route_from_bgp_to_ospf does not work for two cases? Vladislav Grishin

2 2

another bug: system time change
by Wolfgang Hennerbichler 09 Apr '10

09 Apr '10

Hi Ondrejs, I think I found another bug. For some mysterious reason our system time jumped forward (more than 30.000 seconds) on one of our route-servers. I don't know why this happened, but I suspect a broken ntp server could have caused this. Nevetheless, this was reason enough for BIRD to drop the BGP peerings: You see the log-entries from the wtachdog, which is run every minute, all of a sudden the time jumps to 10:08 UTC, and BIRD brings down BGP sessions. Are the session hold timers dependent on the system time? Apr 9 01:33:01 rs2 /USR/SBIN/CRON[25129]: (root) CMD (/usr/local/sbin/watchdog.sh) Apr 9 01:34:01 rs2 /USR/SBIN/CRON[25136]: (root) CMD (/usr/local/sbin/watchdog.sh) Apr 9 01:35:01 rs2 /USR/SBIN/CRON[25143]: (root) CMD (/usr/local/sbin/watchdog.sh) Apr 9 10:08:28 rs2 bird: R8596x189: Error: Hold timer expired Apr 9 10:08:28 rs2 bird: R8596x189: BGP session closed Apr 9 10:08:28 rs2 bird: R8596x189: State changed to flush Apr 9 10:08:28 rs2 bird: R3330x113: Error: Hold timer expired Apr 9 10:08:28 rs2 bird: R3330x113: BGP session closed Apr 9 10:08:28 rs2 bird: R3330x113: State changed to flush Apr 9 10:08:28 rs2 bird: R1853x104: Error: Hold timer expired Wolfgang -- www.vix.at | www.aco.net wh(a)univie.ac.at | WH844-RIPE Vienna University Computer Center

4 7

BGP: Malformed attribute list
by Wolfgang Hennerbichler 09 Apr '10

09 Apr '10

Hi BIRD-Users, I just got into a situation here... I reconfigured my bird (with some new filter rules on BGP), but now some peerings don't come up anymore: bird> show protocols R8596x130 name proto table state since info R8596x130 BGP T8596x130 start 12:03 Idle Received: Malformed attribute list All I see in the logs is: Apr 8 12:04:54 rs2 bird: R8596x130: Connected to table T8596x130 Apr 8 12:04:54 rs2 bird: R8596x130: State changed to up Apr 8 12:04:54 rs2 bird: R8596x130: Received: Malformed attribute list: c00800 Apr 8 12:04:54 rs2 bird: R8596x130: BGP session closed I beg for your help! Wolfgang -- www.vix.at | www.aco.net wh(a)univie.ac.at | WH844-RIPE Vienna University Computer Center

2 5