Discussion:
BFD implementation in 1.4.0
Aleksey Berezin
2014-03-20 10:14:47 UTC
Permalink
Hi there!

Firstly, sorry for my French ;)

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

Case is "OSPF ECMP with less-second failover". On one side - Extreme
Networks switches, other side - several boxes with Debian and BIRD, of
course.

So, I find out several annoying things.

First thing: BIRD BFD implementation uses non-RFC5881 source UDP port for
outgoing packets. Here some tcpdump:
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
20:34:21.355747 <BIRD_BOX_MAC> > <EXTREME_SW_MAC>, ethertype 802.1Q
(0x8100), length 70: vlan <vlan>, p 0, ethertype IPv4, (tos 0xc0, ttl 255,
id 20806, offset 0, flags [none], proto UDP (17), length 52)
<BIRD_BOX_IP>.39156 > <EXTREME_SW_IP>.3784: BFDv1, length: 24
Control, State Init, Flags: [none], Diagnostic: No Diagnostic (0x00)
Detection Timer Multiplier: 5 (5000 ms Detection time), BFD Length: 24
My Discriminator: 0x8a82eb8a, Your Discriminator: 0x00000002
Desired min Tx Interval: 1000 ms
Required min Rx Interval: 10 ms
Required min Echo Interval: 0 ms
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<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:
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
4. Encapsulation

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

Ok, fixing (only for test purposes):
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
***@debian-1:~# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 61000
***@debian-1:~# sysctl -w net.ipv4.ip_local_port_range="49152 65535"
net.ipv4.ip_local_port_range = 49152 65535
***@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 ;)

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
};
protocol ospf OSPF1 {
...
area 0.0.0.0 {
interface <BIRD_BOX_IP>/32 {
...
bfd;
};
};
...
};
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

And what I see with tcpdump:
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
13:09:05.433336 <BIRD_BOX_MAC> > <EXTREME_SW_MAC>, ethertype 802.1Q
(0x8100), length 70: vlan <vlan>, p 0, ethertype IPv4, (tos 0xc0, ttl 255,
id 6662, offset 0, flags [none], proto UDP (17), length 52)
<BIRD_BOX_IP>.62698 > <EXTREME_SW_IP>.3784: BFDv1, length: 24
Control, State Up, Flags: [none], Diagnostic: No Diagnostic (0x00)
Detection Timer Multiplier: 5 (500 ms Detection time), BFD Length: 24
My Discriminator: 0x35e75227, Your Discriminator: 0x00000007
Desired min Tx Interval: 100 ms
Required min Rx Interval: 10 ms
Required min Echo Interval: 0 ms
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

There is no any configured intervals and multiplier. Just default values. I
think this is not correct.

Maybe I misconfigure BIRD? Please advise.

Thanks for attention.
Ondrej Zajicek
2014-03-26 00:21:52 UTC
Permalink
Post by Aleksey Berezin
Hi there!
Hello
Post by Aleksey Berezin
Firstly, sorry for my French ;)
Your French seems better than my ;-)
Post by Aleksey Berezin
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.
Post by Aleksey Berezin
<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
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.
Post by Aleksey Berezin
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
net.ipv4.ip_local_port_range = 32768 61000
net.ipv4.ip_local_port_range = 49152 65535
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.
Post by Aleksey Berezin
But now - second thing: 'protocol bfd' block in bird.conf useless. Here
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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: ***@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."
Vasiliy Tolstov
2014-03-26 03:53:42 UTC
Permalink
Post by Ondrej Zajicek
Post by Aleksey Berezin
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.
I'm second who used bfd =). I'm use it with bgp and very happy. On the
oether side i have cisco. Is about 1 week all works fine =)
--
Vasiliy Tolstov,
e-mail: ***@selfip.ru
jabber: ***@selfip.ru
Aleksey Berezin
2014-03-26 11:28:24 UTC
Permalink
Hi!
Post by Ondrej Zajicek
Post by Aleksey Berezin
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.
Post by Ondrej Zajicek
Post by Aleksey Berezin
<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
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.
Post by Ondrej Zajicek
sysctl -w net.ipv4.ip_local_port_range="49152 65535"
seems like a good idea.
Yep. I completely agree in this case.
Post by Ondrej Zajicek
But at least it should be mentioned in the documentation. Or produce
local warning.
I hope it will be done ;) very useful behavior.
Post by Ondrej Zajicek
Post by Aleksey Berezin
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.
Post by Ondrej Zajicek
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.
Post by Ondrej Zajicek
Post by Aleksey Berezin
But now - second thing: 'protocol bfd' block in bird.conf useless. Here
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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.
Post by Ondrej Zajicek
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.
Mikhail A. Grishin
2014-03-26 13:09:25 UTC
Permalink
Hello,
Post by Ondrej Zajicek
Post by Aleksey Berezin
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.
Ondrej,
We also starting to test BFD implementation.

