IP routing is a set of protocols that determine the path IP packets follow in order to travel across multiple networks from the source to the destination. When information travels through a series of routers and across multiple networks, IP routing protocols enable the routers to build up a forwarding table that correlates the final destination with the next upstream routers.
For routing purposes, the internet is divided into ASs (Autonomous Systems). Data is routed within an AS using an IGP (Interior Gateway Protocol) and routed between different ASs using an EGP (Exterior Gateway Protocol). NIOS appliances support OSPFv2 (for IPv4) and OSPFv3 (for IPv6) for a routing IGP, and BGP4 to advertise DNS anycast addresses in the larger internetwork.
As noted in the section Configuring Anycast Addresses, you configure OSPF or BGP4 to advertise anycast addresses, which configured on the loopback interface of NIOS appliances. Use of either protocol depends on the network topology, based on whether the advertisements will propagate only within a single AS or between more than one AS. 22282467 shows a simplified example.

Figure 24.3 OSPF and BGP Routing Example

Within each AS, OSPF is the protocol used to forward anycast advertisements. Between ASs, BGP is the protocol selected to advertise anycast addresses. Using this technique, DNS servers in diverse locations can operate together to ensure continuous service.

About OSPF

OSPF is a link-state protocol based on the Dijkstra algorithm used to calculate the shortest path to a destination address within an internetwork. This protocol uses a link-state database created using routing information advertised from neighbors and peers, each with costs based on the state of that link to the destination.
OSPF network topologies consist of administrative domains called OSPF areas. An area is a logical collection of OSPF routers, servers and other network devices that have the same area identifier. A router within an area keeps an OSPF database for its OSPF area only, reducing the size of the database that is maintained.

Anycast and OSPF

NIOS appliances can use the OSPF routing protocol to advertise routes for DNS anycast addresses to an upstream router within the autonomous system. The upstream router uses the OSPF advertisement to determine the nearest DNS server from a group of servers within the internetwork. In practice, the NIOS appliance relies upon OSPF to determine the best route for DNS queries to take to the nearest DNS server. The upstream router then forwards the query to the chosen DNS server.
As illustrated in 22282467, to enable anycast for DNS queries, you configure two or more DNS servers within the AS routing domain with the same anycast address on their loopback interfaces. When you select OSPF as the routing protocol, the upstream router determines the nearest server within the group of servers configured with that anycast address. (The "nearest" DNS server may not necessarily be the geographically closest DNS server; it is the DNS server with the lowest cost associated with its reachability from the current node. This is calculated through the OSPF routing algorithm, a discussion of which is far beyond the scope of this manual.) The nearest DNS server configured with the correct anycast address then responds to the DNS query. In the case where the nearest server becomes unavailable, the next nearest server responds to the query. OSPF anycast provides a dynamically routed failover to ensure that DNS can always resolve client requests within the AS. From the client perspective, anycasting is transparent and the group of DNS servers with the anycast address appears to be a single DNS server.

Figure 24.4 Anycast Addressing for DNS Using OSPF

After you configure or change DNS anycast settings, you must restart the DNS services for the settings to take effect. When you enter any OSPF command and wait for the interface to return more information, the appliance disconnects your CLI session after you restart services or make other OSPF configuration changes through Grid Manager. Re-enter your credentials to log back in to the CLI. (For information, refer to the Infoblox CLI Guide.)
To enable the appliance to support OSPF and advertising anycast addresses on OSPF from the loopback, you must first configure the LAN1 or LAN1 (VLAN) interface as an OSPF advertising interface. For information about VLAN, see About Virtual LANs.
You can also configure authentication for OSPF advertisements to ensure that the routing information received from a neighbor is authentic and the reachability information is accurate. This process can be implemented for OSPF over IPv4 networks but is not supported for IPv6/OSPFv3. For information, see 22282467.

Note: For more information about the OSPF routing protocol, refer to RFC 2328 "OSPFv2" and RFC 5340 "OSPF for IPv6".

Configuring OSPF on the NIOS Appliance

Note: Use the CLI command show ospf or show ipv6_ospf to display configuration and statistical information about the OSPF protocol running on the appliance. You can also use the set ospf or set ipv6_ospf command to write OSPF statistical information to the syslog. In the NIOS appliance, configuration of OSPF is limited to Syslog and the DNS anycast application.

To support DNS anycast and other routing-dependent applications on NIOS appliances, you must first configure the LAN1 or LAN1 (VLAN) interface as an OSPF advertising interface, and then assign an area ID on the interface to associate it with a specific OSPF area. The interface advertises the OSPF routing information to the network so that routers can determine the best server to query. Note that the appliance automatically uses the HA interface as the advertising interface for an HA pair, even though you select the LAN1 interface. For anycasting, the advertising interface sends out routing advertisements about the anycast address into the network out to upstream routers.

Note: IPv6 is not supported for the Stub and Not-so-stubby area types.

To configure the LAN1 (HA) or LAN1(VLAN) interface to be an OSPF advertising interface, perform the following tasks:

From the Grid tab, select the Grid Manager tab -> Members tab -> Grid_member check box, and then click the Edit icon.
Select the Anycast tab in the Grid Member Properties editor.
The Anycast Interfaces appear in a table. You can add new anycast interfaces when needed.
Click the Add icon of the OSPF Area Configuration table and choose IPv4 Configuration or IPv6 Configuration to define a new OSPF Area. The OSPF Area Configuration will show a similar set of Add (IPv4/IPv6) OSPF Area configuration settings based on the protocol type. Enter the following information to configure the LAN1, or LAN1 (VLAN) as the OSPF advertising interface:
- Advertising Interface: Displays the interface that sends out OSPF routing advertisement. OSPF advertisements are supported on the LAN1 and LAN1(VLAN) interfaces. For an HA pair, select LAN1 and the appliance automatically uses the HA interface as the advertising interface.
- Area ID: Enter the OSPF area identifier of the network containing the upstream routers, in either an IP address format or a decimal format. All network devices configured with the same OSPF area ID belong to the same OSPF area. The area ID configured on the Grid member must match the area ID of the upstream router configuration. Area ID numbers are defined in the same format for IPv6 and IPv4.
- Area Type: Select the type of OSPF area to associate with the advertising interface from the drop-down list. The area type configured on the Grid member must match the area type of the upstream router configuration. The supported area types are described as follows:
  - Standard: A standard area has no restrictions on routing advertisements, and connects to the backbone area (Area 0) and accepts both internal and external link-state advertisements.
  - Stub: A stub area is an area that does not receive external routes.
  - Not-so-stubby: A not-so-stubby area (NSSA) imports autonomous system (AS) external routes and sends them to the backbone, but cannot receive AS external routes from the backbone or other areas.

Note: OSPF for IPv6 (known as OSPFv3) configuration does not support OSPF authentication options.

AuthenticationType: Select the authentication method to use to verify OSPF routing advertisements on the interface. The authentication type configured on the Grid member must match the authentication type of the upstream router configuration. The supported authentication types are described as follows:
- None: No authentication for OSPF advertisement.
- Simple: A simple password for OSPF advertisement authentication, in clear text.
- MD5: An MD5 hash algorithm to authenticate OSPF advertisements. This is the most secure option.
- Authentication Key ID: Enter the key identifier to use to specify the correct hash algorithm after you select MD as your OSPF authentication type. The authentication key ID configured on the Grid member must match the authentication key ID of the upstream router configuration.
- Authentication Key: Enter the authentication password to use to verify OSPF advertisements after you select Simple or MD as your OSPF authentication type. Specify a key string between 1 to 8 characters for Simple authentication, and a string between 1 to 16 characters for MD5 authentication. The authentication key configured on the Grid member must match the authentication key of the upstream router configuration.
- Cost: Select one of the following:
  - Calculate Automatically: Select this check box to auto generate the cost to associate with the advertising OSPF interface to the appliance. If this check box is not selected, then you specify the cost value explicitly. Calculate the cost as 100,000,000 (reference bandwidth) divided by the interface bandwidth. For example, a 100Mb interface has a cost of 1, and a 10Mb interface has a cost of 10.
  - Fixed Metric: Enter the cost to associate with the advertising OSPF interface to the appliance.
- Hello Interval: Specify how often to send OSPF hello advertisements out from the appliance interface, in seconds. Specify any number from 1 through 65,535. The default value is 10 seconds. The hello interval configured on the Grid member must match the hello interval of the upstream router configuration.
- Dead Interval: Specify how long to wait before declaring that the NIOS appliance is unavailable and down, in seconds. Specify any number from 1 through 65,535. The default value is 40 seconds. The dead interval configured on the Grid member must match the dead interval of the upstream router configuration.
- Retransmit Interval: Specify how long to wait before retransmitting OSPF advertisements from the interface, in seconds. Specify any number from 1 through 65,535. The default value is 5 seconds. The retransmit interval configured on the Grid member must match the retransmit interval of the upstream router configuration.
- Transmit Delay: Specify how long to wait before sending an advertisement from the interface, in seconds. Specify any number from 1 through 65,535. The default value is 1 second. The transmit interval configured on the Grid member must match the transmit interval of the upstream router configuration.
- Click Add to add the interface to the table.

