Cisco Live! Designing Multipoint WAN QoS

Eddie Kempe

Solutions Architect

Designing Multipoint WAN QoS BRKRST-3500

© 2011 Cisco and/or its affiliates. All rights reserved. Cisco Public BRKRST-3500 2

Bridge Puzzle

§ Need the flashlight to cross § Only two at a time § Fast as slowest person

§ Abe – 1 Minute § Bob – 2 Minutes § Chad – 5 Minutes § Dave – 6 Minutes


Bridge Puzzle

What if the slow guys walk together?

§ Abe + Bob (2)

§ Abe returns (1)

§ Chad + Dave (6)

§ Bob returns (2)

§ Abe + Bob (2)

§ Total 13 Minutes


Abstract

§  Real-time and business critical application, such as cloud SaaS applications, Unified Communications and video, are driving the need for any-to-any connectivity with deterministic Quality of Service (QoS). This creates new challenges for multipoint wide area network (WAN) environments that are not QoS-aware, such as the Internet and DMVPN networks.

§  While the requirements have changed, the tools available to provide QoS in multipoint WAN environments have not. QoS policy enforcement points lack visibility into the quantity and type of traffic being received at branch and teleworker offices, forcing network designers to choose between resource underutilization or possible loss of real-time and business critical traffic.

§  This session will examine new methods of meeting today's QoS challenges, identify key design considerations, and review supporting case studies. It is intended for network architects and designers of corporate WAN infrastructures. An advanced understanding of QoS, WAN and virtual private network (VPN) design principles is recommended.


Multipoint WAN QoS

Aggregation Speed Mismatch 1000 Mbps

10 Mbps

1) Multipoint 2) 3rd Party 3) Non-QoS Aware


Agenda § Scenario: Teleworker QoS

§ Remote Ingress Shaping Theoretical Background

§  Implementing Remote Ingress Shaping

§ Proof of Concept Lab

§  Internet-Based Proof of Concept Lab

§ Putting it all together § Remote Ingress Shaping and Teleworker Revisited § Additional Use Cases § Buck’s Financial

§  Looking Ahead


Agenda

Scenario: Teleworker QoS


Internet

Teleworker Overview Residential Traffic

PE

DC1 DC2

ISP

CPE


Ingress Oversubscription


QoS Success Criteria

1.  Protect voice and video

2.  Protect business applications

3.  Meet user expectations

4.  Utilize resources

5.  Flexibility

6.  Financial feasibility

7.  Operationally feasibility


QoS Success Criteria

1.  Can I protect voice and video services from data?

2.  Can I differentiate traffic to ensure business critical applications are not impacted?

3.  Are applications performing as expected?

4.  Does the solution utilize my available resources?

5.  Can I deliver new services or change policy? Example: Add voice or video to the network

6.  Is the solution financially feasible?

7.  Is the solution operationally feasible?


Available Approaches

§ No QoS (do nothing)

§ Change the topology Force hub and spoke topology

§ Head-end shaping/per-tunnel QoS

§ Move to a QoS-aware WAN service


No QoS

Source http://www.bricklin.com/qos.htm


No QoS

§ Simple?

§ QoS is most important under adverse conditions

§ Can’t always throw bandwidth at the problem

§  Lack of QoS can delay Adoption of new applications Business capabilities

§ Can’t satisfy success criteria without it!


Force Hub and Spoke

§ Similar to point-to-point topologies

§  Implies Active/Standby

§ Residential/Guest traffic backhauled to hub

§ Hairpin of spoke-to-spoke traffic Increases latency Consumes hub bandwidth Traffic is increasingly peer-to-peer

§  Inflexible


Head-end shaping/per-tunnel QoS

§ Shaping from hub to spoke Per-tunnel Per-Security Association (SA)

§ Deterministic and well understood

§ Great for hub and spoke

ISP/SP

Branch

Datacenter 2 Datacenter 1

ISP/SP

Per Tunnel QoS


