Tag Archives: BFD

Virtual Router Redundancy Protocol (VRRP) combines a group of routing devices on a LAN into a backup group that functions as a virtual router. From the host perspective in the LAN, it only needs the IP address of the virtual router rather than the IP address of a specific device in the backup group. Virtual IP address must be set as a default gateway for the host in the LAN. VRRP dynamically associates the virtual router with a physical device that transmits services. When the device fails, the second device is selected to handover traffic. The switchover should be transparent to users, allowing the internal and external networks to communicate without interruption. It, of course, depends on configured services. Most sensitive services need higher reliability and VRRP itself is not enough. But I will mention about it later in the post.

Let’s switch from theory to more practical things.

VRRP topology:

Assure communication between all elements in the network. It is omitted here.

BFD process-interface-status and process-pst are applicable only for single-hop BFD. Let’s assume that we have two routers directly connected through interface GE1/0/0.

process-interface-status

By associating BFD session status with interface status we can trigger fast route convergence. We can use this function only for BFD session that uses a default multicast IP address to detect the single-hop link. We can use association between BFD session status and interface status in the case, when transport devices exist on the link between the routers. As the actual physical path is segmented by transport devices, the routers on both ends need a long time to detect a fault that occurred on the link. The change of BFD status affects the protocol status of the interface and thus fast convergence is triggered. When the BFD session becomes DOWN, the correspondence interface status also goes to BFD_DOWN state, causing that this direct route is deleted from the routing table but the router can still forward BFD packets.

[Labnario] bfd
[Labnario-bfd] quit
[Labnario] bfd test bind peer-ip default-ip interface gigabitethernet 1/0/0
[Labnario-bfd-session-test] discriminator local 1
[Labnario-bfd-session-test] discriminator remote 2
[Labnario-bfd-session-test] process-interface-status
[Labnario-bfd-session-test] commit

BFD (Bidirectional Forwarding Detection)

What to do to quickly establish an alternative path in case of communication failure between adjacent systems?

There are two detection mechanisms:

• Hardware detection, for example alarms in SDH used to detect link faults
• Hello mechanism used by routing protocols.

The main disadvantage of hardware detection is that not all media support it. For example Ethernet does not provide this kind of signalling.

When there is no hardware signalling we can use Hello in routing protocols but this mechanism is relatively slow. Sensitive services, for example voice, cannot work with more than one second delay.

The best solution is to use BFD (Bidirectional Forwarding Detection). This is simple mechanism that works independently of media, data and routing protocols. The main goal of BFD is to detect failures in the path between adjacent devices in a short time (minimum detection time for NE40E is 30ms). It does not matter if it is physical link, virtual circuit, tunnel, MPLS LSP, multi-hop path or unidirectional link. We can treat BFD as a simple Hello protocol where a pair of devices periodically sends BFD packets between them. If one device does not receive BFD packets within specified period, the system assumes that the bidirectional path to the neighboring system has failed.