[cisco-voip] Centralized Unity QOS

[pwalenta at wi.rr.com]

Oops, thought I tagged it in there.

Here it is:

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_configuration_example09186a0080094af9.shtml

----- Original Message -----
From: "Ortiz, Carlos" <CORTIZ at broward.org>
Date: Monday, January 23, 2006 3:06 pm
Subject: RE: [cisco-voip] Centralized Unity QOS

> Phil,
> 
> Can you send the link that you mention below showing "how to properly
> set all your Frame relay map class settings correctly based on the PVC
> and link size." 
> 
> -----Original Message-----
> From: Philip Walenta [mailto:pwalenta at wi.rr.com] 
> Sent: Thursday, January 12, 2006 9:59 AM
> To: Ortiz, Carlos; cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] Centralized Unity QOS
> 
> OK, the major things here are:
> 
> 1.  You need FRTS for QoS to work.
> 
> 2.  You *must* use Multilink PPP over this link, as Frame Relay and 
> ATMhave
> no inherent method of transmitting frame-relay style messages.
> 
> Here's a link that shows what you need on both sides:
> 
> http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_exampl
> e091
> 86a0080101210.shtml
> 
> You can use the ACL's you've built already in place of the ones in the
> link,
> but the rest you will definitely need.
> 
> Just looking at the output drops listed on the interface is a dead
> giveaway
> that FRTS is needed.
> 
> I'm also including this link which talks about how to properly set all
> your
> Frame relay map class settings correctly based on the PVC and link 
> size.
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ortiz, Carlos
> Sent: Thursday, January 12, 2006 8:26 AM
> To: erickbe at yahoo.com; cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] Centralized Unity QOS
> 
> Most of our IPT network is connected via high speed Metro Ethernet.
> Only have 2 IPT sites across WAN links so any pointers would be
> appreciated.
> (frame at remotes to ATM at HQ)
> 
> I moved this to the top as I noticed some physical errors on the 
> remoteT1.(That's an obvious problem).
> 
> Serial0/0/0 is up, line protocol is up
>  Hardware is GT96K with integrated T1 CSU/DSU
>  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, 
>     reliability 255/255, txload 8/255, rxload 35/255
>  Encapsulation FRAME-RELAY IETF, loopback not set
>  Keepalive set (10 sec)
>  LMI enq sent  611473, LMI stat recvd 611468, LMI upd recvd 0, DTE 
> LMIup
>  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
>  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE
>  FR SVC disabled, LAPF state down
>  Broadcast queue 1/64, broadcasts sent/dropped 1505335/0, interface
> broadcasts 1403643
>  Last input 00:00:00, output 00:00:00, output hang never
>  Last clearing of "show interface" counters 10w0d
>  Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops:
> 11188
>  Queueing strategy: Class-based queueing
>  Output queue: 1/1000/64/11188 (size/max total/threshold/drops) 
>     Conversations  1/26/256 (active/max active/max total)
>     Reserved Conversations 1/1 (allocated/max allocated)
>     Available Bandwidth 310 kilobits/sec
>  5 minute input rate 213000 bits/sec, 35 packets/sec
>  5 minute output rate 50000 bits/sec, 37 packets/sec
>     187878726 packets input, 997404112 bytes, 0 no buffer
>     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>     12264 input errors, 12263 CRC, 416 frame, 65 overrun, 0 ignored,
> 364 abort
>     248917925 packets output, 2303451383 bytes, 0 underruns
>     0 output errors, 0 collisions, 2 interface resets
>     0 output buffer failures, 0 output buffers swapped out
>     0 carrier transitions
>     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
>