The Cost, Hello Interval, Dead Interval, Retransmit Interval and Transmit Delay settings can be configured for IPv6 deployments. OPSF authentication is not supported for IPv6 on the NIOS platform.

4. Save the configuration and click Restart if it appears at the top of the screen.

Managing OSPF

OSPF advertises the route when the DNS service starts. The start DNS command creates an interface and starts the OSPF daemon.
OSPF stops advertising the route when the DNS service stops. The stop DNS command stops the OSPF daemon and deletes the interface.
The NIOS application does not support a route flap. For example, temporary DNS downtime such as restart, does not stop or re-instate the OSPF advertisement.
The OSPF advertisement stops if DNS service is down for more than 40 seconds.

Anycast and BGP4

Note: Use the CLI command show bgp or show ipv6_bgp to display configuration and statistical information about the Border Gateway Protocol running on the appliance. You can also use the set bgp command to write OSPF statistical information to the syslog. In the NIOS appliance, configuration of BGP is limited to Syslog and the DNS anycast application.

BGP4 (henceforth referred to as BGP) is designed to distribute routing information among ASs and exchange routing and reachability information with other BGP systems using a destination-based forwarding paradigm. Unlike OSPF, which calculates routes within a single AS, BGP is a vector routing protocol that distributes routing information among different ASs. A unique ASN (autonomous system number) is allocated to each AS to identify the individual network in BGP routing. A BGP session between two BGP peers is an eBGP (external BGP) session if the BGP peers are in different ASs. A BGP session between two BGP peers is an iBGP (internal BGP) session if the BGP peers are in the same AS.
BGP configuration enables large enterprises using BGP as the internetworking protocol to provide resilient DNS services using the Infoblox solution. While BGP is mostly used by ISPs, it is also used in larger enterprise environments that must interconnect networks that span geographical and administrative boundaries. In these environments, it is required to use BGP to advertise anycast routes. Using BGP allows the appliance to advertise DNS anycast addresses to neighboring routers across multiple ASs that also use BGP as their routing protocols.
As illustrated in 22282467, to enable anycast for DNS queries among three different networks that span different geographical regions, you can configure two DNS servers with the same DNS anycast addresses in the AS 65497 network. Since other network routers in AS 65498 and AS 65499 also use BGP as the routing protocol, the DNS anycast addresses can be advertised across these networks.
Figure 24.5 Anycast Addressing for DNS using BGP

To enable DNS anycast addressing across different ASs, you configure BGP as the routing protocol on the NIOS appliance. (As illustrated in 22282467, the AS 65497 network contains the Infoblox DNS anycast servers, and the AS 65499 network contains Router 1 and 2. The routers use BGP and are peered with the DNS servers. You can configure anycast addressing on the loopback interface of the DNS servers and select BGP as the protocol to advertise the anycast addresses to Router 1 and 2 in AS 65499. For information, see Configuring Anycast Addresses. Once you have configured the DNS servers, the appliances automatically add filters on the advertising interfaces to limit the advertisements to the configured anycast IP addresses. Similarly, BGP filters are applied to ensure that the DNS servers only receive default route advertisements from the neighboring routers.

Figure 24.6 Anycast and BGP Configuration on Infoblox Appliances

BGP uses timers to determine how often the appliance sends keepalive and update messages, and when to declare a neighboring router out of service. You can configure the time intervals for these timers. For information, see 22282467.
The BGP protocol service is automatically configured to send SNMP queries about BGP runtime data. The appliance sends SNMP traps to its neighboring routers when it encounters issues with the protocol. BGP is configured to send SNMP traps as defined in RFC4273 Definitions of Managed Objects for BGP-4. You must enable and configure the SNMP trap receiver on the Grid member for the member to send SNMP traps. For information, see SNMP MIB Hierarchy SNMP MIB Hierarchy.
You can use the set bgp command to set the verbosity levels of the BGP routing service. The appliance writes BGP statistical information to the syslog. After you configure the settings, you must restart the DNS services for the settings to take effect. For information, refer to the Infoblox CLI Guide. Note that when you enter any BGP command and wait for the interface to return more information, the appliance disconnects your CLI session if you restart services or make other BGP configuration changes through Grid Manager. You must re-enter your credentials to log back in to the CLI.
You can configure BGP on any interface to advertise anycast addresses across multiple ASs.

Note: NIOS selects the interface for BGP advertisement based on the routing configuration.

The appliance supports BGP version 4. For more information about BGP, refer to RFC4271, A Border Gateway Protocol 4 (BGP-4).

Configuring BGP in the NIOS Appliance

You can configure the appliance as a BGP advertising interface for anycast addresses. The NIOS appliance advertises the BGP routing information to the network so routers can determine the nearest server to query. The NIOS appliance does not perform dynamic routing itself; it can use dynamic routing protocols to advertise its DNS anycast availability. You must define the ASN of the interface and list any neighboring routers that will receive the BGP announcements. On an HA pair, BGP runs only on the active node. In an HA failover, the BGP service resumes on the new active node.

Note: If you encounter Malformed AS_PATH error, then remove the dont-capability-negotiate option. Infoblox doesn't provide an option to create confederation of autonomous systems if the BGP peer is configured by enabling the dont-capability-negotiate option.

Authenticating BGP Neighbors

You can configure authentication for BGP advertisements to avoid any malicious interference by ASs. This ensures that the routing information exchanged between BGP peers is authentic, and it is accepted only if the authentication is successful. BGP authentication must be configured with the same password on both BGP peers. Otherwise, the connection between them is not established. The Infoblox BGP authentication fully conforms to RFC 2385. For information about BGP authentication, refer to RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option.

Note: If you upgrade from a previous NIOS version to NIOS 6.11.0 or later, BGP authentication is disabled for existing BGP neighbors.

The BGP service restarts automatically when any of the following authentication changes are made:

MD5 authentication is enabled or disabled for a BGP neighbor.
Change the authentication password of a BGP neighbor, for which MD5 authentication is enabled.

To configure BGP for anycast addresses:

From the Grid tab, select the Grid Manager tab -> Members tab -> Grid_member check box, and then click the Edit icon.
In the Grid Member Properties editor, select the Anycast tab.
In the BGP Configuration section, complete the following:
- Interface Link Detection: Select this check box to enable link detection when the default connection fails. This enables the router to track the next available route. For example, if LAN1 is set as the default gateway when both LAN1 and LAN2 are working, and LAN1 later fails, the router will switch to LAN2. When LAN1 reconnects, the router will then switch back to LAN1.
- ASN: Enter the autonomous system number of the interface. Enter a number from 1 to 65535. You can configure only one ASN on each Grid member.
- BGP Timers: BGP uses timers to control how often the interface sends KEEPALIVE messages and how long it waits before declaring a neighboring router out of service. The keepalive timer determines the time interval at which the interface sends KEEPALIVE messages to a neighboring router to inform the neighbor that the appliance is alive. The hold down timer determines how long the interface waits to hear a KEEPALIVE or UPDATE message before it assumes its neighbor is out of service. If a neighboring router is down, the interface terminates the BGP session and withdraws all the BGP routing information to the neighbor.
  - Keep Alive: Enter the time interval in seconds when the interface sends keepalive messages. You can enter a time from 1 to 21845 seconds. The default is four seconds.
  - Hold Down: Enter the time in seconds that the interface waits to hear a keepalive message from its neighbor before declaring the neighbor out of service. You can enter a time from 3 to 65535 seconds. The default is 16 seconds.

Click the Add icon to add a neighboring router to receive BGP advertisements from the NIOS appliance. The appliance adds a new row to the table. Complete the following:

Neighbor Router IP: Enter the IP address (IPv4 or IPv6) of the neighboring BGP router. The neighboring router can be within the same AS (the most likely case) or from a router in an external AS.
Remote ASN: Enter the ASN of the neighboring router. You can enter an ASN number from 1 to 65535.
MD5 Authentication: Select this check box to enable MD5 authentication for the BGP neighbor. When you enable MD5 authentication, you must enter the authentication password in the Password field.
Password: Enter the authentication password that the NIOS appliance uses to connect to the BGP neighbor.You can enter up to 80 printable ASCII characters. The password configured on the Grid member must match the password of the BGP neighbor.

Note: When you enter the password for a BGP neighbor, it will be preserved even if you disable MD5 authentication for the BGP neighbor later. But if you change the IP address for any existing BGP neighbor, you must re-enter the authentication password for the BGP neighbor, even if the authentication password remains the same.

Comment: Enter useful information about this neighboring router.

Click the Add icon again to add another neighboring router. You can add up to 10 neighboring routers.