What is reasonable to expect with a non-VXR 7246 fully loaded with MC16C's and a NPE225?
I'm now running around 800 D.1 modems through it and seeing my downstreams peaking in the low to mid 20mbps range with my 100Mbps FE seemingly hitting a wall at around 68Mb. Seems like there should still be some headroom in the FE based on my limited understanding of the D.1 downstream limitations overall, but we seem to be falling over at that 68Mb point.
Here's the basic situation...
http://ip-208-080.oberlin.net/uBR.html
As usual, TIA for any info or insight.
Poge
Seems your running 64Qam on your downstream and hitting your max throughput. I would recommend trying 256Qam on your downstream and continue to monitor.
Thanks, Carl. Not sure 256QAM will play nice with an old Motorola C6U. Been searching for that answer to no avail so far. Also seems like I should still have some bandwidth wiggle room according to my math.
Also, does anyone know how to get line protocol up on the 2nd FE on a PA-2FE-FX add on module? First one comes up fine. The I/O Controller is a single FE and I could sure use a 3rd one to segregate some traffic onto a static route to a local college instead of running it out the "public" interface. Would free up around 24Mb of headroom on the main FE.
Poge
As to your bandwidth issue, what is your proc load? May be hitting a proc wall, my 7246 nonvxr/NPE225 with 40 megs of traffic is running 65-70% on the proc I have to imagine with 70 megs you are nearly maxing it out.
C6Us will most definitely work with qam256 and MC16Cs, We use them in our smaller systems all over the place.
never used a PA-2FE-FX but it should be simply
interface X/1
no shutdown
You may look into the dual FE I/O controller they can be had for cheap < $100 second hand. Or if you upgrade to a NPEG1 and a VXR they have 3 Gig interfaces on them.
I have a VXR loaded with MC28U's and a NPEG1 sitting here that I can't get fired up fast enough!!! Just tryng to put a finger in the dike until I can get it production ready. If you do any contracting on the side, I sure could use some help!
Will dbl chk proc load, but suspect you're right.
Thanks.
Poge
oberlin-uBR7246#sh proc
CPU utilization for five seconds: 99%/96%; one minute: 99%; five minutes: 99%
Ouch!
We recently activated the 4th MC16C to add a 2nd frequency pair hoping to ease some congestion on two of the other cards. Would we be better off processor-wise to go back to just 3 cards for the time being to ease the load on the NPE225 instead? Something tells me it's 6 of one, a 1/2 dozen of the other...
Grasping at straws now until I can get the VXR fired up.
Poge
The proc load is likely due to the amount of traffic (mostly number of packets) having fewer blades probably won't help you....
what IOS are you running? you may be able to do policing during peak times which may knock your processing load down a bit and allow a bit more traffic or more of your customers to use what traffic you can use.
the config for that looks like this assuming docsis 1.1+
cable qos enforce-rule D11_HS2
monitoring-basics peak-offpeak docsis11
penalty-period 120
service-class registered D_HS2
service-class enforced D_HSR1
peak-time1 17 d 120 avg 1500 peak-time2 19 d 120 avg 1500 d 240 avg 1500 sa 15 do enf
weekend peak-time1 16 d 120 avg 1500 peak-time2 18 d 120 avg 1500 d 240 avg 1500 sa 15 do enf
enabled
you can set two weekday peak-times and 2 weekend peak times and grab the top talkers and lock them down when your busy. This can help at least give everyone a chance to get on at peak time. But it really only works to a point, whether your beyond that or not is the question.
I may be available for some consulting after the new year but extremely busy till then.
oberlin-uBR7246#sh ver
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (UBR7200-IK8SU2-M), Version 12.3(23)BC7, RELEASE SOFTWARE (fc1)
Thanks for the suggestion and example. Converting to a VXR w/G1 is now the plan that makes the most sense for the time and effort required to handle the immediate problem..., not to mention providing tons of additional flexibility when we add the 2nd one..., hopefully sooner than later. The only thing I have going for me right now is that Winter Break starts this weekend which will knock all the college student traffic down to a bare minimum for a little more processor breathing room.
And if you can indeed find the time to provide some official consulting, please contact me at pogeatoberlindotnet to kick it around. I certainly appreciate the consideration and obviously need the expertise as I move further along with all this.
TIA.
Poge
...due to the non-VXR finally falling over right before the holidays.
Proc load now around 30%, but a few other peculiarities have been encountered since the hardware switch.
Previous setup was NPE225 w/single FE for the public GW interface with an additional PA-2FEISL-TX dual FE port adaptor for the private CMTS side of things -- including the snmp management and monitoring stuff. New setup is just the G1 with the three gigE ports and no additional port adaptors. I'm using the first one for the public GW interface and the second one for the CMTS stuff now.
The first main issue is the private network monitoring activity arbitrarily stops and requires a physical reset of the subnet mask on the monitoring machine's interface to resume seeing traffic. A second monitoring machine no longer sees any traffic from the same network. Cabling and configuration haven't changed on these machines -- only the CMTS port has changed. The easy fix was to hopefully just install the PA-2FEISL-TX into the VXR cage, replicate the previous config for it, and head on down the road. Unfortunately, the VXR chassis doesn't see it -- presumably since there's no additional "legacy" I/O controller as was present in the NPE225 setup. So back to figuring out why the ICMP and SNMP traffic on the 2nd gigE port just goes south and needs a jump start -- even though the provisioning server and related processes on the same interface are unaffected. I've played with the speed/duplex/auto settings on all involved interfaces with no luck and am back to fixed 100/full on everything which is where it all was in the previous setup.
Second issue is with our MRTG monitoring setup. Previous setup worked as expected for seeing all RF interfaces on Bundle1. Same batch of MC16C's in the new chassis with the same bundle configuration only shows the interfaces of the first blade. I've re-walked it a dozen times with MRTG and get the same results each time.
Any tips, suggestions, or insight will certainly be gratefully appreciated as usual!
TIA
Poge
first main issue -- sounds like a routing or routing protocol prob (e.g. ospf) Or possibly subnet mismatch
second issue: Most likely due to the SNMP ifIndex changing from cmts to cmts. You can either re add the device to MRTG this should discover the new interface ifIndexes, or if you want to keep the history from the old cmts to the new, you can change the ifIndex on the CMTS to match your old setup. You would need to know what the old ifindex was to make that happen.