Filter Policies
Router Configuration Guide 495
Redirect Policies
SR OS-based routers support configuring of IPv4 and IPv6 redirect policies. Redirect policies
allow specifying multiple redirect target destinations and defining health check test methods
used to validate the ability for a given destination to receive redirected traffic. This
destination monitoring allows router to react to target destination failures. To specify IPv4
redirect policy, define all destinations to be IPv4. To specify IPv6 redirect policy, define all
destinations to be IPv6. IPv4 redirect policy can only be deployed in IPv4 filter policies. IPv6
redirect policy can only be deployed in IPv6 filter policies.
Redirect policy supports the following destination tests:
• ping test – with configurable interval, drop-count, and time-out for the test
• url-test – with configurable URL to test, interval, drop-count, timeout, and
configurable action (disable destination, lower or raise priority) based upon return
error code
• snmp-test – with configurable OID and Community strings, interval, drop-count,
timeout for the test, and configurable action (disable destination, lower or raise
priority) based upon SNMP return value.
• unicast-rt-test – unicast routing reachability, supported only when router instance is
configured for a given redirect policy. The test yields true if the route to the specified
destination exists in RTM for the configured router instance.
Each destination is assigned an initial or base priority describing this destination’s relative
importance within the policy. The destination with the highest priority value is selected as
most-preferred destination and programmed on line cards in filter policies using this redirect
policy as an action. Only destinations that are not disabled by the programmed test (if
configured) are considered when selecting the most-preferred destination.
In some deployments, it may not be desirable to switch from a currently active, most-
preferred redirect-policy destination when a new more-preferred destination becomes
available. To support such deployments, operators can enable the sticky destination
functionality (config>filter>redirect-policy>sticky-dest). When enabled, the currently
active destination remains active unless it goes down or an operator forces the switch using
the tools>perform>filter>redirect-policy>activate-best-dest command. An optional
sticky destination hold-time-up is available to delay programming the sticky destination in
redirect-policy (transition from "action forward" to PBR action to the most-preferred
destination). When the timer is enabled, the first destination that comes up will not be
programmed and instead the timer is started. Once the timer expires, the most-preferred
destination at that time will be programmed (which may be a different destination from the
one that started the timer). Note the following:
• When manual switchover to most-preferred destination is executed as described
above, the hold-time-up is stopped
To Next Page
Loading...