Head-end shaping/per-tunnel QoS

Shaper has no visibility to multipoint traffic § TCP applications must go through the DC

§ Static reservation for spoke-to-spoke UDP

§ Remaining bandwidth statically divided among active datacenters

§ See calculations in Buck’s Financial case study


DMVPN Per Tunnel QoS (Dynamic)

! DMVPN Hub Configuration Policy-map SHAPING-1.5MBPS Class class-default shape average 1500000 service-policy site Policy-map SHAPING-1.0MBPS Class class-default shape average 1000000 service-policy site interface Tunnel1 bandwidth 45000 ip address 10.0.0.1 255.255.255.0 ip nhrp map multicast dynamic

ip nhrp map group group1 service-policy output SHAPING-1.5MBPS ip nhrp map group group2 service-policy output SHAPING-1.0MBPS

! Spoke Configuration interface Tunnel1 bandwidth 1500 ip address 10.0.0.2 255.255.255.0 ip nhrp group group1

•  Available in 12.4(22)T •  NHRP group per policy


§ Excellent multipoint model

§ QoS enforcement point has visibility to all traffic

§ Cooperation model with ISP/SP

§ Dependent on QoS configurations offered

§ Examples: MPLS Services from a SP Metro-Ethernet services

QoS-Aware WAN Services

ISP/SP

Branch


ISP/SP

QoS Aware WAN


Solution Capabilities—Teleworker No QoS Per-Tunnel QoS-Aware WAN

Service

Protect Voice and Video No No Yes

Support Business Critical Apps Maybe Maybe Yes

Meet Performance Expectations Maybe Maybe Yes

Utilizes Available Resources

Flexibility to deliver new services

Financially Feasible Yes Yes No

Operationally Feasible Maybe Maybe Yes

Valid Solution No No No


No QoS

Per-Tunnel QoS-Aware

WAN Service




Utilizes Available Resources Yes No Yes

Flexibility to deliver new services No Yes Yes




Solution Capabilities—Teleworker


No QoS Per-Tunnel QoS-Aware

WAN Service

Remote Ingress Shaping

Protect Voice and Video No No Yes Yes

Support Business Critical Apps Maybe Maybe Yes Yes

Meet Performance Expectations Maybe Maybe Yes Yes

Utilizes Available Resources Yes No Yes Yes

Flexibility to deliver new services No Yes Yes Yes

Financially Feasible Yes Yes No Yes

Operationally Feasible Maybe Maybe Yes Maybe

Valid Solution No No No Maybe



Agenda

Theoretical Background


Location of QoS

ISP/SP

Branch

Datacenter 2

ISP/SP

Datacenter 1

ISP/SP

Per Tunnel

QoS Aware WAN

QoS at Branch?



§ Create artificial bottleneck

§ Move queuing from ISP

§ Control delay and drops

§ Slow down TCP

§ Prioritize UDP

ISP

Branch 1

Datacenter 2

ISP

Datacenter 1

ISP



Mathis and TCP performance

http://www.linuxsa.org.au/meetings/2003-09/tcpperformance.screen.pdf

MSS Maximum Segment Size RTT Round Trip Time P Loss probability


Delay

Shaping puts “excess” traffic in a queue

Packets in Queue

Del

ay


TCP Loss

§ TCP design balance Don’t over-run the receiver/network Use available bandwidth

§ TCP will adjust to the correct rate based on delay and drops

§ TCP drops packets!


Bandwidth-Delay Product

Delay (RTT)

Ban

dwid

th


TCP Loss

§ There are 2 types of TCP loss Detected by timeout (red area) Detected by duplicate ACK (green area)


Summary

§ Slow TCP sessions

§ Preserve bandwidth-delay product

§ Make room for UDP


Agenda

Implementing Remote Ingress Shaping



Objective

§ Create artificial bottleneck

§ Move queuing from ISP

§ Control delay and drops

ISP

Branch 1

Datacenter 2

ISP

