[cisco-voip] Remote office phone connectivity
Wes Sisk
wsisk at cisco.com
Thu Jan 6 11:10:33 EST 2005
Hi Vandy,
maybe time for a TAC case for QOS assistance as mine is a bit rusty.
I have a concern in this scenario - usually the service policy is
applied at the output interface which means these packets are already
taking up router memory and CPU (in trasnit from the input interface).
You may need to look at rate limiting on the input interface.
I checked with a colleague who frequents QOS configs and recommended:
Do 600 kbps + 50% of interface BW equal a value less than or
equal to 75% of interface BW? If so, theoretically you should
be OK even with lots of traffic in the default queue. Make
sure the interface has the appropriate bandwidth command set.
If the value of 600kbps + 50% of interface BW is a value
greaters than 75% of interface BW, you should change the
value of max-reserved-bandwidth appropriately under the
interface, or adjust the values in the service-policy to
add up to 75% of interface BW.
/Wes
Vandy Hamidi wrote:
>Good call Wes. In the confusion of getting everything back up, I didn't
>bother to look.
>
>CPU on my HUB 3745 did spike, but it spiked what appears to be after the
>issue which was about 6.25 hours ago. It definitely did spike shortly
>after the problem starting.
>
>So it looks like QOS is fine, but the router just couldn't handle the
>processing requirements for some reason.
>
>I wish I ran a sh proc cpu during the spike.
>
>What could cause that? It's just going simple routing with simple BGP
>(20 routes), QOS and relatively showt ACLs (maybe 50 lines over 10
>acls).
>
>Looks like I might need to run a WSTTCP at each remote office and pump
>9MB of traffic across to try to duplicate the situation.
>
>
> 191092112111111111111111 11131121111111111111211111112111111
>111111111
>
>6920297609886788895788839358773088433034444431661124097222318101011010
>100 * *
>
> 90 * **
>
> 80 * **
>
> 70 * **
>
> 60 * **
>
> 50 * **
>
> 40 * ** *
>
> 30 * *** * *
>
> 20 ** ******************** **** *** *** **
>
> 10
>****##******************************************************************
>
>0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
> 0 5 0 5 0 5 0 5 0 5 0 5
>0
> CPU% per hour (last 72 hours)
> * = maximum CPU% # = average CPU%
>
>-----Original Message-----
>From: Wes Sisk [mailto:wsisk at cisco.com]
>Sent: Wednesday, January 05, 2005 5:55 PM
>To: Vandy Hamidi
>Cc: Voll, Scott; cisco-voip at puck.nether.net
>Subject: Re: [cisco-voip] Remote office phone connectivity
>
>How's the router CPU during this time?
>sh proc cpu
>sh proc cpu hist (for a nice graph)
>/Wes
>
>Vandy Hamidi wrote:
>
>
>
>>Thanks for the info Wes,
>>WSTTCP is exactly what I used to test the connection and my QOS Config.
>>I pumped enough traffic through the link to consume 99.99% of the T1
>>
>>
>(or
>
>
>>2xT1) and then placed a call with no problem. It's a great tool for
>>easy traffic generation.
>>
>>I also put an access list checking for the DSCP/TOS bits to make sure
>>the SMTP that was clogging the pipes were set for DSCP Code=0 (routine)
>>and the voice is 5. They were all set right.
>>
>>It's very odd how the QOS is set right, the traffic going through is
>>
>>
>set
>
>
>>right and the voice is prioritized as it should be.
>>
>>One thing to add is that the calls are using a Sprint MPLS network, but
>>I've worked with them and tested (with WSTTCP) to make sure the QOS is
>>set correctly on their side too.
>>
>> -=Vandy=-
>>
>>-----Original Message-----
>>From: Wes Sisk [mailto:wsisk at cisco.com]
>>Sent: Wednesday, January 05, 2005 4:33 PM
>>To: Vandy Hamidi
>>Cc: Voll, Scott; cisco-voip at puck.nether.net
>>Subject: Re: [cisco-voip] Remote office phone connectivity
>>
>>Hi Vandy,
>>
>>Use a tool such as ttcp or wsttcp to setup streams between the sites.
>>Then examine your service policies on your router interfaces to
>>determine what is/is not working properly. Perhaps your SMTP traffic
>>
>>
>is
>
>
>>getting DSCP or TOS modified so it is classified as voice control
>>traffic?
>>
>>Clarify the src/dest, TOS, and DSCP of traffic leaving you Exg server,
>>then check your service policies on your routers to see how that
>>
>>
>traffic
>
>
>>should be governed and check for matches. Use the tool to re-simulate
>>the storm and isolate the condition.
>>
>>/Wes
>>
>>Vandy Hamidi wrote:
>>
>>
>>
>>
>>
>>>Just checked it. All coming in routine:
>>>
>>>
>>>
>>>Extended IP access list DISCOVER
>>>
>>> 1 permit tcp any any eq smtp precedence routine (21 matches)
>>>
>>> 2 permit tcp any any eq smtp precedence priority
>>>
>>> 3 permit tcp any any eq smtp precedence immediate
>>>
>>> 4 permit tcp any any eq smtp precedence flash
>>>
>>> 5 permit tcp any any eq smtp precedence flash-override
>>>
>>> 6 permit tcp any any eq smtp precedence critical
>>>
>>> 7 permit tcp any any eq smtp precedence internet
>>>
>>> 8 permit tcp any any eq smtp precedence network
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>-----------------------------------------------------------------------
>>
>>
>-
>
>
>>
>>
>>
>>
>>>*From:* Voll, Scott [mailto:Scott.Voll at wesd.org]
>>>*Sent:* Wednesday, January 05, 2005 3:00 PM
>>>*To:* Vandy Hamidi
>>>*Cc:* cisco-voip at puck.nether.net
>>>*Subject:* RE: [cisco-voip] Remote office phone connectivity
>>>
>>>
>>>
>>>Could the mail server be marking your smtp traffic?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>-----------------------------------------------------------------------
>>
>>
>-
>
>
>>
>>
>>
>>
>>>*From:* cisco-voip-bounces at puck.nether.net
>>>[mailto:cisco-voip-bounces at puck.nether.net] *On Behalf Of *Vandy
>>>
>>>
>>>
>>>
>>Hamidi
>>
>>
>>
>>
>>>*Sent:* Wednesday, January 05, 2005 2:54 PM
>>>*To:* cisco-voip at puck.nether.net
>>>*Subject:* [cisco-voip] Remote office phone connectivity
>>>*Importance:* High
>>>
>>>
>>>
>>>HELP!
>>>
>>>I need some QOS and VOICE experts here.
>>>
>>>I just got done putting out a major fire.
>>>
>>>Our mail server in our Hub office (CALLMANAGER LOCATION) started
>>>sending out MASSIVE amounts of email to our remote offices. Bandwidth
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>consumption on the WAN links between the HUB and remote offices shot
>>>up to 99.9%/7%.
>>>
>>>Our remote users had complaints of phones rebooting, calls not going
>>>through or being dropped, not being able to make outbound calls
>>>(through their local PRI), but I could call them and talk w/o any
>>>
>>>
>>>
>>>
>>problem.
>>
>>
>>
>>
>>>I don't understand. I do have QOS setup Prioritizing VOICE and VOICE
>>>Control packets and I'm sure it's right (see QOS config below)
>>>
>>>I throttled SMTP at my hub router and all the phones started working
>>>
>>>
>>>
>>>
>>fine.
>>
>>
>>
>>
>>>I've maxed out the interface in the past and tested the phone w/o any
>>>problem.
>>>
>>>All ideas and suggestions are welcome. Thanks!
>>>
>>> -=Vandy=-
>>>
>>>
>>>
>>>class-map match-all VOICE_CONTROL
>>>
>>> match access-group name VOICE_CONTROL
>>>
>>>class-map match-all VOICE
>>>
>>> match access-group name VOICE
>>>
>>>policy-map QOS-POLICY-T3-01
>>>
>>> class VOICE
>>>
>>> priority 600
>>>
>>> class VOICE_CONTROL
>>>
>>> bandwidth 50
>>>
>>> class class-default
>>>
>>> fair-queue
>>>
>>> set precedence 0
>>>
>>>ip access-list extended VOICE
>>>
>>>permit ip any any precedence critical
>>>
>>>permit ip any any dscp ef
>>>
>>>ip access-list extended VOICE_CONTROL
>>>
>>>permit ip any any precedence flash
>>>
>>>permit ip any any dscp af31
>>>
>>>----------------------------------------------------------------------
>>>
>>>
>-
>
>
>>>
>>>
>>>
>>>
>>-
>>
>>
>>
>>
>>>_______________________________________________
>>>cisco-voip mailing list
>>>cisco-voip at puck.nether.net
>>>https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>>
>>>
>>>
>>>
More information about the cisco-voip
mailing list