Saturday, May 30, 2009

Vonage Voice-Bearer and Call Signaling Traffic QoS (Part 1 of 3)

This is the first of 3 posts I am making regarding my experience with Vonage on my Cisco network. Last week, I got a call from my small cable provider (Stowe Cable/Stowe VoIP) which, by the way are awesome and always provide superior customer service. Anyway, the lady called to let me know their VoIP division was bought by Momentum and that they would not be able to carry my home phone number anymore. Because it would be an inconvenience to have to update everyone with a new phone number, I decided to see if there were any other companies that offer VoIP and would be able to carry the number. I searched with Google and found several companies, some of which had already gone out of business, and some major well-known ones. Most provided the ability for me to enter my phone number on their website to see if my number could be transferred to them. I tried with voip.com, 8x8.com, a few others and Vonage.com. Of those, only Vonage could carry my number. So, I signed up, and started the process. All the while, I set to try to understand how this would work. With Stowe VoIP, an EMTA device was placed directly on the coax entering the house from outside, and the phone was connected to it via a regular RJ-11 cable. In contrast, with Vonage, I learned that they would ship me a VDV21-VD which is basically an analog telephone adapter (ATA)-router combo with ethernet ports instead of coax. Now, because I already have two Cisco routers and a Cisco multilayer switch, I wasn't sure how this would connect. Realizing that my setup is not really 'mainstream', I wanted to know how the VDV21 worked and how I could best integrate it. A few days later, I received the device and promptly connected the WAN/Internet port to my internal switch. This was my preference because if I could get this to work, it would mean the VoIP system could take advantage of my dual-ISP redundancy. As expected, the adapter obtained an IP address from my DHCP server. I left the LAN port unused because I believe, in my scenario, it would not be needed since I am not using the "router" functionality of the VDV21, and simply using it as an ATA. I then connected an analog phone to the RJ-11 jack on the VDV21, and was able to immediately make an outbound call. Note- no inbound call is possible yet because my number transfer has not completed. Next order of business was to see if I could also plug the VDV21's LAN port into my network so I could manage the device via its embedded web server. Realizing it would not make sense to connect it into the same subnet, and fearing that the VDV21 was pre-configured as a DHCP server, which would potentially cause havoc by assigning IP addresses in an unwanted range to my internal hosts, I simply connected the LAN port to my laptop port. The laptop obtained 192.168.15.2/24 and I was able to manage the VDV21 device via HTTP. The above method of management was temporary, so I configured the VDV21 to allow remote management (meaning HTTP access from the outside to the WAN/Internet port) by checking the box in "Advanced Setup, Network Options, Remote Config Management". I was then able to assign a static IP address, add the VDV21 device (I made up a hostname) to my internal DNS server, and then administer by name. Now, before discussing QoS next, one observation that impressed me about Vonage is they support many different ATA models of different brands, and allow high flexibility with different options. For example, if the default 90Kbps call (which I found means the G.711u codec) eats up too much bandwidth, they allow the user to lower this to 50Kbps or 30Kbps via their web-based dashboard, among many other features. This not only makes their service more appealing to geeks like me, but provides for potential extra sales to small businesses that may have similar networks, even if customer tech support might be a bit more complicated for them. I applaud this strategy. Finally, being somewhat familiar with the requirement for QoS in converged networks, I set to determine how exactly to configure my switches and routers for voice and call signaling. Via Netflow, I saw that the voice-bearer traffic leaving the ATA going to the Internet (Vonage's datacenter in the New York area, as determined by a traceroute), already had a DSCP of EF. However, the return traffic was set to DSCP 0. And, I was unable to determine by just looking at Netflow data, what consisted of call signaling. I therefore used Wireshark on a SPAN port on the Catalyst switch to capture all traffic to/from the ATA and made a call. Here are the results. Some kind of SIP "REGISTER" keepalives every 20 seconds: UDP/SIP source port 1030 destination port 10000 with DSCP 0 The reply: UDP/SIP source port 10000 destination port 1030 with DSCP CS1 (DSCP CS1 in this case, I assume is one of the ISP's in the path, setting this traffic as scavenger, as per the Cisco SRND) The off-hook/on-hook/invite/dial-phone-number packets: UDP/SIP/SDP source port 1030 destination port 10000 with DSCP 0 ...again with DSCP CS1 for the return traffic. During the call, every second, the following occurs: UDP/RTCP source port 10057 destination port 14697 both outbound and return have DSCP 0. I am unsure if the last one (1-second during-call keepalives) would have a dynamic, different port if I made a second call. I'll have to setup another capture later. So, based on this, configuring QoS for Vonage, will mean classifying and marking the call signaling packets both ways (outbound towards the Internet when entering the Catalyst switch, and also when coming back from the Internet, entering the router), as well as the voice-bearer coming back from the Internet, when it enters the router. Then, assign bandwidth, shape, police, etc. by following some of the suggestions in the Cisco QoS SRND document. I'll post those configs after I've figured them out and they've been tested. UPDATE- June 1 2009 A few days after, I made more captures and discovered the REGISTER/INVITE/etc. source port varies, for example, instead of UDP 1030 like the other day, now, the 20 second interval messages, as well as the off-hook messages are sourced from 1048. So, I guess the ACL will have to match the destination port only. Also, the RTCP 1-second keepalive messages do vary as well. However, they are odd numbers, and I assume from reading the Vonage forums the range is from 10000 to 20000 (same as the RTP traffic). So, to recap, the RTP voice bearer traffic is a random port (even numbered) between 10000 and 20000, and the RTCP traffic is a random port (odd numbered, one up from the RTP port).

