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 addressInterface State Since Interval Timeout
10.0.0.23 eth0 Up 2014-03-310.2000.600
Please add show bfd to context menu:
bird show ?
show interfacesShow network interfaces
show memoryShow 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 statusShow 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 CiscoJuniper - 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
