Configuring OSPFv2 Connectivity
You can configure your Traffic IP Groups to use RHI as the IP distribution mode, using OSPFv2 as the routing protocol. To enable RHI for your Traffic IP addresses, use the Services > Traffic IP Groups page.
The settings in System > Fault Tolerance > OSPF Route Health Injection control OSPFv2 connectivity in your Virtual Traffic Manager cluster:
- ospfv2!enabled: Whether OSPFv2 Route Health Injection is enabled.
- ospfv2!area: The OSPFv2 area in which your Virtual Traffic Manager cluster operates. You can use a decimal or IPv4 address format.
- ospfv2!area_type: The type of OSPFv2 area in which your Virtual Traffic Manager cluster operates. OSPFv2 requires all routers in a specific area to use the same type.
- ospfv2!hello_interval: The interval at which the Virtual Traffic Manager sends OSPFv2 "hello" packets to the network.
- ospfv2!router_dead_interval: The number of seconds that must elapse before the Virtual Traffic Manager declares a silent router down.
If you disable OSPFv2, or shut down the Virtual Traffic Manager, it first de-advertises Traffic IP addresses by sending out a MaxAge Link State Advertisement (LSA) to all adjacent routers.
The Virtual Traffic Manager supports the use of two separate OSPFv2 authentication key/secret pairs ("a" and "b"). This mechanism enables you to maintain authentication across your network infrastructure in the event of your needing to replace one of the key/secret pairs. When updating the authentication key in use, you can keep the old key active until the new key has been provisioned across the network.
The Virtual Traffic Manager supports OSPFv2 authentication types 0 (none) and 2 (MD5). MD5 is used when at least one active key is configured.
- ospfv2!authentication_key_id_a: The OSPFv2 authentication key ID. Set to 0 to disable the key.
- ospfv2!authentication_shared_secret_a: The OSPFv2 authentication shared secret (MD5). Set to blank to disable the key.
- ospfv2!authentication_key_id_b: The OSPFv2 authentication key ID. Set to 0 to disable the key.
- ospfv2!authentication_ shared_secret_b: The OSPFv2 authentication shared secret (MD5). Set to blank to disable the key.
If both key pairs are set to 0 (disabled), the Virtual Traffic Manager does not use OSPFv2 authentication.
The Virtual Traffic Manager does not act as a general purpose OSPFv2 router.
Configuring OSPFv2 IP Addresses
By default, each Virtual Traffic Manager in the cluster joins the OSPFv2 routing domain using the address and subnet by which it is connected to its IPv4 default gateway. To override this behavior, the Admin UI provides the means to set an alternate IPv4 address for each cluster member individually using flipper!ospfv2_ip.
The individual IP addresses you specify are used by each Virtual Traffic Manager as the next hop addresses for OSPFv2 routes that are installed on neighboring routers for traffic IPs that the Virtual Traffic Manager is advertising.
Set flipper!ospfv2_ip to "0.0.0.0" to disable the Virtual Traffic Manager's routing software.
Configuring Neighborhood Monitoring
The Virtual Traffic Manager polls the routing network every 10 seconds to collect neighborhood data. Among this data is a list of routers the Virtual Traffic Manager is peered with. For OSPF, this is known as the “neighbor list”.
To perform neighborhood monitoring, you configure each Virtual Traffic Manager in your cluster with the list of neighboring router IP addresses from which it should expect to receive traffic. This list is compared to the discovered neighbor list in order to determine the health of the routing network.
To configure the expected neighbors, type a space or comma separated list of IPv4 addresses in flipper!ospfv2_neighbor_addrs. Use the default value %gateway% to mean the default IPv4 gateway that each Virtual Traffic Manager is connected to.
To disable neighborhood monitoring for a specific Virtual Traffic Manager, set flipper!ospfv2_neighbor_addrs to an empty list.
The Virtual Traffic Manager reports a warning in the event log if some of the expected routers are not peered, and reports an error if none of the expected routers are peered. The applet in the Admin UI and the Diagnose page both reflect the status at the last poll.
Due to the latency involved in establishing peering, you might experience transient warnings or errors if you modify your OSPF configuration.