How is this different than using port security or ip source guard alone and why is option 82 required for this to work?
When you add the MAC address source filtering to IP source guard using the ip verify source port-security command, the client MAC address is not learned until it has obtained a DHCP lease. Until then, all non-IP traffic except for DHCP will also be blocked.
Since the switch won't learn the MAC address of the client until after it obtains a lease, this leads to a problem of how does the switch know where to send the return DHCP traffic from the server to the client? The information inserted by DHCP option 82 gives this information to the switch. However you do need to make sure your DHCP server then also supports option 82.
This may tie into the above question, but I also would like to know when does the MAC address table get updated with a MAC address when using these features?
This is very relevant to the preceeding question, so lets take a look at several different ways this is handled.
Lets first look at what happens with port security. Remember that port security works by looking at the source MAC address of the traffic and making a decision on what to do with it based on the interface configuration.
As an example, let's take three PC client devices (PC1 - 0001.0001.0001, PC2 - 0002.0002.0002, PC3 - 0003.0003.0003)and on a 3560G running 12.2(44)SE5 configure a switch interface with only port security enabled as below:
switchport port-security maximum 2
switchport port-security aging time 60
switchport port-security violation restrict
switchport port-security mac-address 0001.0001.0001 vlan access
PC1 is connected to the port first, it is given access and all traffic (L2 & L3) is allowed because it has a static port security configuration. The MAC address of PC1 is learned by the switch and inserted into the MAC address table.
We then disconnect PC1 and connect PC2. PC2 is given access and all traffic (L2 & L3) is allowed because port security on this interface allows two MAC address. One is statically configured for PC1, but no other static configurations exist, so PC2's MAC address is configured dynamically. The MAC address of PC2 is also learned by the switch and inserted into the MAC address table.
We now disconnect PC2 and immediately connect PC3. Because we have an aging time of 60 minutes configured, the interface will retain the MAC address of PC2 until 60 minutes have passed. So PC3 is not given access and all traffic is dropped (L2 & L3) as the interface already has two configured MAC address (one static for PC1 and one dyncamic for PC2). The MAC address of PC3 is not learned by the switch nor is it inserted into the MAC address table because all of it's traffic is being dropped (so there is no traffic from which to learn a source MAC address).
In the second example, let's use the same PCs, assume DHCP snooping is configured correctly, and only have IP source guard enabled on the interface as below:
ip verify source
When you connect any of the PCs (PC1, PC2, or PC3), the MAC address of the PC is learned by the switch and is inserted into the MAC address table. When the PC learns its IP address from a DHCP server or when there is a static IP binding configured on the switch, their is an entry added to the IP source binding table (containing the PC's MAC address, the assigned IP address, lease time if applicable, VLAN, and interface). L2 traffic is allowed and L3 traffic is allowed if the source IP address matches the information in the IP source binding table.
Finally, let's look at an example utilizing both features working in conjunction. Again we will use the same three PCs and have the following configured on the switch interface:
switchport port-security violation restrict
ip verify source port-security
Source guard will now validate both the source MAC address and the source IP address before allowing traffic to enter the interface. Naturally we don't want to configure every client statically, so how can a switch allow client devices dynamically to allow them to send traffic?
Well, an exception to dropping all traffic is that the interface will allow DHCP traffic only from a newly connected client. Once the client gets a lease from the DHCP server, the DHCP snooping binding table is update and also updates the IP source binding table. Source guard then has both the MAC and IP adresses now to validate any other types of traffic.
However, allowing even DHCP traffic to trigger the switch to learn the MAC address creates a small vector of attack that could be exploited. A compromised device could send out DHCP traffic for a number of MAC addresses or targeted MAC addresses to get the switch to update the MAC address table in error. So while there is an exception to allow DHCP traffic, the switch still will not learn the MAC address until there is a non-DHCP data frame/packet transmitted by the client and accepted by the switch.
So this now brings us full circle to the first question and why the insertion of option 82 is necessary in the DHCP exchange.