April 2010 - 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

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

RIP MD5 authentication
by jp 08 Apr '10

08 Apr '10

Hi all, I'm trying to use the RIP protocol of BIRD in MD5 authentication mode. I use bird version 1.2.1. While checking interoperability with quagga (i use for this the zeroshell distribution running quagga ripd 0.98.4) md5 authentication failed with the message: "MD5 tail signature is not there". I then used Wireshark to capture a rip response packet sent by bird and found that the MD5 authentication data trailer starts with "FFFF 0100". The same packet from quagga ripd starts with "FFFF 0001". Looking in the RFC2082, the value from quagga seems to be the right one. historically, the value "FFFF 0001" was used by bird but this was changed to "FFFF 0100" in a patch resolving "RIP authentication problem with cisco". So can someone tell me was is the right value? Following RFC2082, it seems that we should use "FFFF 0001" but i don't have cisco products and don't want to break cisco compatibility.... regards, Jean PEREIRA

2 2