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


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

 Point-to-point

  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

 Optimal for point-to-point 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


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?


Remote Ingress Shaping

 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

Protect Voice and Video No No Yes

Support Business Critical Apps Maybe Maybe Yes

Meet Performance Expectations Maybe Maybe Yes



Financially Feasible Yes Yes No

Operationally Feasible Maybe Maybe Yes

Valid Solution No No No

Solution Capabilities—Teleworker




Protect Voice and Video No No Yes Yes

Support Business Critical Apps Maybe Maybe Yes Yes

Meet Performance Expectations Maybe Maybe Yes Yes



Financially Feasible Yes Yes No Yes

Operationally Feasible Maybe Maybe Yes Maybe

Valid Solution No No No Maybe

Solution Capabilities—Teleworker

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




Protect Voice and Video No Yes Yes Yes

Support Business Critical Apps No Yes Yes Yes

Meet Performance Expectations Maybe Maybe Yes Yes

Utilizes Available Resources Yes No Yes Yes

Flexibility to deliver new services Maybe No Maybe Yes

Financially Feasible Yes Yes No Yes

Operationally Feasible Maybe Yes Yes Maybe

Valid Solution No No No Maybe

Solution Capabilities—Buck’s Financial


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.

95

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


UDP

  UDP does not adjust to loss or delay   UDP is generally only used for real-time traffic where

drops are preferred to delays DNS Voice Video (VC and live broadcasts) Financial applications (ticker) Video games

  Multicast (non-real time) Content distribution  IPSec NAT-T Does not count Treat like TCP?


ECN Bits

  2 bits in IP Header

  2 bits in TCP Header ECN-echo (ECE) Congestion Window Reduced (CWR)


ECN

How it works  ECN negotiated during TCP handshake

 Sender sets IP ECT bit

 Congested router sets IP CE bit

 Receiver sets TCP ECE bit (echo)

 Sender receives echo

 Sender acts like packet was dropped

 Sender acknowledges echo (CWR)


Jitter vs. Shaped Rate

20

40

60

80

100

120

140

8.8 8.7 8.6 8.5 8.4 8.3 8.2 8 7.9 7.8 7.7 7.6 7.5 7.4 7.3 7.2

Jitter

50 TCP Sessions


Delay vs. Shaped Rate

40

60

80

100

120

140

160

180

8.8 8.7 8.6 8.5 8.4 8.3 8.2 8 7.9 7.8 7.7 7.6 7.5 7.4 7.3 7.2

Average Delay

50 TCP Sessions


TCP Only Network

ISP

Apply QoS Policy

  TCP and UDP on separate interfaces

  Simple configuration   Shape TCP traffic

  “Reserve” bandwidth for UDP

Branch


RSVP

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

 Requires routers to initiate reservations

 RSVP agent

 RSVP and IOS

 RSVP proxy


RSVP RSVP and QoS in Cisco IOS Routers

Control Plane

Data Plane

Control Plane

Data Plane


RSVP IntServ/DiffServ—IOS Model Interface Queuing

Reserved RSVP flows admitted/

rejected based on ‘ip rsvp bandwidth’ only

RSVP flows assigned to priority queue based on LLQ classes (typically, DSCP)

BW reserved for LLQ/ CBWFQ classes based on policy maps and service policy

Packets assigned to LLQ classes/queues based on class maps (typically, DSCP)

Provision priority queue to match RSVP bandwidth + L2 overhead


RSVP IntServ/DiffServ Cisco IOS Model: Notes

  LLQ/CBWFQ classes can be configured as usual and bandwidth allocated to them on the interface

  No bandwidth is reserved with ip rsvp bandwidth

  Reservations accepted/rejected based exclusively on value configured in ip rsvp bandwidth

  RSVP traffic assigned to queues based on LLQ rules (RSVP is not involved in classification)

  If non-RSVP real-time applications are present, provision the PQ accordingly and ensure they use a CAC mechanism to avoid oversubscription

ip rsvp resource-provider none ip rsvp data-packet classification none

To enable this model in IOS:


class-map match-all VOICE match ip dscp ef ! All voice bearer traffic is marked EF class-map match-any CALL-SIGNALING match ip dscp cs3 ! All call signaling traffic is marked CS3 ! policy-map WAN-EDGE class VOICE priority percent 33 ! For Se1/0 512kbps at L2 = 18 G.729 calls class CALL-SIGNALING bandwidth percent 5 ! For Se1/0 77kbps = ~300 SCCP phones ! interface Multilink1 service-policy output WAN-EDGE ! Attaches the MQC policy to Mu1 ppp multilink ppp multilink group 1 ! interface Serial1/0 bandwidth 1536 ! Overall L2 bandwidth for this interface ip rsvp bandwidth 448 ! RSVP BW (L3) to allow 18 G.729 calls ip rsvp resource-provider none ! Enables IntServ/DiffServ mode ip rsvp data-packet classification none ! Enables IntServ/DiffServ mode ip rsvp signaling dscp 24 ! Marks RSVP signaling with DSCP CS3 no ip address

RSVP Cisco IOS Configuration Example (IntServ/DiffServ)

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

Designing Multipoint WAN QoS...

Documents

Transcript of Designing Multipoint WAN QoS...