I reserve a small number of addresses in each of my DHCP public subnet pools for static assignments to businesses, etc. How do I prohibit a user from hijacking one of these unused addresses and simply plugging it into their setup? I presume it's a very simple class definition/designation and then applied to the host entry?
Could also use some help with a migration path to a third uBR and D2 from our humble little D1 setup using a pair of uBR's currently. D3 won't be in the cards for me until next year, so I need to make do with what I have for now.
'Preciate all the help I can get, gang.
TIA
Hi,
I'm not 100% sure on the ip to CPE verification. Ill have to pull my books out and do some reading.
As for the docsis migration, what do you currently have "cmts / line cards / CPU"and what will you be going to?
We currently have a pair of uBR7246 VXR G-1's loaded w/MC28U's. Each is on a separate pair of up/down frequencies as a poor man's node splitting technique and each is provisioned via its own dedicated server with our public address space spread across the two in /24 chunks. We assign fixed addresses to the modems for easy mapping and identification purposes and also use a rather caveman approach for determining which network a modem will be on. The "A" network is our default on a 10.1.0.0/16. Our "B" network is at 10.11.0.0/16. We have both "A" and "B" config files for the modems, each specifying the downstream freq for the respective networks via the "A" server. Modem comes up just long enough on the "A" network using a 10.1.x.x to receive the "B" config file and then re-registers appropriately via the "B" server and receives its permanent 10.11.x.x address and heads on down the road on the "B" network happily everafter unless being told to go back to the "A" network. Granted, I have to maintain a host entry on each server, but once the initial administration was completed, it's been cake to maintain since. All of that stated, there is obviously quite a bit of headroom and flexibility in our particular situation as we only have around 1600 modems spread across 20 nodes at present. Problem is, our top end LOS is only a 6Mb offering right now and the LEC is almost giving away 12~20Mbps service by comparison and we need to ramp up our offerings significantly. We are also in a bandwidth hungry college town and serve approximately 70 off campus housing co-op's and they're in need of more throughput in general. That's where the 3rd uBR comes into play and will also represent yet a "C" network option for special cases and any overflow conditions from the "A" and "B" networks.
Clear as mud?
psmit
Ok.... First question I have then for you would be...
1) What are your reasons for moving to D2 over D1.x? D2 added advantages in the Upstream direction.
If your looking at increasing your download speed D3 would really be your best bet. Not only does it offer aggregated bandwidth, but also offer's better load balance of D1.x/2 modems
Now 20Mbps service isnt out of the question on the "1" 256QAM channel, but you will have to watch for congestion. It will quickly overtake your port. Now going by your numbers it looks like your avg modem count per node would be "80". This is relatively low which is a good thing! In your situation you could almost do a 1:1 wire mode "1 downstream 1 upstream" or "1 Mac Domain" per node adding up to 20 DS ports or 10 MC28/U cards. But it sounds like you want the option to move CM's from one channel to another. You may also want to look into Dynamic Channel Change. I myself have not played with this feature but I have had a few friends say its a pre D3 for D1.x systems. It allows for the cmts to send a request to the modem to change DS freq under predefined conditions, such as interface load or modem count.
With regards to stopping customers from hard-coding a IP they are not entitled to, you could do stuff like :
Have a look at "cable source-verify dhcp"
http://www.cisco.com/en/US/tech/tk86/tk803/technologies_tech_note09186a0...
or I guess you could possibly write some scripts to periodically audit the ARP table on the CMTS and report any discrepancies relating to the static ranges. Contact any customers who are doing a shonk. If the offending customer refuses to remove the shonk then you you can disconnect their modem.
So you are running out of DS capacity? Sounds like you probably have enough US?
Adding another D2 CMTS will obviously help a bit, but as you have seen, things will get increasing complex as you try to manually juggle customers between different CMTS / frequencies.
D3 is the ideal solution here as each linecard will typically have 4X the DS capacity of a D2 card (Rather than a 2x8 card, you will get 8x8. Rather than 5x20, you will get 20x20).
Being able to run one high capacity chassis rather than multiple smaller CMTS also makes features like cable modem load-balance work very effectively at automatically spreading modems evenly across DS and US interfaces (rather than you have to manually juggle it).
I know you said that D3 was not possible right now, but I reckon you should reconsider that. Don't buy another D2 chassis, spending money there just isn't good value any more.
There may also be other ways to free up some capacity on your current network :
* Are you running 256QAM on the DS? If not, you should look into this.
* Cisco has a feature called "subscriber traffic management". This is a sliding window arrangement for monitoring traffic flows. If a user exceeds your chosen thresholds it will temporarily slow them down.
* Have you thought about using different priorities for different types of customers? Eg you might setup your config files so that business customers get cable qos priority 2, residential customers get priority 1, and then maybe use some scripts to identify any users exceeding some arbitrary monthly traffic limit and at that point switch them to priority 0.... or apply some sort of slower rate-limit..... or cancel their account (A lot of ISPs would never consider cancelling a customer account, but really they should. If you have some massive leecher that is killing the network for everyone else, why would you want to hang onto them? They are causing you to lose money... get rid of them!).
Hi Mbowe,
Do you have some example of the configuration D1.x and D3 to the ubr10k?
I didn't have the luxury of being able to run the "cable source verify" since I was using ISC DHCP and CIsco DHCP lease query didn't follow the RFC (http://www.docsis.org/node/568). So my solution was to set aside the first ~10 usable addresses out of a CPE pool with the range statement, then assign statics based on a "host entry" in ISC. Then I would apply an ACL to block all traffic to the 10 addresses unless I assigned it to a customer. Again not ideal and only stops a host from using a free address, not stopping a host from grabbing an IP already assigned. But Cisco shouldn't let a "known IP" behind a different modem unless cleared on the CLI or the CPE database timer expires(24 hours IIRC).
Thanks for the responses and the link. Seems as though the latter may be what I'm looking for re: the address security issue, though there seem to be a few caveats associated with the method..., or were? After some reading, I'm still unclear on whether the initial Cisco RFC discrepency has been resolved to the extent that "cable source-verify dhcp" now properly functions with ISC DHCPD (I'm still using V3.0.5, btw), and if it does, whether or not the functionality needs to be enabled in the dhcpd.conf file. (I tried adding it to my bundles alone and immediately began receiving call volume about no connectivity.)
As for my D2.0 implementation, I've always been under the impression that throughput was increased in both directions from the D1.x standard, which was clearly a misconception. That stated, I'll be damned if I didn't get 19.62Mbps out of a SB5120 just now, but still can't seem to break the 1.8Mbps barrier up in a D.1 environment. I'll certainly admit to not being the best study on DOCSIS and have learned most of what I know right here, but am getting more comfortable about exploring the more subtle aspects and tweaks to get the most out of what's currently at my disposal hardware-wise until D3-Day rolls around.
We are running 256QAM on our downstreams and I do have prioritzation in my modem config files, but no other traffic management stuff in place at present. Plenty of upstream headroom, but am pushing it on a few of my downstreams, though no flatlining yet. A few 20meg customers will take care of that, I'm sure.
It seems like the flow classifications in D2.0 offer extensive flexibility over D1.0 when it comes to managing traffic and is probably the most attractive aspect of the whole migration idea. Implementation looks pretty klunky, but I'm guessing the same format is essentially the way D3.0 works anyway, so why not get my feet wet with the process ahead of time rather than having a steeper learning curve when the time comes?
And bear in mind, gang..., I just decommissioned the last of my Gen3 Legacy LANcity modems last November and am still learning DOCSIS by the seat o' the pants!!! But if it weren't fun...
Thanks again for your help.
psmit
I have used DHCPD with "cable source-verify" without problem. Moving your upstreams over to D2 is not a bad idea if all your modems on that upstream are D2 ready. Use "show cable modem mac summary" to find out. Also before moving to D2 make sure your upstreams are clean! If your going to run 64QAM on a 6.4Mhz return you'll need it tight out in the field. As for your upstream bandwidth capping at 1.8Mbps, what settings are you running? I have been able to push D1 return's over 3Mbps with little tweaks. D2 goes well over 5.5Mbps on the same settings.
As a side note you can run both D1.1 and D2 over the same upstream. Wont give you much of an improvement but still allows the D2 modems to modulate out on a D2 setup. Plus there is no investment "CMTS wise" that is needed to upgrade to D2 with your setup. I would also look into Load Balance on the DS side. This basically does what your doing with 2 DS Freq, but will auto balance to modems across the 2 without having to change configs. Let me know about your current upstream settings and I'll see what I can do to help :)
It appears that leasequery support wasn't introduced into dhcpd functionality until V3.1 and I'm still at 3.0.5. I obviously need an upgrade there before I can implement it on the uBR effectively. And I presume when the reference to "the master interface" is made re: where to ad the "cable source-verify dhcp" entry for a bundle, it means the actual line card itself vs. say, the Bundle 1 interface, correct? It also appears that "allow leasequery;" indeed needs to be included in dhcpd.conf to enable the functionality...and I presume just as a global declaration?
'Preciate the help.
cable source-verify goes on the bundle interface, or wherever you have your IPs.
in dhcpd.conf yes allow leasequery; is a global declaration.
Please note that prior to IOS 12.2.33 SCG Cisco uses a proprietary version of leasequery that is incapatable with dhcpd. After 12.2.33 scg you can use the RFC version of leasequery which will work with dhcpd.
I trust 12.3(23)BC7 supports leasequery, then? And should I be prepared for any surprises upgrading from dhcp-3.0.5 dirctly to 4.1.1-24?
And the reason I asked about the placement of the source-verify line is due to a rather ambiguous statement in a tech note on the subject which seemed to suggest that in a bundled situation the entry should be associated with the actual master hardware interface (e.g. C3/0) vs. the virtual "bundle" interface. All I know is that when I applied it to the Bundle 1 config we began receiving call volume about connectivity problems until I removed the entry. Could it have been the lack of support in V3.0.5 of dhcpd causing the problem instead? Doesn't seem like it would since dhcpd would have no knowledge of the query packet even being present in the first place.
As usual, TIA for the input and assistance.
the 12.3 ios Train is no longer being developed, it does support leasequery but only the cisco propriatary one, which does not work with dhcpd only cisco cnr.
the 12.2 train is the only one being developed by cisco, it will work on 7246 hardware with NPE g1 or greater and MC28U or greater, will not work with any older cards.
the way source-verify works is if the CMTS does not see a dhcp request/offer/ack from a CPE it will not pass traffic. this is why when turning it on you had customers unable to connect the CMTS did not see any dhcp traffic and received no answer when it sent a leasequery.
dhcpd 4.x.x should work the same as 3.x.x should be pretty painless.
Gotcha. They're counting backwards now. What is the prefered 12.2 release?
Is 12.2(33)SCG5 the way to go?
So does 12.2(33)SCF5 properly support RFC 4388? It appears that 12.2(33)SCG and SCH require a NPE G2 and the latest 12.2 release for G1's is SCF5.
TIA for any clarification.
New Software Features in Cisco IOS Release 12.2(33)SCE1
This section lists the new features in Cisco IOS Release 12.2(33)SCE1.
RFC4388 Compliance DHCP Lease Query
In addition to Cisco standard compliant DHCP LEASEQUERY, Cisco CMTS now also supports RFC 4388 standard compliant DHCP LEASEQUERY. These two standards differ mostly in the identifiers used to query or respond to the DHCP Server. You can choose between these two implementations depending on which standard is supported on your DHCP Server.
The ip dhcp compatibility lease-query client command is modified.
For more information about this feature, see Filtering Cable DHCP Lease Queries on Cisco CMTS Routers guide at the following URL:
http://www.cisco.com/en/US/docs/ios/cable/configuration/guide/cmts_flt_d...
Modified Software Features in Cisco IOS Release 12.2(33)SCE1
There are no modified software features in Cisco IOS Release 12.2(33)SCE1.
It also looks like they removed G1 support from SCF and greater IOS images.
I really appreciate the help. Thank you.