Feedback
|
Table Of Contents
Prerequisites for RSVP Local Policy Support
Restrictions for RSVP Local Policy Support
Information About RSVP Local Policy Support
Feature Design of RSVP Local Policy Support
Benefits of RSVP Local Policy Support
How to Configure RSVP Local Policy Support
Configuration Examples for RSVP Local Policy Support
RSVP Local Policy Support with Match on ACL: Example
RSVP Local Policy Support with Match on AS Number: Example
RSVP Local Policy Support
The Resource Reservation Protocol (RSVP) Local Policy Support feature allows network administrators to create controlled policies to restrict the resources that RSVP reservations are allowed to use.
Feature History for RSVP Local Policy Support
Release Modification12.2(13)T
This feature was introduced.
12.0(29)S
Support for Inter-autonomous system (AS) traffic engineering (TE) was added.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for RSVP Local Policy Support
•
Restrictions for RSVP Local Policy Support
•
Information About RSVP Local Policy Support
•
How to Configure RSVP Local Policy Support
•
Configuration Examples for RSVP Local Policy Support
Prerequisites for RSVP Local Policy Support
•
RSVP must be configured on two or more routers or on one router and one host within the network before you can use the RSVP Local Policy Support feature.
•
Traffic Engineering (TE) must be configured on two or more routers within the network before you can use the TE extensions.
•
Border Gateway Protocol (BGP) must be running in the network before you can configure autonomous system (AS)-based policies.
Restrictions for RSVP Local Policy Support
•
Interface-based policies are not supported in this release.
•
Named access control lists (ACLs) are not supported in this release.
•
RSVP policies apply only to Path, Resv, PathError, and ResvError messages.
Information About RSVP Local Policy Support
To configure RSVP Local Policy Support, you need to understand the following concepts:
•
Feature Design of RSVP Local Policy Support
•
Benefits of RSVP Local Policy Support
Feature Design of RSVP Local Policy Support
Network administrators need the ability to control the resources that RSVP reservations are allowed to use. For example, they may want to restrict RSVP reservations to certain subnets, autonomous systems (ASes), or from specific network servers.
The RSVP Local Policy Support feature allows network administrators to create default, ACL-, and AS-based policies. These policies, in turn, control how RSVP filters its signaling messages to allow or deny quality of service (QoS), as shown in Figure 1, to networking applications based on the IP addresses of the requesting hosts.
Figure 1 RSVP Local Policy Configuration
Benefits of RSVP Local Policy Support
RSVP Reservation Control
Network administrators can restrict the source and destination of RSVP reservations to specific endpoints.
RSVP Reservation Preemption
High priority reservations can preempt existing reservations if there is otherwise no bandwidth available for the new, high-priority reservation.
RSVP Local Policy Functionality Extended
Local policies can reject the following:
•
Path or Resv messages that exceed an upper bandwidth limit for a specific reservation
•
Path messages that cause an upper limit of the number of senders to be exceeded
•
Path or Resv messages that request preemption priority that is too high
•
Path messages that request Fast Reroute (TE only)
•
Path, Resv, PathError, or ResvError messages that originate from an unauthorized AS
How to Configure RSVP Local Policy Support
This section contains the following procedures:
•
Creating an RSVP Local Policy (required)
•
Verifying RSVP Local Policy (optional)
Creating an RSVP Local Policy
Perform this task to create an RSVP local policy.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip rsvp policy local {acl acl [acl1...acl8] | default | origin-as as [as1...as8]}
4.
{accept | forward [all | path | path-error | resv | resv-error] | default | exit | fast-reroute | local-override | maximum {bandwidth [group x] [single y] | senders n}| preempt-priority [traffic-eng x] start-priority [hold-priority]}
5.
end
DETAILED STEPS
Command or Action PurposeStep 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
ip rsvp policy local {acl acl [acl1...acl8] | default| origin-as as [as1...as8]}Example:Router(config)# ip rsvp policy local origin-as 1Creates a local policy to determine how RSVP resources are used in a network.
Note
Before entering the origin-as as keyword argument combination, you must have BGP running; otherwise, an RSVP warning message appears stating that the AS-based policy will be ineffective.
Step 4
{accept | forward [all | path | path-error | resv | resv-error] | default | exit | fast-reroute | local-override | maximum {bandwidth [group x] [single y] | senders n} | preempt-priority [traffic-eng x] start-priority [hold-priority]}Example:Router(config-rsvp-policy-local)# forward all
Enters local policy mode and defines the properties of the default, ACL- or AS-based local policy that you are creating. (These are the submodes.)
Note
This is an optional step. An empty policy rejects everything, which may be desired in some cases.
See the ip rsvp policy local command for more detailed information on submode commands.
Step 5
end
Example:Router(config-rsvp-policy-local)# end
Exits local policy mode and returns the router to privileged EXEC mode.
Verifying RSVP Local Policy
Perform this task to verify that the RSVP Local Policy Support feature is functioning.
SUMMARY STEPS
1.
enable
2.
show ip rsvp policy [local [acl [acl] | origin-as [as]]
3.
show ip rsvp policy local [acl [acl] | default | origin-as [as]] [detail]
4.
show ip rsvp reservation [detail | filter] {destination ipaddress | source ipaddress | dst-port pnum | src-port pnum}
5.
show ip rsvp sender [detail | filter] {destination ipaddress | source ipaddress | dst-port pnum | src-port pnum}
DETAILED STEPS
Examples
This section provides the following example output:
•
Sample Output for the show ip rsvp policy Command
•
Sample Output for the show ip rsvp policy local detail Command
•
Sample Output for the show ip rsvp reservation detail Command
•
Sample Output for the show ip rsvp sender detail Command
Sample Output for the show ip rsvp policy Command
In this example, the show ip rsvp policy command displays policy-related information including local and default policies and the preemption parameter configured—enabled or disabled.
Because there are no submode commands configured, all RSVP messages matching ACL 104 are rejected. The dashes (--) mean no local policies are accepted or forwarded; they are all rejected.
Router# show ip rsvp policyLocal policy:A=Accept F=ForwardPath:-- Resv:-- PathErr:-- ResvErr:-- ACL:104Path:-- Resv:-- PathErr:-- ResvErr:-- ACL:None [Default policy]Generic policy settings:Default policy: Accept all <--- used when no local policies are configuredPreemption: Disabled <--- used only for non-TE reservationsSample Output for the show ip rsvp policy local detail Command
In this example, the show ip rsvp policy local detail command displays information about the selected local policies currently configured.
The TE and non-TE priority information appears because preemption priority was configured. The senders information appears because the senders group bandwidth option was configured.
Router# show ip rsvp policy local detailLocal policy for ACL(s): 101Local Override: Disabled.Fast ReRoute: Accept.Accept ForwardPath: Yes YesResv: Yes YesPathError: Yes YesResvError: Yes YesSetup Priority Hold PriorityTE: 7 7Non-TE: 1 1Current LimitSenders: 1 32Group bandwidth (bps): 5K 0Local policy for ACL(s): 102Local Override: Disabled.Fast ReRoute: Accept.Accept ForwardPath: Yes YesResv: Yes YesPathError: Yes YesResvError: Yes YesSetup Priority Hold PriorityTE: 7 7Non-TE: 2 2Local policy for AS(es): defaultLocal Override: Disabled.Fast ReRoute: Accept.Accept ForwardPath: Yes YesResv: Yes YesPathError: Yes YesResvError: Yes YesSetup Priority Hold PriorityTE: 7 7Non-TE: 5 5Generic policy settings:Default policy: Accept allPreemption: EnabledSample Output for the show ip rsvp reservation detail Command
In this example, the show ip rsvp reservation detail command displays information, including local policies and preemption priorities, related to the Resv message arriving from downstream.
Router# show ip rsvp reservation detailReservation:Tun Dest: 192.168.104.3 Tun ID:1 Ext Tun ID:192.168.104.1Tun Sender:192.168.104.1 LSP ID:6Next Hop:noneLabel:1 (outgoing)Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadResv ID handle:7000041A.Created:13:00:34 UTC Thu Jun 24 2004Average Bitrate is 90K bits/sec, Maximum Burst is 1K bytesMin Policed Unit:0 bytes, Max Pkt Size:0 bytesStatus:ProxiedPolicy:Accepted. Policy source(s):MPLS/TE Local !local policiesPriorities - preempt:0, defend:0 !preemption prioritiesSample Output for the show ip rsvp sender detail Command
In this example, the show ip rsvp sender detail command displays information, including local policies and preemption priorities, related to the Path messages arriving from upstream.
Router# show ip rsvp sender detailPATH:Tun Dest: 192.168.104.1 Tun ID:3 Ext Tun ID:192.168.104.3Tun Sender:192.168.104.3 LSP ID:35Path refreshes:sent: to NHOP 192.168.106.1 on ATM1/0.1Session Attr:Setup Prio:7, Holding Prio:7Flags:(0x7) Local Prot desired, Label Recording, SE StyleSession Name:rsvp7206-3_t3ERO:(incoming)192.168.104.3 (Strict IPv4 Prefix, 8 bytes, /32)192.168.106.1 (Strict IPv4 Prefix, 8 bytes, /32)192.168.104.1 (Strict IPv4 Prefix, 8 bytes, /32)ERO:(outgoing)192.168.106.1 (Strict IPv4 Prefix, 8 bytes, /32)192.168.104.1 (Strict IPv4 Prefix, 8 bytes, /32)RRO:EmptyTraffic params - Rate:90K bits/sec, Max. burst:1K bytesMin Policed Unit:0 bytes, Max Pkt Size 4294967295 bytesFast-Reroute Backup info:Inbound FRR:Not activeOutbound FRR:No backup tunnel selectedPath ID handle:33000406.Incoming policy:Accepted. Policy source(s):MPLS/TE Local !local policiesPriorities - preempt:0, defend:0 !preemption prioritiesStatus:ProxiedOutput on ATM1/0.1. Policy status:Forwarding. Handle:33000408Policy source(s):MPLS/TE Local !local policiesPATH:Tun Dest: 192.168.104.3 Tun ID:1 Ext Tun ID:192.168.104.1Tun Sender:192.168.104.1 LSP ID:6Path refreshes:arriving:from PHOP 192.168.106.1 on AT1/0.1 every 30000 msecsSession Attr:Setup Prio:7, Holding Prio:7Flags:(0x7) Local Prot desired, Label Recording, SE StyleSession Name:rsvp7206-1_t1ERO:(incoming)192.168.106.2 (Strict IPv4 Prefix, 8 bytes, /32)192.168.104.3 (Strict IPv4 Prefix, 8 bytes, /32)RRO:192.168.106.1/32, Flags:0x0 (No Local Protection)Traffic params - Rate:90K bits/sec, Max. burst:1K bytesMin Policed Unit:0 bytes, Max Pkt Size 4294967295 bytesFast-Reroute Backup info:Inbound FRR:Not activeOutbound FRR:No backup tunnel selectedPath ID handle:2E000418.Incoming policy:Accepted. Policy source(s):MPLS/TE Local !local policiesPriorities - preempt:0, defend:0 !preemption prioritiesStatus:Proxy-terminatedConfiguration Examples for RSVP Local Policy Support
This section provides configuration examples for the RSVP Local Policy Support feature.
•
RSVP Local Policy Support with Match on ACL: Example
•
RSVP Local Policy Support with Match on AS Number: Example
RSVP Local Policy Support with Match on ACL: Example
In the following example, any RSVP nodes in the 192.168.101.0 subnet can initiate or respond to reservation requests, but all other nodes can respond only to reservation requests. This means that any 192.168.101.x node can send and receive Path, PathError, Resv, or ResvError messages. All other nodes can send only Resv or ResvError messages.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# access-list 104 permit ip 192.168.101.0 0.0.0.255 anyRouter(config)# ip rsvp policy local acl 104Router(config-rsvp-policy-local)# forward allRouter(config-rsvp-policy-local)# endRouter# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip rsvp policy local defaultRouter(config-rsvp-policy-local)# forward resvRouter(config-rsvp-policy-local)# forward resverrorRouter(config-rsvp-policy-local)# endRSVP Local Policy Support with Match on AS Number: Example
In order for a local policy to match an AS number for an RSVP message originating from a headend router in another AS, the IP address of the sender on the headend router must be routable in a BGP network. The internal routes in Interior Gateway Protocol (IGP) must be redistributed via BGP using route maps. Route maps allow certain internal networks to be advertised into BGP; in this case, External Border Gateway Protocol (eBGP).
In the following four-router configuration (Figure 2), ASBR1 and ASBR2 are connected via eBGP; AS100 and AS200 are connected to a headend router and a tailend router, respectively, via Open Shortest Path First (OSPF). Tunnel 11 is the primary TE tunnel between AS100 and AS200. A local policy is configured on ASBR2 to allow all RSVP traffic originating from AS100, but to reject all other reservation attempts.
Figure 2 Sample Configuration with ASBRs and ASes
The following example verifies the current configuration on ASBR1 in AS100.
Router# show runrouter ospf 10mpls traffic-eng router-id Loopback0mpls traffic-eng area 0log-adjacency-changespassive-interface Serial2/0network 145.2.2.2 0.0.0.0 area 0network 180.0.0.0 0.0.255.255 area 0network 180.3.0.0 0.0.255.255 area 0default-information originate always!router bgp 100 !AS100no synchronizationbgp log-neighbor-changesredistribute connectedredistribute ospf 10 match internal route-map internalneighbor 180.0.0.2 remote-as 200neighbor 180.1.0.2 remote-as 300no auto-summary!access-list 10 permit 145.1.1.1 !headend IP addressroute-map internal permit 10match ip address 10Router# show ip routeCodes:C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGPi - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODRGateway of last resort is not set3.0.0.0/16 is subnetted, 1 subnetsC 3.3.0.0 is directly connected, Ethernet1/0145.1.0.0/32 is subnetted, 1 subnetsO 145.1.1.1 [110/2] via 180.3.0.1, 22:32:12, FastEthernet0/0145.2.0.0/32 is subnetted, 1 subnetsC 145.2.2.2 is directly connected, Loopback0145.3.0.0/32 is subnetted, 1 subnetsB 145.3.3.3 [20/0] via 180.0.0.2, 23:11:02C 180.0.0.0/16 is directly connected, Serial2/0C 180.3.0.0/16 is directly connected, FastEthernet0/0B 180.6.0.0/16 [20/0] via 180.0.0.2, 23:11:03The following example on ASBR2 shows that a local policy is configured for AS100:
Router# debug ip rsvp policy1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-LOCAL - queryfor inbound Path message1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-LOCAL - Pathfrom 145.1.1.1 originated in AS 1001w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-LOCAL - usinglocal policy "AS(es):100" !local policy for AS1001w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-LOCAL - Pathaccepted1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-RRR - Path Query1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-RRR - incomingquery; idb=[Serial2/0]1w6d:RSVP-POLICY-RRR-LPM:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:IncomingPath accept1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:RSVP-POLICY - receiveddecision for Path message1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:RSVP-POLICY - acceptincoming message1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:RSVP-POLICY - Pathquery1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-LOCAL - queryfor outbound Path message1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-LOCAL - nodecision (can't find a matching policy)1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-RRR - Path Query1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:POLICY-RRR - outgoingquery; idb=[Ethernet1/1]1w6d:RSVP-POLICY-RRR-LPM:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:OutgoingPath accept1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:RSVP-POLICY - receiveddecision for Path message1w6d:RSVP:145.1.1.1_2393->145.4.4.4_11[145.1.1.1]:RSVP-POLICY - sendoutgoing message to Ethernet1/1
Note
You can enable policy debug output for a specific label-switched path (LSP) by creating an ACL for it and issuing the debug ip rsvp filter acl-num command. You need to specify User Data Protocol (UDP) as the IP protocol in the ACL.
The following example displays the local policy parameters configured on ASBR1 for AS100:
Router# show ip rsvp policy localLocal policy for AS(es):100 !local policy configured for AS100Local Override:Disabled.Fast ReRoute: Accept.Accept ForwardPath: Yes YesResv: Yes YesPathError: Yes YesResvError: Yes YesGeneric policy settings:Default policy:Default rejectPreemption: DisabledThe following example verifies the configuration on ASBR2:
Router# show runrouter ospf 10mpls traffic-eng router-id Loopback0mpls traffic-eng area 0log-adjacency-changespassive-interface Serial2/0network 145.3.3.3 0.0.0.0 area 0network 180.0.0.0 0.0.255.255 area 0network 180.6.0.0 0.0.255.255 area 0default-information originate always!router bgp 200 !AS200no synchronizationbgp log-neighbor-changesredistribute connectedneighbor 180.0.0.1 remote-as 100neighbor 180.2.0.2 remote-as 300no auto-summary!ip default-gateway 3.3.0.1ip classless!ip rsvp policy local origin-as 100 !local policy allowing traffic from AS100forward all!ip rsvp policy local default !local policy rejecting all other reservationsaccess-list 110 permit 0 any host 145.3.3.3access-list 110 permit 0 any host 145.4.4.4Router# show ip routeCodes:C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGPi - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODRGateway of last resort is not set3.0.0.0/16 is subnetted, 1 subnetsC 3.3.0.0 is directly connected, Ethernet1/0145.1.0.0/32 is subnetted, 1 subnetsB 145.1.1.1 [20/2] via 180.0.0.1, 01:10:19145.2.0.0/32 is subnetted, 1 subnetsB 145.2.2.2 [20/0] via 180.0.0.1, 23:13:03145.3.0.0/32 is subnetted, 1 subnetsC 145.3.3.3 is directly connected, Loopback0145.4.0.0/32 is subnetted, 1 subnetsO 145.4.4.4 [110/11] via 180.6.0.2, 23:15:41, Ethernet1/1C 180.0.0.0/16 is directly connected, Serial2/0B 180.3.0.0/16 [20/0] via 180.0.0.1, 23:13:04C 180.6.0.0/16 is directly connected, Ethernet1/1
Note
Unadvertised internal routes should not appear across AS boundary networks.
The following example verifies the configuration on the headend router:
Router# show runmpls traffic-eng tunnelsmpls traffic-eng reoptimize timers frequency 0no mpls traffic-eng auto-bw timers frequency 0!!!!!interface Loopback0ip address 145.1.1.1 255.255.255.255no ip directed-broadcastip rsvp bandwidth!interface Tunnel11 !primary tunnel between AS100 and AS200description Primary tunnel 36-1->72-1->36-2->72-2->75-1ip unnumbered Loopback0no ip directed-broadcastno logging event link-statustunnel destination 145.4.4.4tunnel mode mpls traffic-engtunnel mpls traffic-eng priority 7 7tunnel mpls traffic-eng bandwidth 10tunnel mpls traffic-eng path-option 1 explicit name main!interface Tunnel12description Inline tunnel 36-1->72-1->72-2ip unnumbered Loopback0no ip directed-broadcastno logging event link-statustunnel destination 145.3.3.3tunnel mode mpls traffic-engtunnel mpls traffic-eng priority 7 7tunnel mpls traffic-eng bandwidth 10tunnel mpls traffic-eng path-option 1 explicit name minor!interface FastEthernet2/0description Link to ASBRip address 180.3.0.1 255.255.0.0no ip directed-broadcastno keepalivempls traffic-eng tunnelsip rsvp bandwidth 1000!router ospf 10log-adjacency-changesmpls traffic-eng router-id Loopback0mpls traffic-eng area 0network 145.1.1.1 0.0.0.0 area 0network 180.3.0.0 0.0.255.255 area 0!ip default-gateway 3.3.0.1ip classlessip route 145.4.4.4 255.255.255.255 Tunnel11ip http server!!ip explicit-path name main enablenext-address 145.2.2.2next-address loose 145.3.3.3!ip explicit-path name pri enable!ip explicit-path name minor enablenext-address 145.2.2.2next-address loose 145.3.3.3!ip explicit-path name path1 enablenext-address 180.0.0.2next-address 180.0.1.2next-address 180.0.2.2!Router# show ip routeCodes:C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGPi - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODRGateway of last resort is 180.3.0.2 to network 0.0.0.03.0.0.0/16 is subnetted, 1 subnetsC 3.3.0.0 is directly connected, Ethernet0/0145.1.0.0/32 is subnetted, 1 subnetsC 145.1.1.1 is directly connected, Loopback0145.2.0.0/32 is subnetted, 1 subnetsO 145.2.2.2 [110/2] via 180.3.0.2, 22:31:13, FastEthernet2/0145.4.0.0/32 is subnetted, 1 subnetsS 145.4.4.4 is directly connected, Tunnel11O 180.0.0.0/16 [110/2] via 180.3.0.2, 22:31:13, FastEthernet2/0C 180.3.0.0/16 is directly connected, FastEthernet2/0O* E2 0.0.0.0/0 [110/1] via 180.3.0.2, 22:31:14, FastEthernet2/0The following example verifies the ASBR2 part of the configuration on the tailend router:
Router# show runmpls traffic-eng tunnelsno mpls traffic-eng auto-bw timers frequency 0!!!interface Loopback0ip address 145.4.4.4 255.255.255.255 !tailend IP addressno ip directed-broadcastip rsvp bandwidth!interface Ethernet2/1/1description Link to ASBR2 !ASBR2ip address 180.6.0.2 255.255.0.0no ip directed-broadcastmpls traffic-eng tunnelsip rsvp bandwidth!router ospf 10log-adjacency-changesmpls traffic-eng router-id Loopback0mpls traffic-eng area 0network 145.4.4.4 0.0.0.0 area 0network 180.6.0.0 0.0.255.255 area 0!ip default-gateway 3.3.0.1ip classless!Additional References
The following sections provide references related to the RSVP Local Policy Support feature.
Related Documents
Related Topic Document TitleRSVP commands: complete command syntax, command mode, defaults, usage guidelines, and examples
Cisco IOS Quality of Service Solutions Command Reference, Release 12.3 T
QoS features including signaling, classification, and congestion management
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.3
Inter-AS features including local policy support and per-neighbor keys authentication
MPLS Traffic Engineering—Inter-AS-TE feature module
Error messages
Cisco IOS Software System Error Messages
Other documentation
"MPLS Inter-AS Traffic Engineering Requirements," Internet draft, January 2004 [draft-ietf-tews-interas-mpls-te-reg-06.txt]; Zhang, R., Vasseur, JP, et. al.
Standards
Standards TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
RFCs TitleNo new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Command Reference
This section documents modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.3 command reference publications.
ip rsvp policy local
To create a local procedure that determines the use of Resource Reservation Protocol (RSVP) resources in a network, use the ip rsvp policy local command in global configuration mode. To disable this feature, use the no form of this command.
ip rsvp policy local {acl acl [acl1...acl8] | default | origin-as as [as1...as8]}
no ip rsvp policy local
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Release Modification12.2(13)T
This command was introduced.
12.0(29)S
The origin-as as keyword argument combination and new submode commands were added.
Usage Guidelines
Use the ip rsvp policy local command to create a local procedure that determines the use of RSVP resources in a network.
Note
Before entering the origin-as as keyword argument combination, you must have Border Gateway Protocol (BGP) running; otherwise, an RSVP warning message appears stating that the AS-based policy will be ineffective.
Local policies can be ACL- or AS-based for traffic engineering (TE) and non-TE reservations.
There are three types of local policies—one default local policy, one or more ACL-based local policies, and one or more AS-based policies. The default policy is used when an RSVP message does not match any ACL- or AS-based policies. You can use local policies in the following combinations:
•
A default policy and no ACL- or AS-based policies. All RSVP messages, regardless of reservation (data flow) source or destination, are subject to whatever is defined in this one policy.
•
ACL-based policies and no default policy. If an RSVP message does not match the ACLs of any of these local policies, then RSVP sees if there are any remote policies in place that allow the router to pass the RSVP message to a COPS server for an accept/reject decision. If there are no COPS servers, the RSVP message is accepted. This final decision can be changed to a reject decision with the ip rsvp policy default-reject command.
Note
Common Open Policy Service (COPS) is not supported in Cisco IOS Releases 12.0 S or 12.2 S.
•
AS-based policies and no default policy. If an RSVP message does not match the ASes of any of these local policies, then RSVP sees if there are any remote policies in place that allow the router to pass the RSVP message to a COPS server for an accept/reject decision. If there are no COPS servers, the RSVP message is accepted. This final decision can be changed to a reject decision with the ip rsvp policy default-reject command.
•
A default policy and AS-based policies. If an RSVP message does not match the ASes of any of these local policies, then RSVP will execute whatever decisions are in the default local policy.
•
A default policy and ACL-based policies. If an RSVP message does not match the ACLs of any of these local policies, then RSVP will execute whatever decisions are in the default local policy.
•
ACL- and AS-based policies. If an RSVP message does not match the AS of any of the AS-based policies, then RSVP looks for a match with an ACL-based policy.
An ACL-based policy must have at least one ACL associated with it, but it can optionally have up to eight ACLs. The ACLs can be standard or extended IP ACLs. They are matched against source/destination addresses/ports based on RSVP objects inside RSVP signaling messages as described in the following section.
Match Criteria for ACL-Based Policies
•
ACL source address—matched against the source address in the SENDER_TEMPLATE object in RSVP messages. If this object is not present, then the source address in the IP header is used.
•
ACL destination address—matched against the destination address in the SESSION object in RSVP messages. If this object is not present, then the destination address in the IP header is used.
•
ACL source port—matched against the source port in the SENDER_TEMPLATE object in RSVP messages. If this object is not present, then the source port of 0 is used.
•
ACL destination port—matched against the destination port in the SESSION object in RSVP messages. If this object is not present, then the destination port of 0 is used.
•
ACL IP protocol—matched against the IP protocol in the SESSION object in RSVP messages. If this object is not present, then the IP protocol of 0 is used.
If the IP protocol is for a TE session, then the ACL IP protocol should be UDP.•
ACL DSCP values—matched against the DSCP value in the IP header of the RSVP message.
Note
These same match criteria apply when you create ACLs for the debug ip rsvp filter command.
An AS-based policy must have at least one AS associated with it, but it can optionally have up to eight ASes. They are matched against the incoming interface/source IP address of the originating tunnel based on RSVP objects inside RSVP signaling messages, not on the IP headers of the RSVP messages.
CLI Submodes
Once you type the ip rsvp policy local default, the ip rsvp policy local acl, or the ip rsvp policy local origin-as command, you enter the local policy CLI submode where you define the properties of the default, AS-, or ACL-based local policy that you are creating.
Note
The local policy that you create automatically rejects all RSVP messages unless you enter a submode command that instructs RSVP on the types of messages to accept.
The submode commands are as follows:
accept—Accepts, but does not forward RSVP messages.
accept {all | path | path-error | resv | resv-error}
–
all—Accepts all incoming RSVP messages.
–
path—Accepts incoming Path messages that match the ACL(s) or AS(es) of this policy. If you omit this command, incoming Path messages that match the ACL(s) or AS(es) are rejected and a PathError message is sent in reply. However, the PathError reply is also subject to local policy.
–
path-error—Accepts incoming PathError messages that match the ACL(s) or AS(es) of this policy. If you omit this command, incoming, including locally-generated, PathError messages that match the ACL(s) or AS(es) are rejected.
–
resv—Accepts incoming Resv messages that match the ACL(s) or AS(es) of this policy and performs any required admission control. If you omit this command, incoming Resv messages that match the ACL(s) or AS(es) are rejected and a ResvError message is sent in reply. However, the ResvError reply is also subject to local policy.
The default bandwidth limit for a policy is unlimited. Therefore, if the policy has no configured bandwidth, a Resv message is always accepted by the local policy since any bandwidth request is less than or equal to unlimited. However, the Resv message may subsequently fail admission control if there is insufficient bandwidth in the RSVP pool on the input interface to which the Resv message applies. If the bandwidth requested by the Resv messages is too large, a ResvError message is transmitted to the Resv sender.
–
resv-error—Accepts incoming ResvError messages that match the policy match criteria of this policy. If you omit this command, the incoming, including locally-generated, ResvError messages matching the ACL(s) are rejected.
•
default—Sets a command to its defaults.
•
exit—Exits local policy configuration mode.
•
fast-reroute—Allows TE LSPs that request Fast Reroute service. The default value is accept.
•
forward—Accepts and forwards RSVP messages.
forward {all | path | path-error | resv | resv-error}
–
all—Accepts and forwards all RSVP messages.
–
path—Accepts and forwards Path messages that match the policy match criteria of this policy. If you omit this command, Path messages matching the policy match criteria are not forwarded to the next (downstream) hop.
–
path-error—Accepts and forwards PathError messages that match the policy match criteria of this policy. If you omit this command, the PathError message matching the policy match criteria are not forwarded to the previous (upstream) hop. You may want to reject outbound PathError messages if you are receiving Path messages from an untrusted node because someone could be trying to port-scan for RSVP. If you reply with a PathError message, then the untrusted node knows you support RSVP and your IP address. Such information could be used to attempt RSVP-based attacks.
–
resv—Accepts and forwards Resv messages that match the policy match criteria of this policy. If you omit this command, Resv messages matching the policy match criteria are not forwarded to the previous (upstream) hop.
–
resv-error—Accepts and forwards ResvError messages that match the policy match criteria of this policy. If you omit this command, the ResvError message matching the policy match criteria is not forwarded to the next (downstream) hop. You may want to reject outbound ResvError messages if you are receiving Resv messages from an untrusted node because it could be someone trying to port-scan for RSVP. If you reply with a ResvError message, then the untrusted node knows you support RSVP and your IP address. Such information could be used to attempt RSVP-based attacks.
•
local-override—Overrides any other policy sources by enforcing this local policy. Finalizes any decisions by this policy. If local-override is omitted, RSVP holds on to the local policy decision to see if another local or remote policy exists that will make a decision on the RSVP message, and only if there is no other policy decision will the local policy decision be enforced.
•
maximum—Sets the limits for resources.
–
bandwidth [group x] [single y]—Indicates bandwidth limits for RSVP reservations. The group parameter specifies the amount of bandwidth that can be requested by all the reservations covered by this policy. The single parameter specifies the maximum bandwidth that can be requested by any specific RSVP reservation covered by this policy. The x and y values are in K bits per second and can range from 1 to 10,000,000 (similar in concept to the existing interface mode ip rsvp bandwidth command). Absence of a bandwidth command implies that there is no policy limit on bandwidth requests.
–
senders n—Limits the number of RSVP senders affected by this policy that can be active at the same time on this router. The value for n ranges from 1 to 50,000 with a default of 1000.
•
no—Negates a command or sets its defaults.
•
preempt-priority [traffic-eng x] start-priority [hold-priority]—The x value indicates the upper limit of the priority for TE reservations. The range of x values is 0 to 7 in which the smaller the number, the higher the reservation's priority. For non-TE reservations, the range of x values is 0 to 65535 in which the higher the number, the higher the reservation's priority.
The start-priority argument indicates the priority of a reservation when it is initially installed. The optional hold-priority argument indicates the priority of a reservation after it has been installed. If omitted, it defaults to the start-priority. Values for the start-priority and hold-priority arguments range from 0 to 7 where 0 is considered the highest priority.
If the incoming message has a preemption priority that requests a priority higher than the policy allows, the message is rejected. The tunnel mpls traffic-eng priority command is used to configure preemption priority for TE tunnels.
A single policy can contain an preempt-priority traffic-eng and a preempt-priority command; which may be useful if the policy is bound to an ACL that identifies a subnet containing a mix of TE and non-TE endpoints or midpoints.
When selecting reservations for preemption, lower-priority reservations are preempted before those with higher priority. If there are multiple non-TE reservations with the same preemption priority, then the oldest reservations are selected first.
Note
If you exit local policy submode without entering any submode commands, the policy you have created rejects all RSVP messages.
Examples
In the following example, any RSVP nodes in the 192.168.101.0 subnet can initiate or respond to reservation requests, but all other nodes can respond only to reservation requests. This means that any 192.168.101.x node can send and receive Path, PathError, Resv, or ResvError messages. All other nodes can send only Resv or ResvError messages.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# access-list 104 permit ip 192.168.101.0 0.0.0.255 anyRouter(config)# ip rsvp policy local acl 104Router(config-rsvp-policy-local)# forward allRouter(config-rsvp-policy-local)# exitRouter(config)# ip rsvp policy local defaultRouter(config-rsvp-policy-local)# forward resvRouter(config-rsvp-policy-local)# forward resverrorRouter(config-rsvp-policy-local)# exitRouter(config)# ip rsvp policy local origin-as 1Router(config-rsvp-policy-local)# endIn the following example, bandwidth is set for a group of senders and for a single sender:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip rsvp policy local defaultRouter(config-rsvp-policy-local)# forward allRouter(config-rsvp-policy-local)# maximum bandwidth group 50Router(config-rsvp-policy-local)# maximum bandwidth single 5Router(config-rsvp-policy-local)# endRelated Commands
show ip rsvp policy local
To display the local policies currently configured, use the show ip rsvp policy local command in EXEC mode.
show ip rsvp policy local [acl [acl] | default | origin-as [as]] [detail]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Release Modification12.2(13)T
This command was introduced.
12.0(29)S
The origin-as as keyword argument combination was added and the acl argument became optional.
Usage Guidelines
Use the show ip rsvp policy local command to display information about the selected local policies currently configured.
If you omit the acl or as arguments, then all ACL- or AS-based local policies currently configured appear.
If you use the ACL or AS options, you can specify only one ACL or AS. However, that parameter can be any ACL or AS of any local policy that you have created. If you have multiple local policies with a common ACL or AS, then using the ACL or AS option displays all local policies with that ACL or AS, respectively. On the other hand, if you have created local policies each with multiple ACLs or ASes, you cannot use the ACL or AS option to show only a specific policy. You must omit the ACL or AS option and show all the local policies.
Examples
The following is sample output from the show ip rsvp policy local detail command in which ACL, ASes, and default policies have been configured:
Router# show ip rsvp policy local detailLocal policy for ACL(s): 1Local Override: Disabled.Fast ReRoute: Accept.Accept ForwardPath: Yes YesResv: Yes YesPathError: Yes YesResvError: Yes YesLocal policy for AS(es): 4Local Override: Disabled.Fast ReRoute: Accept.Accept ForwardPath: No NoResv: No NoPathError: No NoResvError: No NoCurrent LimitSenders: 0 100Group bandwidth (bps): 0 0Local policy for ACL(s): defaultLocal Override: Disabled.Fast ReRoute: Do not accept.Accept ForwardPath: Yes YesResv: Yes YesPathError: Yes YesResvError: Yes YesCurrent LimitSenders: 0 20Group bandwidth (bps): 0 40KSetup Priority Hold PriorityTE: 7 7Non-TE: 5 5Generic policy settings:Default policy: Accept allPreemption: DisabledTable 1 describes the significant fields shown in the display.
Related CommandsL
Command DescriptionCreates a local procedure that determines the use of RSVP resources in a network.
Glossary
ACL—access control list. An ACL consists of individual filtering rules grouped together in a single list. It is generally used to provide security filtering, though it may be used to provide a generic packet classification facility.
AS—autonomous system. A collection of networks that share the same routing protocol and that are under the same system administration.
ASBR—autonomous system boundary router. A router that connects and exchanges information between two or more autonomous systems.
BGP—Border Gateway Protocol. The exterior border gateway protocol used to exchange routing information between routers in separate autonomous systems. BGP uses Transmission Control Protocol (TCP). Because TCP is a reliable protocol, BGP does not experience problems with dropped or fragmented data packets.
EBGP—External Border Gateway Protocol. A BGP session between routers in different autonomous systems (ASs). When a pair of routers in different ASs are more than one IP hop away from each other, an external BGP session between those two routers is called multihop external BGP.
flow—A stream of data traveling between two endpoints across a network (for example, from one LAN station to another). Multiple flows can be transmitted on a single circuit.
IBGP—Internal Border Gateway Protocol. A BGP session between routers within the same autonomous system.
IGP—Interior Gateway Protocol. Internet protocol used to exchange routing information within an autonomous system. Examples of common Internet IGPs include IGRP, OSPF, and RIP.
latency—The delay between the time a device receives a packet and the time that packet is forwarded out the destination port.
LSP—label-switched path. A configured connection between two routers, in which MPLS is used to carry packets. A path created by the concatenation of one or more label switched hops, allowing a packet to be forwarded by swapping labels from an MPLS node to another MPLS node.
MPLS—Multiprotocol Label Switching. A method for forwarding packets (frames) through a network. MPLS enables routers at the edge of a network to apply labels to packets (frames). ATM switches or existing routers in the network core can switch packets according to the labels.
OSPF—Open Shortest Path First. A link-state hierarchical Interior Gateway Protocol routing algorithm, derived from the IS-IS protocol. OSPF features include least-cost routing, multipath routing, and load balancing.
packet—A logical grouping of information that includes a header containing control information and (usually) user data. Packets most often refer to network layer units of data.
policy—Any defined rule that determines the use of resources within the network. A policy can be based on a user, a device, a subnetwork, a network, or an application.
port scanning—The act of systematically checking a computer's ports to find an access point.
RSVP—Resource Reservation Protocol. A protocol for reserving network resources to provide quality of service guarantees to application flows.
router—A network layer device that uses one or more metrics to determine the optimal path along which network traffic should be forwarded. Routers forward packets from one network to another based on network layer information.
TE—traffic engineering. The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been used.
tunnel—A secure communications path between two peers, such as routers.
VoIP—Voice over IP. The ability to carry normal telephony-style voice over an IP-based Internet maintaining telephone-like functionality, reliability, and voice quality.
Note
Refer to Internetworking Terms and Acronyms for terms not included in this glossary.
Copyright © 2004 Cisco Systems, Inc. All rights reserved.
Feedback


