cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1994
Views
0
Helpful
6
Replies

Packet marking with DSCP on lan core switch or wan router?

paulkilcoyne
Level 1
Level 1

Hi,

Im deploying a cisco network whereby a pair of 6509 switches running VSS act as a collapsed core terminating seperate access switches for data, voice and wifi on separate layer 2 port channels.

A wan router connects to the core switch and onwards to the WAN mpls connection.

Usually we terminate the voice network on an interface on the WAN router and mark voice packets coming into the router through this interface and hence the ISP prioritises voice packets across the WAN via EF.

Q1. Do you see any issues with my design above, i.e. Terminating data, voice and wifi on the core switch?

Q2. Does marking voice packets at the core switch, as opposed to at the router interface, pose any issues regarding the ISPs ability to implement EF? 

Thank you,

 

Paul

6 Replies 6

Dennis Mink
VIP Alumni
VIP Alumni

You will need to talk to your provider.  

For example, lets consider RTP (DSCP value ef), if you set up some sort of trust and or autoqos on your access ports, the phones for instance will send all RTP traffic with 'ef'. if you honor this value on your 6500 and pass it on to your providers router, your provider could decide to trust that value and pass it on.  alternately your provider might still decide to do its own traffic marking. it all depends.

so the answer to Q1:  no  I don't  and Q2: Make sure you talk to your provider, dont assume anything.

 

 

 

 

Please remember to rate useful posts, by clicking on the stars below.

Thanks for the reply.

 

We own the edge router, we mark the voice packets and assign the priority and our ISP honours that.

Thanks,

 

Paul

Hi,

 

With regarding to Q1, I don't see any issues on this design as core switches are made to aggregate lower leaf switches in the tree (as you are using two layer model). I am sure that you are using separate VLANs for these services. However, I strongly recommend to use more solid  isolation approach such as VRFs to make sure that Voice and Data/WiFi don't see each other using inter-vlan routing or vlan hopping.

 

For Q2, QoS SRND will be your great tool to understand this. What I would say now that the best design to keep QoS marking as close to the source as possible. To start with, define your trust boundary which should be close to your source. Then implement trust relationship across the network. After that you can prioritize traffic as it goes through the network. Maintaining DSCP markings across the network will preserve your EF marking and forward it to your ISP.

Thanks for your reply,

any tips on how to configure VRFs for the 6500s? I've never done so before.

 

Also,

the way we implement QoS normally is all on our edge Router as follows (see attached diagram):

 

Marking the voice packets:

class-map match-all Mark_Voice
 match access-group 107
!
policy-map MARK_VOIP
 class Mark_Voice
  set ip dscp ef
!
VOICE interface of Edge router:
service-policy input MARK_VOIP

 


Then on the Edge router WAN interface we match any marked packets:


class-map match-all MPLS_Voice
 match  dscp ef
!
policy-map MPLS_Voice
 class MPLS_Voice
    priority 6200
  set ip dscp ef
 class class-default
    fair-queue
     random-detect
!
WAN interface of Edge router:
service-policy output MPLS_Voice

 

*****************

What I want to do now for this scenario is mark the packets at the port channel point on the core switch and prioritise it above data and wifi on the link between the switch and the router:

 

Marking the voice packets on the core switch:

class-map match-all Mark_Voice
 match access-group 107
!
policy-map MARK_VOIP
 class Mark_Voice
  set ip dscp ef
!
int port-channel 2
service-policy input MARK_VOIP

 

 


Then on the router facing interface of the core switch I want to prioritise VOICE packets:


class-map match-all SWITCH_to_ROUTER_Voice
 match  dscp ef
!
policy-map Voice
 class SWITCH_to_ROUTER_Voice
    priority 6200
  set ip dscp ef
 class class-default
    fair-queue
     random-detect
!
int gi 1/1/1:
service-policy output Voice


Finally when the voice packets get to the WAN interface of the Router, prioritise again:


class-map match-all MPLS_Voice
 match  dscp ef
!
policy-map MPLS_Voice
 class MPLS_Voice
    priority 6200
  set ip dscp ef
 class class-default
    fair-queue
     random-detect
!
int gi 0/0/0:
service-policy output MPLS_Voice

 

Does the above look ok, will it work?

 

Thanks,

 

Paul

 

 

Hi . I like ur answer . if i have: phones---[access switch]---[distr sw] ----[core router]---[wanA]---mpls-[wanB]    I need to start marking packets on every port of the access switch where phones are connected , right ?

2 if port has 2 vlans does mls qos trust cos  and qos policies run for both vlans ? 

3 on the WAN Arouter I see we  have service policies shaping bandwith , on wan B router I see we have service policy to trust by protocols (looks like different people tried their best :). Should I bring WAN-A and WAN_B to same configuration ? if yes which is better ?

Thank you

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Q2 (first): As long as the packet go into your ISP with the correct marking, your ISP shouldn't care when or where they got marked.

Q1: As long as they get passed along to your WAN router and/or it examines and remarks if needed, it shouldn't be a problem.  Traditionally, you want to mark ASAP, and validate (if doing so) ASAP too.  Both QoS marking and/or validation were recommended to be kept off the core, to preserve the core for just high speed packet forwarding.  However, on a 6500, it's likely your marking and/or validations will be done in hardware, and if so, you should impede the core's packet forwarding performance.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: