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