BFD implementation in 1.4.0

[Aleksey Berezin]

Hi!

On Wed, Mar 26, 2014 at 4:21 AM, Ondrej Zajicek <santiago at crfreenet.org> wrote:
> On Thu, Mar 20, 2014 at 02:14:47PM +0400, Aleksey Berezin wrote:
>
>> 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.
>

Excellent work! I am very grateful for implementation.

>
>
>> > <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.
>

Heh.. I didn't dig so deeply, thanks for this info.

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

Yep. I completely agree in this case.

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

I hope it will be done ;) very useful behavior.

>>
>> 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 ;-)

As we see already - not all vendors suppose the same. =( But with IANA
port range it's really insignificantly.

>
> 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.

Agreed.

>
>> 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.

It really helps! Great THANK YOU, Ondrej. After change interface
pattern to it name in OS - all works as shall. Cool.

I hope this behavior also will be included in docs soon.

>
> 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.
>

Yep - 'neighbor' option is really unnecessary, I know. It was used
only in attempts to apply BFD config. But without any luck.