We just purchased a blonder tongue CMTS and are attempting to get it up and running. We purchased the management software from Blonder Tongue as well, which is actually created by Coresma. Based on references in the documentation and the configs, I believe the CMTS to be a rebadged EVR (or at least running the same firmware).
I have managed to configure the CMTS and provisioning software but am running into some issues with the TOD and ftp servers. Unfortunately the documentation for the software is less then thorough and it runs on windows (I'm a linux guy). On top of this, I'm more of a software guy and not so much of a network topology guy so I have to figure out how to arrange everything.
So first the problems then the questions:
Right now, modems will complete ranging and the DHCP server will issue an IP, but the modem will not take it. In the modem's logs I can see three main errors
DHCP-warning. Noncritical field invalid in response
TFTP failed - request sent no response
TOD request sent - no response received
I can see in the DHCP server that it is assigning leases to the modems, but the modems' status pages are not showing that they are getting an IP (however the IP listed is pingable). Could it possibly be due to the first warning? I know the TFTP and TOD servers are accessible, as I can access them with a computer plugged directly into the router. Are those errors just because the modem isn't taking the IP and is thus unroutable?
I am also getting an occasional 'T3-timeout 'and 'SYNC timing synchronization failure' but have a feeling that is due to the fact my lab bench isn't perfectly balanced for this new unit and the TOD server isn't up and running.
So, where do I go from here? Here are the options I have set in the DHCP server:
Option Name Vendor Value Class
003 Router Standard 192.168.200.1 None
004 Time Server Standard 192.168.200.3 None
006 DNS Servers Standard 192.168.1.3 None
028 Broadcast Address Standard 192.168.200.255 None
066 Boot Server Host Name Standard 192.168.200.3 None
067 Bootfile Name Standard default.ini None
One thing I'm not sure about is the tftp file (Boot file). The documentation for the FOCS managment software (which is running the tftp server) indicates that it generates the config file on the fly based on settings you make in the GUI. It lists the root folder of the tftp server, but fails to mention what file name to have the dhcp server pass to the modem (or any DHCP settings). Also, I can't seem to find an option in the windows DHCP server for the subnet mask, just the broadcast address.
Now I've covered my problem....here's my question. We are looking to install the CMTS on site and keep the management software and supporting servers at a central office. We would like to keep the modems on a different subnet as the CPE's, or at least prevent CPEs from accessing the CM's and tftp server. How do you all go about doing this? We are somewhat limited by the fact we have a firewall with a single point of entry, so all internet traffic is NATed down to a single public IP. Is there a simple way to do this with DHCP relay?
From the dhcp server, can you ping the modem gateway? is the tftp server the same pc as the dhcp server?
options on my dhcp server are 1 ( subnet mask); 2 (time offset); 3 (gateway); 4 (time server upd & tcp port 37); 7 (log server); 51 (lease time); 66 (tftp server); and 67 (bootfile name). since this is a window's pc, don't know if the cmts is a router or a bridge... if it's a router, you will need to add a route on the windows pc to get back to the hfc or modem and cpe network because it's behind the ethernet network of the cmts and it's a different network. dhcp would work because it's a broadcast.
The CMTS has a provisioning test command. I ran it and this is the result:
/root/admin/boot/>prov-test
Note: This test is testing a standard network configuration.
Configuration cases where this test will fail but the system will work properly do exist.
************* Ping the CMTS gateway 192.168.200.1 ***************
Reply from 192.168.200.1: bytes=64 time<10ms TTL=64
Reply from 192.168.200.1: bytes=64 time<10ms TTL=64
Reply from 192.168.200.1: bytes=64 time<10ms TTL=64
Reply from 192.168.200.1: bytes=64 time<10ms TTL=64
Ping statistics for 192.168.200.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
************* Simulating CM DHCP Test *************
Send DHCP Discover message, retry #0
Received DHCP Offer
Send DHCP Request message, retry #0
Received DHCP Acknowledge message IP Address=192.168.200.15
Options test for CM
subnet = 255.255.255.0
router = 192.168.200.1
log-server = 192.168.200.3
broadcast-addr = 192.168.200.255
bs-host-name = 192.168.200.3
boot-file-name = missing
time-server = 192.168.200.3
************* Simulating CM TFTP Test *************
Critical parameters are missing. Aborting CM configuration file download test
Send DHCP Release message
************* Simulating CPE DHCP Test *************
Send DHCP Discover message, retry #0
Received DHCP Offer message
Send DHCP Request message, retry #0
Received DHCP Acknowledge message IP Address 192.168.200.15
Options test for CPE
subnet = 255.255.255.0
router = 192.168.200.1
dns-server = 192.168.1.3
Send DHCP Release message
Provisioning test failed
So it looks like provisioning is working up to the point of obtaining the config file. I just need to figure out what name the server is expecting
If you can get to the folder where the tftp is set for, I can send you a basic docsis 1.0 file
cmcaldas@gmail.com
thanks, but after 2 hours on the phone with an engineer, we found out the issue.
I'm using a firewall gateway to match what will be in the field. For some reason it is screwing up the tftp transaction. If we hooked it up to a switch instead, modems came online and all was fine.
Now I just have to figure out how to get the firewall to play nice and get the DHCP relay running
TFTP uses dynamic UDP ports to send data in both directions; it definitely has a problem with firewalls. A client will send file request packets to the server on udp/69. At that point,the server will disassociate the data part of the transfer and send it using dynamic/unused udp ports. For example, the data may go from from udp/43224 to udp/3037 while client acks continue to be sent to the server on udp/69.
The only way to allow this to work correctly in a firewall is to either enable tftp connection tracking (many firewalls can't do that) or allow full udp access from the server to modem ranges.
Okay, I think it may be something that we can't overcome with our current setup.
Right now we are looking at setting up a VPN tunnel out to the sites so that the DHCP/TFTP/TOD server can be on the same (virtual) network as the CMTS and CMs, then relay the DHCP requests from the public network over to the private. That should stop any filtering and eliminate NAT issues between the servers and the CMTS/CM's.
Does this sound like a good plan? Ideally we would have a straight layer 2 pipe between the home office and the sites, but right now we still have to pass through the cloud.
You can run DHCP/TFTP/TOD over a routed network; they don't have to be in the same broadcast domain or in a VPN. A typical CMTS blade uses a "helper address" to which the DHCP messages are relayed. A modem DHCP discover message hits the blade via broadcast, the CMTS hears the packet and then relays a unicast DHCP discover message to the helper address (DHCP server) using the source IP of the blade. There's no issues with filtering unless firewalls are implemented that block communications between the cablemodems and DHCP/provisioning servers. (They should not be NATed).
I don't know the configuration terminology for EVR/Blonder, but part of a typical CMTS IOS-like config looks something like this:
int cable 0/0
ip address 10.1.1.1 mask 255.255.255.0
ip address 24.1.1.1 mask 255.255.255.0 secondary
cable helper-address 10.5.1.1 cable modem
cable helper-address 10.5.1.1 host
In this example, cablemodems have 10.1.x addresses & hosts have 24.1.x addresses. The DHCP/TOD server is at 10.5.1.1 in a different subnet/location. It has pools for 10.1.1.0/24 and 24.1.1.0/24 and issues out addresses based on the option type (modem or CPE) that's set in the DHCP request.
The inbound firewall on the DHCP server would look something like
ACCEPT udp 10.1.1.0/24 any port -> any port #Dynamic UDP TFTP tranfers, any port to any port
ACCEPT udp 24.1.1.0/24 any port -> port 67-68 #Inbound DHCP messages from CPE space
Outbound firewalls should allow all UDP to 10.1.1.0/24 and 24.1.1.0/24. It's probably easiest to get provisioning working normally before trying to implement the firewalls.
I did manage to get it up and running, but not to my liking. One big issue we are facing is that the we are separated from the property by the internet cloud. We don't have a private connection from the office (where we want to locate the provisioning servers) to the property. At the property, we have a T-1 circuit on a /29 public network and a DSL that we use for failover and spill-over type load balancing. In the current configuration, we can't avoid NAT without putting the provisioning servers on the local side of the property's network.
I did manage to get it to work, however, with VPN tunnels, but the DHPC relay isn't working right. This is how I have it set up:
Office:
local-network: 192.168.11.0/24
192.168.11.2 ---> provisioning server
this network is linked by a VPN tunnel to the remote site
remote site local network:
172.16.16.0/21 --> CM's and CMTS
172.20.16.0/21 --> CPE's
The VPN runnel routes to the CM (172.16.16.0) network, allowing the modems and CMTS direct access to the provisioning server.
I have relay set up as following:
source
type relay-status relay-ip relay-gateway dhcp-server
------ ------------ --------------- -------------- ---------------
cm(1) active(1) 172.16.16.8 172.16.16.10 192.168.11.2
cpe(2) active(1) 172.20.16.8 172.16.16.10 192.168.11.2
In this config, the CM side works fine, but the CPE's cannot obtain an IP. I've also tried giving the CPE's a 172.20.16.10 gateway with no luck. In fact, the only way I got it to work was to build a second VPN tunnel for the 172.20.16.8 network back to the provisioning server. I really don't want to do this, as it opens up stuff to CPE's that they shouldn't have access to. I though DHCP relay was supposed to be able to bridge networks?
DHCP relay should go across any network; discover and request messages are changed from broadcast into regular unicast and forwarded to the server listed. Once a host (CM or CPE) gets an address, they renew directly with the DHCP server via normal l3/unicast. Because of this, your CPE space needs to be able to route to the DHCP server. Relay is only for the initial discovery states.
Can you ping the server using the cable blade as the source IP? Can you ping it using the CPE gateway as a source IP? Typing "ping" without any other information in the CMTS brings up a dialog where you can specific the dhcp server you want to ping, and then with extended commands you can specific IP address that are configured on the CMTS as the source. Make sure that all networks configured on the box can see the DHCP server properly.
Dear Sir
Can Offer Support For the Coresma CMTS or Ever buy them for a good price.
Please describe your problems or send offer:
moshe@olshevsky.com
Support For Coresma / EVR