Document toolboxDocument toolbox

About BFD (Bidirectional Forwarding Detection)

NIOS supports Anycast addressing for DNS using BGP and OSPF routing protocols. Since BGP and OSPF have timer granularity in seconds, the network re-convergence is slow in case of faults in forwarding path. BFD protocol is designed to provide faster failure detection using millisecond timer intervals. It can be enabled with routing protocols to achieve fast network re-convergence.

You can use BFD to detect failures early on and create adjacency with the next router. BFD can be enabled for OSPF or BGP and you can create BFD templates and assign it to OSPF Area or BGP neighbors. You can enable BFD simultaneously for OSPF and BGP, but only one BFD session will be created for a given neighbor. Infoblox recommends you to use the same BFD template for both OSPF and BGP neighbor whenever such a configuration is required. When BFD is enabled on anycast daemon, any failure on the named DNS service also restarts the anycast daemons. When the anycast restart behavior is 'off', the BFD restarts only when there is a configuration change.

This section provides a brief overview about enabling BFD for OSPF Area and BGP Neighbors, creating BFD templates, SNMP, and CLI commands.

Warning

The default advertised setting for BFD holddown is 300 ms (100 ms transit/receive intervals and detection multiplier 3). 
This setting is optimized for typical routers and directly connected endpoint configurations. 
If your network requires an implementation of L2 multi-path or port redundancy, you must adjust the holddown interval value higher than the spanning-tree rebalance latency 
to avoid unnecessary changes to the L3 network topology or the forwarding path for DNS traffic.

Enabling BFD for OSPF

You can enable BFD for IPv4 or IPv6 OSPF Area. To support DNS anycast and other routing-dependent applications on NIOS appliances, you must first configure the LAN1, LAN1 (VLAN), or HA (for HA pairs only) interface as an OSPF advertising interface, and then assign an area ID on the interface to associate it with a specific OSPF area. 

To enable BFD for IPv4 or IPv6 OSPF Area:

  1. From the Grid tab, select the Grid Manager tab -> Members tab -> Grid_member checkbox, and then click the Edit icon.
  2. In the Grid Member Properties editor, select the Anycast tab.
  3. In the OSPF Area Configuration table, select the OSPF advertising interface, click the Edit icon, and then complete the following:
    • Enable BFD: Select this checkbox to enable BFD for the OSPF advertising interface.
    • BFD template: Click Select BFD Template and select a BFD template from the Select BFD Template dialog box. You can click Clear to remove the selected BFD template and select a new one.
  4. Save the configuration.

When OSPF session with a neighbor router in the OSPF Area reaches FULL state, BFD session is automatically created. By default, BFD runs with no authentication and timer intervals of 100ms transmit, 100ms receive and multiplier 3 (hold down time = 300ms). The actual runtime intervals are negotiated with the peer as per BFD standard RFC 5880. If these intervals are not suitable or authentication needs to be enabled for BFD, you must create a BFD Template as described in the 26479855 section.

Figure 24.7 Enabling BFD for OSPF      

You can use the show ipv6_ospf neighbor CLI command to view runtime BFD information for OSPF.

Enabling BFD for BGP Neighbor

BFD can be enabled for each configured BGP neighbor individually. You can also use the Enable Multi-hop option, which allows BGP to connect to BGP neighbors which are more than one IP hops away.
To enable BFD for the BGP neighboring router:

  1. From the Grid tab, select the Grid Manager tab -> Members tab -> Grid_member checkbox, and then click the Edit icon.
  2. In the Grid Member Properties editor, select the Anycast tab.
  3. In the BGP Neighbor Configuration table, select the BGP neighboring router, click the Edit icon, and then complete the following:
    • Enable Multi-hop (optional): Select this checkbox to allow BGP to connect with the neighbors which are more than one IP hops away.
    • Hop Limit: Enter the maximum hop limit. The default value is 255.
    • Enable BFD: Select this checkbox to enable BFD for the BGP neighboring router.
    • BFD template: You can assign a BFD template to the BGP neighboring router to run BFD with non-default settings. Click Select BFD Template and select a BFD template from the Select BFD Template dialog box. You can click Clear to remove the selected BFD template and select a new one. For information about creating a BFD template, see 26479855.
  4. Save the configuration.

