Hi! On Wed, Mar 26, 2014 at 4:21 AM, Ondrej Zajicek <santiago@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.