Show Run - A Networking Blog

Pages

Saturday, February 8, 2014

I was in Bangalore last week attempting for my CCIE Security lab together with my good friend. Unfortunately, both of us didn't make it again. For me, the exam was even harder than the one that i took last November. I guess i need more preparation time for next attempt.

I'm going to take some time off from this security studies and plan for next attempt maybe later this year. One of the reason is, over the past few months, this exam seemed like an excuse to neglect other things. I know that I've been lacking in Data center side of networks, where i wasn't very sure in details what happens after the load balances, ucs/vm, storage. Now, with a DC tech refresh project, it seems like a good time to start absorbing more of DC technologies.

Secondly, I've been wanting to do something for the next generation of network engineers of my country but, i just didn't happen to do anything over the years. I have plans to do some programs for different levels of network engineer. Let's see how that project goes over next few weeks.

Wednesday, January 22, 2014

My 4th time to Jakarta in 4 months.. It's raining here now I'm just stuck in the traffic on the cab to my hotel.. Those who knows Jakarta will understand this feeling..

The first two times was for nexus 7000 but, this time I'm here for IT consultancy project with one of the largest hotel group in the world. In the past few months, I became one of the approved IT consultants for said hotel group in charge of network, wifi, pabx, cabling, server room, power, aircon, cctv, writing tender documents, project management if necessary..

You might ask, how did a network engineer end up doing all these.. Is it relevant to my career? Well, I always believe in the saying "no single job makes a career, no single job breaks a career".

I'm doing IT consultancy on one hand and doing my usual network projects on the other hand.. Even with less routers and switches, I've learned so much dealing with consultants from different line of work, hospitality, construction, architect, interior designers, mechanical and electrical part of the projects.

Sunday, January 19, 2014

Didn't make it.. only managed to get overall score more than 70%.. did a few mistakes in perimeter security and secure access. Well.. there's not a lot of room for errors in the lab exam..

Anyway, managed to get a slot in Bangalore during Chinese new year. I hoped her to be nice to me as last time.. by the way, good news for our Burmese candidates as you can get visa on arrival at the immigration.

Thursday, August 8, 2013

Cisco sent me a payment reminder yesterday. I was thinking hard if i should confirm my lab exam appointment or not.. A lot of things happening at the new company. A job role that i'm not familiar with.. a lot of people leaving and joining.. I'm also assign to take care of new F5 business and i need to go for 5 days bootcamp next week.. etc.. etc..

Let's see what i have studied so far.. I have watched all the IPX VOD but, I have only finished 3 labs from IPX vol 1 until now. However, I have covered most of the topic from my previous studies and work experience. I think i should be able to do it.

So today, I decided to made the payment and go ahead with the schedule. damn.. these mobile labs are expensive... I'd better make it worth.. So, I will be doing 2 session each day from IPX during coming long holiday and hopefully, i should be finishing all the volume 1 labs at the end of the month. Vol 2 only has 5 labs.

I'm not sure why INE is so slow with coming out on security labs.. :| I will be doing some of their vol 1 labs during week days evening.. 3 months is short.. so..more studies and less fun for me these months..

Thursday, March 28, 2013

It has been so long since i posted my last post here.. But, as "time and tide wait for no man" it's almost 4 years gone since i got my number. A few months back, The good guy Cisco sent me an email to remind me of my number expiry date which is in June..

I have been thinking if i should go for CCIE Security or CCDE.. Piff.. after trying the demo exam of CCDE from cisco learning network, it was decide.. Go for Security.. LOL. DE is just a little far reach for me at this point. Anyway, I have been studying CCNP security and Wireless last year and things i learned while working on projects, it should be fairly easier for me but, wait.. ISE?? Ironport??

Lucky me, IPExpert has released study materials for CCIE Security V4 and i have been watching VOD for last couple of days. All the Volume 1 technology focused labs should be released by end of the month. I should start doing lab from next month onwards.

I will try to update the blog regularly in coming weeks until the hunt is completed..

Tuesday, July 3, 2012

The orginal version of this post can be found here. With all the reduciously platform dependent QOS configuration, i found this post extremely helpful to all the network engineers.