Have some questions/suggestions.

1) How we can view via birdc the state of BFD-enabled peer in terms of
BFD state (up/down) ?

2) When BFD with some BGP peer is in Up state, how BFD-related
parameters for that peer can be viewed via birdc?
Examples for similar outputs from Cisco&Juniper - in attach.

3) We enabled BFD for some BGP peer when BGP proto was Established.
We see BFD Down packets with tcpdump, BGP remains Established.
We don't find in logs any info about BFD state for that BGP peer,
probably this is not normal.

Other side configured BFD several days later. We don't see any
information in logs about changing BFD state for that peer (from Down to
Up). Probably this is also not normal.

4) (Minor)
"bird> show protocols all bfd1" shows some Routes counters. Does that
make sense?
--
Best regards,
Mikhail A. Grishin <***@msk-ix.ru>
Mikhail A. Grishin
2014-04-01 09:14:53 UTC
Permalink
Hello again,

Today our BIRD daemon for BFD tests goes down to core.
I'll send config, log and core files to developers in separate e-mail.
There was around 5-7 BFD sessions active. We started the daemon again
with "debug protocols all;"

Also another one question , in addition to previous mail:
5) Is there any possibility to configure different BFD-timers for
different BGP-peers reachable via the same interface?
Post by Mikhail A. Grishin
Hello,
Post by Ondrej Zajicek
Post by Aleksey Berezin
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.
Ondrej,
We also starting to test BFD implementation.
Have some questions/suggestions.
1) How we can view via birdc the state of BFD-enabled peer in terms of
BFD state (up/down) ?
2) When BFD with some BGP peer is in Up state, how BFD-related
parameters for that peer can be viewed via birdc?
Examples for similar outputs from Cisco&Juniper - in attach.
3) We enabled BFD for some BGP peer when BGP proto was Established.
We see BFD Down packets with tcpdump, BGP remains Established.
We don't find in logs any info about BFD state for that BGP peer,
probably this is not normal.
Other side configured BFD several days later. We don't see any
information in logs about changing BFD state for that peer (from Down to
Up). Probably this is also not normal.
4) (Minor)
"bird> show protocols all bfd1" shows some Routes counters. Does that
make sense?
Ondrej Zajicek
2014-04-02 18:17:10 UTC
Permalink
Post by Mikhail A. Grishin
Hello again,
Today our BIRD daemon for BFD tests goes down to core.
I'll send config, log and core files to developers in separate e-mail.
There was around 5-7 BFD sessions active. We started the daemon again
with "debug protocols all;"
Fixed with attached patch
--
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: ***@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."
Ondrej Zajicek
2014-04-01 16:06:06 UTC
Permalink
Post by Mikhail A. Grishin
1) How we can view via birdc the state of BFD-enabled peer in terms of
BFD state (up/down) ?
bird> show bfd sessions
bfd1:
IP address Interface State Since Interval Timeout
10.0.0.23 eth0 Up 2014-03-31 0.200 0.600
Post by Mikhail A. Grishin
2) When BFD with some BGP peer is in Up state, how BFD-related
parameters for that peer can be viewed via birdc?
Examples for similar outputs from Cisco&Juniper - in attach.
Currently not available, but 'show bfd sessions' shows almost all
relevant info anyways.
Post by Mikhail A. Grishin
3) We enabled BFD for some BGP peer when BGP proto was Established.
We see BFD Down packets with tcpdump, BGP remains Established.
We don't find in logs any info about BFD state for that BGP peer,
probably this is not normal.
That is expected. Only a BFD transition from Up to Down is supposed to
shutdown the BGP or OSPF session, while general unavailability of BFD
(or permanent AdminDown state) on the neighbor is not an obstacle for
BGP or OSPF. See RFC 5882 for details.
Post by Mikhail A. Grishin
Other side configured BFD several days later. We don't see any
information in logs about changing BFD state for that peer (from Down to
Up). Probably this is also not normal.
You must enable 'debug { events }' in BFD for logging Up/Down events,
similarly to BGP.
Post by Mikhail A. Grishin
4) (Minor)
"bird> show protocols all bfd1" shows some Routes counters. Does that
make sense?
Well, no. Note that it also does not make sense for 'device' protocol,
but nobody ever complained about that. ;-)
Post by Mikhail A. Grishin
5) Is there any possibility to configure different BFD-timers for
different BGP-peers reachable via the same interface?
Not currently. I hesitated between putting BFD parameters to a BFD
interface block in the BFD protocol (as done) and to a BFD request block
in client protocols:

