HartBrothersHome Asia New Zealand NEVOSH Art PapaFlew LeeHart.com BradyHart.com Who?
Originally written by Dave Hart on 11 August 2004. Updated to reflect new firmware's changes to management interface 10 September 2004. Updated after another minor firmware upgrade once again interrupted internet service to everything but the phone on 26 October 2004. Updated 11 November 2004 to emphasize that this page is not about NAT and that I am not the one to ask if you're using NAT. Updated 13 November 2004 after another firmware upgrade and brief outage.
This page is a result of considerable experimentation and frustration encountered by Dave Hart attempting a relatively unusual configuration of AT&T CallVantage (alternate link) DVG-1120M VoIP customer premises equipment (referred to by AT&T as a telephone adapter and also commonly referred to as a VoIP adapter) which preserves VoIP traffic-shaping functionality (or QoS) without requiring the use of the VoIP equipment's NAT functionality. If you're asking, "Does what to whom?" then this page probably isn't for you. It's obscure, and I'm only publishing it to help poor souls in similar circumstances as mine achieve better VoIP service easily.
My target audience uses a small internet connection to provision AT&T CallVantage or another VoIP service provider's offering using D-Link DVG-1120M (sales info page, support page) hardware and have a static block of internet addresses provided by a WAN router connected via ethernet. Note that this page is not relevant to the vast majority of AT&T CallVantage users, using consumer mass-market broadband connections such as basic cable modem and DSL. If you have a single public IP address with your internet connection, the instructions on this page for using DVG-1120M bridging are not for you, as it would consume the single public IP address leaving nothing for your home router and/or computers to use. There is no sharing of the DVG-1120M's WAN IP address when a bridged configuration is used.
I have received emails from a number of people trying to work out problems fundamentally caused by being restricted to one public IP address on their internet connection. For example, one asked about connecting multiple PCs and hosting a webserver while using CallVantage with its traffic shaping capability working on the single IP address from their cable modem. While I sympathize, keep in mind I pay for a premium ("business-class") internet connection both because of better reliability and performance and because I use multiple public IP addresses and do not want to depend on the broken-by-design misfortune of technology known as NAT, for Network Address Translation. Please do not be surprised if I do not respond to emails involving NAT, I will not become AT&T CallVantage's backup customer support for troubleshooting NAT issues, particularly because I loathe NAT and all the other compromises that come with mass-market broadband. NAT breaks things. Everyone who really understands application protocols built on IPv4 knows this. If you don't want to break things, don't use NAT. If you want to put more than one computer on the internet, you can either live with the brokenness (or work around it) or you can move to an internet connection option with enough IP addresses to satisfy your needs. If you do opt for NAT, consider using a NAT router that supports UPnP, as it adds even more technology to work around the designed-in brokenness for applications which are adapted to use it. For example, MSN Messenger audio and webcam chats and file transfers are much more likely to work with one or both ends behind NAT if those NAT devices support UPnP. As an aside, IP addresses are practically cost-free for large providers like Verizon and Comcast. The reason their cheapest offerings limit you to one is because the abomination known as NAT became popular in the dialup era and made it feasible for the providers to limit you to one IP address as a means of differentiating their cheapest mass-market offerings from more profitable alternatives sold to more discerning or businesslike clients. That is, they know that NAT breaks things and that eventually the pain of NAT will push some customers to multiple IP address products. The rest can eat cake.
With my multiple IP address configuration, AT&T CallVantage installation instructions would put all computers behind one public static IP address, shared by the VoIP box with other devices via NAT. The recommended configuration has the advantage that the VoIP box can shape the traffic between WAN and LAN to prioritize voice over other uses. This prioritization is often referred to as quality of service, or QoS. In my experience the DVG-1120M prioritization works surprisingly well considering the VoIP box has only indirect control over the queuing of traffic at the remote side of the bottleneck DSL link.
In my case the recommended configuration was not acceptable, due to the required renumbering and consolidation of many public IP addresses to one. Fortunately, the D-Link hardware does have a bridge function available that would appear to be just what I need. In the end it is, but it took me some time and help from others to get it working.
Short version: the bridging implementation is incomplete compared to other bridging (switching) network gear, so that some things must be present on the WAN port that might otherwise be found on the LAN port in a straightforward installation. Specifically, DHCP and DNS servers the VoIP box will use must be reachable through the WAN port even if the device is configured to bridge the two ports together (with VoIP QoS functionality in the bridge).
In my case, that meant I could not leave the VoIP box configured to use DHCP to get IP and DNS configuration, because my DHCP server is connected via its LAN port (labeled "ethernet"). This also meant as I was configuring DNS servers to use in the VoIP box, I found I must use recursive DNS servers located outside my LAN. With those last changes thanks to the IRC advice of a friend, I finally put my entire static address block transparently behind the VoIP QoS shaping and have dramatically clearer VoIP calls.
Update: At 15:03 UTC on 10 September 2004 (8:03am US Pacific time) AT&T apparently upgraded the firmware in my DVG-1120M, knocking my network offline for 90 minutes until I noticed the outage then connected my LAN directly the the WAN router, thereby bypassing the DVG-1120M single point of failure (SPOF). The voice service worked throughout the outage, small comfort to me. The menu options for configuring LAN and WAN IP as well as NAT, DHCP, and bridging all changed, so later that day this page was updated to reflect the new firmware's management webmin user interface. I failed to note the version number of the initial version, but the updated version on 10 September 2004 is R2.0M17d. The version number is shown on the initial management webmin page that you reach by clicking the button labeled "Login to the web-based management module". With this version it is on the 4th line, to the right of "Firmware Version". After updating these instructions to match the new firmware, and applying the described DHCP, NAT, and bridging changes, I was able to once again put my LAN behind the DVG-1120M traffic shaping.
Update 2: Shortly before 19:00 UTC on 26 October 2004, my DVG-1120M's firmware was once again upgraded by AT&T CallVantage automatically. As with the previous upgrade, this reset the unit to factory defaults with the effect of disconnecting everything but the telephone service from the internet. I wish the first thing I had tried upon noticing the internet outage was bypassing the DVG-1120M connecting the rest of my LAN directly to the WAN router, but in fact I fiddled around testing other things for 20 minutes before realizing (due to the startup chirp after I power cycled it) that the VoIP service was working while the rest of the network here was disconnected from the internet. The previous firmware from 10 September was R2.0M17d, the new version on 26 October is X2.0M17d. Whatever the changes were, I didn't notice them in briefly disabling NAT and DHCP service and enabling bridging. I am less happy this time that the configuration is being reset even when there are no obvious underlying software changes triggering the loss of configuration. If I were more clever I would figure out a way to automate the bypassing of the VoIP box when it interrupts the connection between my LAN devices and WAN router.
Update 3: Apparently triggered by a three-minute-long outage of my DSL circuit, my DVG-1120M firmware was once again upgraded 05:30 UTC on 14 November 2004. I was actively browsing the web and watching streaming video when the serial outages occurred (first the DSL, then after receiving the new firmware, the DVG-1120M was reset to defaults and disconnected the rest of my LAN from the DSL). As a result, I was able to keep the outage to a minimum. The new firmware revision is 2.0M17j1. Once again I wish these minor firmware revisions would not reset NAT, DHCP server, and bridging settings needlessly.
If you want to be absolutely sure you're not going to be running out to a store cursing, have one of the two following collections. Either:
Two crossover cat5 cables and two patch cat5 cables. That is, two that present all wires in the same order on both ends (patch) and two that reverse the connections of each of the two 10/100 ethernet pairs (crossover). Alternatively:
Four cat5 ("category 5") cables of any flavor (patch or crossover) and two "auto-sensing" or "MDI-X" ethernet switches. Practically every switch sold in 2004 is able to crossover each port automatically as needed, but lots of older gear doesn't. If you want to be sure, buy two cheap 5 port switches and look for the absence of any "uplink" port or switch to ensure all ports are MDI-X automatic crossover.
Why all this crossover/patch mess? Good question. The DVG-1120M makes it worse than it needs to be by failing to offer MDI-X at least on its WAN port. It's probably also missing on the LAN port. Two cables of any flavor plus a MDI-X switch in the middle makes a magic "cable" that will plug into any crossover requirement on either side. With a couple of magic cables, or a couple of crossover cables and a couple of patch cables, you should be able to make any required WAN and LAN port connection changes. If you go for two crossover and two patch cat5 cables, try a patch cable and if the link lights don't come on, try a crossover instead.
1. Note that the DVG-1120M comes configured for NAT operation with subnet 192.168.15.0/24 (netmask 255.255.255.0) and with the administration interface available on the LAN ("ethernet") port at http://192.168.15.1/. In order to configure the device both before and after the changes described here, use an additional computer which you can sacrifice for the duration, or an additional physical or virtual interface on an existing computer, to statically configure a PC or secondary interface to an IP address in the upper half of the netblock, say 192.168.15.150, with subnet mask 255.255.255.0 and gateway 192.168.15.1. You can use an existing ethernet interface on your LAN if the primary address is statically configured. If you're using Windows and the primary address on your LAN interface comes from DHCP, you'll need another interface or, alternatively, you can switch the primary address to static configuration and add 192.168.15.150 mask 255.255.255.255 as a secondary address for the interface under the Advanced button on the IP dialog box. Connect this computer or interface to the LAN port labeled "ethernet" on the DVG-1120M. This computer should be the only device other than possibly an auto-crossover switch connected to the LAN port of the DVG-1120M at this step. Connect the WAN port of the DVG-1120M to your existing switch or router if it is not already. This computer should be able to browse the entire web if the VoIP box is already working for voice service. Regardless, it can browse the to the web administration interface of the VoIP box at http://192.168.15.1/ if it is the CallVantage default configuration.
2. Are you planning to use DHCP to configure the DVG-1120M? If not, skip to step 3. If you will use DHCP to configure the VoIP box, ensure the DHCP server and DNS servers it recommends are reachable from the WAN port of the DVG-1120M. If that is not possible, plan to configure a static IP address in the DVG-1120M. Make sure the IP address is available and won't conflict with existing static or DHCP configurations on your network, and select DNS servers reachable via the DVG-1120M WAN port, such as those provided by your ISP. If the VoIP service is currently working and is using DHCP to obtain its IP address and you will need to change it to a static IP address, then browse to http://192.168.15.1/ and click on the "Login to the web-based management module" button. In the folder list on the left side, click on "Configure LAN/WAN Access" and then on "Configure WAN Port". Click on the dropdown to the right of "Get IP From" and select Manual. Fill in "IP Address", "Subnet Mask", "Default Gateway", "DNS1 Server IP", and "DNS2 Server IP" entries using values normal for your network, ensuring the DNS IPs are located beyond the local network (in your ISP's network or the greater internet, but not at your location). Click on the Save button and change the selection to reboot immediately. Make sure VoIP dialtone is working before moving on with non-voice configuration.
3. In this configuration, it is important to disable the DVG-1120M NAT and DHCP functions before attempting to connect the existing LAN through the VoIP box. These functions can be disabled while keeping the LAN IP of 192.168.15.1 for the DVG-1120M and its web management interface. Browse to http://192.168.15.1/ and click on the "Login to the web-based management module" button. In the folder list on the left side, click on click on "Configure LAN/WAN Access", then "Configure LAN Port", then "DHCP Configuration" and finally "Dynamic IP Assignment". On the newly-exposed right panel, the last entry is labeled State. Change the dropdown to the right of State to "disabled" and click on the Save button. Do not accept the offer to reboot, instead choose the option to save and reboot later. Next, in the folder list to the left click on "NAT Configuration" and then under that on the indented, second "NAT Configuration". On the right, change the last entry, NAT Function to disabled then click the Save button. Once again, choose to save only and reboot later.
4. The last step of configuration once required a username and password, but appears to be unauthenticated now. On the left side under "Configure LAN Port" click on "Bridge Mode". Change the dropdown from "off" to "on" and click the Save button. This time, choose to save and reboot immediately, effecting DHCP, NAT, and bridging configuration changes in one VoIP box reboot. If all goes well, after a minute or two it'll ring the VoIP phone briefly to indicate service is available.
5. Test the result, theory and practice diverge occasionally. Check for VoIP dialtone. Do not be surprised that a computer connected solely via the VoIP box in the intermediate configuration so far described loses internet access after the bridging, DHCP, and NAT changes. If all is working, that PC should be able to resume the normal IP configuration for your LAN, whether DHCP or a non-192.168.15.* static IP address. Attempt to return it to your normal LAN configuration while it is still the only device connected to the LAN port of the DVG-1120M. If it cannot access the internet while connected to the LAN port but the same configuration works when bypassing the VoIP box and connecting to the same router or switch as the WAN port of the VoIP box is connected to, the bridging configuration is somehow not working. Verify the configuration knobs above. Try things at random while taking notes. Pass on any wisdom you can share with future readers of this page to me.
6. If everything is working for the single PC connected to the LAN ("ethernet") port of the DVG-1120M, it should be safe to rearrange the network so that everything on the LAN is connected to the LAN port, with only your WAN router left connected to the WAN port of the DVG-1120M. Once you have moved all your local devices "behind" the DVG-1120M's QoS function, data traffic will be dropped when needed to shape non-voice flows to leave adequate capacity for voice flows. The sound quality improvement for me was audible (using a 1Mbps MCI SDSL connection). The resulting voice quality is imperfect but more than adequate for me. It's better than TDMA cellphones on AT&T Wireless in Redmond, for comparison. Before considering yourself victorious, check back in an hour to ensure both dialtone and internet access are working as expected. If dialtone works immediately after you move the rest of your network to the LAN ("ethernet") port on the DVG-1120M, but then fails after some time, re-read the information in step 2 above about DHCP and DNS servers and ensure your final configuration has any DHCP and DNS servers used by the DVG-1120M IP configuration reachable over the WAN port, despite the logical bridging of the two ports.
Corrections and suggestions can be sent to me at davehart@davehart.com. Please indicate if and how you want to be attributed. If the information on this page has proved useful to you and you are overflowing with a desire to reward my efforts, amazon.com gift certificates via email to davehart@davehart.com are welcomed.
This page has been viewed something like
times since
11 Aug 2004.
HartBrothersHome Asia New Zealand VOSH Amusements Art PapaFlew LeeHart.com Rack Who?
© 1995 - 2008 HartBrothers.com
or its suppliers, all rights reserved. Please contact us for reproduction
permission at webmaster@hartbrothers.com. We respect intellectual property
rights of others and use our own content as well as free/licensed/permitted/fair
use content.