BFD implementation in 1.4.0
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 =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I saw many messages in switch logs:
<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): =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= root@debian-1:~# sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 61000 root@debian-1:~# sysctl -w net.ipv4.ip_local_port_range="49152 65535" net.ipv4.ip_local_port_range = 49152 65535 root@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.
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@debian-1:~# sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 61000 root@debian-1:~# sysctl -w net.ipv4.ip_local_port_range="49152 65535" net.ipv4.ip_local_port_range = 49152 65535 root@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@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."
2014-03-26 4:21 GMT+04:00 Ondrej Zajicek <santiago@crfreenet.org>:
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,
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.
Hello, Ondrej Zajicek wrote, 26.03.2014 4:21:
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.
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 <magr@msk-ix.ru>
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? Mikhail A. Grishin wrote, 26.03.2014 17:09:
Hello,
Ondrej Zajicek wrote, 26.03.2014 4:21:
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.
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?
On Tue, Apr 01, 2014 at 01:14:53PM +0400, Mikhail A. Grishin wrote:
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: 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 Wed, Mar 26, 2014 at 05:09:25PM +0400, Mikhail A. Grishin wrote:
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
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.
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.
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.
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. ;-)
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: 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."
Ondrej Zajicek wrote, 01.04.2014 20:06:
On Wed, Mar 26, 2014 at 05:09:25PM +0400, Mikhail A. Grishin wrote:
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
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
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?
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.
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.
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 :)
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.
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
On Wed, Apr 02, 2014 at 05:19:06PM +0400, Mikhail A. Grishin wrote:
Ondrej Zajicek wrote, 01.04.2014 20:06:
On Wed, Mar 26, 2014 at 05:09:25PM +0400, Mikhail A. Grishin wrote:
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
Please add "show bfd" to context menu:
Thanks, i missed that.
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.
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: 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."
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. Ondrej Zajicek wrote, 02.04.2014 22:32:
On Wed, Apr 02, 2014 at 05:19:06PM +0400, Mikhail A. Grishin wrote:
Ondrej Zajicek wrote, 01.04.2014 20:06:
On Wed, Mar 26, 2014 at 05:09:25PM +0400, Mikhail A. Grishin wrote:
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
Please add "show bfd" to context menu:
Thanks, i missed that.
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.
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
-- Best regards, Mikhail A. Grishin <m.grishin@msk-ix.ru>
On Thu, Aug 28, 2014 at 03:39:32PM +0400, Mikhail A. Grishin wrote:
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.
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.
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: 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."
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. Ondrej Zajicek wrote, 02.09.2014 15:38:
On Thu, Aug 28, 2014 at 03:39:32PM +0400, Mikhail A. Grishin wrote:
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.
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.
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?
-- Best regards, Mikhail A. Grishin <m.grishin@msk-ix.ru>
On Tue, Sep 02, 2014 at 05:42:15PM +0400, Mikhail A. Grishin wrote:
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: 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 (4)
-
Aleksey Berezin -
Mikhail A. Grishin -
Ondrej Zajicek -
Vasiliy Tolstov