[c-nsp] ATM QOS

Nassess, George (Contractor) George.Nassess at gmacrfc.com
Wed Oct 5 10:07:46 EDT 2005


Dan, you are correct. LANE connections do not use a spvc. But, we only
have 3 sites that run LANE, those with an OC12 connection. The LANE
sites have enough bandwidth, and I can mark traffic and make it UBR+ and
I think things will work fine there. Unfortunately, there is not much
traffic between the LANE sites that will need QOS.
 
Our other sites which are DS3 connected are routed currently, with
spvcs. You'll have to excuse my ignorance of exactly how soft PVCs work,
or rather how to drill down to configure specifics, other than "it just
works". We have a total of 14 sites or so that connect via ATM, but most
of those do not pass an voice traffic I need to be concerned with, I
have a total of 4 sites that will eventually need to prioritize voice
traffic for so that we can replace CES tie lines with IP trunking as the
first step to move off of ATM to a pure optical layer3 switched core and
backbone. Then I can just do standard QOS based on COS or DSCP on 6500
switches and life will be good. 
 
Until then....what Dan suggests seems like a sensible plan. What I do
not understand is how to configure parameters for just ONE of my soft
PVCs to make it  rt-VBR and set the scr, pcr, and burst size. 
 
 
 
One more thing I though I would see if anyone knew anything about. After
cisco told me I cannot do any QOS any way on ATM by marking traffic and
then applying any rules of priority. When I asked why there was a QOS
commend and a map of precedence to WRR queues, they told me if there was
an ARM (atm router module) in my 8510MSRs or if they were really 8510CSR
then I could do QOS based on precedence and wrr queues. Has anyone done
this? 
 
How do I tell if I have an ARM installed in my remote ATM switches? Show
ver doesn't seem to say. I know I have the command options to set qos
switching (it says it is enabled) and to adjust the wrr queues, does
that mean I have the ARM?
 
Bah! now TAC has me confused, as usual. 
 
Gus
 
 
 



________________________________

	From: Dan Martin [mailto:dmartin at micromuse.com] 
	Sent: Tuesday, October 04, 2005 3:41 PM
	To: Nassess, George (Contractor)
	Subject: RE: [c-nsp] ATM QOS
	
	
	first, 
	
	i doubt very much if the lane stuff is using spvcs.  it uses ubr
svcs, unless you guys are vp tunneling?
	 
	and with only a few sites you should get off the lane nod all
together and route.  if you route you will have a network that works
with two fewer pieces, les and bus.
	 
	second, if you don't want to dedicate 20 t1s you can set up a rt
vbr with a low scr, a high pcr and a large burst size for the traffic.
if you're worried about stranding bandwidth you can always set your vbr
overbook factor to times 2 or something.
	 
	this way your ubr traffic will take up all the unoccupied
bandwidth, your rt - vbr circuit will take up very little, and when you
switch over, vbr takes priority over ubr, so it just might work.
	 
	 

________________________________

	From: Nassess, George (Contractor)
[mailto:George.Nassess at gmacrfc.com]
	Sent: Tue 10/4/2005 2:45 PM
	To: Dan Martin
	Cc: cisco-nsp at puck.nether.net
	Subject: RE: [c-nsp] ATM QOS
	
	

	 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/
	



More information about the cisco-nsp mailing list