Datacenter 1

ISP



Ingress Shaping

Problems

§ Platform Support

§ Classification

Solution

§ Shape egress in opposite direction

ISP

Branch


policy-map site class voice priority percent 33 class call-signaling bandwidth percent 5 class critical-data bandwidth percent 37 random-detect dscp-based class class-default bandwidth percent 25 random-detect

Remote Ingress Shaping Configuration example

policy-map shape-in class class-default shape average 1500000 service-policy site interface FastEthernet0/1 Description Connection to branch LAN service-policy output shape-in


Multiple Egress Interfaces/Networks

“LAN” Interface must Support HQoS See all WAN traffic

Branch ISP


Two Router Solution

Apply QoS Policy

ISP R1 R2


VRF-Lite Solution

ISP VRF1

Apply QoS Policy On loopback cable

Branch Router

VRF2


870 Series

Loopback Cable Solution would consume 2 of 4 available LAN ports


GRE Loopback Tunnel Solution

§ Works prior to HQF

§ Verified on 12.4(15)T

ISP VRF1

Apply QoS Policy On loopback tunnel

Branch Router

VRF2


ip vrf inside rd 2:2 ip vrf outside rd 1:1

GRE Loopback Tunnel Configuration Two VRFs (1)

interface Loopback0 ip address 10.1.3.3 255.255.255.255 interface Loopback1 ip address 10.1.3.4 255.255.255.255

! interface Tunnel0 ip vrf forwarding outside ip address 10.3.3.3 255.255.255.0 tunnel source Loopback0 tunnel destination 10.1.3.4 service-policy output shape-in

interface Tunnel1 ip vrf forwarding inside ip address 10.3.3.4 255.255.255.0 tunnel source Loopback1 tunnel destination 10.1.3.3


interface GigabitEthernet1/0 ip vrf forwarding inside ip address 10.0.13.3 255.255.255.0 interface GigabitEthernet2/0 ip vrf forwarding outside ip address 10.0.23.3 255.255.255.0

GRE Loopback Tunnel Configuration Two VRFs (2)

router eigrp 1 network 10.0.0.0 no auto-summary

! address-family ipv4 vrf outside network 10.0.0.0 no auto-summary autonomous-system 1 exit-address-family

! address-family ipv4 vrf inside network 10.0.0.0 no auto-summary autonomous-system 1 exit-address-family


GRE Loopback Tunnel Solution Single VRF and Global Table

§  Same as previous example §  Easier migration and operation

§  Works prior to HQF

§  Verified on 12.4(15)T

ISP VRF1


Branch Router

Global


ip vrf outside ! Create 1 VRFs rd 1:1 ! interface Loopback0 ! Create 2 loopback interfaces in global ip address 10.1.3.3 255.255.255.255 interface Loopback1 ip address 10.1.3.4 255.255.255.255 ! interface Tunnel0 ! Tunnel 0 in VRF outside ip vrf forwarding outside ip address 10.3.3.3 255.255.255.0 tunnel source Loopback0 tunnel destination 10.1.3.4 service-policy output shaper ! interface Tunnel1 ! Tunnel 1 in global ip address 10.3.3.4 255.255.255.0 tunnel source Loopback1 tunnel destination 10.1.3.3

GRE Loopback Tunnel Configuration VRF and Global (1)


interface GigabitEthernet1/0 ! Physical interface in global table ip address 10.0.13.3 255.255.255.0 ! interface GigabitEthernet2/0 ! Physical WAN interface in VRF outside ip vrf forwarding outside ip address 10.0.23.3 255.255.255.0 ! router eigrp 1 network 10.0.0.0 no auto-summary ! address-family ipv4 vrf outside ! Create EIGRP peering between VRF network 10.0.0.0 ! VRF and global no auto-summary autonomous-system 1 exit-address-family

GRE Loopback Tunnel Configuration VRF and Global (2)


890 Series