protocol bgp {
bfd {
...
};
}

I chose the first approach, but perhaps it is a good idea to support
both approachs.
--
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: ***@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."
Ondrej Zajicek
2014-04-02 18:32:58 UTC
Permalink
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
1) How we can view via birdc the state of BFD-enabled peer in terms of
BFD state (up/down) ?
bird> show bfd sessions
IP address Interface State Since Interval Timeout
10.0.0.23 eth0 Up 2014-03-31 0.200 0.600
Thanks, i missed that.
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
2) When BFD with some BGP peer is in Up state, how BFD-related
parameters for that peer can be viewed via birdc?
Examples for similar outputs from Cisco&Juniper - in attach.
Currently not available, but 'show bfd sessions' shows almost all
relevant info anyways.
OK, thanks. Any plans to improve?
Probably.
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
4) (Minor)
"bird> show protocols all bfd1" shows some Routes counters. Does that
make sense?
Well, no. Note that it also does not make sense for 'device' protocol,
but nobody ever complained about that. ;-)
kernel and direct protocols output doesn't show Routes counters :)
Yes if they are up:

bird> show protocols all
name proto table state since info
device1 Device master up 13:08:02
Preference: 240
Input filter: ACCEPT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0

direct1 Direct master up 13:08:02
Preference: 240
Input filter: ACCEPT
Output filter: REJECT
Routes: 5 imported, 0 exported, 5 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 5 0 0 0 5
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0

kernel1 Kernel master up 13:08:02
Preference: 10
Input filter: ACCEPT
Output filter: (unnamed)
Routes: 0 imported, 8 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 20 10 0 --- 10
Export withdraws: 2 --- --- --- 2

bfd1 BFD master up 13:08:02
Preference: 0
Input filter: ACCEPT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0
--
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: ***@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."
Mikhail A. Grishin
2014-08-28 11:39:32 UTC
Permalink
Hi,

Wanted to share some results.

At version 1.4.2 we see solid uptime for BFD sessions.

This output collected at 15August:
bird> show bfd sessions
bfd1:
IP address Interface State Since Interval Timeout
193.232.245.134 bce1 Down 2014-06-09 11:17:23
1.000 0.000
193.232.244.207 bce1 Up 2014-06-09 11:17:24
1.000 5.000
193.232.245.54 bce1 Up 2014-06-09 11:17:24
1.000 5.000
193.232.244.80 bce1 Up 2014-06-13 15:24:28
1.000 5.000
193.232.245.198 bce1 Up 2014-06-23 10:37:03
1.000 5.000
193.232.244.88 bce1 Up 2014-07-30 14:33:23
1.000 5.000
193.232.245.184 bce1 Up 2014-06-09 11:17:24
1.000 5.000
193.232.245.133 bce1 Up 2014-06-17 16:02:02
1.000 5.000
bird>

This is sessions with real customers, real routers which pass traffic in
production environment controlled by different companies. This sessions
was established with our test box (no prefixes announced via BGP, no
reconfiguration changes).

