Polycom V500 over WAN and QoS

Question

we are trying to run two polycoms over WAN. One side is able to see the other while the other side cannot. The side that is unable to see the other has the following QoS setup on the WAN interface:
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
queue-set 2
msl qos trust dscp
auto qos voip trust

Answer 1

Your configuration is not from a WAN port but from a LAN port. Please note that just because the service provider hands you an Ethernet port, that does not mean you can use any old LAN switch to connect to it. The service provider is using Ethernet to keep their costs down but it is still a WAN port and requires a WAN interface on your terminating equipment to properly schedule and queue the traffic.
Examples of a WAN Ethernet (FastEthernet, GigabitEthernet) port are most any ISR router, a Catalyst Metro switch (i.e. 3750-METRO), the WAN blades on a 6500 switch (not LAN blades!), or the Ethernet WAN/Metro SPA adapters for a 6500/7600 SIP module.
Note that a LAN switch assumes high speed interfaces and not much of a speed mismatch between ports. A LAN port connected to a slow WAN will not be able to buffer anywhere close to amount of traffic that comes through the switch to this port and will cause a HOL (head of line) blocking scenario; and this assumes you setup the port speed and shaping/sharing parameters correctly.
A LAN switch port output buffers are measured in K and will handle 4 to 10 packets of bursting; on the other hand, a WAN port's output buffers are measured in M and will handle thousands of packets of burst.
The effects can be staggering. It is not uncommon for a service provider WAN/MAN to be terminated with a bunch of cheap LAN switches that drop upwards of 90% of the traffic destined for the WAN! Just because of lack of buffers on the output queue side and massive oversubscription between the LAN side and the WAN side, using a LAN port.
And we haven't even started talking about traffic shaping yet to match the speed of transmission from a WAN port to that of the contracted rate such that it doesn't exceed the speed on the receiving side.
Remember, regardless of the size of the WAN port (T1, E1, DS-3, OC-3, 10Mb, 100Mb, 1000Mb), the 'width' of the connection is serial and still only 1 bit wide. Just the rate of bits being sent per second is different.
The key concept that often gets lost is if you have a GigabitEthernet port on a LAN switch connected to a WAN or MAN in which you are purchasing 200Mb of service, you are, by definition, dropping 80% of the traffic in the service provider network (or at the ingress port to the service provider!). This is regardless of how 'busy' or utilized the GigabitEthernet link is. A single packet of data, say 500 bytes, will be sent out the GigabitEthernet port at 1 *billion* bits per second. Unfortunately, you may only have paid for 200 *million* bits per second as your contracted access to the service provider's network. Trust me, the service provider will deal with this discrepancy by policing 80% of your data to the bit bucket and they don't care what type of data it is.
So it doesn't matter how much data you are sending, a 1% utilized WAN connection using a LAN switch in this way could still be dropping 80% (or more) of the traffic!
A final note: Please don't be confused by most switch vendor's terminology regarding shaping or sharing of multiple limited output queue resources on their LAN switches, this is *NOT* the same thing as traffic shaping or long queues on a WAN router port or WAN/METRO switch port. This includes Cisco. This is why Cisco (and Juniper and Foundry, etc.) sell switches with METRO or WAN interfaces on them and why they are more expensive than LAN only switches.