•  IOS 15.0 and above (No GRE Loopback Cable) •  Physical loopback cable •  More ports including 2 WAN ports


Cisco 890 Loopback Cable Solution

ISP Global

Apply QoS Policy On loopback cable

Branch Router

§  Switch Ports (FA0 to FA7) §  WAN Ports (FA8 and Gig0)

§  Treat switch ports as 2nd box

§  Connect 2nd WAN port to Switch

Switch


interface FastEthernet7 Description Loopback cable to Gig 0 ! interface FastEthernet8 description WAN Interface ip address 10.10.10.99 255.255.255.0 ip nat outside ! interface GigabitEthernet0 ip address 10.10.100.1 255.255.255.0 ip nat inside service-policy output shaper !! interface Vlan1 no ip address

Cisco 890 Loopback Cable Solution


Summary

§ These are tools you already know

§ Shape egress in opposite direction

§ Requires applicable interface

§ Shaping only at branch


Agenda

Remote Ingress Shaping Proof of Concept


Lab Requirements

§ TCP session emulation (PC1 and PC2)

§ WAN emulator (WAN)

§ Bandwidth constrained link (ISP to CPE2 Link)

§ Remote CPE (CPE2)

§ Head-end CPE (CPE1) (optional)

§ Wireshark

PC1 WAN PC2 ISP/SP CPE2 CPE1


Test 1 ISP Drops vs. Shaped Rate

Can we prevent ISP/SP drops due to a congested WAN link?

1)  Yes 2)  Yes, but it is not practical 3)  No, you can’t



ISP Drops vs. Shaped Rate

0

100

200

300

400

500

600

10 9.9 9.8 9.7 9.6 9.5 9.4 9.3 9.2 9.1 9 8.9 8.8 8.7 8.6 8.5 8.4 8.3 8.2 8.1 8

Dro

pped

Pac

kets

Shaped Rate (Mbps)

ISP Drops


Test 2 UDP Delay and Jitter vs. Shaped Rate

Can we bound the jitter of UDP to acceptable levels under congestion?

1)  Yes 2)  No



UDP Jitter vs. Shaped Rate

20

30

40

50

60

70

80

90

10 9.9 9.8 9.7 9.6 9.5 9.4 9.3 9.2 9.1 9 8.9 8.8 8.7 8.6 8.5 8.4 8.3 8.2 8.1 8

Jitte

r (m

s)

Shaped Rate (Mbps)

Jitter


UDP Delay vs. Shaped Rate

40

60

80

100

120

140

160

180

200

220

240

10 9.9 9.8 9.7 9.6 9.5 9.4 9.3 9.2 9.1 9 8.9 8.8 8.7 8.6 8.5 8.4 8.3 8.2 8.1 8

Aver

age

Del

ay (m

s)

Shaped Rate (Mbps)

Average Delay


Test 3 UDP Delay and Jitter vs. TCP Sessions

How does the number of TCP sessions affect UDP delay, loss and jitter?

1)  No impact 2)  Low impact, no action required 3)  High impact, action required



UDP Average Delay vs. TCP Sessions

20

70

120

170

220

270

1 2 3 4 5 10 15 20 25 30 35 40 45 50 55 60 65 70 100

Aver

age

Del

ay (m

s)

TCP Sessions

Average Delay


Test 4 TCP Sessions and Queue Depth

How does the number of TCP sessions affect average queue depth? 1)  Hard to tell 2)  No impact 3)  Increases queue depth 4)  Decreases queue depth



Queue Depth vs. TCP Sessions

40

140

240

340

440

540

640

740

840

35 40 45 50 55 60 65 70

Aver

age

Que

ue D

epth

(Pac

kets

)

TCP Sessions

Average Queue Depth


Test 5 Queue Depth and UDP Delay

Will increasing queue size affect UDP delay, loss and jitter?

Yes No



Delay vs. Queue Depth

Max Queue Size (Packets) Min Delay (ms) Max Delay (ms) Avg Delay (ms)