Overview

The
purpose of this document is to outline the local area network (LAN)
quality of service templates that will be implemented by you Unified
Communications engineers. This document contains basic configuration
details that should be followed during any UC deployment. The
configurations contained within this document are based on Cisco’s
Quality of Service SRND and Unified Communications Manager SRND. For a
comprehensive list of configuration details, reference the Cisco Quality
of Service SRND and Cisco Unified Communications Manager SRND.

The
configurations in this document should be considered as the base line
for any implementation and should be included in any implementation as
part of the standard delivery process. LAN traps should be conducted
after implementing the QoS to ensure that proper markings are being set
and maintained throughout the enterprise.

The
following markings are used to designate traffic, per the Cisco SRND.
These are the markings that you will account for in the base
professional services implementation pricing.

Voice Bearer Control Video
DSCP 46 (EF) 24 (CS3) 34 (AF41)
COS 5 3 4

Soft Clients

When
IP Phones are deployed in conjunction with other soft clients, such as
CIPC, CUVA, or CUPC, then it is important to ensure the proper marking
of soft client UC traffic. This is accomplished through the use of
access lists and service policies.

The voice component of a call
can be classified in one of two ways, depending on the type of call in
progress. A voice-only (or normal) telephone call would have the media
classified as CoS 5 (IP Precedence 5 or PHB EF), while the audio channel
of a video conference would have the media classified as CoS 4 (IP
Precedence 4 or PHB AF41). All the Cisco IP Video Telephony products
adhere to the Cisco Corporate QoS Baseline standard, which requires that
the audio and video channels of a video call both be marked as CoS 4
(IP Precedence 4 or PHB AF41). The reasons for this recommendation
include, but are not limited to, the following: • To preserve lip-sync between the audio and video channels • To provide separate classes for audio-only calls and video calls

Cisco
Unified Personal Communicator and Cisco IP Communicator with Cisco
Unified Video Advantage are both voice and video capable, which presents
two challenges when using the ACL and policy map for packet
classification and DSCP re-marking. First, Cisco Unified Personal
Communicator uses the same IP address and UDP port range to source voice
and video streams. The ACL that is based on IP address and port number
is not granular enough to differentiate a voice call from a video call
in order to apply appropriate DSCP re-marking. Second, Cisco IP
Communicator uses the same IP address and UDP port range to source its
voice packets. Similarly, the ACL is not granular enough to
differentiate the voice stream of an audio-only call from the voice
stream of a video call. Therefore, using the ACL and policy-map for
packet classification and DSCP re-marking is not a feasible QoS solution
for software-based endpoints.

Because both Cisco Unified
Personal Communicator and Cisco IP Communicator with Cisco Unified Video
Advantage mark their signaling and media packets correctly as they
ingress the network, Cisco recommends configuring the policy map to
trust the DSCP marking of incoming traffic and apply traffic policing
and rate limiting.

1. Catalyst 3550

The Catalyst 3550 switch mode is generally found in the access layer of the LAN. This model supports a 1P3Q1T queuing model.

Global Commands

These
commands are entered on a global level and are necessary in all QoS
implementations. They are used to properly map COS and DSCP values as
well as to associate these markings with the appropriate interface queue
and threshold.Switch(config)#mls qosSwitch(config)#mls qos map cos-dscp 0 8 16 24 34 46 48 56

When
IP Phones are deployed in an environment without other soft clients
such as CIPC, CUVA, or CUPC, then the configuration for these access
ports can be to simply trust the COS of the IP Phones. If a client will
have any soft clients in the enterprise, it is recommended that you
follow the configuration template for “IP Phones with Soft clients” as
it is not feasible to know exactly which ports may or may not have soft
clients active.Switch(config)#int fx/ySwitch(config-if)#wrr-queue bandwidth 5 25 70 1Switch(config-if)#wrr-queue cos-map 1 1Switch(config-if)#wrr-queue cos-map 2 0Switch(config-if)#wrr-queue cos-map 3 2 3 4 6 7Switch(config-if)#wrr-queue cos-map 4 5Switch(config-if)#priority-queue outSwitch(config-if)#mls qos trust device cisco-phoneSwitch(config-if)#mls qos trust cos

IP Phones with Soft Clients

Because
both Cisco Unified Personal Communicator and Cisco IP Communicator with
Cisco Unified Video Advantage mark their signaling and media packets
correctly as they ingress the network, Cisco recommends configuring the
policy map to trust the DSCP marking of incoming traffic and apply
traffic policing and rate limiting. It should be noted that this
document includes IP Phone control traffic for SCCP, Secure SCCP, and
SIP implementations.

The client can elect to add additional
classes for other applications that fall into the Bulk, Transactional,
or Interactive classes such as Oracle, FTP, etc by configuring
additional ACLs and class-maps. You will be creating classes for voice
and video. All other traffic not included in these classes will be
policed at 5Mbps. This helps protect the environment from DoS attacks,
and will not affect legitimate traffic.

Policers

Since we
are going to be marking traffic from PCs to higher classes within the
QoS policies, we need to ensure that we do not open the infrastructure
up to a DoS attack from these PCs by allowing them to transmit more data
than necessary in each class. This is done with policers. By policing
unexpected packets to DSCP 8 (scavenger), we have made excessive packets
with policed markings a lower priority than 0.Switch(config)#mls qos map policed-dscp 0 24 26 34 to 8

Class-Maps
are created to place the traffic identified by the access lists into
the appropriate QoS classes. The 3550 switch can classify based on VLAN
ID, so hierarchy classes are utilized for this switch. In the
following example, “VV” refers to the Voice VLAN ID.class-map match-all VVLAN-VOIP match access-group name VVLAN-VOIPclass-map match-all VVLAN-SIGNALING match access-group name VVLAN-SIGNALINGclass-map match-all MULTIMEDIA-CONFERENCING match access-group name MULTIMEDIA-CONFERENCINGclass-map match-all SIGNALING match access-group name SIGNALINGclass-map match-all TRANSACTIONAL-DATA match access-group name TRANSACTIONAL-DATAclass-map match-all BULK-DATA match access-group name BULK-DATAclass-map match-all SCAVENGER match access-group name SCAVENGERclass-map match-all DEFAULT match access-group name DEFAULT

Policy-Maps

Policy-Maps
are created in order to take action on traffic within a class. In
these examples, the policers assume that the voice only calls will use
G.711 and that video calls will not exceed 384k. If a voice codec with a
higher bandwidth was used, such as G.722, the policer for the voice
class would need to be altered to 320k, instead of 128k.policy-map PER-PORT-POLICING class VVLAN-VOIP set dscp ef police 128k 8000 exceed-action drop

Trunk
ports, which could include connections to other switches, as well as
Dot1Q connections to routers, should be configured to trust the DSCP
markings from the neighboring device.Switch(config)#int gx/ySwitch(config-if)#queue-set 1Switch(config-if)#srr-queue bandwidth share 1 70 25 5Switch(config-if)#srr-queue bandwidth shape 30 0 0 0Switch(config-if)#priority-queue outSwitch(config-if)#mls qos trust dscp

When
IP Phones are deployed in an environment without other soft clients
such as CIPC, CUVA, or CUPC, then the configuration for these access
ports can be to simply trust the COS of the IP Phones. If a client will
have any soft clients in the enterprise, it is recommended that you
follow the configuration template for “IP Phones with Soft clients” as
it is not feasible to know exactly which ports may or may not have soft
clients active.Switch(config)#int gx/ySwitch(config-if)#queue-set 1Switch(config-if)#srr-queue bandwidth share 1 70 25 5Switch(config-if)#srr-queue bandwidth shape 30 0 0 0Switch(config-if)#priority-queue outSwitch(config-if)#mls qos trust device cisco-phoneSwitch(config-if)#mls qos trust cos

IP Phones with Soft Clients

Because
both Cisco Unified Personal Communicator and Cisco IP Communicator with
Cisco Unified Video Advantage mark their signaling and media packets
correctly as they ingress the network, Cisco recommends configuring the
policy map to trust the DSCP marking of incoming traffic and apply
traffic policing and rate limiting. It should be noted that this
document includes IP Phone control traffic for SCCP, Secure SCCP, and
SIP implementations.

The client can elect to add additional
classes for other applications that fall into the Bulk, Transactional,
or Interactive classes such as Oracle, FTP, etc by configuring
additional ACLs and class-maps. You will be creating classes for voice
and video. All other traffic not included in these classes will be
policed at 5Mbps. This helps protect the environment from DoS attacks,
and will not affect legitimate traffic.

Policers

Since we
are going to be marking traffic from PCs to higher classes within the
QoS policies, we need to ensure that we do not open the infrastructure
up to a DoS attack from these PCs by allowing them to transmit more data
than necessary in each class. This is done with policers. By policing
unexpected packets to DSCP 8 (scavenger), we have made excessive packets
with policed markings a lower priority than 0.Switch(config)#mls qos map policed-dscp 0 24 26 34 to 8

Class-Maps
are created to place the traffic identified by the access lists into
the appropriate QoS classes. A class-map is created for each traffic
type for which an ACL was created.class-map match-all VVLAN-VOIP match access-group name VVLAN-VOIPclass-map match-all VVLAN-SIGNALING match access-group name VVLAN-SIGNALINGclass-map match-all MULTIMEDIA-CONFERENCING match access-group name MULTIMEDIA-CONFERENCINGclass-map match-all SIGNALING match access-group name SIGNALINGclass-map match-all TRANSACTIONAL-DATA match access-group name TRANSACTIONAL-DATAclass-map match-all BULK-DATA match access-group name BULK-DATAclass-map match-all SCAVENGER match access-group name SCAVENGERclass-map match-all DEFAULT match access-group name DEFAULT

Policy-Maps

Policy-Maps
are created in order to take action on traffic within a class. In
these examples, the policers assume that the voice only calls will use
G.711 and that video calls will not exceed 384k. If a voice codec with a
higher bandwidth was used, such as G.722, the policer for the voice
class would need to be altered to 320k, instead of 128k.policy-map PER-PORT-POLICING class VVLAN-VOIP set dscp ef police 128k 8000 exceed-action drop

Trunk
ports, which could include connections to other switches, as well as
Dot1Q connections to routers, should be configured to trust the DSCP
markings from the neighboring device.Fast EthernetSwitch(config)#int fx/ySwitch(config-if)#qos trust dscpSwitch(config-if)#service-policy output DBLSwitch(config-if)#tx-queue 3Switch(config-if-tx-queue)#priority highSwitch(config-if-tx-queue)#shape percent 30

When
IP Phones are deployed in an environment without other soft clients
such as CIPC, CUVA, or CUPC, then the configuration for these access
ports can be to simply trust the COS of the IP Phones. If you will have
any soft clients in the enterprise, it is recommended that you follow
the configuration template for “IP Phones with Soft clients” as it is
not feasible to know exactly which ports may or may not have soft
clients active.Fast EthernetSwitch(config)#int fx/ySwitch(config-if)#qos trust device cisco-phoneSwitch(config-if)#qos trust cosSwitch(config-if)#service-policy output DBLSwitch(config-if)#tx-queue 3Switch(config-if-tx-queue)#priority highSwitch(config-if-tx-queue)#shape percent 30

Because
both Cisco Unified Personal Communicator and Cisco IP Communicator with
Cisco Unified Video Advantage mark their signaling and media packets
correctly as they ingress the network, Cisco recommends configuring the
policy map to trust the DSCP marking of incoming traffic and apply
traffic policing and rate limiting. It should be noted that this
document includes IP Phone control traffic for SCCP, Secure SCCP, and
SIP implementations.

You can elect to add additional classes for
other applications that fall into the Bulk, Transactional, or
Interactive classes such as Oracle, FTP, etc by configuring additional
ACLs and class-maps. You will be creating classes for voice and video.
All other traffic not included in these classes will be policed at
5Mbps. This helps protect the environment from DoS attacks, and will not
affect legitimate traffic.

Policers

Since we are going to
be marking traffic from PCs to higher classes within the QoS policies,
we need to ensure that we do not open the infrastructure up to a DoS
attack from these PCs by allowing them to transmit more data than
necessary in each class. This is done with policers. By policing
unexpected packets to DSCP 8 (scavenger), we have made excessive packets
with policed markings a lower priority than 0.Switch(config)#qos map dscp policed 0 24 26 34 to 8

Class-Maps
are created to place the traffic identified by the access lists into
the appropriate QoS classes. A class-map is created for each traffic
type for which an ACL was created.class-map match-all VVLAN-VOIP match access-group name VVLAN-VOIPclass-map match-all VVLAN-SIGNALING match access-group name VVLAN-SIGNALINGclass-map match-all MULTIMEDIA-CONFERENCING match access-group name MULTIMEDIA-CONFERENCINGclass-map match-all SIGNALING match access-group name SIGNALINGclass-map match-all TRANSACTIONAL-DATA match access-group name TRANSACTIONAL-DATAclass-map match-all BULK-DATA match access-group name BULK-DATAclass-map match-all SCAVENGER match access-group name SCAVENGERclass-map match-all DEFAULT match access-group name DEFAULT

Policy-Maps

Policy-Maps
are created in order to take action on traffic within a class. In these
examples, the policers assume that the voice only calls will use G.711
and that video calls will not exceed 384k. If a voice codec with a
higher bandwidth was used, such as G.722, the policer for the voice
class would need to be altered to 320k, instead of 128k.policy-map PER-PORT-POLICING class VVLAN-VOIP set dscp ef police 128k 8000 exceed-action drop

In
order to enforce the classifications and policies, the policy-map must
be applied to the ingress of all IP Phone and PC ports.Switch(config)#int fx/ySwitch(config-if)#qos trust device cisco-phoneSwitch(config-if)#service-policy output DBLSwitch(config-if)#service-policy input PER-PORT-POLICINGSwitch(config-if)#tx-queue 3Switch(config-if-tx-queue)#priority highSwitch(config-if-tx-queue)#shape percent 30

These
Catalyst switch models can be found in the access, distribution, or
core layers of the LAN. These models support a 1P3Q1T queuing model.

Global Commands

These
commands are entered on a global level and are necessary in all QoS
implementations. They are used to properly map COS and DSCP values as
well as to associate these markings with the appropriate interface queue
and threshold.Table Maptable-map COS-2-DSCP map from 0 to 0 map from 1 to 8 map from 2 to 16 map from 3 to 24 map from 4 to 34 map from 5 to 46 map from 6 to 48 map from 7 to 56 default copy!

The
per-port/per-VLAN policing model is essentially the same for the
Catalyst 4500-E Supervisor 6-E, except that it does not require a global
policed-DSCP map and thus the policing commands are slightly different;
also no trust-DSCP statement is required on the interface(s)

UBRL
adopts microflow policing capability to dynamically learn traffic flows
and rate limit each unique flow to an individual rate and, as such, is a
highly effective and efficient policing tool, particularly at the
distribution ayer in a medianet campus network.

UBRL is available
on Supervisor Engine V-10GE with NetFlow support. UBRL can be applied
to ingress traffic on routed interfaces and is typically used in
environments where a per-user, granular rate limiting mechanism is
required, such as at the distribution layer, to provide a second line of
policing defense in the campus. Like other policers, UBRL can be used
to drop or remark exceeding flows.

A flow is defined by
five-tuples (IP source address, IP destination address, IP protocol
field, Layer 4 protocol source, and destination ports), which are the
same for each packet in the flow. Flow-based policers apply a single
policy to discrete flows without having to specify the
virtually-infinite tuple-combinations. UBRL can also be applied with
source or destination flow masks; these masks apply an aggregate
microflow policing policy to multiple flows sharing the same source or
IP destination addresses.

In the per-port UBRL Model, a class map
matches on a microflow basis and aggregates these by source addresses.
Then a policer applies an aggregate limit to all microflows sharing a
common source IP address, remarking traffic in excess of the policing
rate.

Remarking is performed by configuring a policed-DSCP map
with the global configuration command qos map dscp policed, which
specifies which DSCP values are subject to remarking (if out-of-profile)
and what these values should be remarked to (which in the case of
scavenger class QoS policies, the remarking value is CS1/DSCP 8).

