Hey, smee again.
Need more help :( I am stuck at different end: my MTA's get an IP address. However, after DHCP ack package, I never get to see TFTP request from MTA at my provisioning server. What strikes me as very odd is some sort of the routing problem that I cannot get hold of. I have 3 networks - 2 fixed subnets / IP addresses for both CMs and MTAs, and 1 pool set up for CPE. I use ISC-dhcpd, fourth network is defined just for the sake of the dhcpd.
CM goes through provisioning system fine. It gets fixed address provided in dhcpd.conf (host username {hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address 10.x.0.210;}). When it gets provisioned, I can ping it from my provisioning server.
CPE goes through provisioning system fine. It gets an address from the pool, it gets public IP with /32 subnet, gateway is CMTS address, I can surf from the CPE. CPE gets address if mac is in the pre-set list (allow members of "cpe"; in the pool specs). All CPEs are listed like host username_CPE {hardware ethernet aa:bb:cc:dd:ee:ff;}, if same user needs more CPEs or to change MAC, we would not erase old mac - just go add host username_CPE2, etc. This also works fine, if there is no firewall at CPE, I can ping it from both provisioning server and from internet.
MTA gets a fixed address from pre-determined subnet. It has the subnet defined only (no pool, same like CM) since I want to be able to fix an IP address for particular MTA (easier or administration). Thus, MTA subnet has "deny unknown clients" set. Since I have to "inject" every MTA with its own username/pwd and details for SIP, I just wanted to have each MTA get its own aabbccddeeff.bin file according to mta mac address, which I would define with host username_MTA {hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address 10.y.0.210;} MTA does get an TSP address - it does get through first part of provisioning - it gets and keeps DHCP address (if DHCP ACK was wrong, it is required by specification NOT to hold an IP address but to re-request it from the DHCP server). However, i never see it send TFTP requests out.
I can ping MTA from the CMTS, however I cannot ping it from the provisioning server. even worse, I can ping CMTS mta-helper address regularly from the provisioning server, all works fine (thus routing should be OK) but when I try to ping MTA, about 15% of packages go through, others are lost (like, out of 1000 packets, I will get perhaps 130-200 to reach MTA).
Also, even weirder, I was trying to sniff all traffic at the CMTS uplink port (it's ethernet interface) - I have had traffic duplicated at the cisco switch and sniffed with wireshark, I never get to see tftp request come out of the MTA. MTA log does not say much - almost nothing - it says this:
Telephony DHCP Completed
Telephony TFTP N/A
Telephony Provisioning State In Progress
Telephony Line 1 CMS Registration State
Telephony Line 2 CMS Registration State
now: my TSP address, as it is sent in the sub-options of the option 122, enlist TSP serer as the FQDN (mta.mydomain.net) - which points to the private ip address. it gets resolved fine from everywhere - from inside the network, from CPE, from CMTS, from firewall, from outside the network. However, it is still in the FQDN form, not in the IP-address form. DNS servers offered to MTA resolve this address well. I still cannot get neither TFTP request from the MTA towards the provisioning server, nor I can keep ping working towards the MTA - it simply works a little bit. Even - if i leave CMTS pinging MTA (like, ping 10.y.0.210 size 64 100 - so it pings MTA with 64-bit sized packets and repeats it 100 times) - in the meantime, if i try pinging from provisioning server, MTA will not be pingable from CMTS.
This is driving me nuts - especially since I have had my colleagues triple-check my routing rules (I thought i was too tired and overlooked something)... but what is really weird - i do not have problem pinging CMTS's mta address, I can ping everything from CMTS both ways, but I cannot keep pinging MTA from behind CMTS (I've also tried from other equipment, to rule out problems with provisioning server, situation is the same).
If anyone has any advice it will be highly appreciated. I've exhausted my troubleshooting skills and nerves I had reserved for this. Every little step needed is a mile long for me, especially since I am so limited with troubleshooting ... I cannot drive to the site and resolve this there, it'd be much easier, i know - though i have people there helping me, it is really hard to do all this remotely. And excuse my incoherent explanation - i tried to put all relevant but not too much relevant information :)
thx again
Couple of Ideas......
Are you passing option tftp-servers to the MTA via dhcp? The MTA does not TFTP from the provisioning server but from the TFTP server as provided by dhcp, as well the file-name must be specified via dhcp as well using option bootfile-name
If your using Arris modems with SIP Firmware setting the proprietary provisioning type to GUPI MAC (9) negates having to set the bootfile-name option via DHCP and it requests a file in the format mac_address.bin i.e. 001122334455.bin
Well I am passing option tftp server to the MTA, in more than one way, here is my conf shortened:
ddns-update-style none;
default-lease-time 600;
log-facility local7;
option space docsis-mta;
option docsis-mta.dhcp-server-1 code 1 = ip-address;
option docsis-mta.dhcp-server-2 code 2 = ip-address;
option docsis-mta.provision-server code 3 = { integer 8, string };
option docsis-mta.as-req-as-rep-1 code 4 = { integer 32, integer 32, integer 32 };
option docsis-mta.as-req-as-rep-2 code 5 = { integer 32, integer 32, integer 32 };
option docsis-mta.krb-realm-name code 6 = string;
option docsis-mta.tgs-util code 7 = integer 8;
option docsis-mta.timer code 8 = integer 8;
option docsis-mta.ticket-ctrl-mask code 9 = integer 16;
option docsis-mta-pkt code 122 = encapsulate docsis-mta;
class "cm" {
match if substring(option vendor-class-identifier,0,6) = "docsis";
spawn with hardware; }
class "mta" {
match if substring(option vendor-class-identifier,0,4) = "pktc";
spawn with hardware; }
class "cpe" {
match if ((substring(option vendor-class-identifier,0,6) != "docsis") and (substring(option vendor-class-identifier,0,4) != "pktc"));
spawn with hardware;}
#subnet for DHCP server to know where is it
subnet 10.0.0.0 netmask 255.255.255.0 {}
shared-network CABLE {
next-server 10.0.0.10;
option tftp-server-name "10.0.0.10";
option time-servers 10.0.0.10;
option log-servers 10.0.0.10;
option time-offset 7200;
subnet 10.1.0.0 netmask 255.255.0.0 {
option subnet-mask 255.255.0.0;
option domain-name-servers a.b.c.d, a.b.c.d;
option routers 10.1.0.1;
option docsis-mta.dhcp-server-1 10.0.0.10;
deny unknown-clients; }
subnet 10.2.0.0 netmask 255.255.128.0 {
option subnet-mask 255.255.128.0;
option routers 10.2.0.1;
#next-server 10.0.0.10;
next-server 10.2.0.1;
option domain-name "mynet.net";
#option tftp-server-name "10.0.0.10";
option tftp-server-name "10.2.0.1";
option time-servers 10.0.0.10;
option bootfile-name "mta.bin";
filename "mta.bin";
# this just sets the hostname to mta{macaddress} i.e. mta001122334455
option host-name = concat ("mta",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 1, 1))),2), "",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 2, 1))),2), "",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 3, 1))),2), "",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 4, 1))),2), "",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 5, 1))),2), "",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 6, 1))),2));
option docsis-mta.dhcp-server-1 10.2.0.1;
option docsis-mta.provision-server 0 "\003mta\005mynet\003net\000";
option docsis-mta.krb-realm-name "\005BASIC\0011\000";
option domain-name-servers 10.0.0.10;
option bootfile-name "mta.bin";
filename "mta.bin";
# allow members of "mta";
deny unknown-clients; }
subnet a.b.c.0 netmask 255.255.254.0 {
pool {
range a.b.c.11 a.b.c.254;
option routers a.b.c.10;
#option subnet-mask 255.255.254.0;
option subnet-mask 255.255.255.255;
option domain-name "mynet.net";
option domain-name-servers a.b.c.d, a.b.c.d;
allow members of "cpe"; } }
} # end shared-network CABLE
group tester {
filename "test-luciano.cfg";
option bootfile-name "test-luciano.cfg";}
host test_CM {
hardware ethernet 00:1a:ad:a9:20:ee;
fixed-address 10.1.0.210;
group "tester"; }
host test_MTA {
hardware ethernet 00:1a:ad:a9:20:f0;
fixed-address 10.2.0.11;
option bootfile-name "mta3.bin";
filename "mta3.bin";
next-server 10.0.0.10;
option routers 10.0.0.10;
option tftp-server-name "10.0.0.10";}
CableLabs specification claims that sub-option 3 (TSP provisioning server) is the only one needed and sufficient for MTA to obtain TFTP file, it does not care for other specs. However, as you can see, I've included it in any way I could've figured out to make sure - as option tftp-servers, option routers, and next-server. name of mta.mynet.net resolves to the private 10.0.0.10 address from anywhere. no matter what i do, i cannot sniff the TFTP request from MTA towards provisioning server, nor towards anywhere, for that matter.
As for the modems and mac-address.bin - were you saying that arris modems will not accept individual .bin files anyways, or they just won't accept it if it is in the form of mac-address.bin (aabbccddeeff.bin)? If that is the case I can easily and safely go with username-lastname.bin or something else. I just need to feed every MTA with its own username and pwd, thus making sure noone abuses other people's call minutes etc.
thanks for the help once again :) you seem to be the guru that keeps this site revolving around the clock...wish i had more experience with this to be helpful as well.
.play.open.minded.
Looks like you have all the appropriate options set, let me ask you a couple of questions.....
what kind of Modem are you using? Arris, Motorola? What model? There are some Arris specific troubleshooting tools that may help i.e. telnet interface If Arris, what firmware version are you running, there is docs for each particular version (at least major revisions) of firmware that I can forward to you.
the macaddress.bin file will work fine, even with the Arris modems, however if you are using SIP firmware on Arris modems they have a proprietary SNMP oid you can set in the modem config file (see next paragraph), that will tell the modem to TFTP a file with the format macaddress.bin from the dhcp specified tftp server. For some dhcp servers, specifying a unique file per MTA may not be possible or easy so they simplified the process in their firmware. Packetcable (MGCP) does not require a unique config for each MTA, because the Authorization, services and Authentication are all handled at the other side of the connection.
The Arris MTAs require that SnmpMibObject enterprises.4115.1.3.3.1.2.3.6.0 be set to an appropriate setting for the firmware type, I don't have the full list of types handy but I know type 4 (GUPI) will work for Packetcable (MGCP) firmware and type 9 (GUPI Mac) will work for SIP firmware. Changing this setting actually changes the way the MTA provisions. Other Manufacturers may have similar settings though I am unaware of them, because we use Arris modems exclusively for our MTAs.
As to being the guru here I will leave that to others to determine, very recently I was on the other side of equation, looking for help with my own deployment and others, both here and off list helped me tremendously, just trying to return the favor.
here is the thought - do you know how to encode sub-option 3 as an IP address? spec says that if it has value of 0 string [FQDN] will follow, however - if 1 arrives it should look for an IP address? I am not sure that MTA can reach DNS server at this point [even though that i've put laptop behind the cable modem, set manually an ip address from MTA scope, and reached DNS....] as I said - I use motorola surfboard 5121e and thomspon tgh520 modems...
I will probably have to sleep over this some more but it bothers me....
5.2. TSP's Provisioning Server Address Sub-Option
This option contains the address of the TSP's Provisioning server.
MTAs communicate with the Provisioning server at various stages in
their provisioning process.
The address can be configured as either an IPv4 address or as an
FQDN. The encoding of sub-option 3 will adhere to one of 2 formats.
1. IPv4 address. The sub-option length MUST be 5. The length octet
MUST be followed by a single octet that indicates the specific
address type that follows. This type octet MUST be set to 1 to
indicate an IPv4 address. The type octet MUST be followed by 4
octets of IPv4 address:
Code Len Type Address
+-----+-----+-----+-----+-----+-----+-----+
| 3 | 5 | 1 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+-----+
2. FQDN. The length octet MUST be followed by a single octet that
indicates the specific address type that follows. This type octet
MUST be set to 0 to indicate an FQDN. The type octet MUST be
followed by the encoded FQDN:
Code Len Type FQDN
+-----+-----+-----+-----+-----+ +-----+
| 3 | n+1 | 0 | f1 | f2 |...| fn |
+-----+-----+-----+-----+-----+ +-----+
It is not anticipated that additional type codes, beyond IPv4 (1) and
FQDN (0), will be required. Thus, IANA will not be required to
maintain a registry of type codes.
I think this is how you do it:
to use the IP address version change this line
option docsis-mta.provision-server code 3 = { integer 8, string };
To
option docsis-mta.provision-server code 3 = { integer 8, ip-address };
then when you are setting it instead of
option docsis-mta.provision-server 0 "\003mta\005mynet\003net\000";
use
option docsis-mta.provision-server 1 10.0.0.10;
i was guessing it was soemthing like that. isc dhcpd documentation is tricky and sparse, man is not detailed enough about this. i will have to experiment again - i didn't have a chance to try it today....tnx anyways. i will let you know how my saga ends.
e-mail me off line and I'll give you my cell phone number. I'm trying to build a list of references. :) eric@starlightcable.com
Hopefully my test lab parts will show back up soon (parted them out to troubleshoot a problem) and I can test it in my own lab, which is better than me going by memory, I even have a SBV5120 to test with....
Hello,
I resolved provisioning troubles I've had. Just thought that I should inform ya all about problems I've had and solutions they took :) Basically, my original DHCP config was clear and OK. All problems of MTAs and CMs not being able to finish provisioning were related to the unusable and old firmware in Cable Modem. Be sure that you are on the right track if you are trying provisioning for the first time, take modems you know of and have support for. We were able to provision Thomson SGH520, but not until I found somewhat obscure information on telnet access. My main problem was that I was not able to find any logs for MTA nor for CM part of the modem. Once we upgraded firmware to usable version, we were able to initiate and access web configuration interface of the modem (which is by default disabled, and if enabled - available only from the RF side of the modem, not from the "user" interface). Upon enabling web config, it was easier to set values for SIP, however we were not able to set anything for the log server. I tried different combinations of rsyslog ports and IP addressing (same, private scope as CM, as MTA, or public ip, or whatever ip, or default rsyslog port, or some other port....) nothing worked. At the end, I was lucky to re-read Thomson modem documentation and find out that telnet is also disabled by default, and needs to be set via cable modem config file. Once I figured that out, everything else went easy (when you have logs and CLI access to equipment, everything can be set, there are no limits).
Anyways, so first off - modems need to have acceptable firmware version,
secondly - read and re-read your modem documentation, lots of modems have proprietary features that extend or replace packetcable or docsis requirements,
third - do have log and telnet access to your modems, without that it is really hard, if not impossible, to analyze and fix problems you run into.
the last, but not the least - do not forget good people from docsis.org, if you find solution for problems you encountered, come back and post them and other information, there is always other people who will get stuck.
.play.open.minded.