Usage Guidelines
Use the iprsvppolicylocalcommand to determine how to perform authorization on RSVP requests.
Note |
When you enter the origin-asas keyword and argument combination, an RSVP warning message appears stating that the autonomous-system-based policy will be ineffective until BGP is running.
|
You can use all types of match criteria with non-Traffic-Engineering (TE) reservations. You can use all types of match criteria except application ID with TE reservations because TE PATH and RESV messages sent by Cisco routers do not contain application IDs.
There are five types of local policies--one default local policy, one or more ACL-based policies, one or more autonomous-system-based policies, one or more application-ID-based policies, and one or more DSCP-based policies. The default policy is used when an RSVP message does not match any ACL-, autonomous-system-, application-ID-, or DSCP-based policies.
You can configure a mixture of local policy types including ACL, autonomous system, application ID, DSCP, or default on the same interface or globally. Policies have the following priority (from highest to lowest):
-
Nondefault interface policies
-
Default interface policy
-
Nondefault global policies
-
Global default policy
Note |
If you configure an ACL to use with a TE tunnel, do not use 0 as the protocol because RSVP cannot accept any messages since they do not match the ACL.
|
Policy-Match Criteria
Note |
You cannot specify a policy-match criteria more than once using the iprsvppolicylocal command.
|
An ACL-based policy must have at least one ACL associated with it, but it can optionally have up to eight ACLs. The ACLs can be standard or extended IP ACLs. They are matched against source/destination addresses/ports based on RSVP objects inside RSVP signaling messages as described below.
-
ACL source address--Matched against the source address in the SENDER_TEMPLATE object in RSVP messages. If this object is not present, the source address in the IP header is used.
-
ACL destination address--Matched against the destination address in the SESSION object in RSVP messages. If this object is not present, the destination address in the IP header is used.
-
ACL source port--Matched against the source port in the SENDER_TEMPLATE object in RSVP messages. If this object is not present, the source port of 0 is used.
-
ACL destination port--Matched against the destination port in the SESSION object in RSVP messages. If this object is not present, the destination port of 0 is used.
-
ACL IP protocol--Matched against the IP protocol in the SESSION object in RSVP messages. If this object is not present, the IP protocol of 0 is used. If the IP protocol is for a TE session, then the ACL IP protocol should be UDP.
-
ACL differentiated services code point (DSCP) values--Matched against the DSCP value in the IP header of the RSVP message.
Note |
The same policy-match criteria apply when you create ACLs for the debugiprsvpfiltercommand except that the command does not use DSCP and the protocol is ignored for TE sessions.
|
An autonomous-system-based policy must have at least one autonomous system associated with it, but it can optionally have up to eight autonomous systems. They are matched against the incoming interface/source IP address contained in RSVP objects inside RSVP signaling messages, not on the IP headers of the RSVP messages.
An application-ID-based policy must have at least one application ID associated with it, but it can optionally have up to four application IDs. They are matched against the incoming interface/source IP address contained in RSVP objects inside RSVP signaling messages, not on the IP headers of the RSVP messages.
A DSCP-based policy must have at least one DSCP associated with it, but it can optionally have up to four DSCPs. RSVP extracts the DSCP from the aggregate message SESSION object and applies the local policy that matches the DSCP criteria.
Command Restrictions
-
You cannot configure more than 300 local policies per router. This limit is independent of policy location (global or per interface) or match criteria such as application IDs, ACLs, or autonomous systems.
-
You cannot configure a single local policy with more than four RSVP identities.
CLI Submodes
Once you type the iprsvppolicylocal command, you enter the local policy CLI submode where you define the properties of the local policy that you are creating.
Note |
The local policy that you create automatically rejects all RSVP messages unless you enter a submode command that instructs RSVP on the types of messages to accept or forward.
|
The submode commands are as follows:
-
accept --Accepts, but does not forward RSVP messages.
accept {all | path | path-error | resv | resv-error}
-
-
all --Accepts all incoming RSVP messages.
-
path --Accepts incoming PATH messages that meet the match criteria for this policy, which includes ACL(s), autonomous system(s), application ID(s), or default(s). If you omit this command, incoming PATH messages that meet the policy-match criteria are rejected and a PATHERROR message is sent in reply. However, the PATHERROR reply is also subject to local policy.
-
path-error --Accepts incoming PATHERROR messages that meet the match criteria for this policy. If you omit this command, incoming, including locally-generated, PATHERROR messages that meet the policy-match criteria are rejected.
-
resv --Accepts incoming RESV messages that meet the match criteria for this policy and performs any required admission control. If you omit this command, incoming RESV messages that meet the policy-match criteria are rejected and a RESVERROR message is sent in reply. However, the RESVERROR reply is also subject to local policy.
The default bandwidth for a policy is unlimited. Therefore, if the policy has no configured bandwidth, a RESV message is always accepted by the local policy because any bandwidth request is less than or equal to unlimited. However, the RESV message may subsequently fail admission control if there is insufficient bandwidth in the RSVP pool on the input interface to which the RESV message applies. (See the iprsvpbandwidth command for more information.) If the bandwidth requested by the RESV messages is too large, a RESVERROR message that is also subject to local policy is transmitted to the RESV sender.
-
-
resv-error --Accepts incoming RESVERROR messages that meet the policy-match criteria for this policy. If you omit this command, the incoming, including locally-generated, RESVERROR messages that meet the policy-match criteria are rejected.
-
default --Sets a command to its defaults.
-
exit --Exits local policy configuration mode.
-
fast-reroute --Allows TE LSPs that request Fast Reroute service. The default value is accept.
-
forward --Accepts and forwards RSVP messages.
forward {all|path | path-error | resv | resv-error}
-
-
all --Accepts and forwards all RSVP messages.
-
path --Accepts and forwards PATH messages that meet the match criteria for this policy. If you omit this command, PATH messages that meet the policy-match criteria are not forwarded to the next (downstream) hop.
-
path-error --Accepts and forwards PATHERROR messages that meet the match criteria for this policy. If you omit this command, the PATHERROR messages that meet the match criteria are not forwarded to the previous (upstream) hop. You may want to reject outbound PATHERROR messages if you are receiving PATH messages from an untrusted node because someone could be trying to port-scan for RSVP. If you reply with a PATHERROR message, the untrusted node knows that you support RSVP and your IP address. Such information could be used to attempt RSVP-based attacks.
-
resv --Accepts and forwards RESV messages that meet the match criteria for this policy. If you omit this command, RESV messages that meet the match criteria are not forwarded to the previous (upstream) hop.
-
resv-error --Accepts and forwards RESVERROR messages that meet the match criteria for this policy. If you omit this command, the RESVERROR messages that meet the match criteria are not forwarded to the next (downstream) hop. You may want to reject outbound RESVERROR messages if you are receiving RESV messages from an untrusted node because someone could be trying to port-scan for RSVP. If you reply with a RESVERROR message, then the untrusted node knows that you support RSVP and your IP address. Such information could be used to attempt RSVP-based attacks.
-
local-override --Overrides any other policy sources by enforcing this local policy. Finalizes any decisions by this policy. If local-override is omitted, RSVP holds onto the local policy decision to see if another local or remote policy exists that will make a decision on the RSVP message, and only if there is no other policy decision will the local policy decision be enforced.
-
maximum [bandwidth[groupx] [singley] | sendersn]--Sets the limits for resources.
-
bandwidth[groupx] [singley]--Indicates bandwidth limits for RSVP reservations. The group keyword specifies the amount of bandwidth that can be requested by all reservations covered by this policy. The single keyword specifies the maximum bandwidth that can be requested by any specific RSVP reservation covered by this policy. The x and y values are in kilobits per second and can range from 1 to 10,000,000 (similar in concept to the existing interface mode iprsvpbandwidthcommand). Absence of a bandwidth command implies that there is no policy limit on bandwidth requests.
Previously, the maximumbandwidthcommand applied only to PATH messages. However, as part of the application ID enhancement, this command now applies only to RESV messages. This change has the following benefits: Allows the local policy bandwidth limit to be used by RSVP's admission control process for both shared and nonshared reservations. Previous releases that performed group bandwidth checks on PATH messages could not account for bandwidth sharing, and, as a result, you had to account for sharing by creating a larger maximum group bandwidth for the policy. Allows a local policy to trigger preemption during the admission control function if there is insufficient policy bandwidth to meet the needs of an incoming RESV message.
-
-
senders n -- Limits the number of RSVP senders affected by this policy that can be active at the same time on this router. The value for n ranges from 1 to 50,000 with a default of 1000.
Note |
If you do not configure the iprsvppolicypreempt command, the maximumcommand may be rejected, resulting in the following error message: "RSVPerror:insufficientpreemptablebandwidth"iftherearereservationsadmittedagainstthepolicy,andyoutrytoreducethegroupbandwidthtolessthantheamountofadmittedbandwidthonthepolicy.
|
-
no --Negates a command or sets its defaults.
-
preempt-priority [traffic-engx] setup-priority [hold-priority] --Specifies the RSVP QoS priorities to be inserted into PATH and RESV messages if they were not signaled from an upstream or downstream neighbor or local client application, and the maximum setup or hold priority that RSVP QoS or MPLS/TE sessions can signal. A PATHERROR, RESVERROR, or local application error is returned if these limits are exceeded.
The xvalue indicates the upper limit of the priority for TE reservations. The range of xvalues is 0 to 7 in which the smaller the number, the higher the reservation's priority. For non-TE reservations, the range of xvalues is 0 to 65535 in which the higher the number, the higher the reservation's priority.
The setup-priority argument indicates the priority of a reservation when it is initially installed. The optional hold-priorityargument indicates the priority of a reservation after it has been installed; if omitted, it defaults to the setup-priority. Values for the setup-priority and hold-priority arguments range from 0 to 7 where 0 is considered the highest priority.
If the incoming message has a preemption priority that requests a priority higher than the policy allows, the message is rejected. Use the tunnelmplstraffic-engpriority command to configure preemption priority for TE tunnels.
A single policy can contain a preempt-prioritytraffic-eng and a preempt-priority command, which may be useful if the policy is bound to an ACL that identifies a subnet containing a mix of TE and non-TE endpoints or midpoints.
Note |
If you exit local policy configuration mode without entering any submode commands, the policy that you have created rejects all RSVP messages.
|
Per-Interface Local Policies
All the local policy submode commands are also supported on a per-interface basis. You simply enter Cisco IOS interface configuration mode for the selected interface and type in any number and mix of the submode commands.
Per-interface local policies take precedence over global local policies. However, if there is a default local policy configured for an interface, the router does not try to match any RSVP messages arriving on that interface to any of the global local policies. Policies have the following priority (from highest to lowest):
-
Nondefault interface policies
-
Default interface policy
-
Nondefault global policies
-
Global default policy
There are some important points to note about per-interface local policies:
-
Per-interface local policies do not take the place of the iprsvpbandwidth command. The iprsvpbandwidth command indicates if RSVP is enabled on an interface as well as the size of the RSVP bandwidth pool. The iprsvpbandwidth pool is used by the admission control function of RSVP; per-interface policies are used by the policy control function of RSVP. Policy control is the third phase of RSVP message processing, which consists of validation, authentication, policy control (authorization), and admission control.
-
The sum of the group bandwidth of all the local policies assigned to an interface can be greater than the maximum total bandwidth configured in the iprsvpbandwidth command. However, the iprsvpbandwidth command makes the final decision as to whether there is sufficient bandwidth to admit the reservation.