BFD session for a given BGP neighbor is created when BGP state reaches 'Established'.


Figure 24.8 Enabling BFD for BGP Neighbor

Viewing Runtime BFD Information for BGP

You can use the show bgp neighbor CLI command to view runtime BFD information for BGP.

Infoblox > show bgp neighbor

BGP neighbor is 10.34.54.16, remote AS 100, local AS 10, external link BGP version 4, remote router ID 10.40.16.16

BGP state = Established, up for 00:00:42

Using BFD to detect fast fallover in standard mode BFD last signalized state : Added

Last read 00:00:00, hold time is 16, keepalive interval is 4 seconds Neighbor capabilities:

4 Byte AS: advertised and received

Creating a BFD Template

BFD advertises the default hold-down interval of 300ms and authentication is disabled, by default. In order to configure faster or slower hold-down intervals, you can create BFD templates and assign it to the OSPF Area or BGP neighbors. You can configure a BFD template at the Grid level and assign it to multiple Grid members. The BFD template can be assigned to the BGP neighbor or OSPF Area of any Grid member in the Grid and it can be assigned to multiple BGP neighbors or OSPF Areas.
To create BFD templates:

  1. From the Grid tab -> Grid Manager tab, expand the Toolbar and click Manage BFD Templates.
  2. In the Manage BFD Templates wizard, click the Add icon, and then complete the following:
    • Name: Enter the name of the BFD template.
    • Authentication Type: Select the authentication type from the drop-down list. You can select one of the following authentication types: MD5, SHA-1, Meticulous MD5, or Meticulous SHA-1. The BFD authentication type fully conforms to RFC 5883.
    • Authentication Key ID: Enter the key identifier to use to specify the correct hash algorithm after you select the authentication type. If you do not enter a value here, the appliance by default sets 'one' as the authentication key ID. The authentication key ID configured on the Grid member must match the authentication key ID of the upstream router configuration.
    • Authentication Secret/Password: Enter the authentication password to use to verify after you select the authentication type. You can enter password with 4-16 printable ASCII characters. The authentication password configured on the Grid member must match the authentication key of the upstream router configuration.
    • Intervals: Specify the following BFD timer intervals for each router interface.
      • Min Rx Interval (ms): Enter the minimum receive interval. The default is 100ms.
      • Min Tx Interval (ms): Enter the minimum transmit interval. The default is 100ms.
      • Multiplier: Enter the detection multiplier. You can enter a value between 3 and 50. The default is 3.
  3. Click Add.

After you have added BFD templates, you can do the following:

  • Select a BFD template and click the Edit icon to edit the configuration.
  • Select a BFD template and click the Delete icon to delete it.


Figure 24.9 Manage BFD Templates
 


Figure 24.10 Manage BFD Templates Wizard

Enabling and Disabling DNS Health Check Monitor

In order to minimize downtime for DNS and ensure high availability, NIOS implements DNS process monitoring and self-recovery on each Grid member. You can enable the DNS health check monitor to monitor whether the DNS server is responding to client requests. When you enable this feature, the appliance sends a query to the DNS server and waits for the response until the specified timeout duration. If the appliance is unable to receive a response from the DNS server after the specified number of retries, the appliance sends SNMP traps and email notifications about the failure. The appliance performs the DNS health check periodically based on the specified time interval.

If BFD is used for anycast fault detection, the BFD session state advertised from the member can be in the Down state whenever there is a DNS health check failure. This allows quick anycast route tear-down and the network might converge with another DNS server that can serve same anycast IP.

Additionally, you can also configure domain names in the DNS health check monitor, which are probed simultaneously and if any one of the domains fail to resolve for consecutive attempts, the DNS health is considered as Down. If recursion is enabled on the Grid member, the queries to these domains help to assert the ability of the DNS server to reach the external authoritative servers and optionally trigger network re-convergence in case of a failure. When no domains are configured, local PTR queries are used to probe the DNS process.

