Priscilla, Your exactly correct on sub-interfaces. We use a separate subnet for Voice eq. and we configured our primary DHCP server that is on the first sub interface to hand out those address's. The Router ( in our case a 4006 ) will substitute the sub-interface address.
You can actually do some debugs of dhcp server ( even though the router isn't running dhcp ) and see the progression take place. Same thing with debug ip packet against an access-list. Thanks Larry -----Original Message----- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 3:11 PM To: [EMAIL PROTECTED] Subject: Re: Secondary IP Addresses [7:58498] 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=58579&t=58498 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
