Bidirectional Forwarding Detection
The Oracle® Enterprise Session Border Controller (ESBC) supports Bidirectional Forwarding Detection (BFD) over network interfaces. BFD is a network protocol used to detect faults between two forwarding engines connected by a link. It provides low-overhead detection of faults, even on physical media that doesn't support failure detection of any kind, such as Ethernet, virtual circuits, tunnels and MPLS Label Switched Paths. You configure BFD for functions, including gateway path verification.
Note:
You enable BFD on the ESBC by enabling the Enterprise Advanced License in the system's entitlement configuration.BFD is a simple Hello protocol, defined by RFC 5880 and related RFCs, that uses detection mechanisms similar to routing protocols to determine the availability of configured BFD peers. BFD essentially identifies network path failure by transmitting packets periodically between the two peers, and using gaps between the reception of these packets to make the assumption that something in the bidirectional path has failed.
After configuration, each BFD peer identifies itself and sets timing preferences to validate the connection between itself and its peer and establish a BFD session. Peers then negotiate transmit intervals and 'multipliers' on an ongoing basis to fine tune their monitoring intervals, which are not symmetric. BFD peers use the exchange of BFD control packets to monitor the data path between the peers. BFD uses the "multiplier" to augment the timing intervals, which can account for traffic delays and reduce the impact of false positives. This results in network outage detection and recovery in the range of milliseconds.
The ESBC uses BFD to perform two functions:
- Gateway Health
Monitoring—The
ESBC allows the user to
configure BFD sessions with applicable gateways. When a session fails, the
ESBC reduces its health
score and raises a network interface alarm. If the session recovers, the
ESBC resets its health
score and clears the alarm. The
ESBC's HA configuration
is independent of this feature.
You configure primary and secondary sessions on the ESBC for this function.
- Triggering Virtual Address
Re-routing—The
ESBC allows the user to
configure a BFD session between the virtual address of each media interface and
that interface's gateway. The use of BFD extends beyond the layer 2 mechanism
of re-assigning a virtual address to a new physical address using, for example,
GARP. Using BFD provides for this re-assignment over layer 3 networks by
updating the BFD session at the gateway and triggering a dynamic routing update
that reconfigures network routing tables.
You configure Virtual IP (VIP) sessions on the ESBC for this function.
Using BFD on the ESBC can enable faster HA failover processes, as well as faster health score changes. Failover speed is less noticeable within back-to-back HA deployments, but it can make geographically separated (geo-redundant) HA pair deployments more effective.
Note:
The user may not use BFD in conjunction with the gw-heartbeat feature, both of which reside within the network-interface element. The ESBC displays configuration verification errors if it finds both features configured.When operating on the ESBC, significant BFD detail includes:
- Oracle's implementation of BFD on the ESBC implements certain portions of RFCs 5880, 5881, 5882 and 7419.
- The ESBC supports BFD's "Asynchronous Mode", within which both endpoints periodically send hello packets to each other. Timing mechanisms within the protocol, including minimum receive interval, define a monitoring period within which endpoints must receive traffic. If not, they take the session down. This triggers the use of backup processes.
- The
ESBC supports only the
mandatory components of a BFD control packet, including:
- Packet header fields, including "Diag", which specifies the session state.
- Session discriminator (label) used by local host
- Session discriminator (label) used by remote host
- Desired minimum TX interval
- Required minimum RX interval
- Required minimum Echo RX interval (The ESBC does not implement the echo function.)
- The ESBC does not support BFD's "Demand Mode".
- The ESBC does not support BFD's "Echo function".
- The ESBC supports BFD for both IPv4 and IPv6.
- The ESBC supports BFD over UDP transport.
- The ESBC reports the state of all BFD sessions through all reporting mechanisms.
Gateway Health Checking with BFD
The Oracle® Enterprise Session Border Controller (ESBC) allows you to configure Bidirectional Forwarding Detection (BFD) as a means of monitoring and reporting on gateway availability.
This gateway health checking feature monitors the gateway connectivity, and reduces a device's health-score when gateway connectivity is lost. For HA, you can configure it on both the active and standby node to enhance operation of OCSBCs and OCSLBs, especially when deployed in geo-redundant configurations. HA deployments use the changes to health score as a failover trigger; Standalone deployments use the feature to notify you about interface issues.
Note:
Gateway health checking is an alternate means of determining gateway connectivity. Do not use it simultaneously with the gw-heartbeat feature.This feature does not apply to:
- Gateways configured on management interfaces (e.g., wancom0)
- The default gateway for the system ( system-config, default-gateway )
- Default gateways for host routes (host-route, gateway)
- Standalone systems—Primary and secondary BFD sessions are not relevant on standalone systems.
For HA deployments, you can configure both primary and secondary session types, aligning them with the primary and secondary ESBCs as follows:
- Configure a
primary session type
for use by the primary node, which uses the
pri-utility-addr of
the
network-interface as
the local IP address.
These BFD sessions use the network-interface gateway as the remote address (i.e., the target of the BFD session).
- Configure a
secondary session
type for use by the secondary node, which uses the
sec-utility-addr of
the
network-interface as
the local IP address.
These BFD sessions use the sec-gateway of the network-interface, if configured, as the remote address (i.e., the target of the BFD session). If no sec-gateway address is configured, then a secondary session type uses the gateway address for this purpose. This assumes both the primary and secondary nodes are connected to the same gateway.
The diagram below depicts a deployment wherein the primary and secondary node use different gateways.
Session Down Alarm and Trap
The ESBC uses the same alarm and SNMP trap to notify you about session status as used for gw-heartbeat events. Upon detection of loss of connectivity to a gateway (including at system startup), the ESBC raises a GATEWAY UNREACHABLE alarm and issues an apSysMgmtGatewayUnreachableTrap trap.
Upon detection of the restoration of connectivity to a gateway after loss, the ESBC clears the GATEWAY UNREACHABLE alarm and issues an apSysMgmtGatewayUnreachableClear trap.
In an HA deployment, both the active and standby ESBCs can raise this alarm and issue these traps.
BFD Gateway Health Checking Configuration
You configure gateway health checking sessions on the network-interface. Configuration includes a bfd-config and subordinate bfd-sessions. You can configure one primary and one secondary session per interface.
network-interface
name M05
...
ip-address 172.16.84.12
pri-utility-addr 172.16.84.13
sec-utility-addr 172.16.84.15
netmask 255.255.0.0
gateway 172.16.84.1
sec-gateway 172.16.84.2
gw-heartbeat
state disabled
...
bfd-config
state enabled
health-score 30
options
bfd-session
bfd-sess-type primary
admin-state enabled
admin-session-state up
min-tx-interval 5000
min-rx-interval 5000
detect-multiplier 3
hold-down-time 0
local-discriminator 102
bfd-session
bfd-sess-type secondary
admin-state enabled
admin-session-state up
min-tx-interval 5000
min-rx-interval 5000
detect-multiplier 3
hold-down-time 0
local-discriminator 103
Note:
A VIP session type can operate simultaneously with primary and secondary sessions.Using BFD To Signal Virtual Address Re-routing
The Oracle® Enterprise Session Border Controller (ESBC) allows you to configure a BFD session (or sessions) that monitor virtual address availability. During an HA switchover, this feature provides the routing network with a means of quickly reconstituting routing tables and advertising the new route to the virtual address. You enable this feature in conjunction with the ESBC's GARP-based HA mechanism.
Using BFD, you configure VIP sessions between virtual addresses and the gateway configured on each applicable network-interface. HA synchronization makes this configuration applicable to the standby's interfaces in case of a fail-over. Upon fail-over, the ESBC migrates virtual addresses to the new active. Simultaneously, it starts new VIP sessions between the virtual address and the new gateways on the new active. The layer 3 network, using its own mechanisms, withdraws advertisements to the virtual address over the failed VIP sessions and advertises it via the new VIP sessions.
For example:
- A gateway device with an active VIP session between itself and an active ESBC may advertise the appropriate route to the virtual address, thereby provide connectivity to the active ESBC.
- When the network detects VIP session failure with the active ESBC, it may withdraw the route advertisement for the previously active node.
- When the network detects the new VIP session with the standby ESBC, it may issue new advertisements to establish the new route between the new gateway and the virtual address at the new active node.
The local and remote IP addresses for these BFD sessions hosted on the active node include:
- Local IP address: VIP (address) configured for the network interface
- Remote IP address, which
depends on the active node, as follows:
- If active is primary node: Configured gateway for the network interface (gateway)
- If active is secondary node: Secondary gateway (sec-gateway) if configured, else the configured gateway (gateway) for the network interface
Failure of a VIP session has no effect on health score.
VIP Down Alarm
If a VIP session fails, the ESBC sends out the following alarm prior to failover.
ID Task Severity First Occurred Last Occurred
327724 117 5 2017-12-13 05:31:09 2017-12-13 05:31:09
Count Description
1 1 VIP BFD session down !!!
Standalone systems support VIP sessions. When configured on a standalone, the system establishes a BFD session between the network interface address and its gateway; there are no virtual addresses on a standalone. As a result, you can use this alarm to monitor the interface status. But that is the only benefit to configuring VIP sessions on a standalone.
The ESBC does not issue traps on VIP session status.
VIP Session Configuration
You configure VIP sessions on the network-interface. Configuration includes a bfd-config and a subordinate bfd-session. You configure one VIP session per interface. A VIP session can operate simultaneously with a network-interface's gateway health check sessions.
network-interface
name M05
...
ip-address 172.16.84.100
gateway 172.16.84.1
sec-gateway 182.16.84.2
...
bfd-config
state enabled
health-score 0
options
bfd-session
bfd-sess-type vip
admin-state enabled
admin-session-state up
min-tx-interval 5000
min-rx-interval 5000
detect-multiplier 3
hold-down-time 0
local-discriminator 101
Configuring a BFD Config
The Oracle® Enterprise Session Border Controller (ESBC) allows you to perform interface- and session-specific configuration for BFD sessions.
Configuring BFD Sessions
The Oracle® Enterprise Session Border Controller (ESBC) allows you to perform interface- and session-specific configuration for Gateway Health Checking sessions.
Displaying Information on BFD Operation
The ESBC provides you with commands to display status and statistics on BFD sessions for verification, validation and troubleshooting.
The show bfd-stats command displays global status on all active BFD sessions.
ORACLE# show bfd-stats
02:52:52-75
--------- ----------- ---------- ----------------- ------
Interface Type ID Destination Logical Interface State
--------- ----------- ---------- ----------------- ------
M05:0 VIP 101 172.16.84.70 172.16.84.12 Up
M05:0 Primary 102 172.16.84.71 172.16.84.13 Up
--------- ----------- ----------- -----------------
Received packet rate (total): 12 packets/sec
Sent packet rate (total) : 11 packets/sec
--------- ----------- ----------- -------------
The table below provides descriptions of the column information output by the show bfd-stats command.
| Data | Description |
|---|---|
| Interface | The Network Interface |
| Type | Represents the BFD session type, one of primary, secondary or VIP |
| ID | The configured unique local discriminator of the session |
| Destination | Destination address of the session |
| Logical Interface | Local IP address and interface [physical interface:vlan.v4/v6] (similar to network-interface specification in realm-config) of the session |
| State | BFD session state, one of AdminDown, Down, Init, Up (as specified in RFC 5880) |
| Received packet rate (total) | The received packet rate for all BFD sessions combined |
| Sent packet rate (total) | The sent packet rate for all BFD sessions combined |
The ESBC displays global statistics on BFD traffic from the show media command.
ORACLE# show media classify 0 0
Slot 0 Port 0 Fastpath Statistics
--------- Ingress Packet Counts ------------|------Egress Packet Counts-----
IPv4 : 4120 | IPv4 : 4111
IPv6 : 0 | IPv6 : 5
UDP : 4120 | L4 : 0
TCP : 0 | ARP : 490
...
BFD v4 Packets : 0 | BFD V4 Packets : 0
BFD v4 Invalid Packets: 0 | BFD V4 Invalid Packets : 0
BFD v6 Packets : 63598 | BFD V6 Packets : 63547
BFD v6 Invalid Packets: 0 | BFD V6 Invalid Packets : 0
Media Packets : 0 |
MAC Filter Drop : 2 | SLB Success : 0
NAT Miss Drop : 2 | SLB L2 Drops : 0
Standby Drop : 0 | SLB L3 Drops : 0
...BFD-Specific Alarm
The ESBC triggers and clears a BFD-specific alarm (example below) when it detects a BFD session state change.
ID Task Severity First Occurred Last Occurred
805372204 117 4 2018-02-22 05:36:17 2018-02-22 05:36:17
Count Description
1 gateway 192.168.17.51 unreachable on slot 0 port 1 subport 300
For BFD information, set log-level to DEBUG and capture log.bfd for analysis.
- log.bfd: This log file contains process logs and message traces.
- bfd.log: This file contains internal traces between bfd process and other processes that are not call related.