Then we tried to migrate this BFD sessions to our production route
servers and faced with issues related to our network infrastructure. We
have two separate IP networks at the same VLAN. Each customer has 2
peering IP: from the first IP subnet, and from the second. One IP
assigned as primary, another as secondary at the same interface on
customer side.

Problem:
Routers of our customers able to communicate in terms of BFD only with
Route Server located in the same IP subnet with primary IP address on
their interface. With the Route Server in another IP subnet they can't
communicate in terms of BFD because SRC IP address for BFD packets is
wrong, equal to primary IP, not secondary.

This issue seen for Cisco, Juniper. Some platforms allow to redefine IP
address for BFD communication, but as far as we see, nobody could
communicate via BFD in both IP subnets at the same time.
Post by Ondrej Zajicek
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
1) How we can view via birdc the state of BFD-enabled peer in terms of
BFD state (up/down) ?
bird> show bfd sessions
IP address Interface State Since Interval Timeout
10.0.0.23 eth0 Up 2014-03-31 0.200 0.600
Thanks, i missed that.
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
2) When BFD with some BGP peer is in Up state, how BFD-related
parameters for that peer can be viewed via birdc?
Examples for similar outputs from Cisco&Juniper - in attach.
Currently not available, but 'show bfd sessions' shows almost all
relevant info anyways.
OK, thanks. Any plans to improve?
Probably.
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
4) (Minor)
"bird> show protocols all bfd1" shows some Routes counters. Does that
make sense?
Well, no. Note that it also does not make sense for 'device' protocol,
but nobody ever complained about that. ;-)
kernel and direct protocols output doesn't show Routes counters :)
bird> show protocols all
name proto table state since info
device1 Device master up 13:08:02
Preference: 240
Input filter: ACCEPT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0
direct1 Direct master up 13:08:02
Preference: 240
Input filter: ACCEPT
Output filter: REJECT
Routes: 5 imported, 0 exported, 5 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 5 0 0 0 5
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0
kernel1 Kernel master up 13:08:02
Preference: 10
Input filter: ACCEPT
Output filter: (unnamed)
Routes: 0 imported, 8 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 20 10 0 --- 10
Export withdraws: 2 --- --- --- 2
bfd1 BFD master up 13:08:02
Preference: 0
Input filter: ACCEPT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0
--
Best regards,
Mikhail A. Grishin <***@msk-ix.ru>
Ondrej Zajicek
2014-09-02 11:38:57 UTC
Permalink
Hi,
...
Then we tried to migrate this BFD sessions to our production route servers
and faced with issues related to our network infrastructure. We have two
separate IP networks at the same VLAN. Each customer has 2 peering IP: from
the first IP subnet, and from the second. One IP assigned as primary,
another as secondary at the same interface on customer side.
Routers of our customers able to communicate in terms of BFD only with Route
Server located in the same IP subnet with primary IP address on their
interface. With the Route Server in another IP subnet they can't communicate
in terms of BFD because SRC IP address for BFD packets is wrong, equal to
primary IP, not secondary.
Hi

This should work automatically - BFD should use same src, dst IP
addresses as associated BGP session (assuming that BFD session was
requested by BGP and not explicitly configured using 'neighbor' in BFD
protcol).

There are several possible ways how it could be broken, so i need
some info:

1) What is BIRD version and OS (Linux/BSD)?

2) What local IP addresses are reported for BGP sessions?
('Source address' in 'show protocols all')
Correct one or bad one?

3) Is BGP source address explicitly configured in BGP protocol?
('local IP as NUM' instead of 'local as NUM')
If not, could you try to set it and see if anything changes?
--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: ***@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."
Mikhail A. Grishin
2014-09-02 13:42:15 UTC
Permalink
Ondrej,

Looks like you misunderstood me.
This is broken not from the BIRD. This is broken from Cisco/Juniper -
such devices inserts wrong SRC IP in BFD packets.

Do you still need info that you requested?

