Re: Secondary IP Addresses [7:58498]
Priscilla Oppenheimer wrote: p b wrote: Actually using secondaries and DHCP should be a non issue with any reasonable DHCP server platform. As you mention, in many versions of IOS the interface's primary IP address is used as the DHCP giaddr. If an interface has multiple secondaries, one just needs to configure the DHCP server to be aware that there are multiple scopes associated with the giaddr. But how does the server know which scope to use for the incoming requests when they all have the same giaddr? Priscilla Well, if you're going to put secondaries on an interface (physical or sub-interface), one could make the assumption that all relayed DHCP requests from that interface should be treated equally. Which means when the DHCP server gets the DHCP request, looks at the giaddr, sees there are multiple scopes associated with the giaddr, all of which *may be* applicable, and then assigns an IP address from one of the scopes to the end device. Now, if you wanted to segment end-users by function to a particular subnet, one could use sub-interfaces and then VLAN tag ports on the switch to correlate sub's traffic to a particular sub-interface. That's fine. But if you've initially assigned a /25 to the sub-interface and now need to grow it, you've got two options: a) replace the primary subnet with a larger block, which means replacing the primary on the sub-interface, renumber all the users, and update the DHCP server, or b) add a secondary block onto the sub-interface and then define a second scope on the DHCP server and related it back to the primary scope. Using this approach, there's no need to renumber. And if you find out you need to support 180 users, you could drop in a /26 to complement the /25. While you're making the changes, there's no impact to existing users on the interface. If you go option a), you'll need a /24 and lose some addressing efficiency. Option b) seems the way to go, but requires that the DHCP server support the concept of relating secondary scopes back to a primary. CNR supports this mechanism via the primary-scope construct. If your interface looks like: scope_10.0.1.0: scope details scope_10. 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. A sub-interface doesn't help There might be information supplied in the DHCP packet by the client to help identify the type of device, or DHCP information might be inserted by the Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58541t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
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: scope_10.0.2.0: primary-scope=scope_10.0.1.0 scope_10.0.3.0: primary-scope=scope_10.0.1.0 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=7i=58542t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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=7i=58565t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Secondary IP Addresses [7:58498]
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=7i=58578t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Secondary IP Addresses [7:58498]
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=7i=58579t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
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
RE: Secondary IP Addresses [7:58498]
I have just been having an argument about this with some colleagues. Nice to know that I was right. I had to prove this to them on a working environment before they would believe this. Thanks! Andrew -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 04 December 2002 22:11 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=7i=58603t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
Secondarys will really hurt you in a DHCP environment. The workstations on the secondary subnet will get their DHCP request forwarded with a source segment of the initial IP address on the interface. This was good ammo for me when I was in the same boat. HTH Darren At 10:52 PM 12/3/2002 +, Edward Sohn wrote: Thanks to all for the responses to my VPN connections. I have pretty much verified it will work in an active/failover setting... Now, I have an issue where I need to convince my customer that it's better to subinterface a fast ethernet port into two separate VLANs rather than add secondary IP addressing on the router. Now, from my understanding I thought that secondary IP addressing is traditionally not recommended. I thought I read somewhere that it creates instability for both networks and increases traffic. Now, I'm not certain, so correct me if I'm wrong. Thanks, Ed __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com + International Network Services Darren S. Crawford - CCNP, CCDP, CISSP Sr. Network Systems Consultant Northwest Region - Sacramento Office Voicemail (916) 859-5200 x310 Pager (800) 467-1467 mailto:[EMAIL PROTECTED] + Every Job is a Self-Portrait of the person Who Did It...Autograph Your Work With EXCELLENCE! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58503t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
Actually using secondaries and DHCP should be a non issue with any reasonable DHCP server platform. As you mention, in many versions of IOS the interface's primary IP address is used as the DHCP giaddr. If an interface has multiple secondaries, one just needs to configure the DHCP server to be aware that there are multiple scopes associated with the giaddr. The use of secondaries and the DHCP server logic to understand what scopes are associated with an interface is a useful feature when one might need to renumber users from one subnet to another. Or if one runs out of IP addresses on an existing subnet, one can simply add on a secondary subnet onto the interface and DHCP server without causing everyone to be renumbered. Darren S. Crawford wrote: Secondarys will really hurt you in a DHCP environment. The workstations on the secondary subnet will get their DHCP request forwarded with a source segment of the initial IP address on the interface. This was good ammo for me when I was in the same boat. HTH Darren At 10:52 PM 12/3/2002 +, Edward Sohn wrote: Thanks to all for the responses to my VPN connections. I have pretty much verified it will work in an active/failover setting... Now, I have an issue where I need to convince my customer that it's better to subinterface a fast ethernet port into two separate VLANs rather than add secondary IP addressing on the router. Now, from my understanding I thought that secondary IP addressing is traditionally not recommended. I thought I read somewhere that it creates instability for both networks and increases traffic. Now, I'm not certain, so correct me if I'm wrong. Thanks, Ed __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com + International Network Services Darren S. Crawford - CCNP, CCDP, CISSP Sr. Network Systems Consultant Northwest Region - Sacramento Office Voicemail (916) 859-5200 x310 Pager (800) 467-1467 mailto:[EMAIL PROTECTED] + Every Job is a Self-Portrait of the person Who Did It...Autograph Your Work With EXCELLENCE! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58507t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
p b wrote: Actually using secondaries and DHCP should be a non issue with any reasonable DHCP server platform. As you mention, in many versions of IOS the interface's primary IP address is used as the DHCP giaddr. If an interface has multiple secondaries, one just needs to configure the DHCP server to be aware that there are multiple scopes associated with the giaddr. But how does the server know which scope to use for the incoming requests when they all have the same giaddr? Priscilla The use of secondaries and the DHCP server logic to understand what scopes are associated with an interface is a useful feature when one might need to renumber users from one subnet to another. Or if one runs out of IP addresses on an existing subnet, one can simply add on a secondary subnet onto the interface and DHCP server without causing everyone to be renumbered. Darren S. Crawford wrote: Secondarys will really hurt you in a DHCP environment. The workstations on the secondary subnet will get their DHCP request forwarded with a source segment of the initial IP address on the interface. This was good ammo for me when I was in the same boat. HTH Darren At 10:52 PM 12/3/2002 +, Edward Sohn wrote: Thanks to all for the responses to my VPN connections. I have pretty much verified it will work in an active/failover setting... Now, I have an issue where I need to convince my customer that it's better to subinterface a fast ethernet port into two separate VLANs rather than add secondary IP addressing on the router. Now, from my understanding I thought that secondary IP addressing is traditionally not recommended. I thought I read somewhere that it creates instability for both networks and increases traffic. Now, I'm not certain, so correct me if I'm wrong. Thanks, Ed __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com + International Network Services Darren S. Crawford - CCNP, CCDP, CISSP Sr. Network Systems Consultant Northwest Region - Sacramento Office Voicemail (916) 859-5200 x310 Pager (800) 467-1467 mailto:[EMAIL PROTECTED] + Every Job is a Self-Portrait of the person Who Did It...Autograph Your Work With EXCELLENCE! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58513t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Secondary IP Addresses [7:58498]
How do you handle when the DHCP server is on the same subnet as the FE with multiple sub-interfaces ? The router never even gets to touch the packet and therefore the Server doesn't know to assign IP's from the secondary scope. Or at least that has been my experience. Im not going to touch the reasonable DHCP server platform statement. That sounds like an MS bashing in the waiting :) -Original Message- From: p b [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 7:22 PM To: [EMAIL PROTECTED] Subject: Re: Secondary IP Addresses [7:58498] Actually using secondaries and DHCP should be a non issue with any reasonable DHCP server platform. As you mention, in many versions of IOS the interface's primary IP address is used as the DHCP giaddr. If an interface has multiple secondaries, one just needs to configure the DHCP server to be aware that there are multiple scopes associated with the giaddr. The use of secondaries and the DHCP server logic to understand what scopes are associated with an interface is a useful feature when one might need to renumber users from one subnet to another. Or if one runs out of IP addresses on an existing subnet, one can simply add on a secondary subnet onto the interface and DHCP server without causing everyone to be renumbered. Darren S. Crawford wrote: Secondarys will really hurt you in a DHCP environment. The workstations on the secondary subnet will get their DHCP request forwarded with a source segment of the initial IP address on the interface. This was good ammo for me when I was in the same boat. HTH Darren At 10:52 PM 12/3/2002 +, Edward Sohn wrote: Thanks to all for the responses to my VPN connections. I have pretty much verified it will work in an active/failover setting... Now, I have an issue where I need to convince my customer that it's better to subinterface a fast ethernet port into two separate VLANs rather than add secondary IP addressing on the router. Now, from my understanding I thought that secondary IP addressing is traditionally not recommended. I thought I read somewhere that it creates instability for both networks and increases traffic. Now, I'm not certain, so correct me if I'm wrong. Thanks, Ed __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com + International Network Services Darren S. Crawford - CCNP, CCDP, CISSP Sr. Network Systems Consultant Northwest Region - Sacramento Office Voicemail (916) 859-5200 x310 Pager (800) 467-1467 mailto:[EMAIL PROTECTED] + Every Job is a Self-Portrait of the person Who Did It...Autograph Your Work With EXCELLENCE! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58514t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
