X
NMS Prime
Stay informed. No spam. Just content. This is our promise.
I agree to the privacy terms. I can unsubscribe at any time.
X
Thank You!
X
NMS PRIME - Konferenz
Anzahl der Teilnehmer:
Datenschutz gelesen und akzeptiert
X
Vielen Dank!
X Sign up to comment and create new topics

Migrating provisioning servers

Hello NMS Prime devs and users. I've just installed the 3.0 version and am enjoying getting familiar with it.

First let me describe what we are doing. We have an undocumented legacy provisioning system that is currently attached to a Cisco uBR10000 cmts which serves docsis 3.0 to a small gated community in Florida, USA.  My task is to "learn" the secrets currently trapped in the closed legacy system and bring our headend over to a new open provisioning system with a clean and well documented architecture.  We are a "linux shop" with CentOS 7 installed on all of our headend servers. We are avid open source advocates, and we use MVC web applications for some of our internally developed purposes, so I was naturally attracted to NMS Prime as maybe the best match for our purposes.

Along the way I will most likely have some questions for the devs and user community, but here is the first:

I would like to ask the forum members, what are you using for capture/analysis instrumentation? We currently have a Deviser DS2800 portable docsis analyzer which works well as a standalone field unit, but I'd like to find the best way to capture modem registration packet exchanges for realtime and/or postprocessing wireshark/tcpdump analysis. What is everyone using for this? 





Most Popular Post
Ole Ernst on 21 Jul 2021 - Likes 1

Hi Robert,

NMS Prime sounds perfect for you! Let us know if run into issues during set-up / migration. You may also get involved developing if you are familiar with MVC (we are using Laravel as our framework).

Since you are using an ubr10k you can use the cable intercept feature of that CMTS to analyze the modem traffic. You don't need any special hardware / test gear for that. Assuming your modem is within the interface bundle 1, you can do something like this:

CMTS: send all traffic of modem 01:23:45:67:89:ab UDP-encapsulated to 172.20.0.1:9999
cmts#configure terminal 
cmts(config)#interface bundle 1
cmts(config-if)#cable intercept 0123.4567.89ab 172.20.0.1 9999

On the server / PC side you can run tcpdump using:

PC (172.20.0.1): capture UDP-encapsulated traffic
tcpdump -vU -i <NIC> -w /tmp/intercept.pcap port 9999

Once your done, stop the capture and open it with Wireshark using the following "Decode as..." rules:

UDP; port 9999; Integer, base 10; (none); Ethernet

This should give you a nice capture of the modem packets. To disable it on the CMTS run:

cmts#configure terminal 
cmts(config)#interface bundle 1
cmts(config-if)#no cable intercept 0123.4567.89ab 172.20.0.1 9999

Note: This only captures the traffic of the modem. For MTA / CPE add another cable intercept line. It can have the same destination IP address / port combination.

6 Comments

  1. Hi Robert,

    NMS Prime sounds perfect for you! Let us know if run into issues during set-up / migration. You may also get involved developing if you are familiar with MVC (we are using Laravel as our framework).

    Since you are using an ubr10k you can use the cable intercept feature of that CMTS to analyze the modem traffic. You don't need any special hardware / test gear for that. Assuming your modem is within the interface bundle 1, you can do something like this:

    CMTS: send all traffic of modem 01:23:45:67:89:ab UDP-encapsulated to 172.20.0.1:9999
    cmts#configure terminal 
    cmts(config)#interface bundle 1
    cmts(config-if)#cable intercept 0123.4567.89ab 172.20.0.1 9999

    On the server / PC side you can run tcpdump using:

    PC (172.20.0.1): capture UDP-encapsulated traffic
    tcpdump -vU -i <NIC> -w /tmp/intercept.pcap port 9999

    Once your done, stop the capture and open it with Wireshark using the following "Decode as..." rules:

    UDP; port 9999; Integer, base 10; (none); Ethernet

    This should give you a nice capture of the modem packets. To disable it on the CMTS run:

    cmts#configure terminal 
    cmts(config)#interface bundle 1
    cmts(config-if)#no cable intercept 0123.4567.89ab 172.20.0.1 9999

    Note: This only captures the traffic of the modem. For MTA / CPE add another cable intercept line. It can have the same destination IP address / port combination.

  2. Thanks Ole for your fast response. Your cmts idea sounds like a perfect solution for what I'm needing to do. The only thing that would not give us would be visibility to the RF negotiation phase and I'm not sure we really need that anyway. 

  3. So far I didn't really need to debug RF negotiation / ranging thoroughly. But you also have the "debug cable" commands to get insight into that.

  4. No questions today, just a few ramblings:

    The cmts capture procedure worked perfectly to capture a modem registration packet exchange. Then with Wireshark:  File | Export Objects | TFTP  gave us a binary config file which is viewable with your utility docsys -d <file_name>.

    Now with this in hand we can proceed to set up a matching configuration in NMS Prime.

  5. Question of the day:

    When carrying out extensive cmts changes in a running system, it would be convenient to script the changes. In a linux world we can script remote operations by setting up an ssh login certificate and then scripts can look something like this;

      ssh root@remote_server "uptime"

      ssh root@remote_server "uname -a"

    Does anyone have a "best practice" way to script operations in a cmts?

  6. For running just a simple command without an enable password you can basically do it the same way. For more complex scenarios there is expect, with which you can automate command line workflows by matching the answers of the remote device and act upon them.