40 48 109 70 4000 9 57 29

Difference 39 52 41


Conclusions

§ RIS can move queuing from ISP and reduce drops

§ UDP delay and jitter can be bounded to acceptable levels

§ Two key “knobs” Shaped Rate – How aggressively we queue TCP packets Queue Depth – Conserving the bandwidth delay product requires that queue depth increase linearly with the number of TCP sessions

Internet-Based Tests


Lab Setup

§  871W §  3 Mbps cable Internet §  ICMP RTT of 40 ms §  Load generation

FTP HTTrack High definition Internet video

ISP VRF1


Branch Router

Global

Internet


Audience Questions

§  Does ISP queuing delay have a significant impact on delay?

Yes No

§  What is the required ingress shaped rate? 70% of line rate 80% of line rate 90% of line rate

§  How deep will queues need to be? 500 packets 250 packets 100 packets 40 packets


Internet-Based Tests Jitter vs. Shaped Rate

0

20

40

60

80

100

120

140

160

180

200

3.5 3.4 3.3 3.2 3.1 3 2.9 2.8 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2 1.9 1.8 1.7 1.6 1.5

Jitte

r (m

s)

Shaped Rate (Mbps)

Jitter


Internet-Based Test Average Delay vs. Shaped Rate

50

55

60

65

70

75

80

85

90

95

100

3.5 3.4 3.3 3.2 3.1 3 2.9 2.8 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2 1.9 1.8 1.7 1.6 1.5

Del

ay (m

s)

Shaped Rate (Mbps)

Average Delay


Conclusions

§  ISP queue delay peak was 55 ms (95 ms–40 ms = 55 ms) Nearly tripled one-way delay

§  95% of line rate

§ Default (40 packets) queue depth

§  30 ms or less average delay for real-time traffic added by branch and ISP WAN connection

§ GRE Loopback Tunnel on 871W with BVI

§  15% CPU


What Does Remote Ingress Shaping (RIS) Enable?

Two new capabilities that define the use cases 1. Allows you to maintain control over TCP applications,

even if the traffic does not go through your datacenter Examples:

Cloud services (SaaS, IaaS) Teleworkers (residential traffic) Guest networking Split-tunneling

2. Allows a single point of configuration and policy enforcement for a location or WAN link Examples:

A/A Datacenter


Putting it all Together

Teleworker Example Revisited


Internet

Teleworker Overview

PE

DC1

CPE

ISP

DC2


No QoS

Per-Tunnel QoS-Aware

WAN Service












WAN Service


Protect Voice and Video No No Yes Yes

Support Business Critical Apps Maybe Maybe Yes Yes





Operationally Feasible Maybe Maybe Yes Maybe



Buck’s Financial


Internet

Buck’s Financial Overview

§ Financial services company

§  1000s of very small branch offices

§ Dual datacenters

§ Migrating from MPLS VPN to DMVPN

§ DSL and broadband cable connections

§ Future VoIP

Branch Office


PE

ISP

3rd Party 3rd Party

ISP ISP


Internet

Buck’s Financial Challenges

§ Wants to leverage 3rd party (cloud) for live video

§ Branch owners want to use available broadband capacity

§ ScanSafe

§ Future services GuestNet Other 3rd parties

Branch Office


PE

3rd Party 3rd Party

ISP ISP

ISP


Head-End Shaping as a Solution

Shaper has no visibility to multipoint traffic § TCP applications must go through the DC

§ Static reservation for spoke-to-spoke UDP

§ Remaining bandwidth statically divided among active datacenters


Head-End Shaping as a Solution

§ Configure per-tunnel traffic shaping at each DC §  720 Kbps reserved for 3rd party video

(600 Kbps + 20%)

§  160 Kbps reserved for 2 VoIP phone calls § Remaining bandwidth divided between 2 DCs

Branch BW

3rd Party Video 2 VoIP Calls Available to DC

1.5 Mbps 720 Kbps 160 Kbps 310 Kbps

