07-12-2015 03:45 PM - edited 03-08-2019 12:56 AM
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
07-12-2015 06:55 PM
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.
07-13-2015 04:20 AM
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
07-13-2015 03:31 AM
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.
07-13-2015 04:17 AM
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
07-31-2015 08:13 AM
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
07-31-2015 10:26 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide