[c-nsp] ATM QOS

Tue Oct 4 14:45:53 EDT 2005

 OK, so its looking more and more like I can't get this to work the way
I want over ATM. 

So, we use soft PVCs for all our VC setup. So my question is, since I
only have a few sites that I need to ensure QOS between, I can make this
work, if I setup my service-policies on tehse interfaces, and then make
their VCs of a higher traffic class so that traffic on those VCs will
have ensured QOS versus other less sensitive traffic. 

This would lead me to two issues I can immediately see. 

1. I want to continue to use soft PVCs but I want to set certain VCs
that will be created between certain sites to be of a higher traffic
class. How the heck to I do this with soft VCs where they are setup
automatically? 

2. Since the primary motivation is initially for a disaster recovery
scenario, my traffic will not normally be very high over this path,
unless we have to deploy a temporary call center over VOIP, or a portion
of the voice system fails (such as the IVR for example). So I do not
want to make any VCs that can't give up their resorces when there is low
traffic over the link. If memery serves, then I cannot use a CBR VC
because it "reserves" its bandwith. So as I recall there is a way to
setup ABR or rt-VBR to allow the switches to see what portion of a VC is
not in use and allocate that bandwidth if needed for other traffic until
the priority VC starts to flow more data. I remember reading this
somewhere, but have no idea where to start configuring. 
I think this is the setup that Dan recommended (Thanks for the response,
Dan!) but since this VC could carry as much as 20 T-1's worth of
voice-related data, I sure don't want that bandwidth setting idle most
of the time. IF that would not affect other VCs being setup along the
same underlying ATM link, then I could start tackling the policy routing
that is not my forte.

Thanks,

Gus

-----Original Message-----
From: Dan Martin [mailto:dmartin at micromuse.com] 
Sent: Monday, October 03, 2005 5:02 PM
To: Nassess, George (Contractor)
Subject: RE: [c-nsp] ATM QOS

Step 1

Set up a soft pvc on your atm switch with cbr like traffic descriptors.

SCR = 1.536 Mbps
PCR = 1.544
MBS = 300
CDVT = low

I'm assuming pbx equals t1 but I'm not taking into account how much
compression you're doing.

Remember what switch port that was.

Now go to a router plugged into that switch port.

Create a classical ip subinterface on the atm interface on that router.

Give it the same traffic descriptors.

Now you need to figure out how to mark the inbound pbx traffic and set
up some policy based routing that takes all that traffic to that clip
interface with the cbr contract.

If you do the same on the other side, there is your pbx to pbx link.

-----Original Message-----
From: Nassess, George (Contractor) [mailto:George.Nassess at gmacrfc.com] 
Sent: Monday, October 03, 2005 5:51 PM
To: Dan Martin; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] ATM QOS

Thanks for the feedback, 

Well, nothing is broken....yet. The purpose is for business resilliency,
if a large site failed, we need to move their voice traffic over to a
backup PBX at another site. The means to get to that backup site for any
displaced users is IP over ATM. So we won't have this traffic all the
time, but need to be able to handle it as priority traffic. 

The parts of the network that run LANE are over nice OC12 links. They
have no problem, and do not worry me. (Once we migrate to all optical
switching in probably 12-18months, we can configure this all on our
6500s and life will be a little easier. If I can get some of this QOS
working, I can do IP trunking to replace our CES configurations, and
make the transition smoother and faster.)

The rest of the ATM sites did not use LANE, specifically because of
traffic management, and because there is only a DS3 of bandwidth to join
the two big metro areas on the network. Really I am not worried about
the LANE portion. 

For my ATM sites that terminate their soft PVCs at a 3725 router, I have
been advised to either kick up the ATM service class for that PVC (so
its service-policy actually matters downstream) or to move to LANE
terminated at a 6500 so I can mark the voice traffic and classify it as
UBR+ for some bump in service level. 

I would much prefer to be able to use the QOS built into the ATM
Switches. I can do a SHOW QOS SWITCHING, its enabled. I Can do a SHOW
QOS MAPPING and it gives a map of Precedence to WRR weight and you can
adjust the queues, but noone seems to be able to tell me how to actually
configure this to be honored by the ATM switch? Is there any way to mark
traffic upstream and get the 8510MSR to recognize that marking and apply
ANY kind of QOS functionality when it comes to congestion? 

Thanks in advance for the input everyone!

Gus

-----Original Message-----
From: Dan Martin [mailto:dmartin at micromuse.com] 
Sent: Monday, October 03, 2005 4:23 PM
To: Nassess, George (Contractor); cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] ATM QOS

Fix things that are broken, figure out what utilization is like on the
WAN and if its tending up.  look into the composition of that traffic as
well, what percentage are broadcasts?  Is voice getting starved?  If you
get a baseline now, you'll know if what you do next has made any
difference.  

You should also get a trend over some time and try not to leave out the
busy day of the week, the month or the quarter.

Theoretically, having LANE on a wan violates the route to manage
bandwidth and route to manage broadcasts rules.  Taking LANE off the WAN
could make your utilization less subject to the vagaries of broadcasts
and keep you from having to set up a qos infrastructure.  look into
classical IP as a replacement for LANE, assuming your router can route
as fast as your switch can switch.  if you've got some wheezy old
router, don't bother.  On the other hand, if you've got some wheezy old
lane card, don't worry.

You may also consider, assuming its Ethernet, building a point to point
bridge using rfc1483 for your pbx system.  This depends on where your
pbx is and where your atm handoff is and what is between.

I'm assuming that you explored both those alternatives and that is why
you're asking this question.

You may try a pbx to vlan to SPVC with a CBR / low cdvt contract.

If that won't go, you need to figure out how to distinguish the pbx
traffic from the other traffic and color it.  then you need some policy
based routing, then a classical ip instance with that SPVC contract I
mentioned up above.

Hth.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nassess, George
(Contractor)
Sent: Monday, October 03, 2005 2:54 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ATM QOS

Hello, 

I posted part of this question a while ago but no hits. Since I
understand better and can describe it better, I figured I'd try again. 

I have a large multisite ATM network running across two metropolitan
BLSR Sonet rings connected by a long haul BLSR sonet ring in between to
create one large ATM network. I need to setup end-to-end QOS initially
between two of many sites on the ATM network to support IP Trunking
between PBXs at different sites for failover and overflow of voice
traffic. Eventually QOS will need to be end-to-end for all sites, and
eventually we will probably get rid of ATM alltogether and just use all
switched optical links.  

I have Site A that needs QOS to site C. Sites A,B, and C all connect to
their local ATM switch with an OC3 Interface. Site C and site B have ATM
switches connected by an OC3 link. Site B and Site A have ATM switches
that are only connected by a DS3 link.

So this DS3 is a bottleneck for this traffic. I can create a service
policy to prioritize and police traffic as it is put onto the ATM
network, but I have not been able to determine how (and Cisco TAC has
not been able to advise how) to get the ATM switch network to see some
type of marking and apply some sort of priorty queueing or other QOS
mechanism to avoid congestion for our voice traffic from site A to C
without being impacted by any heavy traffic between site A and B. 

For our offices that run LANE I can place the appropriate traffic into a
UBR+ queue to prioritize, but noone can seem to be able to explain how
to use any similar mechanism for traffic placed onto the ATM network by
a routed interface that will be honored further downstream on the ATM. 

Thanks in advance for any assistance, 

Gus Nasses
Network Analyst

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/