2 Mbps 720 Kbps 160 Kbps 810 Kbps

3 Mbps 720 Kbps 160 Kbps 1310 Kbps



WAN Service


Protect Voice and Video No Yes Yes Yes

Support Business Critical Apps No Yes Yes Yes


Utilizes Available Resources Yes No Yes Yes

Flexibility to deliver new services Maybe No Maybe Yes


Operationally Feasible Maybe Yes Yes Maybe


Solution Capabilities—Buck’s Financial


Looking Ahead


Agenda

Looking Ahead


Traffic Classification

Problem § Ports/Protocols

§ Payload Encrypted

§ DSCP Reliability

§ DSCP Trust ISP

Branch


Internet Head-End

§ More than just Internet Business-to-Business VPN Corporate E-Commerce Access to Cloud Services Branch site-to-site VPN Teleworker User Internet access

§ Critical applications separated by circuits


Internet Head-End

§ Simplified classification

§ Ports/Protocols works better

§ TCP session scaling important!

§ Buffering is key

§ Additional Tools Ironport Web Security Appliance (WSA) Services Control Engine (SCE)


WSA Bandwidth Controls for Streaming Media

§ New in WSA AsyncOS 7.0

§ Overall bandwidth limit.

§ User bandwidth limit.


Services Control Engine (SCE)

§  Application-layer deep packet inspection

§  Real-time traffic control

§  Granular bandwidth metering and shaping

§  Quota management


Explicit Congestion Notification (ECN)

§ Notify sender of congestion without packet loss

§ Specified as RFC 3186 (2001)

§ Requires support on hosts and network

§ Not widely used


Explicit Congestion Notification (ECN)

§ Supported in IOS since 12.2T

§ Disabled by default on Windows 7 Windows Server 2008 Windows Vista Mac OS X 10.5 and 10.6

§ Server Mode for Linux

policy-map QoS_Policy class class-default bandwidth per 70 random-detect random-detect ecn


RSVP

§ RSVP implementation could be modified to address the problem for private WANs

§ Requires routers to initiate reservations

§ See backup slides


Additional RIS Considerations

§  L2 Overhead accounting

§ CPU requirements

§ WAAS “Measure” optimized traffic Transport Flow Optimization (TFO)

§ Viruses/scavenger class User-Based Rate Limiting Drop

§ Anti-replay Use caution if applying QoS policies to encrypted traffic

“If you only have a hammer, then you tend to see every problem as a nail.”

Abraham Maslow


Summary

§ Now you have a new tool!

§ RIS can overcome challenges with Multipoint 3rd Party Non-QoS Aware WAN

§ Enables acceptable UDP performance Even if applications do not go through the DC With a single point of configuration and policy enforcement


Complete Your Online Session Evaluation

§  Receive 25 Cisco Preferred Access points for each session evaluation you complete.

§  Give us your feedback and you could win fabulous prizes. Points are calculated on a daily basis. Winners will be notified by email after July 22nd.

§  Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center.

§  Don’t forget to activate your Cisco Live and Networkers Virtual account for access to all session materials, communities, and on-demand and live activities throughout the year. Activate your account at any internet station or visit www.ciscolivevirtual.com.

101

Visit the Cisco Store for Related Titles

http://theciscostores.com


QoS Golden Rules

§ Start with the goal in mind

§ There is no substitute for sufficient bandwidth

§ Queuing and Scheduling can protect voice and video from data

§ Only Call Admission Control can protect voice from voice and video from video

§ Don’t mix UDP and TCP in the same class

Happy Health


Happy Health Overview

§ Healthcare provider

§ MPLS VPN

§ Dozens of large sites

§ DS-3 or better

§ Applications VoIP Medical Imaging Applications in multiple DCs

Location 1

PE

Datacenter 1

PE

Datacenter 2

PE

DR Site

PE


Happy Health Challenges

§ MPLS VPN Service Provider charges for “burst” usage above 50% of line rate