Warning

The DNS Health Check monitor might not work properly if DNS blackhole feature is enabled or if any named ACL is blocking the query sent to the loopback interface.

To enable or disable the DNS health check monitor:

  1. Grid: From the Data Management tab, select the DNS tab, and then select Grid DNS Properties from the Toolbar. 
    Member: From the Data Management tab, select the DNS tab and click the Members tab -> member checkbox -> Edit icon.
    In the Grid DNS Properties or the Member DNS Properties editor, click Toggle Advanced Mode if the editor is in the basic mode.
  2. Click the Advanced subtab of the General tab and then complete the following:
    • Enable DNS Health Check: This checkbox is deselected by default, meaning the DNS health check monitor is disabled. Select this checkbox to enable the DNS health check monitor and specify the following:
    • Interval: Enter the time interval in seconds. The interval value is measured from the end of the previous monitoring cycle. The default is 30 seconds. You can enter a value between 10 and 21600 seconds.
    • Timeout: Enter the timeout value in seconds. This is the time the appliance waits for a response to the query. The default is 3 seconds. You can enter a value between 1 and 10 seconds.
    • Retries: Enter the number of times the appliance tries to send the query after a failed attempt. The default is 3. You can enter a value between 1 and 10.
    • Link BFD session state to DNS Health Check: Select this checkbox to link the BFD session state with the DNS health check monitor.
    • Resolve Additional Domains: Click the Add icon and enter the domain name. The DNS health check monitor sends recursive queries to the local DNS server (BIND/Unbound) for the domain names listed in this table. You can add up to 16 domain names.

     3. Save the configuration.

Note

  • You must carefully select the domain names for DNS health check monitor with BFD session in order to avoid unnecessary changes in downstream DNS traffic due to transient health check query failures. Setting a higher timeout or retry count might help in avoiding false alarms.
  • When you enable BFD, Infoblox recommends as a best practice that you also select the Enable DNS Health Check and the Link BFD session state to DNS Health Check checkboxes.


Figure 24.11 Enabling DNS Health Check Monitor

Monitoring with SNMP

Infoblox MIBs (IB-TRAP-MIB, IB-PLATFORMONE-MIB) are updated to include a notification for BFD process failure (ibBFDSoftwareFailure). By default, SNMP notifications are enabled for the BFD process failure event. You can enable or disable SNMP and email notifications for specific event types, by selecting the corresponding checkboxes in the Notification tab of the Grid Properties or Member Properties editor.

Figure 24.12 Grid Properties Editor
 
In addition, BFD process can generate SNMP traps for session state changes according to the standard BFD MIBs described in RFC 7330 and RFC 7331:

  • .1.3.6.1.2.1.222.0.1 (bfdSessUp): This notification (aka trap) is sent when one of the neighbors changes the BFD-session state as 'Up.'
  • .1.3.6.1.2.1.222.0.2 (bfdSessDown): This notification (aka trap) is sent when one of the neighbors changes the BFD-session state as 'Down' or 'AdminDown.'
  • .1.3.6.1.2.1.222.1.2.1.13 (bfdSessDiag): The diagnostic code which can be one of the following:
    • noDiagnostic (0)
    • controlDetectionTimeExpired (1)
    • echoFunctionFailed (2)
    • neighborSignaledSessionDown (3)
    • forwardingPlaneReset (4)
    • pathDown (5)
    • concatenatedPathDown (6)
    • administrativelyDown (7)
    • reverseConcatenatedPathDown (8)
    • misConnectivityDefect (9)

Note that you must download the following MIBs to enable the trap-receiver to parse the notifications:

  • BFD-STD-MIB
  • BFD-TC-STD-MIB
  • DIFFSERV-MIB
  • DIFFSERV-DSCP-TC
  • INTEGRATED-SERVICES-MIB
  • IANA-BFD-TC-STD-MIB