Docsis Help

  • Increase font size
  • Default font size
  • Decrease font size
Home docsisdude's Blog
docsisdude's Blog

Blog Article from October 1st 2008 (3:00PM)

E-mail Print PDF

I’ve had a few questions thrown at me from people asking about the NPE-G2 processing engine for the VXR chassis.   One engineer had been asking for new MC-28U blades but his boss overrode him, and got a NPE-G2 instead.   The CMTS was loaded with four MC-16S blades, and a NPE-G1.   The NPE-G2 would have bought them the increased horsepower of the G2, as well as switched them from GBIC to SFP ports but other than that nothing else really.   They loaded the box up and booted it into IOS, only problem was the linecards weren’t being recognized.   When they tried to load the old IOS, and it simply refused to load it.   So they were stuck and had to back out and go back to the NPE-G1.   He asked me about that and after some searching I saw the NPE-G2 is only compatible with the 12.2.S code train.  The “Monet” adds plenty of new features and is a big departure from the BC code train.   Unfortunately one of the caveats of the Monet aka the S code train, is that it drops support for anything besides the newer MC-16U/X, MC-28U/X and brand new blade for the 7225VXR the E-28U.   So be aware of this if you want to upgrade your VXR, and if you do… you’re probably better off getting a U/X based blade!   Remember, the U/X blades have NPE-G1’s onboard, and when replacing C/S blades you should notice a 10+% drop in CPU utilization on your NPE.

Document link on the G2

docsisdude

 

Blog Article from June 27th 2008 (5:00PM)

E-mail Print PDF

This post was made after docsisdude spent some time doing a password recovery on a BSR and could not find any documentation for the BSR online.... Sound familiar???

One of the best things about Cisco is how well they document things.   I don't know how many times I've gone to www.cisco.com and found exactly what I was looking for.   Sometimes it can take a little longer than I had hoped, but that's only because they have so much documentation to sift through.   You often have to be pretty specific when doing the search, and when you find something good…. Bookmark it.   Stuff like load balancing configs, RFSW setup, CWDM SFPs, the list is endless.   Like all websites Cisco moves things around, so don't get angry when you get dead linked to the apologetic Cisco page not found error.   This brings up an interesting point.   On one hand Cisco has gone to the infinite degree to document EVERYTHING.   This has pros and cons as having all that info often makes finding things difficult.   The other side of the coin is that the other vendors often have very little as far as public documentation.   I know you can't really expect that from everyone, but it can slow you down when you don't have that PDF you need or are learning on a new box.   Either way it would be helpful if the other vendors could put more info up.   It also wouldn't hurt if Cisco trimmed some of the documentation, or removed that eight year doc about DOCSIS1.0 ;)

docsisdude

 

Blog Article from June 11th 2008 (4:00PM)

E-mail Print PDF

So your a DOCSIS Engineer and you compete with AT&T's U-Verse VDSL service. They're taking some of your single play subs and turning them into triple play subs, but hey you've been turning their single play subs into triple plays subs for years. The problem begins after they take the subs, but before those subs disconnect (or if those subs keep your service). What is the problem? HPNA On the HPNA wiki they brush over the topic and state some of the disadvantages of HPNA3.x are "Doesn't coexist with DOCSIS". Well I'll expand on that a little further. This has gotten some news as Comcast outside Chicago has been battling with AT&T and complained to them. This has for the most part been ignored but I'm sure AT&T is burning the midnight oil trying to come up with a solution to allow HPNA to work without disrupting DOCSIS. (right) HPNA works in the frequencies above DSL and voice, but below broadcast television. Sound familiar? Well it should because that's your DOCSIS return path. When somebody hooks up a 2Wire HPNA router/gateway to a coax line still connected to active cable plant, that HPNA signal leaves the house and gets into our return plant. I saw this first hand, and it forced me in at my previous job to vacate my preferred frequency of 35MHz. I had to use 25MHz which isn't a bad frequency, but again this is a competitors product that actively interferes with your product. The HPNA signal looks like a static "haystack" its not bursty like a TDMA based DOCSIS carrier. It can and will destroy your return path and make large swathes of said spectrum completely unusable. Is the solution for the us to high pass filter subs that switch to Uverse? Or should Uverse use the 43-50MHz range we can't use? This is barring strange mid-split systems and assuming standard diplex filters of 5-45 which roll off at @43Mhz. Everything past ~40MHz has pretty hardcore group delay issues anyway so I'd be happy to give them 40-50MHz. If that was the case they could work, we could work and we could go back to competing fairly...... Or I could just drive around with an unlicensed AM transmitter, or go pee on a VRAD.... something makes me think Harry Potter... err Kevin Martin wouldn't like that, let alone MaBell (or the Engineers at AT&T that would have to fix it).

Till next time

docsisdude