Arris 604G MTA not accepting DHCP lease | docsis.org

You are here

Arris 604G MTA not accepting DHCP lease

I am running a Cisco Ubr7246Vxr and Cisco's Network Registrar 6.3.3.2. I am attempting to get an Arris TM604G to register on the network.
The Cable Modem gets it's IP without a hitch. However, the MTA isn't accepting the offer. I have suboption 1,2,3 and 6 configured in Network Registrar.

This is the dhcp debug from the Ubr.

Mar 28 16:52:43 EDT: DHCPD: BOOTREQUEST from 0100.1dcd.52e7.18 forwarded to 66.231.32.23.
Mar 28 16:52:43 EDT: DHCPD: forwarding BOOTREPLY to client 001d.cd52.e718.
Mar 28 16:52:43 EDT: DHCPD: validating relay information option.
Mar 28 16:52:43 EDT: DHCPD: creating ARP entry (66.231.37.182, 001d.cd52.e718).
Mar 28 16:52:43 EDT: DHCPD: unicasting BOOTREPLY to client 001d.cd52.e718 (66.231.37.182).
Mar 28 16:52:44 EDT: DHCPD: setting giaddr to 66.231.38.1.
Mar 28 16:52:44 EDT: DHCPD: adding relay information option.

It looks to me like the offer is being handed to the MTA but for some strange reason it is declining to accept it.

TIA,
Art Plato.

two things that are gotchas with Arris MTAs.

1. the dhcp offer must contain option 12 and option 15 to form a fqdn

2. the dhcp offer must come from the same IP you have configured in the dhcp offer for the cable modem for the provisioning server. i.e. option 122 suboption 1 & 2

Yep in the cm offer, put
option 122, and then suboption 1 would nominate the provisioning server's IP address

And in the mta offer, make sure you include options like
12 host-name : @use-macaddress
15 domain-name : example.com
and also option 122, and depending on packetcable method you are using you would fill various suboptions like eg suboption 3 and 6

The arris doco explains all this, I recommend you ask for a copy from your Arris distributor.

I can see that I am handing out option 15, but option 12 I would like the MTA to get from my DNS Server. Any idea what value I would assign option 12 to tell it that is how I want to handle the MTA portion of the FQDN, or is that even possible? I created static PTR for my entire network and don't really want that to change.

Well, the Emta is getting option 12 and 15 but still won't accept the offer it is being given. Any insight would be appreciated. I have included the page showing what the MTA has and has not accepted. It looks to me like it has a complete FQDN.

TIA

File attachments: 

Send the MTA dhcp logs, located at the bottom of that page or better yet a wireshark capture.....

From that screenshot several things are missing:

No ip address, gateway, subnetmask, no lease parameters, and no bootfile name (depends on what provisioning method you use)

no option 122 suboption 3,6 Depends on what type of provisioning your trying to do but even Basic.1 requires at least these attributes.

Here are the relevant captures and logs. I did a wireshark capture of the dialogue between the modem/mta and the dhcp server, a debug of the dhcp transactions between my ubr and the Emta as well as including the DHCP logs on the Emta for both the cm and the mta.

Thanks again for taking the time to look.

There are a few problems with your mta's dhcp offer...

The MTA requested the following options via dhcp (option 55)

1
2
3
6
7
12
15
122

your offer only has these options
1
2
3
6
7

The MTA will ignore any offer that does not contain ALL of the requested options your offer is missing

option 12,15 and 122

this is the hostname, domain name and the packet cable settings.

if you set the following filter in wireshark you can see just dhcp transactions for the EMTA

bootp.hw.mac_addr == 00:1d:cd:52:e7:18

and if you only want to see the CM dhcp

bootp.hw.mac_addr == 00:1d:cd:52:e7:17

your very close just add those options and your all set.

Cool. thanks for the insight. Adding options 15 and 122 are a piece of cake. Option 12 is kind of where I am stumbling. I'm using Cisco's Network Registrar 6.3.3.2 and when I attempt to add option 12 it wants a value. I don't want to manually assign the host name. Is there a value that will tell it to query my DNS server, which already has the host name in a static BIND file, to populate that option?

not to my knowledge most people do it the other way assign it at the dhcp server then update the dns server with that infromation.

What I do is set the host name to the mac address of the device. There is a way to do this automatically in CNR but I have not used it in a while so I don't remember exactly. I think you set it to %mac-address% and it fills in the mac address for you. I am also pretty sure that cnr can update a dns server with this information, though maybe only the built in one.

here is the info I was referring to

host-name

set
get
unset

Clients and client-classes—String to replace or generate the client host name. The first form is a string that does not start with an ampersand (@). This form is used to override the DHCP client request host-name option value. When you enter a valid name, the DHCP server ignores the host-name option value and uses this attribute value instead. You can use any valid DNS name except that it cannot include underscores.

The second form is a string that starts with the special token @. Network Registrar uses this form to signal special handling:

