Table Of Contents
Prerequisites for RSVP—Previous Hop Overwrite
Restrictions for RSVP—Previous Hop Overwrite
Information About RSVP—Previous Hop Overwrite
Feature Overview of RSVP—Previous Hop Overwrite
Benefits of RSVP—Previous Hop Overwrite
How to Configure RSVP—Previous Hop Overwrite
Configuring a Source Address or a Source Interface
Verifying the PHOP Configuration
Configuration Examples for RSVP—Previous Hop Overwrite
Configuring RSVP—Previous Hop Overwrite: Examples
Verifying RSVP—Previous Hop Overwrite Configuration: Examples
Feature Information for RSVP—Previous Hop Overwrite
RSVP—Previous Hop Overwrite
First Published: July 11, 2008Last Updated: July 11, 2008The RSVP—Previous Hop Overwrite feature allows you to configure a Resource Reservation Protocol (RSVP) router, on a per interface basis, 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. You can configure the actual address for the router to use or an interface, including a loopback, from which to borrow the address.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for RSVP—Previous Hop Overwrite" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for RSVP—Previous Hop Overwrite
•
Restrictions for RSVP—Previous Hop Overwrite
•
Information About RSVP—Previous Hop Overwrite
•
How to Configure RSVP—Previous Hop Overwrite
•
Configuration Examples for RSVP—Previous Hop Overwrite
•
Feature Information for RSVP—Previous Hop Overwrite
Prerequisites for RSVP—Previous Hop Overwrite
You must configure RSVP on one or more interfaces on at least two neighboring routers that share a link within the network.
Restrictions for RSVP—Previous Hop Overwrite
•
This feature is supported only on integrated services routers (ISRs).
•
Unnumbered IP addresses are not allowed.
Information About RSVP—Previous Hop Overwrite
To use the RSVP—Previous Hop Overwrite feature, you should understand the following concepts:
•
Feature Overview of RSVP—Previous Hop Overwrite
•
Benefits of RSVP—Previous Hop Overwrite
Feature Overview of RSVP—Previous Hop Overwrite
An RSVP PATH message contains a PHOP object that is rewritten at every RSVP hop. The object's purpose is to enable an RSVP router (R1) sending a PATH message to convey to the next RSVP router (R2) downstream that the previous RSVP hop is R1. R2 uses this information to forward the corresponding RESV message upstream hop-by-hop towards the sender.
The current behavior in Cisco IOS software is that an RSVP router always sets the PHOP address to the IP address of the egress interface onto which the router transmits the PATH message.
There are situations where, although some IP addresses of R1 are reachable, the IP address of its egress interface is not reachable from a remote RSVP router R2. This results in the corresponding RESV message generated by R2 never reaching R1 and the reservation never being established.
Figure 1 shows a sample network in which the preceding scenario occurs and no reservation is established.
Figure 1 Sample PHOP Network with Unified Communcations Manager (CM)
In Figure 1, when a call is made from branch office 1 to branch office 2, the RSVP Agent on customer edge (CE)1 tries to set up a session with CE2 and sends a PATH message. CE1 stamps its outgoing interface IP address (192.168.54.1), which is an unroutable IP address, in the PHOP object of the PATH message. This PATH message is tunneled across the service provider network and processed by CE2. CE2 records this IP address in the PHOP object of the received PATH message in the PSB (Path State Block).
CE2 has a receiver proxy configured for the destination address of the session. As a result, when CE2 replies back with a RESV message, CE2 tries to send the RESV message to the IP address that CE2 had recorded in its PSB. Because this IP address (192.168.54.1) is unroutable from CE2, the RESV message will fail.
Note
Once you configure a source address on an interface, RSVP always uses the RSVP-overwritten address rather than the native interface address.
Benefits of RSVP—Previous Hop Overwrite
Flexibility and Customization
You can configure a CE to populate the PHOP object in a PATH message with an address that is reachable in the customer VPN. This enables the RESV message to find its way back towards the sender so that reservations can be established.
How to Configure RSVP—Previous Hop Overwrite
This section contains the following procedures:
•
Configuring a Source Address or a Source Interface (required)
•
Verifying the PHOP Configuration (optional)
Configuring a Source Address or a Source Interface
Perform this task to configure a source address or a source interface.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type number
4.
ip rsvp bandwidth [interface-kbps] [single-flow-kbps]
5.
ip rsvp source {address ip-address | interface type number}
6.
end
DETAILED STEPS
Verifying the PHOP Configuration
Perform this task to verify the PHOP configuration.
Note
You can use the following show command in user EXEC or privileged EXEC mode.
SUMMARY STEPS
1.
enable
2.
show ip rsvp interface [detail] [interface-type interface-number]
3.
exit
DETAILED STEPS
Configuration Examples for RSVP—Previous Hop Overwrite
This section provides the following configuration examples for RSVP—Previous Hop Overwrite:
•
Configuring RSVP—Previous Hop Overwrite: Examples
•
Verifying RSVP—Previous Hop Overwrite Configuration: Examples
Configuring RSVP—Previous Hop Overwrite: Examples
This section contains the following configuration examples:
•
Configuring a Source Address on Router CE1 for the CE1-to-PE1 Interface
•
Configuring a Source Address on Router CE2 for the CE2-to-PE2 Interface
•
Creating a Listener Proxy on Router C2
•
Creating a Session from Router C1 to Router C2
Figure 2 shows a sample network in which PHOP is configured.
Figure 2 Sample PHOP Network
Configuring a Source Address on Router CE1 for the CE1-to-PE1 Interface
The following example configures a source address on the CE1-to-PE1 (Ethernet 1/0) interface in Figure 2:
Router(CE1)# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(CE1)(config)# interface ethernet 1/0Router(CE1)(config-if)# ip rsvp source address 10.2.2.2 <--------------------Router(CE1)(config-if)# endConfiguring a Source Address on Router CE2 for the CE2-to-PE2 Interface
The following example configures a source address on the CE2-to-PE2 (Ethernet 0/0) interface in Figure 2:
Router(CE2)# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(CE2)(config)# interface ethernet 0/0Router(CE2)(config-if)# ip rsvp source address 10.6.6.6 <---------------------Router(CE2)(config-if)# endCreating a Listener Proxy on Router C2
The following example creates a listener proxy on Router C2 and requests that the receiver reply with a RESV message for the flow if the PATH message destination is 10.7.7.7 in Figure 2:
Router(C2)# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(C2)(config)# ip rsvp listener 10.7.7.7 any any reply <--------------------Router(C2)(config)# endCreating a Session from Router C1 to Router C2
The following example creates an RSVP session from Router C1 to Router C2:
Router(C1)# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(C1)(config)# ip rsvp sender-host 10.7.7.7 10.1.1.1 UDP 100 200 1 1 <-------------Router(C1)(config)# endVerifying RSVP—Previous Hop Overwrite Configuration: Examples
This section contains the following verification examples:
•
Verifying the Source Address on Router CE1 for the CE1-to-PE1 Interface
•
Verifying the Source Address on Router CE2 for the CE2-to-PE2 Interface
•
Verifying the Listener Proxy on Router C2
•
Verifying the Session from Router C1 to Router C2
•
Verifying the Next-Hop Address
Verifying the Source Address on Router CE1 for the CE1-to-PE1 Interface
The following example verifies the source address (10.2.2.2) configured on the CE1-to-PE1 (Ethernet 1/0) interface in Figure 2:
Router(CE1)# show ip rsvp interface detail ethernet 1/0Et1/0:RSVP: EnabledInterface State: UpBandwidth:Curr allocated: 1K bits/secMax. allowed (total): 100K bits/secMax. allowed (per flow): 100K bits/secMax. allowed for LSP tunnels using sub-pools: 0 bits/secSet aside by policy (total): 0 bits/secAdmission Control:Header Compression methods supported:rtp (36 bytes-saved), udp (20 bytes-saved)Traffic Control:RSVP Data Packet Classification is ON via CEF callbacksSignalling:DSCP value used in RSVP msgs: 0x3FNumber of refresh intervals to enforce blockade state: 4Ip address used in RSVP objects: 10.2.2.2 <------------------------------------Authentication: disabledKey chain: <none>Type: md5Window size: 1Challenge: disabledHello Extension:State: DisabledVerifying the Source Address on Router CE2 for the CE2-to-PE2 Interface
The following example verifies the source address configured on the CE2-to-PE2 (Ethernet 0/0) interface in Figure 2:
Router(CE2)# show ip rsvp interface detail ethernet 0/0Et0/0:RSVP: EnabledInterface State: UpBandwidth:Curr allocated: 0 bits/secMax. allowed (total): 100K bits/secMax. allowed (per flow): 100K bits/secMax. allowed for LSP tunnels using sub-pools: 0 bits/secSet aside by policy (total): 0 bits/secAdmission Control:Header Compression methods supported:rtp (36 bytes-saved), udp (20 bytes-saved)Traffic Control:RSVP Data Packet Classification is ON via CEF callbacksSignalling:DSCP value used in RSVP msgs: 0x3FNumber of refresh intervals to enforce blockade state: 4Ip address used in RSVP objects: 10.6.6.6 <-----------------------------------Authentication: disabledKey chain: <none>Type: md5Window size: 1Challenge: disabledHello Extension:State: DisabledVerifying the Listener Proxy on Router C2
The following example verifies the listener proxy configured on Router C2 in Figure 2:
Router(C2)# show ip rsvp listenersTo Protocol DPort Description Action10.7.7.7 <-------- any any RSVP Proxy replyVerifying the Session from Router C1 to Router C2
The following example verifies that the session configured between Router C1 and Router C2 in Figure 2 is up:
Router(C1)# show ip rsvp reservationTo From Pro DPort Sport Next Hop I/F Fi Serv BPS10.7.7.7 10.1.1.1 UDP 100 200 10.1.2.21 Et0/0 FF RATE 1KVerifying the PHOP Address
The following example on Router CE2 verifies the source address configured on the CE1-to-PE1 interface in Figure 2 as the PHOP address:
Router(CE2)# show ip rsvp sender detailPATH:Destination 10.7.7.7, Protocol_Id 17, Don't Police , DstPort 100Sender address: 10.1.1.1, port: 200Path refreshes:arriving: from PHOP 10.2.2.2 on Et0/0 every 30000 msecs <-------------------Traffic params - Rate: 1K bits/sec, Max. burst: 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytesPath ID handle: CA000406.Incoming policy: Accepted. Policy source(s): DefaultStatus:Output on Ethernet1/0. Policy status: Forwarding. Handle: 0E000402Policy source(s): DefaultVerifying the Next-Hop Address
The following example on Router CE1 verifies the source address configured on the CE2-to-PE2 interface in Figure 2 as the next-hop address:
Router(CE1)# show ip rsvp reservation detailRSVP Reservation. Destination is 10.7.7.7, Source is 10.1.1.1,Protocol is UDP, Destination port is 100, Source port is 200Next Hop: 10.6.6.6 on Ethernet1/0 <---------------------------------------------Reservation Style is Fixed-Filter, QoS Service is Guaranteed-RateResv ID handle: 03000400.Created: 07:01:40 IST Tue Mar 25 2008Average Bitrate is 1K bits/sec, Maximum Burst is 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size: 0 bytesStatus:Policy: Forwarding. Policy source(s): DefaultAdditional References
The following sections provide references related to the RSVP—Previous Hop Overwrite feature.
Related Documents
Standards
Standard TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
Technical Assistance
Command Reference
The following commands are introduced or modified in the feature or features documented in this module. For information about these commands, see the Cisco IOS Quality of Service Solutions Command Reference at http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_book.html. For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or the Cisco IOS Master Command List, All Releases, at http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html.
•
debug ip rsvp
•
ip rsvp source
•
show ip rsvp interface
Feature Information for RSVP—Previous Hop Overwrite
Table 1 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Glossary
QoS—quality of service. A measure of performance for a transmission system that reflects its transmission quality and service availability.
RSVP—Resource Reservation Protocol. A protocol that supports the reservation of resources across an IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature (bandwidth, jitter, maximum burst, and so on) of the packet streams that they want to receive.
RSVP Agent—Implements a Resource Reservation Protocol (RSVP) agent on Cisco IOS voice gateways that support Unified CM.
Unified Communcations Manager (CM)—The software-based, call-processing component of the Cisco IP telephony solution. The software extends enterprise telephony features and functions to packet telephony network devices such as IP phones, media processing devices, voice-over-IP (VoIP) gateways, and multimedia applications.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0807R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2008 Cisco Systems, Inc. All rights reserved.