UBRL is supported on Layer 3 interfaces and can be applied on either a per-port or per-port/per-VLAN-basis

In
contrast with the previous example, if the campus distribution block is
using a Layer 2/Layer 3 design, and as such has Layer 2 trunked
interfaces (TenGigabitEthernet 1/1 and 1/2) connecting it to the access
layer switches, then UBRL can be applied on a per-port/per-VLAN basis.
In this case, separate UBRL policies can be applied to each VLAN
traversing the trunked interfaces via per-port/per-VLAN UBRL policies as
each VLAN is routed through the switch.

To highlight policy
flexibility, additional levels of classification are included in this
second UBRL example (which incidentally can also be applied to the
per-port UBRL model). Instead of applying a blanket UBRL policy to all
endpoints, separate UBRL polices can be applied to different types of
endpoints or application-and-endpoint-combinations. For example, VoIP
from Cisco IP phones in the VVLAN can be rate limited to 128 Kbps, while
signaling traffic from these endpoints can be limited to 32 kbps.
Similarly, TelePresence endpoints in the VVLAN (which mark their media
flows to CS4) can be limited to 25 Mbps. All other endpoint-generated
traffic in the VVLAN can be limited to 32 kbps per endpoint.

Similar
policy granularity can be applied to the DVLAN policer, if desired.
However in this example, a simplified DVLAN policer is applied to all
flows to ensure that any DVLAN endpoint transmitting at more than 5%
capacity (an example value) of the access edge 10/100/1000 switch ports
are subject to data plane policing/scavenger class QoS.

Static
DSCP-trust is configured on the physical ports and the per-port/per-VLAN
UBRL policers are applied to their respective VLANs within the trunked
interface

These
Catalyst switch models can be found in the distribution or core layers
of the LAN. The queuing method is directly dependent upon the line
cards. Consult the Cisco QoS SRND or line card datasheet on Cisco
website documentation to ensure that the proper queuing method is
configured on the switch.

Global Commands

These commands
are entered on a global level and are necessary in all QoS
implementations. They are used to properly map COS and DSCP values as
well as to associate these markings with the appropriate interface queue
and threshold.Switch(config)#mls qosSwitch(config)#mls qos map cos-dscp 0 8 16 24 34 46 48 56

Trunk Port Commands

Trunk
ports, which could include connections to other switches, as well as
Dot1Q connections to routers, should be configured to trust the DSCP
markings from the neighboring device. Additionally, with Native IOS, the
queue configurations are also made on the actual interfaces and are
dependent upon the transmit queue support of the line cards.

Microflow
policing dynamically learns traffic flows and rate limits each unique
flow to an individual rate and as such, is a highly effective and
efficient policing tool—particularly at the distribution layer in a
medianet campus network.

Microflow policing can be applied to
ingress traffic on routed interfaces and is typically used in
environments where a per-user, granular rate limiting mechanism is
required—such as at the distribution layer—to provide a second-line of
policing defense in the campus. Like other policers, microflow policing
can be used to drop or remark exceeding flows.

Microflow policers
are enabled with the police flow policy-map class-action command. A
flow is defined by five-tuples (IP source address, IP destination
address, IP protocol field, Layer 4 protocol source, and destination
ports), which are the same for each packet in the flow. Microflow
policers apply a single policy to discrete traffic flows, without having
to specify the virtually-infinite tuple combinations. Microflow
policing can also be applied with source or destination flow masks (with
the mask src-only and mask dest-only optional keywords, respectively);
these masks apply an aggregate microflow policing policy to multiple
flows sharing the same source or IP destination addresses.

In the
per-port microflow policing model, a flow-based policer is applied with
a mask src-only option and applies an aggregate limit to all microflows
sharing a common source IP address, remarking traffic in excess of the
policing rate.

Remarking is performed by configuring policed-DSCP
maps with the global configuration commands mls qos map policed-dscp
normal-burst (which specifies the exceeding remarking action) and mls
qos map policed-dscp max-burst (which specifies the violating remarking
action, in the case of a dual rate policer). These commands specify
which DSCP values are subject to remarking if out-of-profile and what
value these should be remarked as (which in the case of data plane
policing/scavenger class QoS policies, this value is CS1/DSCP 8).