•@host-name-option—The server uses whatever host-name DHCP option the client sends. This is the default behavior if there is no entry for the host-name option in either the client or client-class.

•@no-host-name-option—The server drops the host-name DHCP option that the client sends and does not replace it. If you disable DNS name synthesis, the client has no name placed in DNS.

•@use-macaddress—The server synthesizes a host name for the client that is derived from its MAC address, and is thus unique. This token is used to ensure that a client has a valid name in DNS.

For the host-name string to have an effect, you must set scope name enable dynamic-dns (the default) in the scope that includes the address. Optional, no default; if blank, uses the host-name DHCP option.

found here http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/6.1/command/r...

You are asking what to put into option 12. Did you read the example I gave you back at the start of this topic?

> And in the mta offer, make sure you include options like
> 12 host-name : @use-macaddress
> 15 domain-name : example.com

Yes and I figured it was just an example string because I added that exact string to the host-name option in my policy and it didn't update my DNS or pass an fqdn to the mta.

Well, I can now see that the MTA is getting every option it needs, including 122 and 15 except 12 host-name. Saw it in a wireshark capture The strange part is that I configured option 12 for the cable modem part and option 12 is being handed back to the cable modem but for some bizarre reason, even though option 12 is configured exactly the same in the public scope, which is where the MTA needs to get it's IP, the MTA isn't being handed option 12. It isn't in the offer. FYI, apparently the enable dynamic-dns command for Network Registrar was deprecated in version 6.3.3.2.

I'm truly at my wits end on this one. I am including the latest wireshark capture. I have configured option 12 in the policies for all of my public IP scopes. It doesn't matter which IP pool the MTA gets it's IP from the offer doesn't include option 12. Not sure what I'm missing. Something silly I'm sure. I had to rename the extension on the capture file to pdf in order to upload it to this site. It's original extension was pcap.

File attachments: 

Please provide the following output :

nrcmd -r -N admin -P YOUR_PASS policy YOUR_CM_POLICY
nrcmd -r -N admin -P YOUR_PASS policy YOUR_CM_POLICY listOptions
nrcmd -r -N admin -P YOUR_PASS policy YOUR_MTA_POLICY
nrcmd -r -N admin -P YOUR_PASS policy YOUR_MTA_POLICY listOptions

And also, what did you set arrisMtaDevProvMethodIndicator mib to in your cm config file?

There are several things you can do to see what is happening. I'll list them below:

1) Enable incoming-packet-detail and outgoing-packet-detail logging on the CNR DHCP server. This will show what options the MTA is requesting, and which options the DHCP server is sending. In wireshark, the host-name appears to be untitled.
2) When changing configuration or logging settings in CNR, a DHCP reload is required for the changes to take effect.
3) Setting the host-name option to @use-macaddress would be the correct way for the device MAC address to be used as the host-name, as the other folks on this thread have noted.
4) You have some other problems going on, such as the DHCP server not being authoritative when performing DDNS updates to the DNS server.
5) If you have purchased this product from Cisco, you should be able to open a TAC case, and they will work with you to solve these problems.
6) If you can post a copy of the name_dhcp_1_log file, which is located in /opt/nwreg2/local/logs, if this is a solaris server implementation, I'd be happy to have a look at the logs. You will want to enable the incoming-packet-detail and outgoing-packet-detail, then perform a DHCP reload before rebooting the device to gather the information in the log.

You can also send me an e-mail at esnider@essaz.com and I'll help you directly. I have over 12 years of experience working with CNR and BAC in high speed network environments.

Regards,
-Eric

I was playing around with this same config on my system, and I noticed the problem you describe with option 12 / @use-macaddress.

I found that if you put @use-macaddress into the policy, it just gets ignored.

Instead I had to put it in my client-class (and you can see how the doco quoted above by kwesibrunee says "clients and client-classes", not policies)

eg nrcmd -N admin -P XXX client-class arris-mta-test-class
100 Ok
arris-mta-test-class: host-name=@use-macaddress; policy-name=arris-mta-test-policy;

and then in the policy you put all the other bits, eg option 2,3,4,6,7,15,51,122

On my system, each MTA has a client entry which points to appropriate client-class. And then each client-class points to appropriate policy.

And dont forget to save / reload dhcp after making any changes

Hope that helps!

The problem I guess is that for my CPE's I don't use a client-class. The cable modems get assigned to a client-class but not the CPE's and if I understand correctly if I create a client-class for my public IP scopes then my customers CPE's will have to be assigned to the client-class or they won't get an IP. Is my understanding of client-class tagging correct or am I missing something here? Obviously, I don't have the deep understanding of CNR I should. I would like to say thanks to all who have given me input on this. I truly appreciate your time and value your input.

On our system we have a client entry from every CM IP (private-ip, cm class -> cm policy, option 122 present if there are voice services to activate)
And another client entry for every MTA IP (private-ip, mta class -> mta policy, option 122 etc)
Then anything left over is a CPE IP, and it gets a public IP, falls through to default cpe class / cpe policy