Location 1

PE

Datacenter 1

PE

Datacenter 2

PE

DR Site

PE


Without RIS

1) TCP applications must go through the DC (or similar QoS enforcement point) to prevent oversubscription

2) Every active datacenter must share bandwidth with other active datacenters

3) Bandwidth must be statically reserved for UDP applications that do not go through the datacenter


Egress Shaping as a Solution No Tunnels

§  Identify destination networks

§ Shape traffic toward each destination

§ Requires a mapping of every network to every location


ip access-list extended site1 permit ip 10.0.1.0 0.0.0.255 any permit ip any 10.0.1.0 0.0.0.255 ip access-list extended site2 permit ip 10.0.2.0 0.0.0.255 any permit ip any 10.0.2.0 0.0.0.255 ip access-list extended site3 permit ip 10.0.3.0 0.0.0.255 any permit ip any 10.0.3.0 0.0.0.255

Traffic Shaping Configuration Example No Tunnels (1)

class-map match-any site1 match access-group name site1 class-map match-any site2 match access-group name site2 class-map match-any site3 match access-group name site3


policy-map site class voice priority percent 33 class call-signaling bandwidth percent 5 class critical-data bandwidth percent 37 random-detect dscp-based class class-default bandwidth percent 25 random-detect

Traffic Shaping Configuration Example No Tunnels (2)

policy-map all-sites class site1 shape average 600000 service-policy site class site2 shape average 400000 service-policy site class site3 shape average 200000 service-policy site

interface FastEthernet0/1 service-policy output all-sites


Egress Shaping as a Solution Static Tunnels

§ Simplifies classification of destination networks

§ Requires a full-mesh overlay on top of existing any-to-any network (5050 tunnels)

§ Shape traffic toward each destination

§ Full mesh routing protocol can cause network meltdown


policy-map site ! Omitted for brevity

Traffic Shaping Configuration Example Static GRE Tunnels

policy-map 600ksite class class-default shape average 600000 service-policy site

policy-map 400ksite class class-default shape average 400000 service-policy site

Interface tunnel 1 Description tunnel to site1 service-policy output 600ksite

Interface tunnel 2 Description tunnel to site2 service-policy output 400ksite


Egress Shaping as a Solution DMVPN

§ Further simplifies the configuration by automating tunnel creation

§ New dynamic per-tunnel QoS, 12.4(22)T

§ Within the tunnel interface associate the QoS policy with the “ip nhrp map group” command

§ Simplifies the association of a QoS policy at the hub to each spoke location

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tunnel_ qos.html#wp1072822


Traffic Shaping Configuration Example DMVPN Per Tunnel QoS (Dynamic)

Policy-map SHAPING-1.5MBPS Class class-default shape average 1500000 service-policy site

Policy-map SHAPING-1.0MBPS Class class-default shape average 1000000 service-policy site

interface Tunnel1 bandwidth 45000 ip address 10.0.0.1 255.255.255.0 ip nhrp map multicast dynamic ip nhrp map group group1 service-policy output SHAPING-1.5MBPS ip nhrp map group group2 service-policy output SHAPING-1.0MBPS

. no ip mroute-cache tunnel source 172.17.0.1 tunnel mode gre multipoint tunnel key 253 tunnel protection ipsec profile DMVPN


No QoS (Do Nothing) Per-Tunnel QoS-Aware

WAN Service


Protect Voice and Video Yes Yes Yes

Support Business Critical Apps Yes Yes Yes

Meet Performance Expectations Yes Maybe Yes

Utilizes Available Resources Yes No Yes

Flexibility to deliver new services Maybe Maybe Yes

Financially Feasible No Yes Yes

Operationally Feasible Yes Maybe Maybe

Valid Solution No No N/A Maybe

Solution Capabilities—Happy Health

Cisco Live! Designing Multipoint WAN QoS

Technology

Transcript of Cisco Live! Designing Multipoint WAN QoS