[no] less-specific [allow-default]
config>vrrp>policy>priority-event>route-unknown
Supported on all 7210 SAS platforms as described in this document
This command enables a CIDR shortest match hit on a route prefix that contains the IP route prefix associated with the route unknown priority event.
The less-specific command modifies the search parameters for the IP route prefix specified in the route-unknown priority event. Specifying less-specific allows a CIDR shortest match hit on a route prefix that contains the IP route prefix.
The less-specific command eases the RTM lookup criteria when searching for the prefix/mask-length. When the route-unknown priority event sends the prefix to the RTM (as if it was a destination lookup), the result route table prefix (if a result is found) is checked to see if it is an exact match or a less specific match. The less-specific command enables a less specific route table prefix to match the configured prefix. When less-specific is not specified, a less specific route table prefix fails to match the configured prefix. The allow-default optional parameter extends the less-specific match to include the default route (0.0.0.0).
The no form of this command prevents RTM lookup results that are less specific than the route prefix from matching.
no less-specific
Specifies that an RTM return of 0.0.0.0 matches the IP prefix. If less-specific is entered without the allow-default parameter, a return of 0.0.0.0 will not match the IP prefix. To disable allow-default, but continue to allow less-specific match operation, only enter the less-specific command (without the allow-default parameter).
[no] next-hop ip-address
config>vrrp>policy>priority-event>route-unknown
Supported on all 7210 SAS platforms as described in this document
This command adds an enabled next hop IP address to match the IP route prefix for a route-unknown priority control event.
If the next-hop IP address does not match one of the defined ip-address, the match is considered unsuccessful and the route-unknown event transitions to the set state.
The next-hop command is optional. If no next-hop ip-address commands are configured, the comparison between the RTM prefix return and the route-unknown IP route prefix are not included in the next hop information.
When more than one next hop IP addresses are eligible for matching, a next-hop command must be executed for each IP address. Defining the same IP address multiple times has no effect after the first instance.
The no form of this command removes the ip-address from the list of acceptable next hops when looking up the route-unknown prefix. If this ip-address is the last next hop defined on the route-unknown event, the returned next hop information is ignored when testing the match criteria. If the ip-address does not exist, the no next-hop command returns a warning error, but continues to execute if part of an exec script.
no next-hop
Specifies the IP address for an acceptable next hop IP address for a returned route prefix from the RTM when looking up the route-unknown route prefix.
protocol {ospf | is-is | static}
no protocol
config>vrrp>policy>priority-event>route-unknown
Supported on all 7210 SAS platforms as described in this document
This command adds one or more route sources to match the route unknown IP route prefix for a route unknown priority control event.
If the route source does not match one of the defined protocols, the match is considered unsuccessful and the route-unknown event transitions to the set state.
The protocol command is optional. If the protocol command is not executed, the comparison between the RTM prefix return and the route-unknown IP route prefix will not include the source of the prefix. The protocol command cannot be executed without at least one associated route source parameter. All parameters are reset each time the protocol command is executed and only the explicitly defined protocols are allowed to match.
The no form of this command removes protocol route source as a match criteria for returned RTM route prefixes.
To remove specific existing route source match criteria, execute the protocol command and include only the specific route source criteria. Any unspecified route source criteria is removed.
no protocol
Specifies OSPF as an eligible route source for a returned route prefix from the RTM when looking up the route-unknown route prefix. The ospf parameter is not exclusive from the other available protocol parameters. If protocol is executed without the ospf parameter, a returned route prefix with a source of OSPF will not be considered a match and will cause the event to enter the set state.
Specifies IS-IS as an eligible route source for a returned route prefix from the RTM when looking up the route-unknown route prefix. The is-is parameter is not exclusive from the other available protocol parameters. If protocol is executed without the is-is parameter, a returned route prefix with a source of IS-IS will not be considered a match and will cause the event to enter the set state.
Specifies a static route as an eligible route source for a returned route prefix from the RTM when looking up the route-unknown route prefix. The static parameter is not exclusive from the other available protocol parameters. If protocol is executed without the static parameter, a returned route prefix with a source of static route will not be considered a match and will cause the event to enter the set state.
[no] route-unknown prefix/mask-length
config>vrrp>policy>priority-event
Supported on all 7210 SAS platforms as described in this document
This command enables a context to configure a route unknown priority control event that monitors the existence of a specific active IP route prefix within the routing table.
The route-unknown command configures a priority control event that defines a link between the VRRP priority control policy and the Route Table Manager (RTM). The RTM registers the specified route prefix as monitored by the policy. If any change (add, delete, new next hop) occurs relative to the prefix, the policy is notified and takes proper action according to the priority event definition. If the route prefix exists and is active in the routing table according to the conditions defined, the event is in the cleared state. If the route prefix is removed, becomes inactive or fails to meet the event criteria, the event is in the set state.
The command creates a route-unknown node identified by prefix/mask-length and containing event control commands.
Multiple unique (different prefix/mask-length) route-unknown event nodes can be configured within the priority-event node, up to the maximum limit of 32 events.
The route-unknown command can reference any valid IP address mask-length pair. The IP address and associated mask length define a unique IP router prefix. The dynamic monitoring of the route prefix results in one of the event operational states described in the following table.
| route-unknown operational state | Description |
|---|---|
Set – non-existent |
The route does not exist in the route table |
Set – inactive |
The route exists in the route table but is not being used |
Set – wrong next hop |
The route exists in the route table but does not meet the next-hop requirements |
Set – wrong protocol |
The route exists in the route table but does not meet the protocol requirements |
Set – less specific found |
The route exists in the route table but does is not an exact match and does not meet any less-specific requirements |
Set – default best match |
The route exists in the route table as the default route but the default route is not allowed for route matching |
Cleared – less specific found |
A less specific route exists in the route table and meets all criteria including the less-specific requirements |
Cleared – found |
The route exists in the route table manager and meets all criteria |
An existing route prefix in the RTM must be active (used by the IP forwarding engine) to clear the event operational state. It may be less specific (the defined prefix may be contained in a larger prefix according to Classless Inter-Domain Routing (CIDR) techniques) if the event has the less-specific statement defined. The less specific route that incorporates the router prefix may be the default route (0.0.0.0) if the less-specific allow-default statement is defined. The matching prefix may be required to have a specific next hop IP address if defined by the event next-hop command. Finally, the source of the RTM prefix may be required to be one of the dynamic routing protocols, or be statically defined if defined by the event protocol command. If an RTM prefix that matches all the preceding criteria (if defined in the event control commands) is not found, the event is considered to be set. If a matching prefix is found in the RTM, the event is considered to be cleared.
When an event transitions from clear to set, the set is processed immediately and must be reflected in the associated virtual router instances in-use priority value. As the event transitions from clear to set, a hold-set timer is loaded with the value configured by the events hold-set command. This timer prevents the event from clearing until it expires, damping the effect of event flapping. If the event clears and becomes set again before the hold-set timer expires, the timer is reset to the hold-set value, extending the time before another clear can take effect.
The no form of this command is used to remove the specific prefix/mask-length monitoring event. The event can be removed at anytime. When the event is removed, the in-use priority of all associated virtual router instances must be reevaluated. The events hold-set timer has no effect on the removal procedure.
no route-unknown
Specifies the IP prefix address to be monitored by the route unknown priority control event, in dotted decimal notation.
Specifies the subnet mask length, expressed as a decimal integer, associated with the IP prefix defining the route prefix to be monitored by the route unknown priority control event.
Specifies the IP address of the host for which the specific event will monitor connectivity. The ip-address can only be monitored by a single event in this policy. The IP address can be monitored by multiple VRRP priority control policies. The IP address can be used in one or multiple ping requests. Each VRRP priority control host-unreachable and ping destined to the same ip-address is uniquely identified on a per message basis. Each session originates a unique identifier value for the ICMP echo request messages it generates. This allows received ICMP echo reply messages to be directed to the appropriate sending application.