Troubleshooting "Optional attribute error"
Hi, After having been down for some time, I decided to bring up an old test session (IPv6 full table). However, the session doesn't come up fully. I do see a fair amount of UPDATE packets coming in, but then at a certain point the connection gets closed and the routes purged again. All I can find in the logs is "Optional attribute error", even with "debug all all". Is there some other trick to find out what the actual problem is with this session? Regards, Ruben Laban
On Wed, Apr 27, 2011 at 05:21:21PM +0200, Ruben Laban wrote:
Hi,
After having been down for some time, I decided to bring up an old test session (IPv6 full table). However, the session doesn't come up fully. I do see a fair amount of UPDATE packets coming in, but then at a certain point the connection gets closed and the routes purged again. All I can find in the logs is "Optional attribute error", even with "debug all all". Is there some other trick to find out what the actual problem is with this session?
Could you send the exact error message and the BIRD version? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
On Friday 29 April 2011 at 00:54 (CET), Ondrej Zajicek wrote:
On Wed, Apr 27, 2011 at 05:21:21PM +0200, Ruben Laban wrote:
After having been down for some time, I decided to bring up an old test session (IPv6 full table). However, the session doesn't come up fully. I do see a fair amount of UPDATE packets coming in, but then at a certain point the connection gets closed and the routes purged again. All I can find in the logs is "Optional attribute error", even with "debug all all". Is there some other trick to find out what the actual problem is with this session?
Could you send the exact error message and the BIRD version?
Exact error message: 03-05-2011 10:49:22 <RMT> bgp1: Error: Optional attribute error BIRD version: Was 1.3.0 until this morning; after upgrading to 1.3.1 the error remains. Regards, Ruben Laban
On Tue, May 03, 2011 at 10:52:20AM +0200, Ruben Laban wrote:
On Friday 29 April 2011 at 00:54 (CET), Ondrej Zajicek wrote:
On Wed, Apr 27, 2011 at 05:21:21PM +0200, Ruben Laban wrote:
After having been down for some time, I decided to bring up an old test session (IPv6 full table). However, the session doesn't come up fully. I do see a fair amount of UPDATE packets coming in, but then at a certain point the connection gets closed and the routes purged again. All I can find in the logs is "Optional attribute error", even with "debug all all". Is there some other trick to find out what the actual problem is with this session?
Could you send the exact error message and the BIRD version?
Exact error message:
03-05-2011 10:49:22 <RMT> bgp1: Error: Optional attribute error
There are (AFAIK) only two things that may generate such error - malformed NLRI or its next hop attribute. Also NLRI of unexpected kind (like IPv4 in bird6). Perhaps the other side sends both IPv4 and IPv6 in one session? So probably the only thing how to find out the problem is to get dump of BGP traffic using tcpdump (like tcpdump -n -s 0 -w file ...) and examine that or send it to me. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
On 05/06/2011 01:50 AM, Ondrej Zajicek wrote:
There are (AFAIK) only two things that may generate such error - malformed NLRI or its next hop attribute. Also NLRI of unexpected kind (like IPv4 in bird6). Perhaps the other side sends both IPv4 and IPv6 in one session?
Just a note - we had similar issue caused by IPv6 prefix originated somewhere (we also have full BGP). In our setup, BGP communities was not filtered and additionaly, metric was set. If there was high ammount of the communities and metric was set, in this case Cisco router malformed update packet - there was empty NLRI sent out... In our case, Quagga on the remote side was failing processing malformed update and it was resetting the peer. Maybe this is similar issue (as this is expected behavior stated in RFC). Bug was confirmed by Cisco - but is not fixed yet on all platforms. Our workaround was removal of the metric statement from the route-map or striping/reducing number of the communities on the peer. This must be done on the Cisco side. Daniel
On Fri, May 06, 2011 at 08:34:07PM +0200, Daniel Suchy wrote:
On 05/06/2011 01:50 AM, Ondrej Zajicek wrote:
There are (AFAIK) only two things that may generate such error - malformed NLRI or its next hop attribute. Also NLRI of unexpected kind (like IPv4 in bird6). Perhaps the other side sends both IPv4 and IPv6 in one session?
Just a note - we had similar issue caused by IPv6 prefix originated somewhere (we also have full BGP). In our setup, BGP communities was not filtered and additionaly, metric was set. If there was high ammount of the communities and metric was set, in this case Cisco router malformed update packet - there was empty NLRI sent out...
We found that in this case it was also a problem on the other side, which send malformed packets - NLRI was smaller that needed and one prefix in it was truncated (just two bytes for /48 prefix). Unfortunately, i don't know yet type and version of the other side. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
participants (3)
-
Daniel Suchy -
Ondrej Zajicek -
Ruben Laban