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.
The BFD protocol feature is supported in NIOS 8.0.0 and later releases. 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.
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. For more information, refer to the NIOS Administration Guide.
To enable BFD for IPv4 or IPv6 OSPF Area:
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 Creating a BFD Template 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.
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:
BFD session for a given BGP neighbor is created when BGP state reaches 'Established'.
Figure 24.8 Enabling BFD for BGP Neighbor
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
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:
After you have added BFD templates, you can do the following:
Figure 24.9 Manage BFD Templates
Figure 24.10 Manage BFD Templates Wizard
In order to minimize downtime for DNS and ensure high availability, NIOS implements DNS process monitoring and self-recovery on each Grid member, in order to minimize downtime for DNS and ensure high availability. 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:
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.
Figure 24.11 Enabling DNS Health Check Monitor
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 check boxes 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:
Note that you must download the following MIBs to enable the trap-receiver to parse the notifications:
This page has no comments.