Cisco IOS Configs for QoS Classification and Marking of Vonage Traffic (Part 2 of 3)

This is the second post of 3 about my experience with Vonage QoS on my Cisco network.

As mentioned earlier, here are the configs I came up with.  But before, the layout of the network:

    Vonage Datacenter
           |
           |
        Internet 
        /       \  
       /         \
Cable modem     ADSL modem
      |            \
Fa0/1 |             \ Fa0/1
Cisco router-----Cisco router
Fa0/0 |              | Fa0/0
      |              |
Fa0/1 |              | Fa0/2 
Cisco Catalyst 3550 switch
Fa0/23    |
          |
  VDV21 ATA (192.168.8.96)

Note- I use the cable ISP as my primary ISP as they give me 512 Kbps of uploads vs 384 Kbps for the DSL telco.  However, the QoS configs are applied to both routers in case of failover. 

So, the first step was to ensure the DSCP for every voice bearer and call signaling packet leaving the 3550 was correct. Because the voice bearer RTP traffic leaving the VDV21 to the Internet was already marked as DSCP EF, I didn't change anything. For the call signaling traffic leaving the VDV21, I classified and marked it on the input interface of the 3550 as follows.

mls qos
ip access-list extended ACL_CALL_SIGNALING
 deny udp host 192.168.8.96 any dscp ef
 permit udp host 192.168.8.96 any range 10000 20000

class-map match-any CM_CALL_SIGNALING
  match access-group name ACL_CALL_SIGNALING

policy-map PM_CLASSIFY_AND_MARK
  class CM_CALL_SIGNALING
   set dscp cs3

int fa0/23
 desc VDV21 - VONAGE ATA
 service-policy input PM_CLASSIFY_AND_MARK

int range fa0/1 - 2
 mls qos trust dscp

The first ACE will prevent the voice bearer originated by the ATA from being re-marked. The second will allow any packet with a source of the ATA, and a destination anywhere with a UDP port >= 10000 and <= 20000 to be marked.

The class-map is created to classify the call signaling based on the ACL. Then, a policy-map is created to mark the traffic identified by the class map to DSCP CS3. I chose CS3 for call signaling based on the Cisco QoS SRND document. This way, if future needs warrant adding more classes such as a mission-critical class, AF31 will be available for this. Note- the CS3 is also chosen over AF31 because WRED will work better with Assured Forwarding 1,2 and 3 for different levels of drop probabilities.

Note that the 3550 does not support NBAR, which might have worked to classify the RTCP traffic. Instead, we are restricted to using ACLs.

Once the policy-map is created, it is applied to the input interface where the ATA is connected. And, the interfaces to the routers are configured as trusted, meaning, any packet received with specific DSCP values will not be re-marked or reset to default. We do this for the return traffic.

This takes care of our 2 outbound traffic classes. Practically, for the other direction, there is no need to mark and classify this traffic as it enters the routers from the Internet because we are dealing with high-speed FastEthernet interfaces toward the LAN, which will most likely not get congested. However, for the purpose of the exercise, we will classify and mark this traffic so we can action it in the future on the internal LAN if we need to, as well as for reporting purposes (i.e. to be able to generate NetFlow reports based on DSCP).

On the Cisco routers, we will classify and mark the voice and call signaling traffic when it enters from the Internet:

object-group network OBJ_VONAGE_ATA_HOSTS
 description VONAGE ANALOG TELEPHONE ADAPTERS
 host 192.168.8.96

ip access-list extended ACL_VONAGE_ATA_HOSTS
 permit ip any object-group OBJ_VONAGE_ATA_HOSTS
ip access-list extended ACL_VONAGE_SIP
 permit udp any eq 10000 object-group OBJ_VONAGE_ATA_HOSTS

class-map match-all CM_VONAGE_SIP
  match access-group name ACL_VONAGE_SIP
class-map match-all CM_VONAGE_RTCP
  match protocol rtcp
  match access-group name ACL_VONAGE_ATA_HOSTS

class-map match-all CM_VONAGE_VOICE_BEARER
  match protocol rtp
  match access-group name ACL_VONAGE_ATA_HOSTS

class-map match-any CM_VONAGE_CALL_SIGNALING
  match class-map CM_VONAGE_SIP
  match class-map CM_VONAGE_RTCP

policy-map PM_CLASSIFY_AND_MARK
  class CM_VONAGE_VOICE_BEARER
   set dscp ef
class CM_VONAGE_CALL_SIGNALING
   set dscp cs3

int fa0/1
 desc OUTSIDE - ISP
 ip nbar protocol-discovery
 service-policy input PM_CLASSIFY_AND_MARK

Note that I use an object group since this router runs 12.4(22)T1 and I wanted to test this new functionality which I assume Cisco carried over from the PIX OS. Better late than never!

So, the first ACL permits any traffic with a destination of my ATA. The second one permits traffic with a source of UDP 10000 and a destination of my ATA. This is for the UDP/SIP 20-second interval REGISTER "keepalives" as well as INVITE/On-hook/Off-hook messages.

The CM_VONAGE_SIP class-map matches this ACL. However, call signaling consists not only of SIP, but also of RTCP as stated earlier. So, we also need the CM_VONAGE_RTCP class-map. Thankfully, we can use NBAR for this one. This is why we also have "ip nbar protocol-discovery" applied to the outside interface.

Once the SIP and RTCP class maps are defined, we put them together in a class-map called "CM_VONAGE_CALL_SIGNALING". This class-map matches either one ("OR" boolean).

Then, we classify the voice bearer traffic using a similar method. This time, we tell the router, if your NBAR process receives RTP packets (voice packets) with a destination of the ATA, classify those.

We then create the policy-map, and mark the voice packets with DSCP EF, and the call signaling (RTCP & SIP) with DSCP CS3. We do this by applying the policy-map to the outside interface, inbound.

Note- The routers in question run NAT and CBAC so I wasn't sure if the classification would work as it calls the ACL which contain the private IP address of the ATA. And, as far as I can tell, documentation on this is non-existent. But a packet capture reveals the NAT de-translation processing occurs before the QoS classification, hence we are good to go!

Now that we have our voice and call signaling marked in both direction, the last step is to take action on it. Meaning, configure queueing and shaping to prioritize this traffic over the web browsing, email and other less time-sensitive traffic. I will post those configs in the near future.