Tuesday, May 26, 2009

Cisco WAAS over DMVPN

I finally got my WAAS setup to work on my home network (the hub site) which consists of a dual headend (DSL, cable) dual-DMVPN and 3 spokes (the spokes are my other family members homes). In one of the spokes, I installed an edge WAE file engine, and at the hub, a core WAE and a third separate WAE central manager for administration. The motivation behind all this was to learn the technology but also to improve access to the Sharepoint site, other HTTP intranet sites, as well as RDP and SSH to/from that spoke. After installing the recovery CD on all 3 WAE's, for some reason, the the application traffic policy consisted of "N/A" but seemed to contain all the needed applications and settings. So, I didn't think much of it. But over time, savings were zero, and the graphs were not populating with any optimized traffic. I finally figured out to click the "Restore the default application policies" and "Restore the default application policies and classifiers". I now see reduction in web, SSH and WAFS traffic over the tunnel. Note- because each DMVPN subnet is a /25 and contains other non-WAAS sites, I configured a WCCP redirect ACL on the headend routers to ensure only traffic to/from the single spoke WAAS site gets redirected.

Tuesday, May 12, 2009

Cisco IOS Zone-Based Firewall vs CBAC

Having had some experience with PIX firewalls in the past, I was interested when I learned a similar firewall technology appeared in IOS. So, I've started reading about the newer zone-based firewall in IOS, and wanted to 'upgrade' from my well-working CBAC, if not only to simplify DMZ or guest LAN configurations. I found the lack of an equivalent "router-traffic" command to be a major inhibitor, especially because on the routers in question, NTP, Dynamic DNS and GRE/IPSec (DMVPN) are all connections that are initiated by the router, and even with a relaxed or no inbound ACL, this traffic has to be configured (allowed) from the self zone to the Internet. Anyway, by the time I had an almost fully working configuration, it was a lot lengthier than my original CBAC config. I think perhaps, if I had had more than a couple of DMZ's, the ZBF might have been worth it. But for a simple 3-zone [Internet Zone, internal Zone, and Guest Zone] setup on a small 800 series router, CBAC is still the way to go! If anyone knows when Cisco will improve/shorten the ZBF configs for such router-initiated traffic as above, I'd be anxious to find out!