BFD implementation in 1.4.0

[Ondrej Zajicek]

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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140401/523ebfd0/attachment-0001.asc>