I remember when I first saw Storm Control in a config and thought “woah, whats that looks really confusing”, but really its pretty simple stuff.

We use storm control to rate limit layer 2 traffic, this helps us prevent a subnet from being flooded with broadcasts, multicasts which would adversely affect the performance of the entire subnet. Storm Control can only be configured on physical interfaces and will not work on subinterfaces, or an LACP/PAGP interface.

Configuration

The first command shown limits the broadcast to 200pps, and if this limit is reached will not forward any more broadcasts until this is reduced to 150pps
(config-if)#storm-control broadcast level pps 200 150

Multicast and unicast traffic can also be limited, the maximum level can also be entered as a percentage instead of pps, in the example below multicasts can use up to 5% of the interface bandwidth, and once that limit is reach no more multicasts will be forwarded until it drops to 4.5% of the total interface bandwidth
(config-if)#storm-control multicast level 5 4.5

In the final example unicast is limited to 80% of the interface bandwidth but a second value is not specified, this causes all unicast to be forwarded up to 80% of the bandwidth and it does not force the traffic to wait until it drops below a second level
(config-if)#storm-control unicast level 80

The default response for storm control is the drop packets which are over the rate limit, and create a syslog message, we can also generate a SNMP trap with the command
(config-if)#storm-control action trap

The show commands for this are also really easy, I will paste the output of this when I am home
(config-if)#show storm-control port [unicast|broadcast|multicast]

A recent example of a Layer 2 attack happening in the real world was where the popular hacking tool website Metasploit was taken down, the attacker who had a server in the same subnet as the Metasploit web server would send ARP messages saying that the MAC of the metasploit web server was actually on the attackers server. The actual MetaSploit webserver was up and running fine but any user visiting the website would see the attackers “victory” message instead of the actual Metasploit website. This attacked was not resolved but Dynamic Arp Inspection but its a cool example of what it can prevent.

There are many other attacks which abuse ARP messages and they commonly result in DOS or man in the middle attacks. Dynamic ARP Inspection (DAI) is a great method of preventing ARP based attacks.

If DAI is deployed on a switch it will examine ARP messages on every untrusted port and discard inappropriate ones, it does not examine ARPs on trusted ports. End stations should be configured as untrusted and connections to other switches & network devices should always be trusted, otherwise possibly valid ARP messages could be discarded.

The following are steps which DAI will decide whether to discard a packet on an untrusted port. Only step 1 is used by default steps 2 to 4 require extra configuration.

1 – If an ARP message states an IP address which has not been assigned via DHCP to that port the ARP is dropped.

2 – The ARP is checked against a staic list of IP/MACs and if it doesnt match the ARP is dropped

3 – An ARP reply should have the source MAC and the MAC in the message the same, if they are different the ARP is dropped. Also the destination MAC and MAC target are compared, if they are different the ARP is dropped

4 – Unusual IP addresses can be also filtered such as the subnet addresses, broadcast addresses and multicast addresses.

Configuration

DAI is enabled per VLAN with the following command;
ip arp inspection vlan vlan-range

All ports default to become trusted ports so to start the inspection of ARPs ports must be configured as untrusted with the interface command
no ip arp inspection trust

Option 2 in the list above where static IP/MAC lists can be checked with the following command
ip arp inspection filter arp-acl-name vlan vlan-range [static]

Steps 3 & 4 in the list above are not checked by default but they can be with the command
ip arp inspection validate {[src-mac] [dst-mac] [ip]}

The maximum rate of ARPs can also be limited to prevent DoS attacks with the command
ip arp inspection limit {rate pps [burst interval seconds] | none}