| Attachment | Size |
|---|---|
 0015CEABB8B1.emta_.txt | 1.99 KB |
| wayemp.cm_.txt | 1.69 KB |
Hello All,
I need some help here. I'm trying to take a crash course in PacketCable and eMTA's to get dial-tone ASAP. I'll explain what I know and some of what I need to know so maybe someone can help. This is my task, all weekend until I get dial-tone. Here we go:
Plant Info:
* We are running 2 uBR7246VXR's using Cisco Network Registrar (CNR) as our DHCP and TFTP servers. Using Windows 2003 Servers for DNS, email, www, etc...
* We just received 100 Arris TM602G's and we are using Knology for our turn-key VOIP solution.
* I know we are going to use dynamically created *.mta files, but for now, I need to get a dial-tone ASAP with a manually created *.mta config.
* Knology has provisioned one eMTA on their side. I have the SIP Server IP, username (phone#), SIP password, etc. I have PacketACE and I have created a [MAC].mta file for test provisioning. See attached file converted to .txt...
* I have an eMTA connected with the data side working. I provisioned it just like our Motorola CMs. See attached DOCSIS 1.1 wayemp.cm.txt
A few questions:
1.) Having a test eMTA config, I basically just need to setup a DHCP server to handle eMTA requests, correct?
2.) We do not have Cisco "Broadband Access Center". Will CNR (Cisco's DHCP) do the eMTA provisioning by itself? If not, or even if CNR will handle it, would it be easier to setup a Linux box just for eMTA DHCP tasks? I also have access to a windows DHCP server, but I assume that wont suffice. I can easily setup a linux box but I'm not quite familiar with DHCP configuration tasks, although I do catch on quick. Remember, this isn't permanent. I simply want a dail-tone at this point.
3.) If I use a different DHCP server for the eMTA, how do I tell the eMTA that the DHCP server for the eMTA side is a different IP from the CM side?
4.) What is a MIC key (shared secret?) and is it required from our CMTS for the *.mta config files to work? How do I get the CMTS key?
5.) I guess my main task is configuring a DHCP server for the eMTA side. Can someone provide some guidance?
6.) Anything else I need to do or that I am missing.
Thanks to anyone for any help you can provide!
~Will
1. think mta as another network device. It will need ip via dhcp, need a config file via tftp. It can get quite complicated using secure flow which involved kerberos.
2. we don't have bacc; cnr can do mta provison just fine. However you might need to create custom dhcp option depend on the verison you are running. option122 would be what you need to focus on.
3. there is going to be some hack... from dhcp server point of view the mta would be the same as any other CPE. We did this via cnr extension by looking @ the dhcp packet option43 and option60.
4. you don't need MIC for mta. It's only use for CM. However you do need sha1sum for the mta config file.
challange 1
option 122 for emta dhcp
http://www.cisco.com/en/US/docs/net_mgmt/broadband_access_center_for_cab...
challange 2
getting the emta to be on the scope that you want them on. If you are doing sip; I don't see any reason not treating them like CPE devices
That helps. What is "sha1sum"? Can you explain further? Thanks for the reply.
it might not be a concern.
There are usual private mibs or vendor specific option to turn the hash check off.
mib description:
Hash of the contents of the config file, calculated and
sent to the MTA prior to sending the config file. If the
authenticationalgorithm is MD5, the length is 128 bits.
If the authenticationalgorithm is SHA-1, the length is 160
bits. Hash calculation MUST follow the requirements
in [10].
http://en.wikipedia.org/wiki/Sha1sum
similar to md5sum
it's a unix command that caculate the hash:
ex
sha1sum arrismta.bin
7c1875fd03d3298e66c04e7030483f43d3cd898d arrismta.bin
in your emta config file:
SnmpMibObject pktcMtaDevProvConfigHash.0 HexString 0xc775dc622b22582578fbded7d797c2ab662b31d5 ;
step1
create the mta config file without hash
step2
Caculate the hash of the binary file
step3
add the hash back in the file and recreate mta binary file.
the mta will substract hash check sum from the file so the check sum should match and that's one thing packetcable does to ensure the mta file have not been temper with.
Thanks everyone for all the help. I now have 2 cases opened with Cisco and one open with Arris.
Through Arris eMTA traces via telnet and the CNR DHCP logs, it looks like we now have CNR configured properly and the MTA appears to send a DHCPREQUEST (Step 3 of DHCP) but it looks like the CNR never receives it.
The problem is that there’s only 2 or 4 DHCP steps being completed. Of the 4 steps (DISCOVER, OFFER, REQUEST, ACK), here’s what’s taking place:
MTA sends DHCPDISCOVER to DHCP server
DHCP Server sends DHCPOFFER to MTA
MTA sends DHCPREQUEST to DHCP Server
DHCP Server never receives DHCPREQUEST
And the process starts all over again…
Seems that it's CMTS related. I've enabled packetcable, but I was told this isn't neccessary from another DOCSIS engineer. Fro some reason, it's not passing the request back to the server. I've tried DHCP debugging on the CMTS, but it doesn't give much info.
engineer on a cisco SR requested this command:
uBR7246VXR_02#sh packetcable global
Packet Cable Global configuration:
Packetcable DQOS Enabled : Yes
Packetcable Multimedia Enabled : Yes
Element ID: 78221
Max Gates : 2097152
Allow non-PacketCable UGS
Intercept Hold Content: Enabled
Default Multimedia Timer value -
T1 : 200000 msec
Persistent gate : 0 hour
Volume Limit : STOPPED
Default DQoS Timer value -
T0 : 30000 msec
T1 : 300000 msec
uBR7246VXR_02#
At any rate, I am pulling my hair out because it's got to be something simple!
Ideas? Thanks in Advance...
Edit: See below for MTA trace, as you can see, it repeats this over and over...
PK DHCP: waitResponseRetry(): Attempt 0, timeout 600
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: verifySuboption6(): retval = 1
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: [MTA-2] DHCP_OFFER Received
PK DHCP: handleResponseDiscover(): Accepting offer only from primary, retry=0
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): Attempt 1, timeout 1600
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: verifySuboption6(): retval = 1
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: [MTA-2] DHCP_OFFER Received
PK DHCP: handleResponseDiscover(): Accepting offer only from primary, retry=1
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): Attempt 2, timeout 3000
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: verifySuboption6(): retval = 1
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: [MTA-2] DHCP_OFFER Received
PK DHCP: handleResponseDiscover(): Accepting offer only from primary, retry=2
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): Attempt 3, timeout 6400
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: verifySuboption6(): retval = 1
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: [MTA-2] DHCP_OFFER Received
PK DHCP: handleResponseDiscover(): No secondary server exists, retry=3
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): Attempt 4, timeout 12800
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: verifySuboption6(): retval = 1
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: [MTA-2] DHCP_OFFER Received
PK DHCP: handleResponseDiscover(): No secondary server exists, retry=4
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): retries exhausted, returning
PK DHCP: stateSelecting(): pk_dhcp_waitResponseRetry() failed, going idle
PK DHCP: task(): State transition 2-2
PK DHCP: [MTA-1] Sending the Discover Message
PK DHCP: waitResponseRetry(): Attempt 0, timeout 800
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: verifySuboption6(): retval = 1
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: [MTA-2] DHCP_OFFER Received
PK DHCP: handleResponseDiscover(): Accepting offer only from primary, retry=0
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
Any chance of a wireshark capture of the DHCP packets?
from what your describing sounds like router option is missing or wrong subnet
because DHCPDISCOVER and DHCPOFFER are both broadcast and DHCPREQUEST and ACK are unicast.
The REQUEST and ACK being unicast makes me think even more that it's something to do with the router config. Like it's ignoring the packets because they're not from a CM or CPE.
I'll have to remember how to setup monitoring for capture. I think I've done it before but it was years ago. If I remember correctly, you can copy all traffic from a cable or bundle interface to an Ethernet port and setup sniffing there.
I kinda figured that was the next step, I just didn't want to hassle. Oh well, we gotta do what we gotta do.
I was even thinking it may have something to do with the "cable helper-address a.b.c.d." command. I know in the latest versions of IOS, it allows for modem, cpe, and mta options at the end. I wonder if this has anything to do with it...?
Anyone here have a Cisco CMTS running packetcable? If so, what is your cable-helper-address command configured as?
Thanks for the input! Any other ideas feel free to reply.
As far as cisco config goes there really is nothing to it.
cable helper-address ip-address
or
cable helper-address ip-address cable-modem
cable helper-address ip-address host
note unless you use actual packetcable MTAs i.e. not SIP
the cable helper-address ip-address mta won't do a thing
I can help you solve the problem, and it does not require any weird monitoring on the cmts.
On your DHCP server install wireshark and capture the DHCP server side of things for one of the MTAs in question and either post it here or shoot it to me offlist at jasonp at cablemo dot com
MTAs are really picky when it comes to DHCPOFFERs they will accept, if I can see what they are being given I can help you solve your problem.
Thanks! I'll do that in the morning and post it here...
Here's the DHCP capture filtered cap file. I'm not sure how to filter out the particular MTA yet. CM side is 00.15.ce.ab.b8.b0 and MTA side is 00.15.ce.ab.b8.b1. Thanks to anyone that can help.
http://users.wayxcable.com/~willieb/dhcp.zip
Edit: I figured out how to add display filter with "bootp.hw.mac_addr == 00:15:ce:ab:b8:b1" to filter just the MTA. It looks like the DHCPREQUEST never makes it back to the DHCP server...?
Here's the CMTS Monitor capture. It looks like the TM602G is never sending the request. I'm calling Arris back.
I'll keep this thread updated, please pop in if you might have some helpful info. Thanks!
http://users.wayxcable.com/~willieb/cmts.zip
Here's the latest...
Called Arris back and they stick with their guns about something being wrong with the DHCPOFFER. And Cisco says there's nothing wrong with it. What some crap, lol...
So now I have to setup a conference call with Cisco and Arris for Weds morning to get all this worked out. I can't beleive it's this difficult with all the systems out there in place working fine.
In the mean time, just for grins, I downgraded the firmware on our Arris TM602G's to the recommended version our VOIP provider is still using (4.5.6). At least now, I'm getting a different error in the trace that's giving more info. It doesn't seem to help Arris engineers or Cisco CNR experts, but hey, maybe someone here knows the magic parameter from this new info. So here it is...
Someone tell me what's wrong so I can stop the madness, lol...
PK DHCP: waitResponseRetry(): Attempt 1, timeout 1400
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: handleResponseDiscover(): Accepting offer only from primary, retry=1
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): Attempt 2, timeout 3200
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: handleResponseDiscover(): Accepting offer only from primary, retry=2
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): Attempt 3, timeout 6400
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: handleResponseDiscover(): No secondary server exists, retry=3
PK DHCP: waitResponse(): handler ignored message
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Response xid (0x4e39a892) and request xid (0xaaf1bd0) differ
PK DHCP: handleResponseDiscover(): Offer of unknown type 5, ignoring
PK DHCP: waitResponse(): handler ignored message
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Response xid (0x564d141e) and request xid (0xaaf1bd0) differ
PK DHCP: handleResponseDiscover(): Offer of unknown type 5, ignoring
PK DHCP: waitResponse(): handler ignored message
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Response xid (0x38a1b5ef) and request xid (0xaaf1bd0) differ
PK DHCP: handleResponseDiscover(): Offer of unknown type 5, ignoring
PK DHCP: waitResponse(): handler ignored message
PK DHCP: msgQWait(): timeout
PK DHCP: waitResponse(): pk_dhcp_msgQWait() timeout
PK DHCP: waitResponse(): no acceptable response, returning to same state
PK DHCP: waitResponseRetry(): Attempt 4, timeout 12800
PK DHCP: waitResponse(): Sending DHCP REQUEST
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Verify phase done, acc=0 (Perfect)
PK DHCP: handleResponseDiscover(): No secondary server exists, retry=4
PK DHCP: waitResponse(): handler ignored message
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Response xid (0x21d669a) and request xid (0xaaf1bd0) differ
PK DHCP: handleResponseDiscover(): Offer of unknown type 5, ignoring
PK DHCP: waitResponse(): handler ignored message
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Response xid (0xff0f737c) and request xid (0xaaf1bd0) differ
PK DHCP: handleResponseDiscover(): Offer of unknown type 5, ignoring
PK DHCP: waitResponse(): handler ignored message
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Response xid (0x2f494030) and request xid (0xaaf1bd0) differ
PK DHCP: handleResponseDiscover(): Offer of unknown type 5, ignoring
PK DHCP: waitResponse(): handler ignored message
PK DHCP: waitResponse(): Received response, verifying...
PK DHCP: processReplyMsg(): Response xid (0x6d78a879) and request xid (0xaaf1bd0) differ
PK DHCP: handleResponseDiscover(): Offer of unknown type 5, ignoring
PK DHCP: waitResponse(): handler ignored message
Ok I think I may have your answer.....
Your dhcp server is telling your modem that your MTA DHCP server is 66.20.37.70
option 122.1 == 66.20.37.70
but the MTA is hearing the offer from 172.18.37.70
and since they do not match it is ignoring the offer....
told ya MTAs are picky....
set your option 122.1 == 172.18.37.70 on the modem and you should be in business
OMG!! That was it. It's no wonder Cisco and Arris couldn't see it. Freekin' amazing.
I can't tell you enough Thank you!
Status is now "Telephony-Reg with Call Server". I'll let you know how that goes. Picky MTA crap, lol...
Edit: That is strange since the MTAs are not internal to the firewall. But I'll worry about that later, lol. Yay!
We got a dial-tone yesterday. Thanks for everyone's replys and help.
wbashlor @ mediastreamga dot com
.
1. yes, you need a DHCP server that can handle option 122 for both the arris modems and the MTA.
2. Depending on your version of CNR it can do it need 6.x or higher to use option 122, if not DHCPd for linux can indeed do it as well
3. Cisco CMTSes support multiple cable helper commands i.e. :
cable helper-address 192.168.224.39 cable-modem
cable helper-address 192.168.224.41 host
cable helper-address 192.168.224.40 cable-modem
cable helper-address 192.168.224.42 host
this series of commands will send all cablemodem dhcp requests to both 192.168.224.39 and 192.168.224.40 and all host dhcp requests to 192.168.224.41 and 192.168.224.42
The way to make this work would be to have only non-voice modems authorized on one dhcp servers and voice modems authorized on the other.
This is the way we are currently set up non-voice modems go to Cisco CNR and voice modems goto DHCPd (since we don't have cnr 6.x)
4. I don not believe that MIC keys work for config files for MTAs
5. I have written a howto for doing what your trying with DHCPd found Here
6. you sound like you have a firm grasp on the process, however one piece of advice, MTAs be they SIP or Packetcable or whatever absolutely refuse to accept DHCPOFFERs unless they contain a FQDN. So for your MTAs you need to make sure you give them these two options: domain-name and host-name. Note the FQDN does not need to actually resolve, i use [MAC_ADDRESS_OF_MTA].mta.domain.com
7. The Guys at Arris are generally helpful give em a call if you get stuck they may be able to help you too.