Subject pretty much sums it up.
Have our initial uBR w/NPE-G1 and four MC16C's at the wall of the MC16's capabilities during peak usage periods. Have a 2nd uBR w/NPE-G1 and four MC28U's wired up and sitting in the wings ready to go -- more or less. Also have four more MC28U's ready to put into the 1st uBR when I get the 2nd one fired up.
So the MC16's are bundled on uBR #1 at 10.1.0.1 with secondary gateways to all the public IP space (5 /24's at present), etc. The DHCP server talks to uBR #1 on a secondary FE at 10.10.1.1. Cable modems on the 10.1.0.0 /16 network are assigned static addresses and CPE addresses are dynamically assigned. Two frequency pairs are spread across the MC16's with the downstreams specifically included in the CM config files to force the modems to the desired RF portion of the network on any given node. (In other words, essentially a poor man's node split.)
The MC28U's are bundled on uBR #2 at 10.100.0.1, currently with no secondary gateways applied since I'm not quite sure how to make that part fly yet. The DHCP server talks to uBR #2 on one of the GigE ports at 10.10.1.2. The MC28's will operate on yet a third (and probably a fourth as well) frequency pair to facilitate yet another "node spit" or "frequency stack", or whatever one wants to call it, but you get the idea....eliminating congestion on both upstreams and downstream by simply adding more of them to the network.
I have both the 10.1.0.0 and 10.100.0.0 networks declared in my shared-network portion of dhcpd.conf.
A modem configured for this third RF downstream does what its supposed to do according to the frequency specified in the config file and registers on uBR #2, but the discover and offer to pull the config file itself from the server is still happening on the 10.1.0.0 network of uBR #1, hence not achieving online status. That's issue number one.
Issue number two is the secondary gateways on the bundle of uBR #2 to facilitate utilization of existing address inventory for CPE assignment, but first things first...
I presume my main issue lies somewhere in my dhcpd.conf, or there's a way easier way to do all of this that I obviously have no clue about whatsoever.
Any and all assistance gratefully appreciated as usual.
Poge
A few questions for you:
0. Do you have one node (or trunk and feeder) or multiple nodes?
1. Why don't you use load balancing instead of forcing the CM to one frequency or another?
2. Why are you statically assigning CM ips?
what you should definitely look into is docsis load-balancing kind of a pain to setup but it works well. You need a 12.2 code to use it though, so that means it will only work with G1/MC28Us or better. Sounds like that wont be an issue.
This assumes you have the system broken into manageable nodes/trunks
each node/group of nodes can be setup like so
c3/0
U0 Node 1 freq 1
U1 Node 2 freq 1
U2 Node 3 freq 1
U3 Node 4 freq 1
c3/1
U0 Node 1 freq 2
U1 Node 2 freq 2
U2 Node 3 freq 2
U3 Node 4 freq 2
cable load-balance docsis-group 300
downstream Cable3/0
downstream Cable3/1
upstream Cable3/0 0
upstream Cable3/1 0
threshold load minimum 1
policy pure-ds-load
docsis-policy 100
!
!
so on each node you will have 2 Downstreams and two upstreams that will be load-balanced by downstream bandwidth utilization.
you could also do it like so
c3/0
U0 Node 1 freq 1
U1 Node 1 freq 2
U2 Node 2 freq 1
U3 Node 2 freq 2
c3/1
U0 Node 1 freq 3
U1 Node 1 freq 4
U2 Node 2 freq 3
U3 Node 2 freq 4
the docsis load balance setup for this would be
cable load-balance docsis-group 300
downstream Cable3/0
downstream Cable3/1
upstream Cable3/0 0
upstream Cable3/0 1
upstream Cable3/1 0
upstream Cable3/1 1
threshold load minimum 1
policy pure-ds-load
docsis-policy 100
!
!
This way you have 2 DS and 4 US for each node balanced by Downstream bandwidth.
on ubr 1
interface bundle 1
ip address 10.1.0.1 255.255.0.0
ip address xxx.xxx.1.1 255.255.255.0
ip address xxx.xxx.2.1 255.255.255.0
! cable load-balance commands
!
cable load-balance docsis-enable
cable load-balance rule 1 enabled
cable load-balance docsis-policy 100 rule 1
on ubr 2
interface bundle 1
ip address 10.100.0.1 255.255.0.0
ip address xxx.xxx.3.1 255.255.255.0
ip address xxx.xxx.4.1 255.255.255.0
ip address xxx.xxx.5.1 255.255.255.0
! cable load-balance commands
!
cable load-balance docsis-enable
cable load-balance rule 1 enabled
cable load-balance docsis-policy 100 rule 1
on the dhcp server you will need two shared networks
class "CM" {
# only match if first 6 chars of option 61 are docsis
match if (substring(option vendor-class-identifier,0,6) = "docsis");
spawn with hardware;
}
class "MTA" {
# only match if first 4 chars of option 61 are pktc
match if (substring(option vendor-class-identifier,0,4) = "pktc");
spawn with hardware;
}
# Anything but a modem or an MTA
class "PC" {
match if ((substring(option vendor-class-identifier,0,6) != "docsis") and (substring(option vendor-class-identifier,0,4) != "pktc"));
spawn with hardware;
}
shared-network ubr1 {
subnet 10.1.0.0 netmask 255.255.0.0 {
#specific info for modems
pool {
#range statement
allow members of "CM";
deny members of "PC";
deny members of "MTA";
}
}
subnet xxx.xxx.1.0 netmask 255.255.255.0 {
#cpe specific info
pool {
#range statement
allow members of "PC";
allow members of "MTA";
deny members of "CM";
}
}
subnet xxx.xxx.2.0 netmask 255.255.255.0 {
#cpe specific info
pool {
#range statement
allow members of "PC";
allow members of "MTA";
deny members of "CM";
}
}
}
shared-network ubr2 {
subnet 10.100.0.0 netmask 255.255.0.0 {
#specific info for modems
pool {
#range statement
allow members of "CM";
deny members of "PC";
deny members of "MTA";
}
}
subnet xxx.xxx.3.0 netmask 255.255.255.0 {
#cpe specific info
pool {
#range statement
allow members of "PC";
allow members of "MTA";
deny members of "CM";
}
}
subnet xxx.xxx.4.0 netmask 255.255.255.0 {
#cpe specific info
pool {
#range statement
allow members of "PC";
allow members of "MTA";
deny members of "CM";
}
}
subnet xxx.xxx.5.0 netmask 255.255.255.0 {
#cpe specific info
pool {
#range statement
allow members of "PC";
allow members of "MTA";
deny members of "CM";
}
}
}
moving Ips around for clients is never fun, but short of moving to a new chassis that can handle all your customers i.e. 7246 vxr w G2 and MC88V blades or Ubr10k it is a necessary step.
We have 19 nodes plus a central coax-only segment, so basically, a 20 node HFC architecture with a 1 to 4 laser to node ratio with 1 to 1 return receivers for just a little over 50 strand miles of plant.
The load balancing certainly seems like a more elegant solution than the brute force approach I seem to be attempting, but we're learning by the seat of our pants here and simply applying the same basic techniques as have been in place for years and which have actually been the very reason we were able to get away with the legacy gear for so long. And we just don't know any better, hence my leaning on you folks for a little more help at this newest juncture of our ongoing adventures. That stated, the main requirement at this time is to get the second uBR online to relieve the congestion on the first one so we can migrate further into the process and to actually have the inherent flexibility and advanced features available in a dual CMTS environment.
As for statics on the modems, we've always done it that way and that's how we map and graph and cross-index and search and name and...works for us and SNMPc likes it that way, too. (see attached)
But back to the load balancing. I'm running 12.3(23)BC7, but can't apply the DOCSIS load balancing to a VXR G1 w/MC16C's anyway if I understand correctly. (And I presume the DOCSIS load balancing is DOCSIS version agnostic and applies to the CMTS itself rather than D1.x, D2.0, etc.? I'm still just D1.0.)
So that brings me back full circle to what appears to be the immediate issue, which is how my shared network is set up (or not) and how to get a modem online that is brute-force directed to the downstream frequencies of a second uBR. In the example provided, it looks like my problem may be in trying to include the second uBR in the existing shared network when it indeed should exist in a second shared network? I've tried a couple of variations of that, but break dhcpd and it complains about shared networks not being allowed where I'm attempting to add the second one. And as mentioned, a modem will lock and register on the second uBR as desired with the discover getting to the server, but the offer wants to use the first uBR's subnet to get back to it.
I also presume that the existing batch of /24's and respective gateways as secondary addresses on the bundle on the 1st uBR won't fly on the second uBR and I'll need to dedicate additional address space and respective secondary gateways to the second uBR -- or possibly NAT while recovering the remainder of my last two /24's still assigned to legacy modem subscribers? (I think I get that part.)
I'd be more than happy to post any config snippets of either of the uBR's or my dhcpd.conf for digestion if that would help the cause.
I am extremely grateful for the help.
Poge
if you have two ubr's you are going to need two different shared networks for sure, I always put the whole shared-network stanza at the root of the file rather than in a group or something like that. Each shared network should have a Modem subnet and client subnet(s). You don't neccessarily need more client IP space but you will at the least have to split it between the two CMTSes.
If you get your shared network right you should be able to force modems to the second UBR but without additional IP space the clients won't be able to get IPs. The example I gave in the first reply is how the shared networks should be set up.
The docsis load-balancing is indeed docsis version nuetral.
If it were me doing this, I would
- Upgrade my new UBR with MC28U blades to 12.2 code train so that you can use whatever features you would like.
- Migrate all your modems to the new CMTS using load balancing, in one swoop and then discconnect old cmts
- Upgrade your older cmts to 12.2 and add the MC28U blades you have
- Split your nodes between the two CMTSes half of the nodes on one CMTS half on the Other.
With 32 upstreams on a CMTS you would only have to combine 8 nodes upstreams together until you got both CMTSes online then each node could have 2 upstreams itself without any upstrream combining.
If you would like some assistance getting things going contact me at jasonp <> cablemo <> com and I can give you a hand.
* I suggest to you, to configure the new CMTS with MC28 cards, and remove the old CMTS at all. you should do that late at night (try to connect modems to the CMTS in a lab) then put it in the system.
when you upgrade you old CMTS with new cards, you can put it back into the system.
*I had recently the same situation, i used 2 CMTS's one with MC28 and one with MC16, and worked fine, but later i just removed the MC16 Cards and use the new newest one, just reconfigured the CMTS with G1&MC28.
don't change any thing in the DHCP server and tftboot.
Regards
Thank you for the gracious offer. I don't think it will take much to get us pointed in the right direction. I'll compile a few tid-bits of configs and shoot them your way for review....and probably a few chuckles, too!
Poge
The only problem when using load-balancing is when you have HFC network, the combination of Coaxial network and Fiber (nodes) will make the noise moving from one upstream to another, and he will have the noise on all upstreams.
i suggest this variant of balancing when have only nodes connected to the CMTS.
the bundle setup which kwesibrunee suggest is correct and will do it fine.
the modems using static ip's is good, i also use that, so i have all graphs for my modems.
regards