Static routes remain in the routing table even if the next hop gateway becomes unavailable. Static routes are only removed from the routing table if the associated interface goes down. This allows you to define a default route to an ISP_A gateway and a backup default route to a secondary ISP_B in case the primary route should fail.
Static routes remain in the routing table even if the next hop gateway becomes unavailable. Static routes are only removed from the routing table if the associated interface goes down. This allows you to define a default route to an ISP_A gateway and a backup default route to a secondary ISP_B in case the primary route should fail.
Static routes remain in the routing table even if the next hop gateway becomes unavailable. Static routes are only removed from the routing table if the associated interface goes down. This allows you to define a default route to an ISP_A gateway and a backup default route to a secondary ISP_B in case the primary route should fail.
One of the problems with static routes is that there is no inherent mechanism to determine if the route is up or down. They remain in the routing table even if the next hop gateway becomes unavailable. Static routes are only removed from the routing table if the associated interface goes down.
The static route tracking feature provides a method for tracking the availability of a static route and installing a backup route if the primary route should fail. This allows you to; for example, define a default route to an ISP_A gateway and a backup default route to a secondary ISP_B in case the primary ISP becomes unavailable.
The security appliance does this by associating a static route with a monitoring target that you define. It monitors the target using ICMP echo requests. If an echo reply is not received within a specified time period, the object is considered down and the associated route is removed from the routing table. A previously configured backup route is used in place of the removed route.
When selecting a monitoring target, you need to make sure it can respond to ICMP echo requests.
In our Network, TRACK is configured for many customers who are running on static routes. We will use AFL which is a similar case.
Prepared by : Nawazish Khan The links are configured on core P2_G2 (71.2.3.5). The static routes configured for primary link are having a default AD value of 1. Track 119 has been configured for these static routes. Please refer below snap.
Track 119 will remain in up state till the ip 10.235.11.222 is reachable, As soon as the primary link goes down and the ip 10.235.11.222 becomes unreachable track goes down, forcing the all the static routes marked with track 119 to be removed from the routing table.
Prepared by : Nawazish Khan
Static routes for secondary link are configured with higher AD value 240, which will take over in case of Track 119 goes down. Please refer below snap.
Prepared by : Nawazish Khan Steps for confi guring SLA TRACK.
Step 1 Confi gure the tracked object moni tori ng parameters:
a. Define the monitoring process:
b. Specify the monitoring protocol.
Prepared by : Nawazish Khan c. Specify the VRF and Frequency.
d. Schedule the monitoring process.
Prepared by : Nawazish Khan
Step 2 Associ ate the SLA monitori ng process with the TRACK.
Step 2 Associate the TRACK with the desired static route.