Even
if single rate policers are used, it is recommended to configure the
mls qos map dscp policed max-burst markdown map, as the
maximum_burst_bytes parameter for the policer is set to equal to the
normal_burst_bytes parameter, unless explicitly specified otherwise. In
other words, the PIR is set to equal the CIR, unless explicitly
specified otherwise, and thus the exceed-action policed-dscp-transmit
keywords causes PFC QoS to mark traffic down DSCP values as defined by
the policed-dscp max-burst markdown map (and not the policed-dscp
normal-burst markdown map).

In
contrast with the previous example, if the campus distribution block is
using a Layer 2/Layer 3 design, and as such has Layer 2 trunked
interfaces (TenGigabitEthernet 3/1 and 3/2) connecting it to the access
layer switches, then microflow policing can be applied on a per-VLAN
basis. In this case, separate microflow policing policies can be applied
to each VLAN.

To highlight policy flexibility, additional levels
of classification are included in this second microflow policing
example (which incidentally can also be applied to the per-port
microflow policing model). Instead of applying a blanket microflow
policer to all endpoints, separate microflow policers can be applied to
different types of endpoints or application-and-endpoint-combinations.
For example, VoIP from Cisco IP phones in the VVLAN can be policed to
128 Kbps, while signaling traffic from these endpoints can be policed to
32 kbps. Similarly, TelePresence endpoints in the VVLAN (which mark
their media flows to CS4) can be policed to 25 Mbps. All other
endpoint-generated traffic in the VVLAN can be policed to 32 kbps per
endpoint.

Similar policy granularity can be applied to the DVLAN
policer, if desired. However in this example, a simplified DVLAN policer
is applied to all flows to ensure that any DVLAN endpoint transmitting
at more than 5% capacity (an example value) of the access edge
10/100/1000 switch ports are subject to data plane policing/scavenger
class QoS.

In
order to ensure true end to end QoS throughout the environment, the
voice gateways must be configured to properly mark control and bearer
traffic sourced from their processes, including MGCP, H.323, and SIP.

MGCP Gateways

By
default, MGCP gateways mark bearer traffic with DSCP EF and control
traffic with AF31. This is not consistent with current standards. The
following modifications should be made to all deployed MGCP gateways.Router(config)#mgcp ip qos dscp cs3 signalingRouter(config)#mgcp ip qos dscp ef media

H.323/SIP Gateways

By
default, H.323 and SIP dial-peers mark bearer traffic with DSCP EF and
control traffic AF31. This is not consistent with current standards. The
follow modifications should be made to VOIP dial-peers on all deployed
H.323 and SIP gateways.Router(config)#dial-peer voice x voipRouter(config-dial-peer)#ip qos dscp cs3 signalingRouter(config-dial-peer)#ip qos dscp ef media

WAN Quality of Service

When
you are trying to guarantee traffic service over long distance
involving WAN circuits such as point-to-point, MPLS, and Metro Ethernet;
then there must be QoS implementation on your WAN gateway of all ends
of your location. In addition, your WAN QoS implementation must match
QoS specification your service provider uses to maintain end-to-end QoS
service.

As illustration, let's say you have point-to-point 1
Gbps Metro Ethernet circuit from your service provider to interconnect
two of your locations. The service provider has specification that 5
Mbps is guaranteed for Class of Service (CoS) Priority 5 (EF) traffic, 5
Mbps is guaranteed for CoS Priority 2; while the remaining bandwidth is
freely used for CoS default traffic.

Let's assume you have IP
Phone that uses DSCP EF 5 or CoS 5 of UDP port range 16384 - 32767 for
voice traffic and uses DSCP AF 41 (CS 3) or CoS 3 of SIP (UDP and TCP
port range 5060 - 5061) and SCCP (TCP port range 2000 - 2002) for
signalling traffic. Within LAN, you typically let these specification as
default while setting all LAN switch access and trunk ports to
acknowledge these traffic. Once the traffic is headed to the
point-to-point circuit, then somehow you have to modify the traffic
specification when you intend to match your traffic specification with
the service provider specification.

