VOIP Ruckus network

[aleksandar_coli]

Can you help me improve VOIP in my network, I have around 20 ruckus switches that are connected to one core switch. Now, users are complaining that they have a problem with the voice quality, but I am not sure if it's the network issue. 

Every phone port has trust dscp configured, can you let me know what else can I do from a network perspective to improve voip? Maybe qos configuration advice? 

[netwizz]

Good Morning:

Running quite a few VoIP sites myself, and trust-dscp is correct.  That said, you will want to ensure the phones are actually setting EF, which in a packet capture may appear as 46.  All this does is mark the actual layer-3 packets, so the telco recognizes them as being real-time traffic.

Now each provider is different, but may expect a layer-2 priority be set as well.  You would need to talk to your provider to check if this is the case.

As for the provider, we generally order the network circuit with the provider taking care of the QoS for inbound traffic; since, you have no control over that.

****

Now for outbound, you probably are going to be quite limited on an ICX what you can do.  I am pretty sure there are other Ruckus switches that have the full QoS capabilities.  This is one of the very few things I still prefer doing on Cisco.  The vast majority of things are more straight-forward on the FastIronOS platforms.


Generally what you will do for QoS is make a class-map that matches the DSCP.  Often I actually match an ACL, and use the ACL to match the DSCP particularly if I want counters.

From there, I make a policy-map, and add that class-map then take an action on outbound traffic.  Generally, the action you want is priority; since, it not only guarantees bandwidth, but it also provides low-latency queuing.  The gist of QoS is that each class in a policy-map matches a class-map, and each class in a policy-map is a queue.

Now, it gets pretty weird because there is also a default-class, and it is fairly common to nest policy-maps.

At any rate, you ultimately add the policy-map as an outbound service-policy on the interface that connects to your WAN/telco.

[vu_pham_ghtztqm]

Hi Aleksandar -  Does it impact both internal and external call or just internal call only? Also, some additional questions below:

1. Is 'trust dscp' configured on all the uplink/downlink between edge and core switches? If not, enable there as well.
2. What is the current DSCP values being tagged on the phone now? Use the 'show lldp neighbors detail' command below to check for DSCP and L2 priority values. If lldp is not enable, please enable it by 'lldp run' globally.
-"show lldp neighbors detail ports ethernet x/y/z", where x/y/z is the phone port
3. Check the current dscp to L2 priority mapping to verify if the default mapping is optimal for your network.
-"show qos-tos", in the output below, I have dscp 40-46 mapped to Q5.
4. Check for any egress drops on phone port and uplink port
-"show interface ethernet x/y/z", check for egress queue drops, especially in the voices queue

Please share the output here if you can. Thanks. Vu


***************************************
Sample outputs are below:

ICX7150-C12-SW2#show lldp neighbors detail ports ethernet 1/1/3
Local port: 1/1/3
  Neighbor: b4b0.178d.f786, TTL 114 seconds
    + Chassis ID (network address): 10.200.5.177
    + Port ID (MAC address): b4b0.178d.f786
    + Time to live: 120 seconds
    + System name         : "AVX8DF786"
.......
    + MED Network Policy
      Application Type  : Voice
      Policy Flags      : Known Policy, Tagged
      VLAN ID           : 4
      L2 Priority       : 5
      DSCP Value        : 46
........

SSH@ICX7150-C12-SW1#show qos-tos
DSCP-->Traffic-Class map: (DSCP = d1d2: 00, 01...63)

     d2|  0   1   2   3   4   5   6   7   8   9
  d1   |
  -----+----------------------------------------
   0   |  0   0   0   0   0   0   0   0   1   1
   1   |  1   1   1   1   1   1   2   2   2   2
   2   |  2   2   2   2   3   3   3   3   3   3
   3   |  3   3   4   4   4   4   4   4   4   4
   4   |  5   5   5   5   5   5   5   5   6   6
   5   |  6   6   6   6   6   6   7   7   7   7
   6   |  7   7   7   7

Traffic-Class-->802.1p-Priority map (use to derive DSCP--802.1p-Priority):

Traffic | 802.1p
Class   | Priority
--------+---------
   0    |    0
   1    |    1
   2    |    2
   3    |    3
   4    |    4
   5    |    5
   6    |    6
   7    |    7
--------+---------

SSH@ICX7150-C12-SW1#show int e 1/1/2
GigabitEthernet1/1/2 is up, line protocol is up
  Port up for 19 day(s) 21 hour(s) 56 minute(s) 45 second(s)
........
 This port is not being monitored for queue drops
Egress queues:
Queue counters    Queued packets        Dropped Packets
         0           115590932                   0
         1            17005567                   0
         2              574059                   0
         3              340182                   0
         4             1719004                   0
         5             1375238                   0
         6               26652                   0
         7              947504                   0

[netwizz]

One thing I should probably mention is that it is fairly common to use lldp-med on the ICX platform.  It is important because it announces the VoIP VLAN and also the priority and DSCP flags.

Basically, phones typically set an 802.1q tag to use the same switching infrastructure as data only their layer-2 frames are separated; hence, the interfaces they connect are usually tagged under a VLAN on an ICX platform.  Data (i.e. computers, printers, servers) typically connects on the same interfaces generally without an 802.1q tag set.  It is said data belongs on the access-vlan (untagged); however, if that interface happens to also have a Trunk (tagged) then the untagged vlan is known as a native-vlan.  On ICX, dual-mode sets your native-vlan on an interface that otherwise allows tags.  Of course recently the keyword dual-mode was depreciated, and you simply tag an interface to as many VLANS as you want and can then untag it to one VLAN; since, any given frame can belong to one VLAN (or the untagged VLAN if no tag).  Basically, a frame can never belong to more than one VLAN, which is why these rules exist (i.e. an interface cannot be untagged to two different VLANS)... and when frames pass through interfaces they get sorted into the proper VLANs, and when transmitted they get sent with the proper tag (or no tag).

What many folks have trouble coming to ICX and Cisco vs non-Cisco is the change of terminology as mentioned above.  Also the configuration methodology in ICX is placing interfaces into VLANS tagged or untagged, instead of configuring the vlans on the interfaces (trunked or access).   Then it gets worse when more terminology is thrown around such as "voice vlan" on the interfaces of another vendor used in conjunction with typically with access ports.  A voice VLAN is no different than a trunk aside from the fact it turns on announcements via lldp-med and cdp, too.

I hope this helps.  On an ICX a common statement to turn on announcements is something like:
lldp med network-policy application voice tagged vlan 2110 priority 5 dscp 46 ports ethernet 1/1/1 to 1/1/48

lldp run by itself merely will help with setting PoE+ and things like that.

That is an actual statement I took from a 48 port ICX on one of our many networks, and it announces vlan 2110 as a voice VLAN to the phones along with the priority and dscp.