Yes, I assumed IOS DHCP server for Option A. If the DHCP server is non-IOS and doesn't support option 82 of 0.0.0.0, then you need to disable option 82 addition on the switch.
With regards Kings On Sun, Dec 5, 2010 at 1:01 AM, Mark Senteza <[email protected]>wrote: > Kings, > > thanks for further clarification. For Option A, are you assuming that the > DHCP server is an IOS DHCP Server ? If its not, then what would be the > workaround if the DHCP server doesnt support Option 82 ? > > In his scenario, the request was to check the source IP address field only > and he used option B, which is definitely inline with the confirmation you > got from him. > > Thanks alot > > Mark > > > On Sat, Dec 4, 2010 at 5:13 AM, Kingsley Charles < > [email protected]> wrote: > >> The option 82 is used to identify the subnet of the IP address which the >> DHCP server should lease. >> >> The Cisco switch adds giaddr of 0.0.0.0 which the IOS DHCP server doesn't >> accept. >> >> >> *Option A : *The workaround is to add the following on the server to >> accept the DHCP request with giaddr of 0.0.0.0 >> >> >> ip dhcp relay information trust-all (config mode) >> ip dhcp relay information trusted. (interface mode) >> >> >> *Option B :* Disable the dhcp option 82 addition using the following >> command: >> >> >> >> no ip dhcp snooping information option >> >> >> When you use DHCP snooping for IPSG with mac-address check, then "ip dhcp >> snooping information option" is required on the switch because when the >> switch gets the reply from the DHCP server, the switch will use option 82 to >> find the port to which the client is connected and forward the DHCP reply. >> >> Hence for DHCP snooping with IPSG of checking IP address alone, you can >> use either option A or B. >> >> For DHCP snooping with IPSG of checking IP address and MAC address (you >> need to enable switchport security), you should use option A only. This I >> got confirmation from Yusuf. >> >> >> >> With regards >> Kings >> >> On Sat, Dec 4, 2010 at 10:26 AM, Vybhav Ramachandran >> <[email protected]>wrote: >> >>> Hello Mark, >>> >>> By default , *ip dhcp snooping information option *is enabled when one >>> turns on DHCP snooping on a switch. Now, the issue with that, although the >>> switch here is NOT acting as a DHCP relay, it still inserts the Option-82 >>> field in the DHCP requests that it receives and sends it over to the DHCP >>> server. In this case, since the switch is NOT acting as a relay ,so it will >>> not modify the "giaddr" field that is present in the DHCP packet. This field >>> is meant only for DHCP relays to modify. >>> >>> Suppose, now you have an aggregation switch sitting in between our >>> earlier switch and the DHCP server . If the aggregation switch has DHCP >>> snooping enabled and if it receives a DHCP packet with the Option-82 field >>> set and with a GiADDR or 0.0.0.0 on an untrusted interface , it will drop >>> that packet. This i think is because the aggregation switch expects some >>> non-zero IP on the giaddr field. >>> >>> So , to prevent this >>> >>> 1) We can disable option-82 information addition by the remote switch. >>> This is using the *no ip dhcp snooping information option*. This way , >>> the chances of the DHCP packet getting dropped on it's way to the DHCP >>> server are less. >>> * >>> * >>> 2) If we really want the Option-82 information to be present in the DHCP >>> requests ( assuming that the DHCP server also supports option-82 based IP >>> address allocation ), then we can configure the aggregate switch to allow >>> Packets with a GiAddr of 0.0.0.0 by using the *ip dhcp snooping >>> information option allow-untrusted. * Now the aggregation switch also >>> learns about the DHCP Bindings . But this is not advisable because, this >>> could lead to the aggregation switch accepting packets with spoofed >>> Option-82 fields. >>> >>> Cheers, >>> TacACK >>> >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com >>> >>> >> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
