|
|
|
Routers called Area Border Routers (ABR) have interfaces to multiple areas. ABRs compact the topological information for an area and transmit it to the backbone area. Check Point supports the implementation of ABR behavior as outlined in the Internet draft of the Internet Engineering Task Force (IETF). The definition of an ABR in the OSPF specification as outlined in RFC 2328 does not require a router with multiple attached areas to have a backbone connection. However, under this definition, any traffic destined for areas that are not connected to an ABR or that are outside the OSPF domain is dropped. According to the Internet draft, a router is considered to be an ABR if it has more than one area actively attached and one of them is the backbone area. An area is considered actively attached if the router has at least one interface in that area that is not down.
Rather than redefine an ABR, the Check Point implementation includes in its routing calculation summary LSAs from all actively attached areas if the ABR does not have an active backbone connection, which means that the backbone is actively attached and includes at least one fully adjacent neighbor. You do not need to configure this feature; it functions automatically under certain topographies.
OSPF uses the following types of routes:
All routers on a link must agree on the configuration parameters of the link. All routers in an area must agree on the configuration parameters of the area. A separate copy of the SPF algorithm is run for each area. Misconfigurations prevent adjacencies from forming between neighbors, and routing black holes or loops can form.
Gaia supports the OSPF protocol in clusters configured either via VRRP or ClusterXL.
In this configuration, the cluster becomes a Virtual Router. The neighbor routers see it as a single router, where the virtual IP address of the cluster becomes the router ID. Each member of the cluster runs the OSPF process, but only the master actively exchanges routing information with the neighbor routers. When a failover occurs, a standby member of the cluster becomes the master and begins exchanging routing information with the neighbor routers.
Gaia also supports the OSPF protocol over VPN tunnels which terminate in the VRRP or ClusterXL cluster.
VRRP
Gaia supports advertising of the virtual IP address of the VRRP Virtual Router instead of the actual interface IP address. If you enable this option, but do not enable Graceful Restart, OSPF runs only on the master of the Virtual Router. During a failover, a traffic break may occur, while the new VRRP master becomes active and learns the OSPF routes. This happens because the OSPF route database exists only on the master and is not synchronized on all members of the cluster. The larger the network, the more time it takes OSPF to synchronize its database and install routes again.
To avoid traffic loss during failovers, you can configure Graceful Restart. In this case, the master synchronizes the route table with the VRRP backup member. If the master fails, the backup member takes on a role of the new master, sends grace-LSAs to the OSPF neighbors, and establishes adjacencies with them. The new master keeps the kernel routes that were installed before the failover until it establishing full adjacency with the neighbors.
|
Note - You must use monitored-circuit VRRP, not VRRP v2, when configuring virtual IP support for OSPF or any other dynamic routing protocol. |
|---|
ClusterXL
Gaia ClusterXL advertises the virtual IP address of the ClusterXL Virtual Router. The OSPF routes database of the master is synchronized across all members of the cluster. The OSPF task of each standby member obtains routing state and information from the master and installs the routes in the kernel as the master does. On a failover, one of the standby members becomes the new master and then continues where the old master failed. During the time that the new master resynchronizes routes database with the neighbor routers, traffic forwarding continues using the old kernel routes until OSPF routes are fully synchronized and pushed into the kernel.
Multiple OSPF Instances let you separate OSPF into multiple OSPF domains. Each instance contains a fully independent OSPF database, and routes from one domain are not automatically advertised to another domain. You can manually configure route maps with CLI to filter and redistribute routes from one domain into another domain. The redistributed routes show as OSPF external routes in the routing table of the other domain.
Multiple instances are supported both on IPv4 and IPv6. If two different OSPF instances try to install the same route with equal cost, the route with the lower next-hop IP address is preferred. If the routes have different costs, the route with the lower cost is selected.
To add an OSPFv2 instance in Clish:
|
To add an OSPFv2 instance in Portal:
Go to OSPF > Instances > Add OSPF Instance
To add an OSPFv3 instance Clish:
|
To add an OSPFv3 instance in Portal:
Go to IPv6 OSPF > Instances > Add OSPF Instance
