The `access-list ...` command was causing bfdd to return
'unknown commands'. Make bfdd at least cognizant of
access-lists enough to not create strange error messages
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow `bfdd` to configure inexisting interfaces / VRF and only activate
them once the interface/VRF start existing. This implementation doesn't
handle dynamic VRFs yet.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Avoid all complexities of handling ethernet/IP/UDP headers and just use
UDP sockets: let the OS kernel handle this task.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Enumerate all codes, update the string representation and fix the
misdiagnosed echo failure.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Remove all VxLAN code. There are probably better ways to write VxLAN
support without having to use raw sockets and depend on extra user
configuration input.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When `bfdd` is enabled - which it is by default - re-route the PTM-BFD
messages to the FRR's internal BFD daemon instead of the external
PTM daemon.
This will help the migration of BFD implementations and avoid
duplicating code.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Implement vty shell integration and allow `bfdd` to be configured
through FRR's vtysh.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
