[c-nsp] QoS on dual T1s ok?

[Voll, Scott]

MLPPP could be an option but remember with the 2 T1's your going to
loose to bandwidth due to overhead.  

Better Option might be to route all Video over a single T1.

We policy route all Voice / Video over a single T1.  Then I don't have
to worry about these issues.

Scott

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bob Fronk
Sent: Tuesday, February 14, 2006 12:56 PM
To: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] QoS on dual T1s ok?


Sorry to hi-jack this thread but I have a related question.

I just added a second T1 and am using ip cef and load sharing per-packet
to bond the two T1s for 3MB.

Yesterday there was a video conference (Polycom equipment) with two
external sites.  There was a considerable degradation of the video than
what we usually encounter, but initially I attributed it to the external
sites having a lower bandwidth. 

Could this have been a product of the load sharing per-packet?

Would changing to MLPPP make a difference?  (I would have to get Sprint
to change their end, but that is no big deal)

Any other suggestions?  (I have a 2600 Edge router with two T1 WICS that
is basically a converter to Ethernet, then a PIX 515 behind that.  I
don't have any QOS in either, but have never had issues until now.)  I
did check bandwidth utilization and with the confences we were barely
over 512K, so it wasn't saturated.)


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Jose
> Sent: Tuesday, February 14, 2006 3:21 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] QoS on dual T1s ok?
> 
> The customer hasn't specifically mentioned that this will be for Voice
> traffic but more to give priority to certain machines over others no
> matter what kind of traffic is going through.
> 
> Jose
> 
> Jessup, Toby wrote:
> > Per-flow forwarding is better for VoIP/video (less jitter). However,
if
> > you do per-flow be aware that some VoIP products (not Cisco)
transmit
> > all active calls within a single flow (IP address/port pair) between
> > locations -- an "IP trunk"). This single large flow is then crammed
> > through the 768k priority queue of only one T1.
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Voll, Scott
> > Sent: Tuesday, February 14, 2006 11:45 AM
> > To: Jose; cisco-nsp at puck.nether.net
> > Subject: RE: [c-nsp] QoS on dual T1s ok?
> >
> >
> > Depends on the traffic.  Voice and Video don't do real well with per
> > packet load balancing.  Other traffic shouldn't be bad.
> >
> > scott
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jose
> > Sent: Tuesday, February 14, 2006 11:19 AM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] QoS on dual T1s ok?
> >
> > Just wanted to get some added reassurance from you guys since I
think
> > this will work but just wanted to make sure.
> >
> > Customer wants us to prioritize a specific /28 from his assigned
blocks
> > across the two T1s he has from us.  He would like this block to be
able
> > to use up to half of his bandwidth if needed and when the /28 is not
> > using any bandwidth, the other blocks on his network should have the
> > ability to use up to the full two T1s worth of bandwidth.
> >
> > Based on this request I created a policy map based on an access-list
to
> > match any traffic on that specific block like this:
> >
> > access-list 120 permit ip any 10.0.0.16 0.0.0.15
> > access-list 120 deny   ip any any
> > !
> > class-map match-any customer
> >   match access-group 120
> > !
> > policy-map customer
> >   class customer
> >     priority 768
> >   class class-default
> >     fair-queue
> >
> > I then apply this policy map to each serial interface:
> >
> > interface Serial1/1/0:1
> >  no ip directed-broadcast
> >  ip load-sharing per-packet
> >  no fair-queue
> >  service-policy output customer
> > !
> > interface Serial1/1/1:1
> >  no ip address
> >  no ip directed-broadcast
> >  ip load-sharing per-packet
> >  no fair-queue
> >  service-policy output customer
> > !
> >
> > Does anyone see anything wrong with the way I set this up?  I assume
> > that per-packet load balancing won't throw anything off?
> >
> > Thanks for any feedback.
> >
> > Jose
> > _______________________________________________
> > 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/
> >
> > _______________________________________________
> > 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/
> >
> >
> >
> _______________________________________________
> 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/

_______________________________________________
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/