Hi every body!
<br />I just want to discuss one line from cisco side and its logic.
<br />"When IP source guard with source IP and MAC address filtering is enabled, the switch filters IP and non-IP traffic. If the source MAC address of an IP or non-IP packet matches a valid IP source binding, the switch forwards the packet. The switch drops all other types of packets except DHCP packets"
<br />The question is if switch does allow dhcp traffic while block others which does not match the src ip or mac or both, then the whole concept of RFC 3046( option 82) is lost.
<br />One of the reasons that was addressed in the rfc ,was how to stop depletion of ip addresses by rogue host who spoofs mac addresses.
<br />just to make my point, please consider the following example.
<br />assume dhcp snooping and ip source guard are in use. Now i replace h1 by a rogue h2.According to the quote above, dhcp request from h2 will be allowed. H2 ended up getting an ip address, again h2 spoofed a mac address and got another ip address from the server , h2 continue to spoof mac address and keep getting ip address. Soon the server has no ip address left to assign. Though a rfc 3046(option 82) did suggest that dhcp server can implement a policy to restrict the number of ip address assigned to each port on the relay agent, but rfc 3046 does not require it.An implementation that did not implement this suggestion is open for Ip address depletion issue by rogue host.
<br />I think if we block any traffic be it dhcp or otherwise which does not match the src and mac in snooping database for the port ,( but making a provision that packet with src ip 0.0.0.0 but matching mac will pass, the rational is when h1, a genuine host boots up, it will send dhcp req with src ip 0.0.0.0 )
<br />For example, in our case when h2 tried to get ip address from server, this traffic could have been blocked on the port by ip source guard feature. I don't understand why Cisco did not implement this.
<br />Any input will be appreciated.
<br />thanks a lot!