BFD implementation in 1.4.0
Mikhail A. Grishin
magr at ripn.net
Wed Apr 2 15:19:06 CEST 2014
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
More information about the Bird-users
mailing list