BFD implementation in 1.4.0

[Mikhail A. Grishin]

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 at msk-ix.ru>