BFD implementation in 1.4.0

[Ondrej Zajicek]

On Thu, Mar 20, 2014 at 02:14:47PM +0400, Aleksey Berezin wrote:
> Hi there!

Hello

> Firstly, sorry for my French ;)

Your French seems better than my ;-)

> Recently I tried to test BFD implementation in 1.4.0 BIRD release.

I am glad you tried the new BFD implementation, your post is perhaps
the first public response to it.



> > <Warn:BFD.RxPktInv> Received BFD an invalid packet on VLAN <vlan>
> Error:Invalid UDP src port Number
> 
> BFD session between BIRD and Extreme Networks switch can't be established.
> 
> So, src port for outgoing BFD-packet from BIRD is 39156, when RFC5881
> contains:

>   BFD Control packets MUST be transmitted in UDP packets with
>   destination port 3784, within an IPv4 or IPv6 packet.  The source
>   port MUST be in the range 49152 through 65535.


Yes, i know about this issue. I would say it is more a problem in Linux,
as IANA specifies that (universal) dynamic port range should be
49152-65535 (i am not sure where it was first specified, but it is 
at least in RFC 6056 and RFC 6335) and most other OSes already switched to
it, while Linux still uses some legacy range (32768-61000) by default.

Because of that, fixing Linux behavior by:
  sysctl -w net.ipv4.ip_local_port_range="49152 65535"
seems like a good idea.

But at least it should be mentioned in the documentation. Or produce
local warning.

> Ok, fixing (only for test purposes):
> =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> root at debian-1:~# sysctl net.ipv4.ip_local_port_range
> net.ipv4.ip_local_port_range = 32768 61000
> root at debian-1:~# sysctl -w net.ipv4.ip_local_port_range="49152 65535"
> net.ipv4.ip_local_port_range = 49152 65535
> root at debian-1:~# sysctl net.ipv4.ip_local_port_range
> net.ipv4.ip_local_port_range = 49152 65535
> =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> After this BFD session was estabilished.
> 
> Of course, net.ipv4.ip_local_port_range tuning seems to be not usable in
> production environment, and need to be fixed in BIRD, I think. Just because
> some network hardware vendors interprets RFC's exactly as written ;)

Well, the RFC does not specify that src port should be checked for
conformity on received packets ;-)

IMHO the intent of RFC 5881 is clear - use universal dynamic port range,
not some fixed port. But checking that on receiver does not make much sense.



> But now - second thing: 'protocol bfd' block in bird.conf useless. Here
> part of config:
> =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> protocol bfd FOR_OSPF {
> interface <BIRD_BOX_IP>/32 {
> interval 50 ms;
> min rx interval 50 ms;    # presence of this string by the docs does not
> matter
>  min tx interval 50 ms;    # presence of this string by the docs does not
> matter
>  multiplier 3;
> };
> neighbor <EXTREME_SW_IP> dev "<BIRD_BOX_IP>" local <BIRD_BOX_IP>;   #
> presence of this string by the docs does not matter
> };


The 'interface' option for BFD requires interface names / masks, cannot
be specified by prefix like in OSPF (see the BFD example in the
documentation). This is probably intentional, unfortunately the check in
the parser grammar (and a note in the documentation) is missing, so the
interface block was ignored and default values were used.

Also the 'neighbor' option is unnecessary in your case (i hope). OSPF
would provide all necessary information to BFD, as soon as it detects
a neighbor by hello packets.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140326/0ee0ba05/attachment-0001.asc>