| Attachment | Size |
|---|---|
 VoiceCMconf.PNG | 31.78 KB |
We offer cable internet service as well as a VoIP service which uses a Linksys ATA to our customers and we're trying to find a way to essentially make a 'voiceonly' modem config that will block access to all addresses except for our class 5 switch's session border controller and our ATA provisioning server and 'support' servers like our NTP cluster and so on. We have a test modem set up in one of our remote headends with an ATA behind it, the modem takes the config file without issue but it seems that the ATA behind it cannot pull DHCP and I am wondering if the modem is not allowing broadcasts to go from ETH -> RF to reach our DHCP cluster. I can poll SNMP from the modem and see the ATA in the ARP table but it never acquires an address. The CMTS is a Cisco uBR7114 with cable helper addresses pointing to our DHCP cluster. I have attached a screenshot showing the ACL I have set up with our addresses removed. For right now I am just allowing access to the relevant subnets as a whole to get it working then we will siphon it off even further down to the exact addresses that are required for the ATA to function. The subnets allowed include our DHCP cluster so traffic should be flowing to them. Each subnet is listed twice - once for the source and again for the destination as traffic can originate or be destined from these subnets. If I deploy our standard 3x600 config to the modem the ATA fires right up and registers.
We have yet to run pcaps from an upstream router between the CMTS and our DHCP cluster to see if the requests are leaving the CMTS, but I suspect an issue in the ACL which isn't glaringly obvious to me at the moment and just need someone to verify that I have this going in the right direction. I have tried adding a destination entry for 255.255.255.255/32 to match broadcasts but that doesn't seem to work, either.
Thanks in advance.
Just wondering why you would bother with CM + ATA when you could instead use a eMTA ?
eMTA allows you to bypass issues you describe above, provide better QoS, reduce the number of devices at customer site, and provide better visibility of the phone components to your helpdesk.
Well.. that depends. When we first tried firing up emta's here, the voice quality was horrible.... but the ATA's were fine. The problem turned out to be the way our voip provider at the time was set up. There was too much delay in the link between the switch and the CMS, which was half the country away through the cloud. Once we switched over to our new switch where everything is right here, the emta's work great.
Here, why don't you try setting up your service flows like this. (see text file)
That establishes the service flows for voice packets and datapackets. The first upstream and first downstream service flows are for the data, and they've been restricted to 5k, which should allow your ata to register, but anyone trying to surf would get an agonizingly slow experience. If the 5000 doesn't work, try 10000, and see how that works.
One reason for not going with an eMTA is because we don't have the provisioning server for them (we use RCA/Thomson modems now) and only a handful of us know how to make modem configs by hand - which is all we have to configure the modems. The ATAs have a provisioning web portal that all customer service reps and helpdesk techs are trained to use. The ATAs report into the provisioning server every 5 minutes with their registration status and if not registered, why and how long it hasn't been registered among other things. Plus with an ATA customers can take their phone service wherever they want if they are on vacation or what have you. QoS is handled upstream by our core routers, and as we operate our own voice switch, is all internal to our network. The cable plants combined have maybe 90 customers total across our markets that use DOCSIS and is only one service platform that we operate (the smallest, actually). We also have ADSL/2+, VDSL, FTTH, and wireless platforms that we offer this service on, so the ATAs keep the service offering consistent across all of our platforms.
Anyway - I like the idea of the service flows. Currently I just have the voice only modems synced at 100Kb/s symmetrical - more than enough to handle a G.711u call with overhead (I also have a config for those with 2 lines to up that a tad) but make web browsing excruciatingly slow in the Web 2.0 world we live in.