Configuring Quality of Service
This chapter provides information about configuring quality of service (QoS) features using the VSPA on the Catalyst 6500 Series switch. It includes the following sections:
•Understanding QoS in the VSPA
•Using the Module QoS Features of the VSPA
•Using the Carrier QoS Features of the SSC-600
•Using the Platform QoS Features of the Switch
•QoS Configuration Examples
For more information about the commands used in this chapter, see the Cisco IOS Security Command Reference at this URL:
http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_book.html
Also refer to the related Cisco IOS Release 12.2 software configuration guide, command reference, and master index publications. For more information about accessing these publications, see the "Related Documentation" section on page xvi.
Tip To ensure a successful configuration of your VPN using the VSPA, read all of the configuration summaries and guidelines before you perform any configuration tasks.
Understanding QoS in the VSPA
Typical applications of quality of service (QoS) for VPN are the use of traffic policing to prevent a hub from overwhelming a lower-capacity spoke, and the prioritization over VPN of delay-sensitive traffic such as voice over IP (VoIP). In a system including the VSPA, QoS features for VPN traffic are provided by the VSPA module, its carrier card (SSC-600), and the platform (Catalyst 6500 Series switch).
•Module QoS—The VSPA provides traffic shaping, queuing, and bandwidth reservation services before encryption. Policies are attached to a crypto engine within the interface configuration.
•Carrier QoS—For each crypto engine, the SSC-600 provides a dual-priority queue for module traffic. Policies are attached to a crypto engine.
•Platform QoS—The Catalyst 6500 Series switch provides trust, data classification, and either remarking or policing of traffic on the tunnel interface. Policies are attached to an interface.
To activate the QoS capabilities of the module, carrier, and platform, you must enable QoS globally by entering the mls qos command.
When QoS is disabled globally, the system behavior is as follows:
•All QoS fields are left intact in packets.
•Packets flow through only one queue in the carrier card.
When QoS is enabled globally, the default system behavior is as follows:
•The default state of all ports and VLANs is the untrusted state, causing ports to clear the QoS fields in all traffic to zero unless a QoS policy is configured on the port.
•Packets flow through two queues in the carrier card. Packets with a CoS value of 5 will use the higher priority queue, while all other packets will use the lower priority queue.
Before configuring QoS for VPN, see the additional information provided in the following URLs:
Configuring QoS on the Catalyst 6500 Series switch:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html
Configuring QoS Features on a SIP:
http://www.cisco.com/en/US/docs/interfaces_modules/shared_port_adapters/configuration/6500series/76cfgsip.html#Configuring_QoS_Features_on_a_SIP
Configuring QoS on the FlexWAN Modules:
http://www.cisco.com/en/US/docs/routers/7600/install_config/flexwan_config/flexqos.html
QoS Policing on the Catalyst 6500 Series switch:
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801c8c4b.shtml
QoS Output Scheduling on the Catalyst 6500 Series switch:
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bf98.shtml
QoS Troubleshooting:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008074d6b1.shtml
Using the Module QoS Features of the VSPA
In VRF mode configurations using Virtual Tunnel Interface (VTI) or GRE with tunnel protection (TP), the VSPA can provide traffic shaping, queuing, and bandwidth reservation of outbound traffic before encryption, allowing you to prioritize traffic on a per-tunnel basis as well as to configure a shape rate for each tunnel. This section contains the following topics:
•Classifying, Marking, and Policing Traffic
•Setting Priority
•Shaping Traffic
•Reserving Bandwidth
•Setting the Queue Limit
•Failover
•Configuring Module QoS
Classifying, Marking, and Policing Traffic
To apply the VSPA's QoS features, you must first ensure that the class of service (CoS) of packets is marked on ingress and that any necessary policing is performed before the packets are passed to the VSPA.
The Catalyst 6500 Series switch performs classification, marking, and policing of traffic to the VSPA. These functions are configured using the following commands:
•Use the class-map command to classify types of traffic.
•Use the set command to mark the CoS or DSCP bits for a traffic class.
•Use the police command to limit the rate of a traffic class.
For details on configuring classification, marking, and policing, see the "Using the Platform QoS Features of the Switch" section.
Setting Priority
For each tunnel, the VSPA provides one high-priority low-latency queue (LLQ) for latency-sensitive outbound traffic, such as VoIP. The high priority queue is served ahead of other queues in that tunnel. The priority policy-map class configuration command gives priority to a class of traffic belonging to a policy map, causing that traffic to be diverted to the high-priority queue. Only one priority level per tunnel is supported. When the priority command is used in a class map, no form of the bandwidth command is allowed in the same class map.
Shaping Traffic
The shape average policy-map class configuration command specifies a maximum data rate for a class of outbound traffic. While policing enforces a maximum rate by dropping or marking down excess packets, shaping queues the excess packets for sending at a later time. Packets exceeding the maximum rate will be delayed but will not be dropped unless excess traffic is sustained at rates higher than the configured shape rate for long periods of time, causing shape buffers to overflow.
When shaping is applied to a tunnel, all traffic in the tunnel must be included in the default class. Any additional classes must be defined in a child policy.
To configure traffic shaping in the VSPA, use the shape average rate bc be command, where the rate argument specifies the maximum average bit rate and the optional be argument is the allowed excess burst level. The optional bc argument (the committed burst size) is ignored, but if be is specified, then bc must be configured to a value of at least the number of bits transferred during 4 milliseconds of traffic at the shape rate. The shape average command can be configured only for the tunnel top-level policy. It cannot be used in a child policy.
Reserving Bandwidth
The bandwidth policy-map class configuration command reserves a minimum bandwidth for a class of traffic. You can configure the bandwidth command in a child policy to reserve either an absolute rate or a percentage of the tunnel shape rate. If the priority command is configured on another class map within the same policy map, only the bandwidth remaining form of the bandwidth command can be used, since the higher priority traffic overrules any bandwidth guarantees.
When you configure bandwidth reservation for a class, your settings are checked for capacity and oversubscription relative to the maximum shape rate. If a tunnel aggregate shaper is not configured, any configuration of bandwidth reservation will be rejected.
Setting the Queue Limit
The queue-limit policy-map class configuration command specifies the maximum number of packets the queue can hold for a class policy configured in a policy map. The VSPA supports only a packet-based queue limiting, and supports queue-limit configuration only on a class map.
Failover
If you deploy two VSPAs for intrachassis stateful failover using a blade failure group (BFG), the QoS configuration on the active VSPA is automatically reflected on the standby module. During a failover, packets in the queue are lost. The standby VSPA takes over, scheduling newly-received packets according to the QoS configuration. Interchassis failover is not supported.
For more information on failover using a blade failure group, see "Configuring Intrachassis IPsec Stateful Failover Using a Blade Failure Group" section on page 11-10.
Configuring Module QoS
Module QoS configuration in the VSPA uses the Cisco Modular QoS CLI (MQC) framework. You can define traffic classes, associate policies and actions to each traffic class, and attach these policies to interfaces by following these steps:
Step 1 Define traffic classes using match statements with the class-map command.
Step 2 Configure policies using the defined traffic classes with the policy-map command.
Step 3 Within the interface configuration, attach policies to a crypto engine with the service-policy command.
For the module QoS, attach the service policy to the tunnel interface in the config-crypto-engine configuration mode after entering the crypto-engine interface level command.
The VSPA supports a hierarchical policy using two service policy levels:
•A parent policy, supporting only a single default class, to apply a QoS mechanism to a traffic aggregate.
•A child policy to apply a QoS mechanism to a flow or subset of the aggregate.
Logical interfaces, such as subinterfaces and tunnel interfaces, require a hierarchical policy with the traffic-shaping feature at the parent level and queuing at lower levels. While the traffic-shaping feature regulates the output rate, queuing may introduce additional latency or cause packet drops when the ingress traffic rate surpasses the configured queuing capacity.
For each tunnel, the VSPA supports a child policy with up to 8 classes, including the default-class. Only one of the 8 traffic classes can be configured as a priority class on a tunnel interface. You can configure bandwidth reservation on any class that is not configured as the priority class. You cannot configure shaping on a traffic class (a child shaper); a single aggregate shaper can be configured in the parent policy.
Module QoS Configuration Guidelines and Restrictions
When configuring QoS settings for the VSPA, follow these guidelines and note these restrictions:
•To use the QoS features of the VSPA, you must enable QoS globally by entering the mls qos command.
•Because the VSPA performs QoS functions only on tunnel interfaces associated with the VSPA, configuring module QoS on a tunnel interface will always result in the tunnel being taken over.
•When module QoS is configured on a GRE/TP tunnel, the GRE processing is taken over by the VSPA.
•The VSPA performs QoS functions only on VTI or GRE/TP interfaces in VRF mode. The QoS functions are not supported with crypto connect mode or DMVPN.
•The QoS functions operate only on IPv4 traffic.
•QoS is supported for up to 2 K VTI tunnels or 1 K GRE/TP tunnels.
•The VSPA supports a maximum of 8 traffic classes per tunnel, including the default class.
–We recommend that you configure one class as class-default.
–One traffic class can be configured as priority, to be processed ahead of all other classes. This class is typically used for voice or other latency-sensitive traffic.
–Each class can be configured separately for bandwidth reservation and a queue limit.
–You cannot configure priority setting and bandwidth reservation within the same class map.
•When configuring bandwidth reservation, note the following guidelines:
–Bandwidth reservation means a minimum bandwidth guarantee when 100 percent of the configured shape rate is utilized. If less than 100 percent is used, any class may use the available bandwidth above its configured reservation.
–If no bandwidth is reserved for the default class, then 1 percent of the shape rate will be automatically reserved for the default class.
•The VSPA supports one aggregate shaper per tunnel, to be defined at the tunnel (parent) level. All traffic within the tunnel must be included in the shaper. If a shaper is defined, only the class-default class should be defined at the tunnel level, with the shaper applied to it. All other traffic classes must be defined in child policies.
•Any tunnel that uses module QoS functions must have a shaping policy.
•Because the VSPA relies on the ToS/CoS bits to classify and queue the packets properly, you should ensure that packets arriving at the VSPA have already been properly classified and marked.
•The dropping policy is Random Early Detection (RED), and the RED parameters are not configurable. You cannot configure fair queueing.
•Bandwidth is reserved per class for each tunnel independently. The minimum bandwidth guarantee on a class level will not propagate to the tunnel level. There is no bandwidth guarantee on a tunnel. You cannot configure an explicit minimum rate at the tunnel level.
•You should avoid any policy that causes the reordering or dropping of post-encrypted packets.
•The configuration of priority applies only within the tunnel in which it is configured, and does not affect other tunnels.
•Increasing the queue limit increases latency.
Configuring a Child and Parent Policy
To configure a child and parent policy, perform this task:
|
|
|
Step 1 |
Router(config)# policy-map child_policy_name |
Enters the policy map configuration for the specified child policy map. |
Step 2 |
Router(config-pmap)# class [child_policy_name | class-default] |
Enters the policy map class configuration for the default class map. |
Step 3 |
Router(config-pmap-c)# priority |
(Optional) Enables strict-priority (low latency queuing) on the class. |
Step 4 |
Router(config-pmap-c)# bandwidth {kbps | bandwidth percent percentage | bandwidth remaining percent percentage} |
(Optional) Enables minimum bandwidth reservation on a traffic class. •bandwidth kbps — Specifies the reserved bandwidth as an absolute value in kbps that cannot exceed the configured tunnel shape rate. •bandwidth percent percentage — Specifies the reserved bandwidth as a percentage of the configured tunnel shape rate. •bandwidth remaining percent percentage — Specifies the reserved bandwidth as a percentage of the remaining tunnel bandwidth up to the configured tunnel shape rate after all LLQ packets have been served. |
Step 5 |
Router(config-pmap-c)# queue-limit number_of_packets |
(Optional) Sets the maximum size (in packets) of the traffic queue for the class. |
Step 6 |
Router(config-pmap-c)# exit |
Exits the policy map class configuration. |
Step 7 |
Router(config-pmap)# exit |
Exits the policy map configuration. |
Step 8 |
Router(config)# policy-map parent_policy_name |
Enters the policy map configuration for the specified parent policy map. |
Step 9 |
Router(config-pmap)# class class-default |
Enters the policy map class configuration for the default class map. |
Step 10 |
Router(config-pmap-c)# shape average rate [bc be] |
Enables average rate traffic shaping. •rate—Specifies the committed information rate (CIR), in bits per second (bps). •bc—(Optional) Specifies the committed burst size, in bits. This field will be ignored, but must be set to a legal value if be is specified. •be—(Optional) Specifies the excess burst size, in bits. |
Step 11 |
Router(config-pmap-c)# service-policy child_policy_name |
(Optional) Attaches a child policy map with up to seven additional class maps. Including the class-default class map, there can be a total of up to eight class maps. |
Step 12 |
Router(config-pmap-c)# exit |
Exits the policy map class configuration. |
Step 13 |
Router(config-pmap)# exit |
Exits the policy map configuration. |
•The bandwidth and bandwidth percent commands cannot be configured in conjunction with the priority command. The bandwidth remaining percent command can be configured in conjunction with the priority command.
•By default, the queue limit is 1000 for all non-LLQ traffic classes; for LLQ classes, the default is the number of packets that can be transferred in 4 milliseconds at the configured shape rate.
•The shape rate can range from 128 Kbps to 1 Gbps. If a tunnel has a low shape rate, we recommend that you also configure a small excess burst size (be).
•The default excess burst size (be) is the number of bits transferred during 4 milliseconds of traffic at the shape rate. For example, for a 256000 bps shape rate, the default excess burst size will be 1024 bits.
•If you configure be, then you must configure bc (the committed burst size) to a value of at least the number of bits transferred during 4 milliseconds of traffic at the shape rate.
Note We recommend that you allow the system to determine settings for bc and be.
Configuring Shaping on a Tunnel
To configure shaping on a tunnel, perform this task:
|
|
|
Step 1 |
Router(config)# mls qos |
Enables QoS globally. |
Step 2 |
Router(config)# interface tunnel_name |
Selects the tunnel to which the policy map will be applied. |
Step 3 |
Router(config-if)# crypto-engine |
Enters QoS policy configuration mode for the VSPA. |
Step 4 |
Router(config-crypto-engine)# service-policy output parent_policy_name |
Applies the policy map to tunnel egress traffic. |
Step 5 |
Router(config-crypto-engine)# end |
Exits to the privileged EXEC mode. |
Step 6 |
Router# show policy-map interface tunnel_name |
Displays the statistics and configurations of the QoS policies attached to the tunnel interface. |
For QoS configuration examples, see the "QoS Configuration Examples" section.
Using the Carrier QoS Features of the SSC-600
The SSC-600 implements a two-level, strict-priority QoS with two queues for each direction, inbound and outbound. Packets are dequeued in a two-to-one ratio, meaning that two packets are dequeued from the high-priority low-latency queue (LLQ) before one packet is dequeued from the low-priority queue. Packets are enqueued based on your priority-queue configuration settings. To take advantage of the SSC-600's QoS capability, you must use standard QoS commands to ensure that the class of service (CoS) of packets is marked on ingress. You must configure the CoS map for the inside and outside ports and you must also enable QoS globally for the SSC-600 to acknowledge the CoS mapping.
Carrier QoS Configuration Guidelines and Restrictions
When configuring QoS settings for an SSC-600, follow these guidelines and note these restrictions:
•Packets are enqueued based on the mls qos command and the priority-queue configuration settings as follows:
–When the mls qos command is not configured, all data packets are enqueued into the high-priority queue.
–When the mls qos command is configured and no explicit priority-queue configuration is present on the VSPA Ethernet interfaces, only packets with a CoS value of 5 are enqueued into the high-priority queue; all other packets are enqueued into the low-priority queue.
–When the mls qos command is configured and priority-queue configuration is present on the VSPA Ethernet interfaces, traffic is enqueued based on the priority-queue configuration.
•A maximum of three CoS map values can be sent to the high-priority queue. Because the CoS value of 5 is preconfigured as high-priority, you can choose only two other values for high-priority queueing.
Note Do not configure more than three CoS map values because any additional values will overwrite previously configured values. If you overwrite the CoS value of 5, the system will restore it, overwriting one of your other configured values. To restore an overwritten CoS map value, you must first delete the new value and then reconfigure the earlier value.
•When the mls qos command is configured, you must also configure the mls qos trust command on the VSPA Ethernet interfaces, as in the following example:
Interface GigabitEthernet4/0/1
priority-queue cos-map 1 0 1 5
Interface GigabitEthernet4/0/2
priority-queue cos-map 1 0 1 5
In this example, the CoS values of 0, 1, and 5 are sent to the high-priority queue.
•In a blade failover group, both VSPAs must have matching carrier QoS configurations.
•If the mls qos trust command is not configured, the QoS fields in all traffic will be cleared to the default level. If the mls qos trust command is configured, the QoS fields will be preserved.
For a configuration example of module QoS, see the "Module QoS Configuration Example" section.
Using the Platform QoS Features of the Switch
The Catalyst 6500 Series switch allows data classification and either remarking or policing of packets on the tunnel interface.
Platform QoS configuration uses the Cisco Modular QoS CLI (MQC) framework. You can define traffic classes, associate policies and actions to each traffic class, and attach these policies to interfaces by following these steps:
Step 1 Define traffic classes using match statements with the class-map command.
Step 2 Configure policies using the defined traffic classes with the policy-map command.
Step 3 Attach defined policies to an interface with the service-policy command.
For more information on configuring QoS in the Catalyst 6500 Series switch, see the following URL:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html
Remarking of Packets
Remarking is specified by using a set command within a policy map. Platform QoS for VPN is capable of remarking the priority settings of original IP, GRE, and IPsec headers of tunnel traffic, depending on the tunnel type. For remarking of packets, the port trust settings must be as follows:
•If matching is based on ToS bits of the incoming packets, the LAN interface must be configured as a trusted port, using the mls qos trust command.
•Depending on the VPN mode and the desired behavior, the inside interface of the VSPA must be configured as VLAN-based, using the mls qos vlan-based command, or as a trusted port, using the mls qos trust command.
The following sections describe remarking behavior in different modes.
Remarking of GRE Packets in Crypto-Connect Mode
The outside interface of the VSPA must be configured as a trusted port, using the mls qos trust command.
The inside interface of the VSPA is configured as VLAN-based, using the mls qos vlan-based command. The remarking behavior will be as follows:
•Remarking is supported for both inbound and outbound traffic.
•If the GRE tunnel is taken over by the VSPA:
–Apply the service policy to the tunnel interface. Any service policy on the crypto interface VLAN will be ignored.
–Remarking is performed on the original IP header and copied to the GRE header and the IPsec header.
•If the GRE tunnel is not taken over by the VSPA:
–Apply the service policy to the tunnel interface or to the crypto interface VLAN.
–If the service policy is applied to the tunnel interface, remarking is performed on the original IP header and copied to the GRE header and the IPsec header.
–If the service policy is applied to the crypto interface VLAN, remarking is performed on the GRE header and copied to the IPsec header. Remarking is not performed on the original IP header (inner header).
•Traffic matching the service policy will be remarked.
Remarking of GRE Packets with Tunnel Protection in VRF Mode
The outside interface of the VSPA must be configured as a trusted port, using the mls qos trust command. After egress from the VSPA, an encrypted packet cannot be remarked.
The inside interface of the VSPA is configured as VLAN-based, using the mls qos vlan-based command. The remarking behavior will be as follows:
•Remarking is supported for both inbound and outbound traffic.
•Apply the service policy to the tunnel interface.
•If the GRE tunnel is taken over by the VSPA, remarking is performed on the original IP header and copied to the GRE header and the IPsec header.
•If the GRE tunnel is not taken over by the VSPA, remarking is performed on the GRE header and copied to the IPsec header. Remarking is not performed on the original IP header (inner header).
•Traffic matching the service policy will be remarked.
Remarking of VTI Packets in VRF Mode
The outside interface of the VSPA must be configured as a trusted port, using the mls qos trust command. After egress from the VSPA, an encrypted packet cannot be remarked.
The inside interface of the VSPA is configured as VLAN-based, using the mls qos vlan-based command. The remarking behavior will be as follows:
•Apply the service policy to the tunnel interface.
•Remarking is supported for both inbound and outbound traffic.
•Remarking is performed on the original IP header and the IPsec header.
•Traffic matching the service policy will be remarked.
Policing of Packets
Policing enforces a maximum packet rate by dropping excess packets. Policing can limit the rate that packets are passed to and from the VSPA.
For more information on configuring policing in the Catalyst 6500 Series switch, see the following URL:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html
Platform QoS Guidelines and Restrictions
When configuring platform QoS for VPN, follow these guidelines and note these restrictions:
•To enable QoS, you must apply the mls qos command globally.
•Platform QoS policies can be applied to the tunnel interface in any of these situations:
–GRE in crypto-connect mode, whether or not GRE is taken over by the VSPA
–GRE with tunnel protection, whether or not GRE is taken over by the VSPA
–Static VTI
–mGRE
•The match all, match not, and match cos classification criteria are not supported for platform QoS on the tunnel interface.
•In the police command, the exceed-action set options are not supported for platform QoS on the tunnel interface, and cannot be configured for remarking or policing.
•Platform QoS policies do not apply to packets generated by the route processor or destined for the route processor.
•Platform QoS supports 1023 policers or remarkers.
•When applying a service policy during configuration, the policy does not take effect until after you exit the interface configuration mode.
•If you apply and then remove a service policy, some packets will be remarked to other priorities during the transition. To prevent this issue, enter the mls acl tcam default-result permit command in the global configuration.
•In some cases, upon removal of a service policy from a tunnel, the tunnel continues to remark outbound traffic. To prevent this issue, remove the IP access list first, then remove the service policy.
•In VRF mode, the outside interface is always untrusted. To provide QoS to inbound traffic, apply a service policy to the GRE or VTI tunnel interface, or to the interface VLAN.
•When configuring for blade-to-blade failover, you must enter identical QoS configurations on the inside interfaces of both VSPAs.
For a configuration example of platform QoS, see the "Platform QoS Configuration Example" section.
QoS Configuration Examples
This section provides examples of the following configurations:
•Platform QoS Configuration Example
•Carrier QoS Configuration Example
•Module QoS Configuration Example
Platform QoS Configuration Example
This example shows how to configure platform QoS with inbound and outbound service policies:
! LAN interface configuration
interface GigabitEthernet2/3
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 46,51,3501-4000
mls qos trust ip-precedence
! inside interface configuration
interface GigabitEthernet3/0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan none
spanning-tree portfast edge trunk
! outside interface configuration
interface GigabitEthernet3/0/2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan none
mls qos trust ip-precedence
! tunnel interface configuration
ip address 26.0.1.2 255.255.255.0
ip access-group T1ACL_IN in
ip access-group T1ACL_OUT out
tunnel destination 192.0.20.1
tunnel protection ipsec profile TUN_PROTECTION
crypto engine slot 3/0 inside
service-policy input SET_1TO5
service-policy output SET_3TO5
Carrier QoS Configuration Example
The following example shows how to configure carrier QoS:
Interface GigabitEthernet4/0/1
priority-queue cos-map 1 0 1 5
Interface GigabitEthernet4/0/2
priority-queue cos-map 1 0 1 5
Module QoS Configuration Example
The following example shows how to configure module QoS:
service timestamps debug datetime
service timestamps log datetime
no service password-encryption
service counters max age 10
no mls acl tcam share-global
mls cef error action reset
crypto pki trustpoint MSCA
enrollment url http://43.0.111.111:80/certsrv/mscep/mscep.dll
subject-name cn=HUB2,ou=isbu,o=cisco
crypto pki certificate chain MSCA
certificate 1C67C77C0000000004C4
certificate ca 7C0299B7C394F789436EBEFCCEAED66D
crypto engine gre vpnblade
power redundancy-mode combined
diagnostic bootup level minimal
diagnostic monitor syslog
diagnostic cns publish cisco.cns.device.diag_results
diagnostic cns subscribe cisco.cns.device.diag_commands
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
no spanning-tree vlan 2-7
vlan internal allocation policy descending
vlan access-log ratelimit 2000
class-map match-any class7
class-map match-any class6
class-map match-any class5
class-map match-any class4
class-map match-any class3
class-map match-any class2
class-map match-any class1
class-map match-any class567
class-map match-any class34
class-map match-any class12
policy-map Tunnel0ChildPolicy
bandwidth remaining percent 40
bandwidth remaining percent 40
bandwidth remaining percent 20
policy-map Tunnel0ParentPolicy
service-policy Tunnel0ChildPolicy
policy-map Tunnel1ChildPolicy
policy-map Tunnel1ParentPolicy
shape average 34000000 136000 0
service-policy Tunnel1ChildPolicy
policy-map Tunnel2ChildPolicy
policy-map Tunnel2ParentPolicy
service-policy Tunnel2ChildPolicy
policy-map Tunnel3ChildPolicy
policy-map Tunnel3ParentPolicy
service-policy Tunnel3ChildPolicy
policy-map Tunnel4ChildPolicy
bandwidth remaining percent 20
bandwidth remaining percent 20
bandwidth remaining percent 20
bandwidth remaining percent 10
bandwidth remaining percent 10
bandwidth remaining percent 10
bandwidth remaining percent 10
policy-map Tunnel4ParentPolicy
service-policy Tunnel4ChildPolicy
policy-map Tunnel5ParentPolicy
shape average 128000 512 0
crypto isakmp invalid-spi-recovery
crypto ipsec transform-set MyTranSet esp-aes 256 esp-sha-hmac
no crypto ipsec nat-transparency udp-encaps
crypto ipsec profile MyIpsecProf
set transform-set MyTranSet
buffers small permanent 1024
buffers small max-free 1500
buffers small min-free 500
buffers middle permanent 512
buffers middle max-free 3000
buffers middle min-free 100
buffers big permanent 1000
buffers big max-free 1000
ip address 3.0.0.1 255.255.255.0
ip hello-interval eigrp 10 60
ip hold-time eigrp 10 180
tunnel destination 5.0.0.1
tunnel protection ipsec profile MyIpsecProf
crypto engine slot 4/0 inside
service-policy output Tunnel0ParentPolicy
ip address 3.0.1.1 255.255.255.0
ip hello-interval eigrp 10 60
ip hold-time eigrp 10 180
tunnel destination 5.0.1.1
tunnel protection ipsec profile MyIpsecProf
crypto engine slot 4/0 inside
service-policy output Tunnel1ParentPolicy
ip address 3.0.2.1 255.255.255.0
ip hello-interval eigrp 10 60
ip hold-time eigrp 10 180
tunnel destination 5.0.2.1
tunnel protection ipsec profile MyIpsecProf
crypto engine slot 4/0 inside
service-policy output Tunnel2ParentPolicy
ip address 3.0.3.1 255.255.255.0
ip hello-interval eigrp 10 60
ip hold-time eigrp 10 180
tunnel destination 5.0.3.1
tunnel protection ipsec profile MyIpsecProf
crypto engine slot 4/0 inside
service-policy output Tunnel3ParentPolicy
ip address 3.0.4.1 255.255.255.0
ip hello-interval eigrp 10 60
ip hold-time eigrp 10 180
tunnel destination 5.0.4.1
tunnel protection ipsec profile MyIpsecProf
crypto engine slot 4/0 inside
service-policy output Tunnel4ParentPolicy
ip address 3.0.5.1 255.255.255.0
ip hello-interval eigrp 10 60
ip hold-time eigrp 10 180
tunnel destination 5.0.5.1
tunnel protection ipsec profile MyIpsecProf
crypto engine slot 4/0 inside
service-policy output Tunnel5ParentPolicy
ip address 4.0.0.1 255.255.255.255
ip address 4.0.1.1 255.255.255.255
ip address 4.0.2.1 255.255.255.255
ip address 4.0.3.1 255.255.255.255
ip address 4.0.4.1 255.255.255.255
ip address 4.0.5.1 255.255.255.255
interface TenGigabitEthernet2/1
description EGRESS INTERFACE
ip address 6.0.0.1 255.255.255.0
interface TenGigabitEthernet2/2
interface TenGigabitEthernet2/3
description INGRESS INTERFACE
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 2-7
interface TenGigabitEthernet2/4
description TO TESTCENTER PORT 2/2 (NOT IN USE)
interface TenGigabitEthernet2/5
interface TenGigabitEthernet2/6
interface TenGigabitEthernet2/7
interface TenGigabitEthernet2/8
interface GigabitEthernet4/0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan none
priority-queue cos-map 1 5 6 7
spanning-tree portfast edge trunk
interface GigabitEthernet4/0/2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan none
priority-queue cos-map 1 5 6 7
spanning-tree portfast edge trunk
interface GigabitEthernet5/1
interface GigabitEthernet5/2
ip address 44.0.111.118 255.0.0.0
ip address 1.0.0.1 255.255.255.0
ip address 1.0.1.1 255.255.255.0
ip address 1.0.2.1 255.255.255.0
ip address 1.0.3.1 255.255.255.0
ip address 1.0.4.1 255.255.255.0
ip address 1.0.5.1 255.255.255.0
distribute-list T0000 out Tunnel0
distribute-list T0001 out Tunnel1
distribute-list T0002 out Tunnel2
distribute-list T0003 out Tunnel3
distribute-list T0004 out Tunnel4
distribute-list T0005 out Tunnel5
redistribute connected metric 900 100 255 1 1400
summary-address 4.0.0.0 255.0.0.0
redistribute connected metric 10 subnets
network 6.0.0.0 0.0.0.255 area 0
ip default-gateway 44.0.100.1
ip route 43.0.0.0 255.0.0.0 44.0.100.1
ip route 223.255.254.53 255.255.255.255 44.0.100.1
ip access-list standard T0000
ip access-list standard T0001
ip access-list standard T0002
ip access-list standard T0003
ip access-list standard T0004
ip access-list standard T0005
logging alarm informational
access-list 10 permit 4.0.0.0 0.255.255.255
mac-address-table aging-time 0
ntp clock-period 17219357
ntp server 223.255.254.53