Ah, ok. I think I see some of the confusion. Recall that one can configure sub-interfaces with secondaries:
int ethernet 4/0.10 ip address 1.2.3.1 255.255.255.0 ip address 2.3.4.1 255.255.255.0 secondary ip helper-address 99.88.77.66 int ethernet 4/0.20 ip address 3.4.5.1 255.255.255.0 ip address 4.5.6.1 255.255.255.0 ip helper-address 55.66.77.88 So the VLAN and trunking will bring a packet (DHCP broadcast as well) into the right sub-interface. If there's a single subnet on the sub-interface, then there should be a single (respective) scope on the DHCP server. If there's more than one subnet on the sub-interface, then DHCP server will need to know which secondary scopes are associated with the giaddr. Of course, if all of this seems like a major hassle, you could upgrade to 12.2 and use the "ip dhcp smart-relay" command. This command is suited to an environment where the (sub-)interface has secondaries and one doesn't want to have to configure the secondary to primary relationship on the DHCP server. When a DHCP device performs DHCP for the first time, it's DISCOVER will get helpered with the giaddr set to the primary interface IP. If the client tries 3 times and gets no DHCP OFFER, the 4th time the client sends its DHCP DISCOVER, the router will set the giaddr to one of the secondary IPs. This cycling through secondaries as giaddrs continues forever or until the DHCP server responds with an OFFER. Note, it will take some time for some clients to get an IP as they go through multiple DISCOVERs until they get an IP address. In an enterprise environment, I'd expect this would mainly kick in when the primary subnet has no free IPs on the primary subnet, and hence no OFFERs are made, and so devices would roll onto a secondary subnet. Priscilla Oppenheimer wrote: > > Thanks for all the info p b. It's very helpful. > > Regarding the first situation, where the DHCP server is on > another segment and we're using a helper address to get the > requests over to the server: > > We have established that if you use secondaries, the router > puts its primary address into the giaddr field. I can see how > that might not be a problem in some situations and could work > well with a server with multiple scopes. As you mentioned, when > increasing the original address space, multiple scopes work well. > > How about subinterfaces, though? I was under the impression > that in that case, the router inserts the address of the > subinterface. That way the DHCP server assigns an address in > the right scope/subnet. This is helpful when devices are > divided up into VLANs/subnets and you want to make sure a > device in a particular VLAN ends up with an IP address for the > subnet associated with the VLAN. If that's your goal, then you > want to use subinterfaces. Secondaries don't work because of > the issue with the router putting in its primary address only. > > But I may be making assumptions about the behavoir with > subinterfaces. Let me know if I'm confused. Thanks! > > Priscilla > > p b wrote: > > > > > > Argh. Tab and return doesn't work well in when posting > through > > the web page.... > > > > Let me revise the last part of my message: > > > > If the interface (or sub-interface) looks like: > > > > int ethernet 4/0.42 > > ip address 10.0.1.1 255.255.255.0 > > ip address 10.0.2.1 255.255.255.0 sec > > ip address 10.0.3.1 255.255.255.0 sec > > > > Your scope logic in the DHCP server would look something like: > > > > scope_10.0.1.0: > etc.)> > > scope_10.0.2.0: primary-scope=scope_10.0.1.0 > details> > > scope_10.0.3.0: primary-scope=scope_10.0.1.0 > details> > > > > So when the DHCP packet arrived with the giaddr 10.0.1.1, it > > would > > match the "scope_10.0.1.0". The DHCP server would be able to > > determine that there are really three scopes which might apply > > to > > this request. > > > > Now, if one had secondaries on an interface (or sub-int) and > > wanted to vector a device (or particular types of devices) > > to a particular secondary, one needs to provide the DHCP > server > > with more information in order to make the right scope > selection > > decision. > > > > There are several places where this additional information > > might be found: > > > > - on the DHCP server. One might encode MAC addresses of the > > devices in the DHCP server and specify a "tag" value > > for this device. Scopes would also have tags and > > a device's DHCP request could only match a scope of their > > respective tags matched. Encoding MACs is nasty. > > > > - look at the DHCP information provided by the client. The > > client device might encode information in its DHCP packet > > which the DHCP server can use to help make a scope selection > > decision (see DHCP Option 60 and many others). > > > > - look at the DHCP information inserted by the router when the > > packet was relayed. In certain environments, the router will > > insert special DHCP options (see DHCP Option 82) which the > DHCP > > server can use to determine the type of device and hence > > appropriate scope. > > > > Regarding the question about what happens if the DHCP server > > is on the same ethernet segement as your clients. I've > > never run this configuration. A couple of thoughts on this: > > > > * This must be a single network as I don't think you'd want to > > have the DHCP server physically connected to each ethernet > > segment where DHCP services are being provided. > > > > * As soon as one wanted to support a second interface (and > > thus different set of interface and DHCP addresses) you'd need > > to move to a model where there is a giaddr. Otherwise, the > > DHCP server would not have sufficient info to pick an > > appropriate > > address. > > > > * I'd move the DHCP server onto its own subnet and use > helpering > > and the giaddr approach. > > > > > > > > > > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=58584&t=58498 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