Assume you like to utilize
the service provider CoS 5 for the voice traffic, CoS 2 for the
signalling, and remaining bandwidth is utilize for other traffic such as
email, web, and file sharing. Therefore as the traffic is about to
leave one location over the point-to-point circuit to reach your other
location, you need to map your existing CoS 5 traffic to the service
provider CoS 5, map your existing CoS 3 traffic to the service provider
CoS 2, and map remaining traffic to the service provider CoS default
traffic.

When the traffic is already going over the
point-to-point circuit from one location and arrive at the other
location, you need set your traffic back to its original specification
in order to match your traffic specification. Therefore as the traffic
arrives at the other location, you need to map the service provider CoS 5
traffic to the original CoS 5 traffic, map the service provider CoS 2
to the original CoS 3, and map remaining traffic as default traffic.

As
you may note that these WAN QoS mapping occurs on your WAN gateway
while LAN QoS mapping occurs on your LAN. Following is one solution how
the WAN QoS mapping and configuration look like. The assumption here is
that your WAN gateway is a router using GigabitEthernet 0/0/0 port to
connect to the WAN circuit.

The
information posted here is a summarized version of the Cisco AVVID QoS
Design Guide. The person who posted this is not liable for any network
problems or any damage caused by configuring their router to the
following specification. If in doubt, open up a Cisco TAC case where a
Cisco Engineer will get in touch to help you implement or troubleshoot
your design or issue respectively. You may also ask the Cisco forum
community for any advice but community accept no liability for any
recommendations made which are then implemented.

The example
below is using a Cisco 79xx IP Phone, 2924 Switch (12.0(5)XU EN, and a
2600 Router (12.2(11)T IP/FW/IDS PLUS IPSEC 56). Make sure the versions
of IOS that you're running support the commands used before implementing
in a production environment. It also assumes that you are using
separate VLANs for data and voice (VLAN 100 for data, and 101 for
voice).

This example assumes the following network setup: PC--->79xx---->2924---->2600---->Internet

The
above port configuration allows for both voice and data traffic from
separate vlans. Cisco IP Phones automatically support 802.1q trunking
and 802.1p COS tagging, which will tag all outgoing voice traffic with
an L2 COS of 5, and a L3 IP Precedence of 5. The 'switchport priority
extend cos 0' ensures that all data traffic has it's L2 COS tag
re-classified as 0. This will ensure a PC connected to the phone is not
also classifying its traffic.

NOTE:
The 'speed auto' command is extremely important. Cisco IP phones
default to auto-negotiation for speed and duplex.If the switch port is
set to 100baseT full-duplex, the IP phone automatically sets its port to
100baseT half-duplex, causing a duplex mismatch.

Configuring the 2600 router:

The first thing we need to do is define access-lists to match our
voice traffic. We will create 2 extended ACLs, one for the voice RTP
traffic, and one for the voice signaling traffic.

NOTE:
You may also use a 'permit ip 1.1.1.0 0.0.0.255 any' command on the
signaling access-list to match all hosts in a particular subnet,
assuming all IP phones are on the same subnet and their own vlan.

The
policy-map on the router places all voice traffic into the Priority
Queue, which is given 240kbps of bandwidth. All signaling traffic is in a
class-based queue with 16kbps of bandwidth. And all other traffic is
queued using Weighted Fair Queuing.

NOTE:
If you are using sub-interfaces, applying the policy to the fa0/0
interface will also apply it to all sub-interfaces (i.e. fa0/0.1,
fa0/0.2 etc.) To apply a QoS service-policy to a specific sub-interface
refer to this Cisco link.Applying QoS Features to Ethernet Sub-interfaces

As
Qos is generally configured on outgoing traffic, it will help if you
have control over both sides of the link. You can also apply rate
limiting to inbound traffic if you so choose, however it will only work
with TCP traffic.!interface Serial0/0 rate-limit input 1408000 8000 8000 conform-action transmit exceed-action drop

This
will allow no more than 1408kbps through; any excess will be dropped.
Again, this only works for TCP traffic, since dropped packets will cause
the sender to back off and try again slower.