![]() |
Cisco IOS Quality of Service Solutions Command Reference
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ip rsvp precedence through load protocol
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Contents
ip rsvp precedence through load protocol ip rsvp precedenceTo enable the router to mark the IP Precedence value of the type of service (ToS) byte for packets in a Resource Reservation Protocol (RSVP) reserved path using the specified values for packets that either conform to or exceed the RSVP flowspec, use the iprsvpprecedencecommand in interface configuration mode. To remove existing IP Precedence settings, use the no form of this command.
ip
rsvp
precedence
{conform precedence-value | exceed precedence-value}
no
ip
rsvp
precedence
[conform | exceed]
Syntax Description
Command DefaultThe IP Precedence bits of the ToS byte are left unmodified when this command is not used. The default state is equivalent to execution of the noiprsvpprecedence command. Command History
Usage GuidelinesPackets in an RSVP reserved path are divided into two classes: those that conform to the reservation flowspec and those that correspond to a reservation but that exceed, or are outside, the reservation flowspec. The iprsvpprecedence command allows you to set the IP Precedence values to be applied to packets belonging to these two classes. You must specify the IP Precedence value for at least one class of traffic when you use this command. You can use a single instance of the command to specify values for both classes, in which case you can specify the conform and exceed keywords in either order. As part of its input processing, RSVP uses the iprsvpprecedence command to set the IP Precedence bits on conforming and nonconforming packets. If per-VC DWRED is configured, the system uses the IP Precedence and ToS bit settings on the output interface in its packet drop process. The IP Precedence setting of a packet can also be used by interfaces on downstream routers. Execution of the iprsvpprecedence command causes IP Precedence values for all preexisting reservations on the interface to be modified. RSVP receives packets from the underlying forwarding mechanism. Therefore, before you use the iprsvpprecedence command to set IP Precedence, one of the following features is required:
ExamplesThe following example sets the IP Precedence value to 3 for all traffic on the ATM interface 0 that conforms to the RSVP flowspec and to 2 for all traffic that exceeds the flowspec: interface atm0 ip rsvp precedence conform 3 exceed 2 The following example sets the IP Precedence value to 2 for all traffic on ATM interface 1 that conforms to the RSVP flowspec. The IP Precedence values of those packets that exceed the flowspec are not altered in any way. interface ATM1 ip rsvp precedence conform 2 Related Commands
ip rsvp qosTo enable Resource Reservation Protocol (RSVP) quality of service (QoS) flows on a router running Multiprotocol Label Switching traffic engineering (MPLS TE), use the iprsvpqos command in global configuration mode. To disable RSVP QoS flows, use the no form of this command. Usage GuidelinesIf RSVP QoS flows and MPLS TE are enabled, the router processes and installs RSVP label switched path (LSP) and IPv4 messages such as PATH and RESV. If RSVP QoS flows and MPLS TE are then disabled with IPv4 and LSP states installed, all installed IPv4 states are immediately cleared. LSP states remain unmodified. Further refreshes or new IPv4 RSVP messages are forwarded unmodified. Use the showiprsvp command to display the status of the iprsvpqos command. ip rsvp reservationTo enable a router to simulate receiving Resource Reservation Protocol (RSVP) RESV messages from a downstream host, use the iprsvpreservationcommand in global configuration mode. To disable this function, use the no form of this command.
ip
rsvp
reservation
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
next-hop-address
next-hop-interface
{ff | se | wf}
{load | rate}
bandwidth
burst-size
[identity alias]
no
ip
rsvp
reservation
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
next-hop-address
next-hop-interface
{ff | se | wf}
{load | rate}
bandwidth
burst-size
[identity alias]
Syntax DescriptionCommand History
Usage GuidelinesUse the iprsvpreservation command to make the router simulate receiving RSVP RESV messages from a downstream host and to proxy RSVP RESV messages for that host. By giving a local (loopback) next-hop address and next-hop interface, you can also use this command to proxy RSVP for the router that you are configuring or you can use the iprsvpreservation-host command. An alias must reference an RSVP identity that you created by using the iprsvpidentity command. The policy-locator string associated with this identity is signaled in the RESV message. This identity overrides any application ID that is contained in the matching PATH message. If the matching PATH message has an application ID, but you have not specified an application ID using the iprsvpreservation command, the RESV message will not contain an application ID. However, the RESV message proxied by the iprsvplistener command does put the matching PATH message application ID into the proxied RESV message. ExamplesThe following example specifies the use of a Shared Explicit style of reservation and the controlled load service, with token buckets of 100 or 150 kbps and a maximum queue depth of 60 or 65 kbps: Router(config)# ip rsvp reservation 192.168.0.2 172.16.1.1 udp 20 30 172.16.4.1 Ethernet1 se load 100 60 Router(config)# ip rsvp reservation 192.168.0.2 172.16.2.1 tcp 20 30 172.16.4.1 Ethernet1 se load 150 65 The following example specifies the use of a Wildcard Filter style of reservation and the guaranteed bit rate service, with token buckets of 300 or 350 kbps, a maximum queue depth of 60 or 65 kbps, and an application ID: Router(config)# ip rsvp reservation 192.168.0.3 0.0.0.0 udp 20 0 172.16.4.1 Ethernet1 wf rate 300 60 identity xyz Router(config)# ip rsvp reservation 192.168.1.1 0.0.0.0 udp 20 0 172.16.4.1 Ethernet1 wf rate 350 65 identity xyz Note that the wildcard filter does not admit the specification of the sender; it accepts all senders. This action is denoted by setting the source address and port to zero. If, in any filter style, the destination port is specified to be zero, RSVP does not permit the source port to be anything else; it understands that such protocols do not use ports or that the specification applies to all ports. Related Commands
ip rsvp reservation-hostTo enable a router to simulate a host generating Resource Reservation Protocol (RSVP) RESV messages, use the iprsvpreservation-hostcommand in global configuration mode. To disable this function, use the no form of this command.
ip
rsvp
reservation-host
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
{ff | se | wf}
{load | rate}
bandwidth
burst-size
[identity alias]
[vrf vrf-name]
no
ip
rsvp
reservation-host
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
{ff | se | wf}
{load | rate}
bandwidth
burst-size
[identity alias]
[vrf vrf-name]
Syntax Description
Command History
Usage Guidelines
Use the iprsvpreservation-hostcommand to make a router simulate a host generating its own RSVP RESV messages. This command is similar to the iprsvpreservation command, which can cause a router to generate RESV messages on behalf of another host. The main differences between the iprsvpreservation-host and iprsvpreservation commands follow:
An alias must reference an RSVP identity that you created by using the iprsvpidentity command. The policy-locator string associated with this identity is signaled in the RESV message. This identity overrides any application ID that is contained in the matching PATH message. If the matching PATH message has an application ID, but you have not specified an application ID using the iprsvpreservation-host command, the RESV message does not contain an application ID. However, the RESV message proxied by the iprsvplistener command does put the matching PATH message application ID into the proxied RESV message. ExamplesThe following example specifies the use of a Shared Explicit style of reservation and the controlled load service, with token buckets of 100 or 150 kbps, 60 or 65 kbps maximum queue depth, and an application ID: Router(config)# ip rsvp reservation-host 10.1.1.1 10.30.1.4 udp 20 30 se load 100 60 identity xyz Router(config)# ip rsvp reservation-host 10.40.2.2 10.22.1.1 tcp 20 30 se load 150 65 identity xyz Related Commands
ip rsvp resource-providerTo configure a resource provider for an aggregate flow, use the iprsvpresource-provider command in interface configuration mode. To disable a resource provider for an aggregate flow, use the no form of this command. Command DefaultWFQ (the wfqinterfacekeyword) is the default resource provider that Resource Reservation Protocol (RSVP) configures on the interface. Command History
Usage Guidelines
Use the iprsvpresource-provider command to configure the resource provider with which you want RSVP to interact when it installs a reservation. To ensure that a flow receives quality of service (QoS) guarantees when using WFQ on a per-flow basis, configure wfqinterface or wfqpvc as the resource provider. To ensure that a flow receives QoS guarantees when using class-based weighted fair queueing (CBWFQ) for data packet processing, configurenone as the resource provider.
ExamplesIn the following example, the iprsvpresource-provider command is configured with wfqpvc as the resource provider, ensuring that a flow receives QoS guarantees when using WFQ on a per-flow basis: Router# configure terminal Router(config)# interface atm 6/0 Router(config-if)# ip rsvp resource-provider wfq pvc In the following example, the iprsvpresource-provider command is configured with noneas the resource provider, ensuring that a flow receives QoS guarantees when using CBWFQ for data-packet processing: Router# configure terminal Router(config)# interface atm 6/0 Router(config-if)# ip rsvp resource-provider none ip rsvp senderTo enable a router to simulate receiving Resource Reservation Protocol (RSVP) PATH messages, use the iprsvpsendercommand in global configuration mode. To disable this function, use the no form of this command.
ip
rsvp
sender
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
previous-hop-ip-address
previous-hop-interface
bandwidth
burst-size
[identity alias]
no
ip
rsvp
sender
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
previous-hop-ip-address
previous-hop-interface
bandwidth
burst-size
[identity alias]
Syntax Description
Command History
Usage GuidelinesUse the iprsvpsender command to make the router simulate the receiving of RSVP PATH messages from an upstream host and to proxy RSVP PATH messages from that host. By including a local (loopback) previous-hop address and previous-hop interface, you can also use this command to proxy RSVP for the router that you are configuring. An alias must reference an RSVP identity that you created by using the iprsvpidentity command. The policy-locator string associated with this identity is supplied in the PATH message. ExamplesThe following example sets up the router to act as though it is receiving RSVP PATH messages using UDP over loopback interface 1: Router(config)# ip rsvp sender 192.168.0.1 172.16.2.1 udp 20 30 172.16.2.1 loopback1 50 5 identity xyz Router(config)# ip rsvp sender 192.168.0.2 172.16.2.1 udp 20 30 172.16.2.1 loopback1 50 5 identity xyz Related Commands
ip rsvp sender-hostTo enable a router to simulate a host generating a Resource Reservation Protocol (RSVP) PATH message, use the iprsvpsender-hostcommand in global configuration mode. To disable this function, use the no form of this command.
ip
rsvp
sender-host
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
bandwidth
burst-size
[identity alias]
[vrf vrf-name]
no
ip
rsvp
sender-host
session-ip-address
sender-ip-address
{ip-protocol | tcp | udp}
session-dest-port
sender-source-port
bandwidth
burst-size
[identity alias]
[vrf vrf-name]
Syntax Description
Command History
Usage Guidelines
Use the iprsvpsender-hostcommand to make a router simulate a host generating its own RSVP PATH messages. This command is similar to the iprsvpsender command, which can cause a router to generate RSVP PATH messages on behalf of another host. The main differences between the iprsvpsender-host and iprsvpsender commands follow:
An alias must reference an RSVP identity that you created by using the iprsvpidentity command. The policy-locator string associated with this identity is signaled in the RESV message. This identity overrides any application ID that is contained in the matching PATH message. ExamplesThe following example sets up the router to act like a host that sends traffic to the given address:
Router(config)# ip rsvp sender-host 10.0.0.7 10.0.0.1 udp 1 1 10 10 identity xyz
Related Commands
ip rsvp signalling dscpTo specify the differentiated services code point (DSCP) value to be used on all Resource Reservation Protocol (RSVP) messages transmitted on an interface, use the iprsvpsignallingdscp command in interface configuration mode. To disable this function, use the no form of this command. Usage GuidelinesYou configure the DSCP per interface, not per flow. The DSCP determines the priority that a packet receives from various hops as it travels to its destination. The DSCP applies to all RSVP flows installed on a specific interface. You can configure each interface independently for DSCP. ExamplesHere is an example of the iprsvpsignallingdscpcommand with a DSCP value of 6 Router(config-if)# ip rsvp signalling dscp 6 Router(config-if)# end To verify the DSCP value, enter the showiprsvpinterfacedetail command:
Router# show ip rsvp interface serial2/0 detail
Se2/0:
Bandwidth:
Curr allocated:10K bits/sec
Max. allowed (total):1536K bits/sec
Max. allowed (per flow):1536K bits/sec
Neighbors:
Using IP enacp:1. Using UDP encaps:0
DSCP value used in Path/Resv msgs:0x6
Burst Police Factor:300%
RSVP:Data Packet Classification provided by: none
ip rsvp signalling fast-local-repair notificationsTo configure the number of per flow notifications that Resource Reservation Protocol (RSVP) processes during a fast local repair (FLR) procedure before suspending, use the iprsvpsignallingfast-local-repairnotifications command in global configuration mode. To set the number of notifications to its default, use the no form of this command.
ip
rsvp
signalling
fast-local-repair
notifications
number
no
ip
rsvp
signalling
fast-local-repair
notifications
Command DefaultNotifications are sent by the Routing Information Base (RIB) and processed by RSVP. If the iprsvpsignallingfast-local-repairnotifications command is not configured, RSVP processes 1000 notifications, suspends the notifications, and then resumes processing of another 1000 notifications. Usage GuidelinesUpon a route change, RIB builds a list of notifications, one per affected flow, and notifies RSVP by sending an event including these notifications. Therefore, these events can contain thousands of elements, depending on the number of path state blocks (PSBs) affected. RSVP processes, by default, 1000 notifications at a time and then suspends if required, to prevent the CPU from being overwhelmed. However, you can configure this number using the iprsvpsignallingfast-local-repairnotifications command. ExamplesThe following example shows how to configure the number of flows that are repaired before RSVP suspends to 100:
Router(config)# ip rsvp signalling fast-local-repair notifications 100
Related Commands
ip rsvp signalling fast-local-repair rateTo configure the repair rate that Resource Reservation Protocol (RSVP) uses for a fast local repair (FLR) procedure, use the iprsvpsignallingfast-local-repairratecommand in global configuration mode. To set the repair rate to its default, use the no form of this command.
ip
rsvp
signalling
fast-local-repair
rate
messages-per-second
no
ip
rsvp
signalling
fast-local-repair
rate
Command DefaultIf this command is not configured, the RSVP message pacing rate is used.
Usage GuidelinesThe default repair rate is based on the RSVP message pacing rate. If you configure the FLR rate by using the iprsvpsignallingfast-local-repairrate command, and RSVP message pacing is enabled, the lower FLR rate and the RSVP message pacing rate takes effect. If you disable the RSVP rate limit by using thenoiprsvpsignallingrate-limitcommand, then the FLR rate is used. However, if you disable the RSVP rate limit and do not configure an FLR rate, then RSVP performs no message pacing and messages are sent back-to-back. This action is not recommended because the point of local repair (PLR) may flood the downstream node with PATH messages causing some of them to be dropped. The repair rate is determined at notification time, and this same rate is used during the time of the repair even if you change either the RSVP message pacing rate or the FLR rate during this time. ExamplesThe following example shows how to configure a repair rate of 100 messages per second:
Router(config)# ip rsvp signalling fast-local-repair rate 100
Related Commands
ip rsvp signalling fast-local-repair wait-timeTo configure the delay that Resource Reservation Protocol (RSVP) uses before starting a fast local repair (FLR) procedure, use the iprsvpsignallingfast-local-repairwait-timecommand in interface configuration mode. To set the delay to its default, use the no form of this command.
ip
rsvp
signalling
fast-local-repair
wait-time
interval
no
ip
rsvp
signalling
fast-local-repair
wait-time
Usage GuidelinesUse the iprsvpsignallingfast-local-repairwait-time command to configure the delay desired in starting an FLR procedure. If you do not configure a delay, then path refreshes are triggered immediately after RSVP receives a route change notification from the Routing Information Base (RIB). ip rsvp signalling hello (configuration)To enable Hello globally on the router, use the iprsvpsignallinghellocommand in global configuration mode. To disable Hello globally on the router, use the no form of this command. Command History
Usage GuidelinesTo enable Hello globally on the router, you must enter this command. You also must enable Hello on the interface. ip rsvp signalling hello (interface)To enable hello on an interface where you need Fast Reroute protection, use the iprsvpsignallinghellocommand in interface configuration mode. To disable hello on an interface where you need Fast Reroute protection, use the no form of this command Command History
ExamplesIn the following example, hello is enabled on an interface:
Router(config-if)# ip rsvp signalling hello
Related Commands
ip rsvp signalling hello dscpTo set the differentiated services code point (DSCP) value that is in the IP header of a Resource Reservation Protocol (RSVP) traffic engineering (TE) hello message sent from an interface, use the iprsvpsignallinghellodscp command in interface configuration mode. To set the DSCP value to its default, use the no form of this command. Command History
Usage GuidelinesIf a link is congested, it is recommended that you set the DSCP to a value higher than 0 to reduce the likelihood that hello messages will be dropped. You configure the DSCP per interface, not per flow. The DSCP applies to the RSVP hellos created on a specific interface. You can configure each interface independently for DSCP. If you issue the iprsvpsignallinghellodscp command without the optional fast-reroutekeyword, the command applies to Fast Reroute hellos. This command is provided for backward compatibility; however, we recommend that you use the iprsvpsignallinghellofast-reroutedscpcommand. ExamplesIn the following example, hello messages sent from this interface have a DSCP value of 30 and Fast Reroute capability is enabled by specifying the fast-reroute keyword:
Router(config-if)# ip rsvp signalling hello fast-reroute dscp 30
In the following example, hello messages sent from this interface have a DSCP value of 30 and Fast Reroute capability is enabled by default:
Router(config-if)# ip rsvp signalling hello dscp 30
Related Commands
ip rsvp signalling hello graceful-restartTo enable the Resource Reservation protocol (RSVP) traffic engineering (TE) graceful restart capability on a neighboring router, use the iprsvpsignallinghellograceful-restart command in interface configuration mode. To disable the graceful restart capability, use the no form of this command. Usage GuidelinesUse the iprsvpsignallinghellograceful-restart command to enable support for graceful restart on routers helping their neighbors recover TE tunnels following stateful switchover (SSO).
ExamplesThe following example configures graceful restart on POS interface 1/0/0 of a neighboring router with the IP address 10.0.0.1: Router# configure terminal Enter configuration commands, one per line. End with CTTL/Z. Router(config)# interface POS1/0/0 Router(config-if)# ip rsvp signalling hello graceful-restart ip rsvp signalling hello graceful-restart dscpTo set the differentiated services code point (DSCP) value that is in the IP header of a Resource Reservation Protocol (RSVP) traffic engineering (TE) graceful restart hello message, use the iprsvpsignallinghellograceful-restartdscp command in global configuration mode. To set the DSCP valueto its default, use the no form of this command.
ip
rsvp
signalling
hello
graceful-restart
dscp
num
no
ip
rsvp
signalling
hello
graceful-restart
dscp
Usage GuidelinesIf a link is congested, set the DSCP to a value higher than 0 to reduce the likelihood that hello messages get dropped. The DSCP applies to the RSVP hellos created on a specific router. You can configure each router independently for the DSCP. ip rsvp signalling hello graceful-restart modeTo enable Resource Reservation Protocol (RSVP) traffic engineering (TE) graceful restart capability on a Route Processor (RP), use the iprsvpsignallinghellograceful-restartmodecommand in global configuration mode. To disable graceful restart capability, use the no form of this command. Cisco IOS 12.0(29)S, 12.2(33)SRA, 12.2(33)SXH, and Later Releases
ip
rsvp
signalling
hello
graceful-restart
mode
{help-neighbor | full}
no
ip
rsvp
signalling
hello
graceful-restart
mode
Cisco IOS T and XE Trains
ip
rsvp
signalling
hello
graceful-restart
mode
help-neighbor
no
ip
rsvp
signalling
hello
graceful-restart
mode
help-neighbor
Command History
Usage GuidelinesUse the iprsvpsignallinghellograceful-restartmodehelp-neighborcommand to enable support capability for a neighboring router to restart after a failure. Use the iprsvpsignallinghellograceful-restartmodefullcommand to enable support capability for a router to begin self-recovery or help its neighbor to restart on platforms that support stateful switchover (SSO), such as Cisco 7600 series routers, provided that you have installed and configured a standby RP. ExamplesThe following example shows how to configure an RP with support capability to perform self-recovery after a failure:
Router(config)# ip rsvp signalling hello graceful-restart mode full
Related Commands
ip rsvp signalling hello graceful-restart mode help-neighbor
To enable Resource Reservation Protocol (RSVP) traffic engineering (TE) graceful restart capability on a neighboring router, use the iprsvpsignallinghellograceful-restartmodehelp-neighborcommand in global configuration mode. To disable graceful restart capability, use the no form of this command.
ip
rsvp
signalling
hello
graceful-restart
mode
help-neighbor
no
ip
rsvp
signalling
hello
graceful-restart
mode
help-neighbor
Command History
Usage GuidelinesUse the iprsvpsignallinghellograceful-restartmodehelp-neighbor command to restart a neighboring router. ExamplesIn the following example, graceful restart is enabled:
Router(config)# ip rsvp signalling hello graceful-restart mode help-neighbor
Related Commands
ip rsvp signalling hello graceful-restart neighborTo enable Resource Reservation Protocol (RSVP) traffic engineering (TE) graceful restart capability on a neighboring router, use the iprsvpsignallinghellograceful-restartneighborcommand in interface configuration mode. To disable graceful restart capability, use the no form of this command.
ip
rsvp
signalling
hello
graceful-restart
neighbor
ip-address
no
ip
rsvp
signalling
hello
graceful-restart
neighbor
ip-address
Command DefaultNo neighboring routers have graceful restart capability enabled until you issue this command. Usage GuidelinesUse the iprsvpsignallinghellograceful-restartneighbor command to enable support for graceful restart on routers helping their neighbors recover TE tunnels following stateful switchover (SSO).
ExamplesThe following example configures graceful restart on POS interface 1/0/0 of a neighboring router with the IP address 10.0.0.1: Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# interface POS1/0/0 Router(config-if)# ip rsvp signalling hello graceful-restart neighbor 10.0.0.1 ip rsvp signalling hello graceful-restart refresh intervalTo configure the Resource Reservation Protocol (RSVP) traffic engineering (TE) refresh interval in graceful restart hello messages, use the iprsvpsignallinghellograteful-restartrefreshinterval command in global configuration mode. To set the interval to its default value, use theno form of this command.
ip
rsvp
signalling
hello
graceful-restart
refresh
interval
interval-value
no
ip
rsvp
signalling
hello
graceful-restart
refresh
interval
Usage GuidelinesA node periodically generates a hello message that contains a Hello Request object for all its neighbors. The frequency of those hello messages is determined by the hello interval.
ExamplesIn the following example, hello requests are sent to a neighbor every 5000 ms:
Router(config)# ip rsvp signalling hello graceful-restart refresh interval 5000
Related Commands
ip rsvp signalling hello graceful-restart refresh missesTo specify how many sequential Resource Reservation Protocol (RSVP) traffic engineering (TE) graceful restart hello acknowledgments (ACKs) a node can miss before the node considers communication with its neighbor lost, use the iprsvpsignallinghellograceful-restartrefreshmisses command in global configuration mode. To return the missed refresh limit to its default value, use the no form of this command.
ip
rsvp
signalling
hello
graceful-restart
refresh
misses
msg-count
no
ip
rsvp
signalling
hello
graceful-restart
refresh
misses
Usage GuidelinesA hello message comprises a hello message, a Hello Request object, and a Hello ACK object. Each request is answered by an acknowledgment. If a link is congested or a router has a heavy load, set this number to a value higher than the default value to ensure that hello does not falsely declare that a neighbor is down.
ExamplesIn the following example, if the node does not receive five sequential hello acknowledgments, the node declares that its neighbor is down:
Router(config)# ip rsvp signalling hello graceful-restart refresh misses 5
Related Commands
ip rsvp signalling hello graceful-restart sendTo configure the time for Resource Reservation Protocol (RSVP) label switched paths (LSPs) in a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network to recover or restart after a stateful switchover (SSO) occurs, use the iprsvpsignallinghellograceful-restartsend command in global configuration mode. To keep the default recovery and restart times, use the no form of this command.
ip
rsvp
signalling
hello
graceful-restart
send
{recovery-time ms | restart-time ms}
no
ip
rsvp
signalling
hello
graceful-restart
send
{recovery-time ms | restart-time ms}
Command DefaultThe default recovery and restart times of 120,000 and 30,000 ms, respecively, are in effect until you change them. Usage GuidelinesUse the iprsvpsignallinghellograceful-restartsendcommand to give LSPs a longer time to recover or restart after an SSO occurs. Otherwise, the LSPs may not all come back up and your network performance is negatively affected. ExamplesIn the following example, a recovery time of 300,000 ms is configured:
Router(config)# ip rsvp signalling hello graceful-restart send recovery-time 300000
Related Commands
ip rsvp signalling hello refresh intervalTo configure the Resource Reservation Protocol (RSVP) traffic engineering (TE) hello refresh interval, use the iprsvpsignallinghellorefreshinterval command in interface configuration mode. To set the refresh interval to its default value, use theno form of this command.
ip
rsvp
signalling
hello
[fast-reroute]
refresh
interval
interval-value
no
ip
rsvp
signalling
hello
[fast-reroute]
refresh
interval
Syntax Description
Command DefaultThe default frequencyat which a node sends hello messages to a neighbor is 200 msec. Command History
Usage GuidelinesYou can configure the hello request interval on a per-interface basis. A node periodically generates a hello message containing a Hello Request object for each neighbor whose status is being tracked. The frequency of those hello messages is determined by the hello interval. If you issue the iprsvpsignallinghellorefreshintervalcommand without the optional fast-reroutekeyword, the command applies to Fast Reroute hellos. This command is provided for backward compatibility; however, we recommend that you use the iprsvpsignallinghellofast-rerouterefreshintervalcommand. ExamplesIn the following example, hello requests are sent to a neighbor every 5000 milliseconds and Fast Reroute capability is enabled by specifying the fast-reroute keyword:
Router(config-if)# ip rsvp signalling hello fast-reroute refresh interval 5000
In the following example, hello requests are sent to a neighbor every 5000 milliseconds and Fast Reroute capability is enabled by default:
Router(config-if)# ip rsvp signalling hello refresh interval 5000
Related Commands
ip rsvp signalling hello refresh missesTo specify how many Resource Reservation Protocol (RSVP) traffic engineering (TE) hello acknowledgments a node can miss in a row before the node considers that communication with its neighbor is down, use the iprsvpsignallinghellorefreshmisses command in interface configuration mode. To return the missed refresh limit to its default value, use the no form of this command.
ip
rsvp
signalling
hello
[fast-reroute]
refresh
misses
msg-count
no
ip
rsvp
signalling
hello
[fast-reroute]
refresh
misses
Command History
Usage GuidelinesA hello comprises a hello message, a Hello Request object, and a Hello ACK object. Each request is answered by an acknowledgment. If a link is very congested or a router has a very heavy load, set this number to a value higher than the default value to ensure that hello does not falsely declare that a neighbor is down. If you issue the iprsvpsignallinghellorefreshmissescommand without the optional fast-reroutekeyword, the command applies to Fast Reroute hellos and Fast Reroute capability is enabled by default. This command is provided for backward compatibility; however, we recommend that you use the iprsvpsignallinghellofast-rerouterefreshmissescommand. ExamplesIn the following example, if the node does not receive five hello acknowledgments in a row, the node declares that its neighbor is down and Fast Reroute is enabled by specifying the fast-reroute keyword:
Router(config-if)# ip rsvp signalling hello fast-reroute refresh misses 5
In the following example, if the node does not receive five hello acknowledgments in a row, the node declares that its neighbor is down and Fast Reroute is enabled by default:
Router(config-if)# ip rsvp signalling hello refresh misses 5
ip rsvp signalling hello reroute dscpTo set the differentiated services code point (DSCP) value that is in the IP header of a Resource Reservation Protocol (RSVP) traffic engineering (TE) reroute hello (for state timeout) message sent from an interface, use the iprsvpsignallinghelloreroutedscp command in interface configuration mode. To set the DSCP value to its default, use the no form of this command. Usage GuidelinesIf a link is congested, you should set the DSCP to a value higher than 0 to reduce the likelihood that hello messages get dropped. You configure the DSCP per interface, not per flow. The DSCP applies to the RSVP hellos created on a specific interface. You can configure each interface independently for DSCP. ip rsvp signalling hello reroute refresh intervalTo configure the Resource Reservation Protocol (RSVP) traffic engineering (TE) reroute hello (for state timeout) refresh interval, use the iprsvpsignallinghellorerouterefreshinterval command in interface configuration mode. To set the refresh interval to its default value, use theno form of this command.
ip
rsvp
signalling
hello
reroute
refresh
interval
interval-value
no
ip
rsvp
signalling
hello
reroute
refresh
interval
Command DefaultThe default frequencyat which a node sends hello messages to a neighbor is 1000 milliseconds (10 seconds). Usage GuidelinesYou can configure the hello request interval on a per-interface basis. A node periodically generates a hello message containing a Hello Request object for each neighbor whose status is being tracked. The frequency of those hello messages is determined by the hello interval. For some routers, if you set the interval to a value less than the default value, CPU usage may be high. ip rsvp signalling hello reroute refresh missesTo specify how many Resource Reservation Protocol (RSVP) traffic engineering (TE) reroute hello (for state timeout) acknowledgments (ACKs) a node can miss in a row before the node considers communication with its neighbor is down, use the iprsvpsignallinghellorerouterefreshmisses command in interface configuration mode. To return the missed refresh limit to its default value, use the no form of this command.
ip
rsvp
signalling
hello
reroute
refresh
misses
msg-count
no
ip
rsvp
signalling
hello
reroute
refresh
misses
Usage GuidelinesA hello comprises a hello message, a Hello Request object, and a Hello ACK object. Each request is answered by an acknowledgment. If a link is very congested or a router has a very heavy load, set this number to a value higher than the default value to ensure that hello does not falsely declare that a neighbor is down. ip rsvp signalling hello statisticsTo enable Hello statistics on the router, use the iprsvpsignallinghellostatistics command in global configuration mode. To disable Hello statistics on the router, use the no form of this command. Command History
ip rsvp signalling initial-retransmit-delayTo configure the minimum amount of time that a Resource Reservation Protocol (RSVP)-configured router waits for an acknowledgment (ACK) message before retransmitting the same message, use the iprsvpsignallinginitial-retransmit-delay command in global configuration mode. To reset the delay value to its default, use thenoform of this command.
ip
rsvp
signalling
initial-retransmit-delay
delay-value
no
ip
rsvp
signalling
initial-retransmit-delay
Usage GuidelinesUse the ip rsvp signalling initial-retransmit-delaycommand to configure the minimum amount of time that a router waits for an ACK message before retransmitting the same message. If an ACK is not received for a state, the first retransmit occurs after the initial retransmit interval. If no ACK is received after the first retransmit, a second retransmit occurs. The message continues to be retransmitted, with the gap between successive retransmits being twice the previous interval, until an ACK is received. Then the message drops into normal refresh schedule if it needs to be refreshed (Path and Resv messages), or is processed (Error or Tear messages). If no ACK is received after five retransmits, the message is discarded as required. ExamplesThe following command shows how to set the initial-retransmit-delay to 2 seconds:
Router(config)# ip rsvp signalling initial-retransmit-delay 2000
The following command shows how to reset the initial-retransmit-delay to the default (1.0 sec):
Router(config)# no ip rsvp signalling initial-retransmit-delay
ip rsvp signalling patherr state-removalTo reduce the amount of Resource Reservation Protocol (RSVP) traffic messages in a network, use the iprsvpsignallingpatherrstate-removal command in global configuration mode. To disable this function, use the no form of this command. Usage GuidelinesUse the iprsvpsignallingpatherrstate-removalcommand to allow routers to delete Path state automatically when forwarding a PathError message, thereby eliminating the need for a subsequent PathTear message. This command is most effective when all network nodes support this feature. All nodes need to have the latest version of Cisco IOS software configured. This command applies only to label-switched path (LSP) flows. ExamplesThe following command shows how to enable iprsvpsignallingpatherrstate-removal:
Router(config)# ip rsvp signalling patherr state-removal
The following command shows how to disable iprsvpsignallingpatherrstate-removal:
Router(config)# no ip rsvp signalling patherr state-removal
The following command shows how to enable iprsvpsignallingpatherrstate-removal based on an access control list (ACL):
Router(config)# ip rsvp signalling patherr state-removal neighbor 98
The following command shows how to disable iprsvpsignallingpatherrstate-removal based on an ACL:
Router(config)# no ip rsvp signalling patherr state-removal neighbor 98
ip rsvp signalling rate-limitTo control the transmission rate for Resource Reservation Protocol (RSVP) messages that are sent to a neighboring router during a specified amount of time, use the iprsvpsignallingrate-limit command in global configuration mode. To disable this function, use the no form of this command. Releases Before Cisco IOS Release 12.4(20)T
ip
rsvp
signalling
rate-limit
[burst number]
[maxsize bytes]
[period ms]
no
ip
rsvp
signalling
rate-limit
Cisco IOS 12.0S Releases, 12.2S Releases, XE 2 Releases, Release 12.4(20)T, and Later T Releases
ip
rsvp
signalling
rate-limit
[burst number]
[limit number]
[maxsize bytes]
[period ms]
no
ip
rsvp
signalling
rate-limit
Syntax Description
Command History
Usage GuidelinesUse the iprsvpsignallingrate-limitcommand to prevent a burst of RSVP traffic engineering signaling messages from overflowing the input queue of a receiving router, which would cause the router to drop some messages. Dropped messages substantially delay the completion of signaling. This command replaces the iprsvpmsg-pacingcommand. ExamplesThe following command shows how 6 messages with a message queue of 500 bytes are sent every 10 ms to any neighboring router: Router(config)# ip rsvp signalling rate-limit burst 6 maxsize 500 period 10 Related Commands
ip rsvp signalling refresh intervalTo specify the interval between sending refresh messages for each Resource Reservation Protocol (RSVP) state, use the iprsvpsignallingrefreshinterval command in global configuration mode. To set the interval to its default value, use theno form of the command. Command History
Usage GuidelinesUse the iprsvpsignallingrefreshinterval command to specify the interval between sending refresh messages for each RSVP state. The RSVP protocol relies on a soft-state mechanism to maintain state consistency in the face of network losses. This mechanism is based on continuous refresh messages to keep a state current. Each RSVP router is responsible for sending periodic refresh messages to its neighbors.
ExamplesThe following example shows how to specify a refresh interval of 60000 milliseconds (60 seconds):
Router(config)# ip rsvp signalling refresh interval 60000
The following example returns the refresh interval to the default value of 30 seconds:
Router(config)# no ip rsvp signalling refresh interval
ip rsvp signalling refresh missesTo specify the number of successive refresh messages that can be missed before Resource Reservation Protocol (RSVP) removes a state from the database, use the iprsvpsignallingrefreshmisses command in global configuration mode. To return the missed refresh limit to its default value, use the no form of this command. Command History
Usage GuidelinesUse theiprsvpsignallingrefreshmissescommand to specify the number of successive refresh messages that can be missed before RSVP regards the router state as expired and removes that state from the database.
ip rsvp signalling refresh reductionTo enable Resource Reservation Protocol (RSVP) refresh reduction, use theiprsvpsignallingrefreshreduction command in global configuration mode. To disable refresh reduction, use the no form of this command. Usage GuidelinesRSVP refresh reduction is a set of extensions to reduce the messaging load imposed by RSVP and to help it scale to support larger numbers of flows. The following features of the refresh reduction standard (RFC 2961) are supported and will be turned on with this command:
Refresh reduction requires the cooperation of the neighbor to operate; for this purpose, the neighbor must also support the standard. If the router detects that a directly connected neighbor is not supporting the refresh reduction standard (either through observing the refresh-reduction-capable bit in messages received from the next hop, or by sending a MESSAGE_ID object to the next hop and receiving an error), refresh reduction will not be used on this link irrespective of this command. ip rsvp signalling refresh reduction ack-delayTo configure the maximum amount of time that a Resource Reservation Protocol (RSVP)-configured router holds on to an acknowledgment (ACK) message before sending it, use theiprsvpsignallingrefreshreductionack-delaycommand in global configuration mode. To reset the ack-delay value to its default, use the noform of this command.
ip
rsvp
signalling
refresh
reduction
ack-delay
delay-value
no
ip
rsvp
signalling
refresh
reduction
ack-delay
ip rsvp sourceTo configure a Resource Reservation Protocol (RSVP) router to populate an address other than the native interface address in the previous hop (PHOP) address field of the PHOP object when forwarding a PATH message onto that interface, use the iprsvpsource command in interface configuration mode. To keep the native interface address in the PHOP address field, use the no form of this command. ExamplesThe following example configures IP address 10.1.3.13 for the PHOP address field: Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# interface ethernet 0/0 Router(config-if)# ip rsvp bandwidth Router(config-if)# ip rsvp source address 10.1.3.13 Router(config-if)# end The following example configures loopback interface 0 as the interface whose address is used in the PHOP address field: Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# interface ethernet 1/0 Router(config-if)# ip rsvp bandwidth Router(config-if)# ip rsvp source interface loopback 0 Router(config-if)# end ip rsvp svc-requiredTo enable creation of a switched virtual circuit (SVC) to service any new Resource Reservation Protocol (RSVP) reservation made on the interface or subinterface of an Enhanced ATM port adapter (PA-A3), use the iprsvpsvc-required command in interface configuration mode. To disable SVC creation for RSVP reservations, use the no form of this command. Command History
Usage GuidelinesThis command applies exclusively to the RSVP-ATM QoS Interworking feature. Usually reservations are serviced when RSVP classifies packets and a queueing mechanism schedules them for transmission to manage congestion. Traditionally, RSVP is used with weighted fair queueing (WFQ). When RSVP is coupled with WFQ, all of the packets visible to WFQ are also visible to RSVP, which allows RSVP to identify and take action on packets important to it. In this case, WFQ provides bandwidth guarantees. However, when the iprsvpsvc-required command is used to configure an interface or subinterface, a new SVC is established and used to service each new reservation on the interface. ATM SVCs are used to provide bandwidth guarantees and NetFlow is used on input interfaces to make data packets visible to RSVP.
This command must be executed on both ends of an SVC driven by RSVP. This command is supported only for the Enhanced ATM port adapter (PA-A3) and its subinterfaces.
Use the showiprsvpinterface command to determine whether this command is in effect for any interface or subinterface. ExamplesThe following example signals RSVP that reservations made on ATM interface 2/0/0 will be serviced by creation of an SVC: interface atm2/0/0 ip rsvp svc-required Related Commands
ip rsvp tosTo enable the router to mark the five low-order type of service (ToS) bits of the IP header ToS byte for packets in a Resource Reservation Protocol (RSVP) reserved path using the specified values for traffic that either conforms to or exceeds the RSVP flowspec, use the iprsvptos command in interface configuration mode. To remove existing settings for the ToS bits, use the no form of this command; if neither the conformnor exceed keyword is specified, all settings for the ToS bits are removed. Syntax Description
Command DefaultThe ToS bits of the ToS byte are left unmodified when this command is not used. (The default behavior is equivalent to use of the noiprsvptos command.) Command History
Usage GuidelinesPackets in an RSVP reserved path are divided into two classes: those that conform to the reservation flowspec and those that correspond to a reservation but that exceed, or are outside, the reservation flowspec. The iprsvptos command allows you to set the ToS values to be applied to packets belonging to these two classes. You must specify the ToS value for at least one class of traffic when you use this command. You can use a single instance of the command to specify values for both classes, in which case you can specify the conform and exceed keywords in either order. As part of its input processing, RSVP uses the iprsvptos command configuration to set the ToS bits of the ToS byte on conforming and nonconforming packets. If per-virtual circuit (VC) VIP-distributed Weighted Random Early Detection (DWRED) is configured, the system uses the ToS bit and IP Precedence bit settings on the output interface in its packet drop process. The ToS bit and IP Precedence bit settings of a packet can also be used by interfaces on downstream routers. Execution of the iprsvptos command causes ToS bit values for all preexisting reservations on the interface to be modified.
RSVP receives packets from the underlying forwarding mechanism. Therefore, to use the iprsvptos command to set the ToS bits, one of the following features is required:
ExamplesThe following example sets the ToS bits value to 4 for all traffic on ATM interface 1 that conforms to the RSVP flowspec. ToS bits on packets exceeding the flowspec are not altered. interface atm1 ip rsvp tos conform 4 Related Commands
ip rsvp transportTo create a Resource Reservation Protocol (RSVP) transport session, use the iprsvptransport command in global configuration mode. To disable the RSVP transport session, use the no form of this command.
ip
rsvp
transport
{client client-id | statistics}
no
ip
rsvp
transport
{client client-id | statistics}
Usage GuidelinesYou can use the iprsvptransport command to configure RSVP to be used as transport mechanism for the clients. The client-id is used for identification of the client that initiates the RSVP as a transport protocol. The statistics keyword is used to record statistics for RSVP TP sessions. The statistics recorded includes information passed by RSVP to the RSVP TP client as part of callback. The maximum amount of information that can be recorded is 32 MB. The iprsvptransport command enables a router to simulate a host generating RSVP PATH message. This command is used for testing and debugging purposes. ip rsvp transport sender-hostTo register a transport client ID with Resource Reservation Protocol (RSVP), use the iprsvptransportsender-host command in global configuration mode. To disable the static RSVP host path configuration, use the no form of this command.
ip
rsvp
transport
sender-host
[tcp | udp]
destination-address
source-address
ip-protocol
dest-port
source-port
client-id
init-id
instance-id
[vrf vrf-name]
[data data-value]
no
ip
rsvp
transport
sender-host
[tcp | udp]
destination-address
source-address
ip-protocol
dest-port
source-port
client-id
init-id
instance-id
[vrf vrf-name]
[data data-value]
Syntax Description
Usage GuidelinesUse the iprsvptransportsender-host command to configure the RSVP transport proxy path. When this command is configured, RSVP sends PATH messages downstream. ip rsvp tunnel overhead-percentTo manually override the Resource Reservation Protocol (RSVP) percentage bandwidth, use the iprsvptunneloverhead-percentcommand in interface configuration mode. To restore the tunnel overhead percentage to its default values, use the no form of this command. Command DefaultThe percentage overhead for generic routing encapsulation (GRE) or multipoint generic routing encapsulation (mGRE) interfaces is 4 percent. The percentage overhead for GRE and mGRE with IPsec interfaces ranges from 4 to 15 percent, with an average of 10 percent. Usage GuidelinesDuring the bandwidth admission control, the Cisco IOS software must consider the additional IP overhead introduced because of tunneling and a possible encryption over these tunnels. The default values for the overhead depends on the average size of an Internet packet. However, you can manually override the default values by using the iprsvptunneloverhead-percentcommand. For example, when the Cisco IOS software gets a reservation request for 100 bytes, and if the outbound interface is a GRE or an mGRE interface, then a bandwidth reservation request for 104 bytes is made available locally on that tunnel interface. In case the GRE or mGRE interface is in protected mode, 110 bytes is requested on the respective link. This IP overhead does not affect the bandwidth signaled via RSVP. ip rsvp udp-multicastsTo instruct the router to generate User Datagram Protocol (UDP)-encapsulated Resource Reservation Protocol (RSVP) multicasts whenever it generates an IP-encapsulated multicast packet, use the iprsvpudp-multicastscommand in interface configuration mode. To disable this function, use the no form of this command. Command DefaultThe generation of UDP multicasts is disabled. If a system sends a UDP-encapsulated RSVP message to the router, the router begins using UDP for contact with the neighboring system. The router uses multicast address 224.0.0.14 and starts sending to UDP port 1699. If the command is entered with no specifying multicast address, the router uses the same multicast address. Command History
Usage GuidelinesUse this command to instruct a router to generate UDP-encapsulated RSVP multicasts whenever it generates an IP-encapsulated multicast packet. Some hosts require this trigger from the router. RSVP cannot be configured with VIP-distributed Cisco Express Forwarding (dCEF). ExamplesThe following example reserves up to 7500 kbps on Ethernet interface 2, with up to 1 Mbps per flow. The router is configured to use UDP encapsulation with the multicast address 224.0.0.14. interface ethernet 2 ip rsvp bandwidth 7500 1000 ip rsvp udp-multicasts 224.0.0.14 Related Commands
ip rtp compression-connectionsTo specify the total number of Real-Time Transport Protocol (RTP) header compression connections that can exist on an interface, use the iprtpcompression-connectionscommand in interface configuration mode. To restore the default value, use the no form of this command. Command DefaultFor PPP and High-Level Data Link Control (HDLC) interfaces, the default is 16 compression connections. For Frame Relay interfaces, the default is 256 compression connections. Command History
Usage GuidelinesYou should configure one connection for each RTP call through the specified interface. Each connection sets up a compression cache entry, so you are in effect specifying the maximum number of cache entries and the size of the cache. Too few cache entries for the specified interface can lead to degraded performance, and too many cache entries can lead to wasted memory.
ExamplesThe following example changes the number of RTP header compression connections supported to 150: Router> enable Router# configure terminal Router(config)# interface Serial1/0.0 Router(config-if)# encapsulation ppp Router(config-if)# ip rtp header-compression Router(config-if)# ip rtp compression-connections 150 Router(config-if)# end ip rtp header-compressionTo enable Real-Time Transport Protocol ( RTP) header compression, use the iprtpheader-compressioncommand in interface configuration mode. To disable RTP header compression, use the no form of this command.
ip
rtp
header-compression
[passive | iphc-format | ietf-format]
[periodic-refresh]
no
ip
rtp
header-compression
[passive | iphc-format | ietf-format]
[periodic-refresh]
Syntax Description
Command DefaultDisabled For PPP interfaces, the default format for header compression is the IPHC format. For High-Level Data Link Control (HDLC) and Frame Relay interfaces, the default format for header compression is the original proprietary Cisco format. The maximum number of compression connections for the proprietary Cisco format is 256. Command History
Usage GuidelinesCompressing Headers You can compress IP/User Datagram Protocol (UDP)/RTP headers to reduce the size of your packets. Compressing headers is especially useful for RTP because RTP payload size can be as small as 20 bytes, and the uncompressed header is 40 bytes. The passive Keyword By default, the iprtpheader-compression command compresses outgoing RTP traffic. If you specify the passive keyword, outgoing RTP traffic is compressed only if incoming RTP traffic on the same interface is compressed. If you do not specify the passive keyword, all outgoing RTP traffic is compressed. The passive keyword is ignored on PPP interfaces. PPP interfaces negotiate the use of header-compression, regardless of whether the passive keyword is specified. Therefore, on PPP interfaces, the passive keyword is replaced by the IPHC format, the default format for PPP interfaces. The iphc-format Keyword The iphc-format keyword indicates that the IPHC format of header compression that will be used. For PPP and HDLC interfaces, when the iphc-format keyword is specified, TCP header compression is also enabled. For this reason, the iptcpheader-compression command appears in the output of the showrunning-config command. Since both RTP header compression and TCP header compression are enabled, both UDP packets and TCP packets are compressed. The iphc-format keyword includes checking whether the destination port number is even and is in the ranges of 16,385 to 32,767 (for Cisco audio) or 49,152 to 65,535 (for Cisco video). Valid RTP packets that meet the criteria (that is, the port number is even and is within the specified range) are compressed using the compressed RTP packet format. Otherwise, packets are compressed using the less-efficient compressed non-TCP packet format. The iphc-format keyword is not available for interfaces that use Frame Relay encapsulation.
The ietf-format Keyword The ietf-formatkeyword indicates that the IETF format of header compression will be used. For HDLC interfaces, theietf-formatkeyword compresses only UDP packets. For PPP interfaces, when the ietf-format keyword is specified, TCP header compression is also enabled. For this reason, the iptcpheader-compression command appears in the output of the showrunning-config command. Since both RTP header compression and TCP header compression are enabled, both UDP packets and TCP packets are compressed. With the ietf-format keyword, any even destination port number higher than 1024 can be used. Valid RTP packets that meet the criteria (that is, the port number is even and is higher than 1024) are compressed using the compressed RTP packet format. Otherwise, packets are compressed using the less-efficient compressed non-TCP packet format. The ietf-format keyword is not available for interfaces that use Frame Relay encapsulation.
Support for Serial Lines RTP header compression is supported on serial lines using Frame Relay, HDLC, or PPP encapsulation. You must enable compression on both ends of a serial connection. Unicast or Multicast RTP Packets This command can compress unicast or multicast RTP packets, and, hence, multicast backbone (MBONE) traffic can also be compressed over slow links. The compression scheme is beneficial only when you have small payload sizes, as in audio traffic. Custom or Priority Queueing When you use theiprtpheader-compression command and configure custom or priority queueing on an encapsulated HDLC or Frame Relay interface, the compressed packets may go to the default queue instead of the user-defined queue, which results in protocol flaps (loss of keepalives). Therefore, we recommend that you use the Modular Quality of Service (QoS) Command-Line Interface (CLI) (MQC) model for configuring QoS features. ExamplesThe following example enables RTP header compression on the Serial1/0 interface and limits the number of RTP header compression connections to 10. In this example, the optional iphc-format keyword of theiprtpheader-compressioncommand is specified. Router> enable Router# configure terminal Router(config)# interface Serial1/0 Router(config-if)# encapsulation ppp Router(config-if)# ip rtp header-compression iphc-format Router(config-if)# ip rtp compression-connections 10 Router(config-if)# end The following example enables RTP header compression on the Serial2/0 interface and limits the number of RTP header compression connections to 20. In this example, the optional ietf-format keyword of theiprtpheader-compressioncommand is specified. Router> enable Router# configure terminal Router(config)# interface Serial2/0 Router(config-if)# encapsulation ppp Router(config-if)# ip rtp header-compression ietf-format Router(config-if)# ip rtp compression-connections 20 Router(config-if)# end In the following example, RTP header compression is enabled on the Serial1/0 interface and the optional periodic-refresh keyword of theiprtpheader-compressioncommand is specified: Router> enable Router# configure terminal Router(config)# interface Serial1/0 Router(config-if)# encapsulation ppp Router(config-if)# ip rtp header-compression iphc-format periodic-refresh Router(config-if)# ip rtp compression-connections 10 Router(config-if)# end Related Commands
ip rtp priority
To reserve a strict priority queue for a set of Real-Time Transport Protocol (RTP) packet flows belonging to a range of User Datagram Protocol (UDP) destination ports, use the iprtppriority command in interface configuration mode. To disable the strict priority queue, use the no form of this command. Syntax Description
Command History
Usage GuidelinesThis command is most useful for voice applications, or other applications that are delay-sensitive. This command extends and improves on the functionality offered by the iprtpreserve command by allowing you to specify a range of UDP/RTP ports whose voice traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first--that is, before packets in other queues are dequeued. We recommend that you use the iprtppriority command instead of the iprtpreserve command for voice configurations. This command can be used in conjunction with either weighted fair queueing (WFQ) or class-based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; voice packets in the priority queue are always serviced first. Remember the following guidelines when using the iprtppriority command:
Remember the following guidelines when configuring the bandwidth argument:
For more information on IP RTP Priority bandwidth allocation, refer to the section "IP RTP Priority" in the chapter "Congestion Management Overview" in the Cisco IOS Quality of Service Solutions Configuration Guide. ExamplesThe following example first defines a CBWFQ configuration and then reserves a strict priority queue with the following values: a starting RTP port number of 16384, a range of 16383 UDP ports, and a maximum bandwidth of 40 kbps: ! The following commands define a class map: class-map class1 match access-group 101 exit ! The following commands create and attach a policy map: policy-map policy1 class class1 bandwidth 3000 queue-limit 30 random-detect random-detect precedence 0 32 256 100 exit interface Serial1 service-policy output policy1 ! The following command reserves a strict priority queue: ip rtp priority 16384 16383 40 Related Commands
ip tcp compression-connectionsTo specify the total number of Transmission Control Protocol (TCP) header compression connections that can exist on an interface, use the ip tcp compression-connections command in interface configuration mode.To restore the default, use the noform of this command. Command DefaultFor PPP and High-Level Data Link Control (HDLC) interfaces, the default is 16 compression connections. For Frame Relay interfaces, the default is 256 compression connections. Command History
Usage GuidelinesYou should configure one connection for each TCP connection through the specified interface. Each connection sets up a compression cache entry, so you are in effect specifying the maximum number of cache entries and the size of the cache. Too few cache entries for the specified interface can lead to degraded performance, and too many cache entries can lead to wasted memory.
ExamplesThe following example sets the first serial interface for header compression with a maximum of ten cache entries: Router> enable Router# configure terminal Router(config)# interface serial 0 Router(config-if)# ip tcp header-compression Router(config-if)# ip tcp compression-connections 10 Router(config-if)# end ip tcp header-compressionTo enable Transmission Control Protocol (TCP) header compression, use the ip tcp header-compression command in interface configuration mode.To disable compression, use the noform of this command.
ip
tcp
header-compression
[passive | iphc-format | ietf-format]
no
ip
tcp
header-compression
[passive | iphc-format | ietf-format]
Syntax Description
Command DefaultFor PPP interfaces, the default format for header compression is the IPHC format. For High-Level Data Link Control (HDLC) and Frame Relay interfaces, the default format is as described in RFC 1144, Compressing TCP/IP Headers for Low-Speed Serial Links. Command History
Usage GuidelinesYou can compress the headers of your TCP/IP packets in order to reduce the size of your packets. TCP header compression is supported on serial lines using Frame Relay, HDLC, or PPP encapsulation. You must enable compression on both ends of a serial connection. Compressing the TCP header can speed up Telnet connections dramatically. In general, TCP header compression is advantageous when your traffic consists of many small packets, not for traffic that consists of large packets. Transaction processing (usually using terminals) tends to use small packets and file transfers use large packets. This feature only compresses the TCP header, so it has no effect on User Datagram Protocol (UDP) packets or other protocol headers. The passive Keyword By default, the ip tcp header-compression command compresses outgoing TCP traffic. If you specify the passive keyword, outgoing TCP traffic is compressed only if incoming TCP traffic on the same interface is compressed. If you do not specify the passive keyword, all outgoing TCP traffic is compressed. For PPP interfaces, the passive keyword is ignored. PPP interfaces negotiate the use of header-compression, regardless of whether the passive keyword is specified. Therefore, on PPP interfaces, the passive keyword is replaced by the IPHC format, the default format for PPP interfaces. The iphc-format Keyword The iphc-format keyword indicates that the IPHC format of header compression will be used. For PPP and HDLC interfaces, when the iphc-format keyword is specified, Real-Time Transport Protocol (RTP) header compression is also enabled. For this reason, the ip rtp header-compression command appears in the output of the show running-config command. Since both TCP header compression and RTP header compression are enabled, both TCP packets and UDP packets are compressed. The iphc-format keyword is not available for interfaces that use Frame Relay encapsulation.
The ietf-format Keyword The ietf-format keyword indicates that the IETF format of header compression will be used. For HDLC interfaces, the ietf-format keyword compresses only TCP packets. For PPP interfaces, when the ietf-format keyword is specified, RTP header compression is also enabled. For this reason, the ip rtp header-compression command appears in the output of the show running-config command. Since both TCP header compression and RTP header compression are enabled, both TCP packets and UDP packets are compressed. The ietf-format keyword is not available for interfaces that use Frame Relay encapsulation.
ExamplesThe following example sets the first serial interface for header compression with a maximum of ten cache entries: Router> enable Router# configure terminal Router(config)# interface serial 0 Router(config-if)# ip tcp header-compression Router(config-if)# ip tcp compression-connections 10 Router(config-if)# end The following example enables RTP header compression on the Serial1/0.0 subinterface and limits the number of RTP header compression connections to 10. In this example, the optional iphc-format keyword of the ip tcp header-compression command is specified. Router> enable Router# configure terminal Router(config)# interface Serial1/0.0 Router(config-if)# encapsulation ppp Router(config-if)# ip tcp header-compression iphc-format Router(config-if)# ip tcp compression-connections 10 Router(config-if)# end The following example enables RTP header compression on the Serial2/0.0 subinterface and limits the number of RTP header compression connections to 20. In this example, the optional ietf-format keyword of the ip tcp header-compression command is specified. Router> enable Router# configure terminal Router(config)# interface Serial2/0.0 Router(config-if)# encapsulation ppp Router(config-if)# ip tcp header-compression ietf-format Router(config-if)# ip tcp compression-connections 20 Router(config-if)# end Related Commands
iphc-profileTo create an IP Header Compression (IPHC) profile and to enter IPHC-profile configuration mode, use the iphc-profile command in global configuration mode. To attach an existing IPHC profile to an interface or subinterface, use the iphc-profile command in interface configuration mode. To delete the IPHC profile, use the no form of this command. Syntax Description
Command Modes
Usage GuidelinesThe iphc-profile command creates an IPHC profile used for enabling header compression and enters IPHC-profile configuration mode (config-iphcp). An IPHC profile is a template within which you can configure the type of header compression that you want to use, enable any optional features and settings for header compression, and then apply the profile to an interface, a subinterface, or a Frame Relay permanent virtual circuit (PVC). Specifying the IPHC Profile Type When you create an IPHC profile, you must specify the IPHC profile type by using either the ietf keyword or the van-jacobson keyword. The IETF profile type conforms to and supports the standards established with RFC 2507, RFC 2508, RFC 3544, and RFC 3545 and is typically associated with non-TCP header compression (for example, RTP header compression). The Van Jacobson profile type conforms to and supports the standards established with RFC 1144 and is typically associated with TCP header compression.
Considerations When Specifying the IPHC Profile Type When specifying the IPHC profile type, consider whether you are compressing TCP traffic or non-TCP traffic (that is, RTP traffic). Also consider the header compression format capabilities of the remote network link that will receive traffic. The IPHC profile type that you specify directly affects the header compression format used on the remote network links to which the IPHC profile is applied. Only TCP traffic is compressed on remote network links using a Van Jacobson IPHC profile, whereas TCP and/or non-TCP traffic (for example, RTP traffic) is compressed on remote network links using an IETF IPHC profile.
Configurable Header Compression Features and Settings The specific set of header compression features and settings that you can configure (that is, enable or modify) is determined by the IPHC profile type that you specify (either IETF or Van Jacobson) when you create the IPHC profile. Both sets are listed below. If you specify Van Jacobson as the IPHC profile type, you can enable TCP header compression and set the number of TCP contexts. The table below lists each available Van Jacobson IPHC profile type header compression feature and setting and the command used to enable it.
If you specify IETF as the IPHC profile type, you can enable non-TCP header compression (that is, RTP header compression), along with a number of additional features and settings. The table below lists each available IETF IPHC profile type header compression feature and setting and the command or commands used to enable it.
For More Information About IPHC Profiles For more information about using IPHC profiles to configure header compression, see the "Header Compression" module and the "Configuring Header Compression Using IPHC Profiles" module of the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T. ExamplesIn the following example, an IPHC profile called profile1 is created, and the Van Jacobson IPHC profile type is specified. Router> enable Router# configure terminal Router(config)# iphc-profile profile1 van-jacobson Router(config-iphcp)# end In the following example, a second IPHC profile called profile2 is created. For this IPHC profile, the IETF IPHC profile type is specified. Router> enable Router# configure terminal Router(config)# iphc-profile profile2 ietf Router(config-iphcp)# end In the following example, an existing IPHC profile called profile2 is attached to serial interface 3/0. For this IPHC profile, the IPHC profile type (in this case, IETF) of profile2 is specified. Router> enable Router# configure terminal Router(config)# interface serial 3/0 Router(config-if)# iphc-profile profile2 ietf Router(config-iphcp)# end Related Commands
lane client qosTo apply a LAN Emulation (LANE) quality of service (QoS) database to an interface, use the laneclient qos command in subinterface configuration mode. To remove the QoS over LANE feature from the interface, use the no form of this command. Command History
ExamplesThis example shows how to apply a LANE QoS database to a subinterface:
Router(config-subif)# lane client qos user1
Related Commands
lane qos databaseTo build the LAN Emulation (LANE) quality-of-service database, use the laneqosdatabasecommand in global configuration mode. To remove a LANE QoS database name, use the no form of this command. Command History
Usage GuidelinesThis command specifies a named database of QoS parameters. The database can be applied on the subinterfaces on which a LANE client is configured. ExamplesThis example shows how to begin configuring a QoS over LANE database named user1 on a Catalyst 5000 family ATM switch: ATM# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATM(config)# lane qos database user1 This example shows how to begin configuring a QoS over LANE database named user2 on a router: Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# lane qos database user2 load protocolTo load a protocol header description file (PHDF) onto a router, use the loadprotocolcommand in global configuration mode. To unload all protocols from a specified location or a single protocol, use the no form of this command. Syntax Description
Usage GuidelinesFlexible packet matching allows users to classify traffic on the basis of any portion of a packet header given the protocol field, length, and pattern. Protocol headers are defined in separate files called PHDFs; the field names that are defined within the PHDFs are used for defining the packet filters. A PHDF is a file that allows the user to leverage the flexibility of extensible markup language (XML) to describe almost any protocol header. The important components of the PHDF are the version, the XML file schema location, and the protocol field definitions. The protocol field definitions name the appropriate field in the protocol header, allow for a comment describing the field, provide the location of the protocol header field in the header (the offset is relative to the start of the protocol header), and provide the length of the field. Users can choose to specify the measurement in bytes or in bits.
In case of a redundant setup, users should ensure all PHDFs that are used in the flexible packet matching configuration are present on the corresponding standby disk. If the PHDFs are not on standby disk, all flexible packet matching policies using the PHDFs will be broken. Users can write their own custom PHDFs via XML. However, the following standard PHDFs can also be loaded onto the router: ip.phdf, ether.phdf, tcp.phdf, and udp.phdf. Standard PHDFs are available on Cisco.com at the following URL: http://www.cisco.com/pcgi-bin/tablebuild.pl/fpm Because PHDFs are defined via XML, they are not shown in a running configuration. Issue the loadprotocol command to apply filters to a protocol by defining and loading a PHDF for that protocol header. ExamplesThe following example shows how to configure FPM for blaster packets. The class map contains the following match criteria: TCP port 135, 4444 or UDP port 69; and pattern 0x0030 at 3 bytes from start of IP header. load protocol disk2:ip.phdf load protocol disk2:tcp.phdf load protocol disk2:udp.phdf class-map type stack match-all ip-tcp match field ip protocol eq 0x6 next tcp class-map type stack match-all ip-udp match field ip protocol eq 0x11 next udp class-map type access-control match-all blaster1 match field tcp dest-port eq 135 match start 13-start offset 3 size 2 eq 0x0030 class-map type access-control match-all blaster2 match field tcp dest-port eq 4444 match start 13-start offset 3 size 2 eq 0x0030 class-map type access-control match-all blaster3 match field udp dest-port eq 69 match start 13-start offset 3 size 2 eq 0x0030 policy-map type access-control fpm-tcp-policy class blaster1 drop class blaster2 drop policy-map type access-control fpm-udp-policy class blaster3 drop policy-map type access-control fpm-policy class ip-tcp service-policy fpm-tcp-policy class ip-udp service-policy fpm-udp-policy interface gigabitEthernet 0/1 service-policy type access-control input fpm-policy The following example is the XML setup for the PHDF "ip.phdf:" <?xml version="1.0" encoding="UTF-8"?> <phdf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchem aLocation="D:\harinadh\Doc\Projects\FPME\XML\ex.xsd"> <protocol name="ip" description="Definition-for-the-IP-protocol"> <field name="version" description="IP-version"> <offset type="fixed-offset" units="bits"> 0 </offset> <length type="fixed" units="bits">4</length> </field> <field name="ihl" description="IP-Header-Length"> <offset type="fixed-offset" units="bits">4</offset> <length type="fixed" units="bits">4</length> </field> <field name="tos" description="IP-Type-of-Service"> <offset type="fixed-offset" units="bits">8</offset> <length units="bits" type="fixed">8</length> </field> <field name="length" description="IP-Total-Length"> <offset type="fixed-offset" units="bytes">2</offset> <length type="fixed" units="bytes">2</length> </field> <field name="identification" description="IP-Identification"> <offset type="fixed-offset" units="bytes">4</offset> <length type="fixed" units="bytes">2</length> </field> <field name="flags" description="IP-Fragmentation-Flags"> <offset type="fixed-offset" units="bytes">6</offset> <length type="fixed" units="bits">3</length> </field> <field name="fragment-offset" description="IP-Fragmentation-Offset"> <offset type="fixed-offset" units="bits">51</offset> <length type="fixed" units="bits">13</length> </field> <field name="ttl" description="Definition-for-the-IP-TTL"> <offset type="fixed-offset" units="bytes">8</offset> <length type="fixed" units="bytes">1</length> </field> <field name="protocol" description="IP-Protocol"> <offset type="fixed-offset" units="bytes">9</offset> <length type="fixed" units="bytes">1</length> </field> <field name="checksum" description="IP-Header-Checksum"> <offset type="fixed-offset" units="bytes">10</offset> <length type="fixed" units="bytes">2</length> </field> <field name="source-addr" description="IP-Source-Address"> <offset type="fixed-offset" units="bytes">12</offset> <length type="fixed" units="bytes">4</length> </field> <field name="dest-addr" description="IP-Destination-Address"> <offset type="fixed-offset" units="bytes">16</offset> <length type="fixed" units="bytes">4</length> </field> <headerlength type="fixed" value="20"></headerlength> </protocol> </phdf> © 2012 Cisco Systems, Inc. All rights reserved.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|