P.S. Later we found that in older JunOS problem is present, but in newer
versions of JunOS all is fine. Regarding Cisco some of our customers
keep trying to open case at Cisco TAC.
Post by Ondrej Zajicek
Hi,
...
Then we tried to migrate this BFD sessions to our production route servers
and faced with issues related to our network infrastructure. We have two
separate IP networks at the same VLAN. Each customer has 2 peering IP: from
the first IP subnet, and from the second. One IP assigned as primary,
another as secondary at the same interface on customer side.
Routers of our customers able to communicate in terms of BFD only with Route
Server located in the same IP subnet with primary IP address on their
interface. With the Route Server in another IP subnet they can't communicate
in terms of BFD because SRC IP address for BFD packets is wrong, equal to
primary IP, not secondary.
Hi
This should work automatically - BFD should use same src, dst IP
addresses as associated BGP session (assuming that BFD session was
requested by BGP and not explicitly configured using 'neighbor' in BFD
protcol).
There are several possible ways how it could be broken, so i need
1) What is BIRD version and OS (Linux/BSD)?
2) What local IP addresses are reported for BGP sessions?
('Source address' in 'show protocols all')
Correct one or bad one?
3) Is BGP source address explicitly configured in BGP protocol?
('local IP as NUM' instead of 'local as NUM')
If not, could you try to set it and see if anything changes?
--
Best regards,
Mikhail A. Grishin <***@msk-ix.ru>
Ondrej Zajicek
2014-09-02 15:28:04 UTC
Permalink
Post by Mikhail A. Grishin
Ondrej,
Looks like you misunderstood me.
This is broken not from the BIRD. This is broken from Cisco/Juniper - such
devices inserts wrong SRC IP in BFD packets.
Do you still need info that you requested?
Yes, i misunderstood. In that case i don't need the info.
--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: ***@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."
Mikhail A. Grishin
2014-04-02 13:19:06 UTC
Permalink
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
1) How we can view via birdc the state of BFD-enabled peer in terms of
BFD state (up/down) ?
bird> show bfd sessions
IP address Interface State Since Interval Timeout
10.0.0.23 eth0 Up 2014-03-31 0.200 0.600
Please add "show bfd" to context menu:
bird> show ?
show interfaces Show network interfaces
show memory Show memory usage
show ospf ... Show information about
OSPF protocol
show protocols [<protocol> | "<pattern>"] Show routing protocols
show roa ... Show ROA table
show route ... Show routing table
show static [<name>] Show details of static
protocol
show status Show router status
show symbols ... Show all known symbolic names
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
2) When BFD with some BGP peer is in Up state, how BFD-related
parameters for that peer can be viewed via birdc?
Examples for similar outputs from Cisco&Juniper - in attach.
Currently not available, but 'show bfd sessions' shows almost all
relevant info anyways.
OK, thanks. Any plans to improve?
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
3) We enabled BFD for some BGP peer when BGP proto was Established.
We see BFD Down packets with tcpdump, BGP remains Established.
We don't find in logs any info about BFD state for that BGP peer,
probably this is not normal.
That is expected. Only a BFD transition from Up to Down is supposed to
shutdown the BGP or OSPF session, while general unavailability of BFD
(or permanent AdminDown state) on the neighbor is not an obstacle for
BGP or OSPF. See RFC 5882 for details.
Post by Mikhail A. Grishin
Other side configured BFD several days later. We don't see any
information in logs about changing BFD state for that peer (from Down to
Up). Probably this is also not normal.
You must enable 'debug { events }' in BFD for logging Up/Down events,
similarly to BGP.
Already did this.
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
4) (Minor)
"bird> show protocols all bfd1" shows some Routes counters. Does that
make sense?
Well, no. Note that it also does not make sense for 'device' protocol,
but nobody ever complained about that. ;-)
kernel and direct protocols output doesn't show Routes counters :)
Post by Ondrej Zajicek
Post by Mikhail A. Grishin
5) Is there any possibility to configure different BFD-timers for
different BGP-peers reachable via the same interface?
Not currently. I hesitated between putting BFD parameters to a BFD
interface block in the BFD protocol (as done) and to a BFD request block
protocol bgp {
bfd {
...
};
}
I chose the first approach, but perhaps it is a good idea to support
both approachs.
May be yes, both approaches is good.
Our tests not show yet that this is requirement for us, but we see
questions from customers about different sets of timers.

P.S. One of customers shows :
http://tools.ietf.org/html/draft-ietf-bfd-intervals-00
Loading...