I get quite a few emails and and private messages that contain the phrase above, “Network is down! Please help!”. In the vast majority of cases it usually turns out that the problem is self inflicted. Here are a few simple steps that I strongly recommend you look at if it’s your responsibility to manage the network. These features will help mitigate some serious operational issues from spoiling your day.
Spanning Tree (FastStart / PortFast)
You can’t imagine how many times I’ve seen a patch cable patched from one port on a switch in an IDF back into the same switch. It’s usually a case of sloppy cabling, although I’ve met a quite a few users who thought that both ends of the cable needed to be plugged into the wall plate. In order to prevent such scenarios from spoiling your day you should verify that you have Spanning Tree enabled on all edge ports (ports that face the users). And you should also verify that you have FastStart or PortFast enabled to help eliminate the 30 second delay during STP learning (those of us that used to run IPX/SPX networks with Novell NetWare learned this a long time ago).
BPDU Guard (called BPDU Filtering by some vendors)
In addition to Spanning Tree you should also enable BPDU guard on all your edge ports. This will immediately disable the switchport if it receives a BPDU Spanning Tree frame. This can help mitigate topology loops and it can help prevent your users from plugging in their own switches in their offices or cubicles. There are some scenarios where connecting the PC port on the back of an Avaya IP phone could potentially put a loop into the network. BPDU guard (called BPDU filtering by Avaya) will detect the BPDU frame and disable the port, thereby protecting the network.
Rate Limiting (Broadcast / Multicast)
If your in the networking field long enough you’ll eventually see some really odd behavior from one or more devices. I’ve seen my fair share of oddities and eventually you’ll run across a few too. You should prepare for that eventuality today by configuring broadcast and Multicast rate limiting on your edge ports. This helps prevent any single device from flooding too many broadcast or Multicast packets into your network which could impact either other devices connected to the network or the network itself.
You’re already doing each of the previously listed items? Well you could look at the following additional steps. You can find additional detail in a blog post titled, DHCP Snooping ARP Inspection IP Source Guard.
DHCP Snooping
Dynamic Host Configuration Protocol (DHCP) snooping provides security to the network by preventing DHCP spoofing. DHCP spoofing refers to an attacker’s ability to respond to DHCP requests with false IP information. DHCP snooping acts like a firewall between untrusted hosts and the DHCP servers, so that DHCP spoofing cannot occur. There are 2 types of ports in DHCP snooping, trusted and untrusted. The network will only allow DHCP responses from trusted ports – usually uplinks as opposed to allowing DHCP responses from untrusted ports – usually edge switch ports.
DHCP Option 82 – With DHCP Option 82 the switch will append additional information to the DHCP request which can be stored and captured by your DHCP server (or your IP Address Management solution) to help identify the switch and port from which the request was initiated.
ARP Inspection
Dynamic Address Resolution Protocol Inspection (DAI) is a security feature that validates ARP packets in the network.
Without dynamic ARP inspection, a malicious user can attack hosts, switches, and routers connected to the Layer 2 network by poisoning the ARP caches of systems connected to the subnet and by intercepting traffic intended for other hosts on the subnet. Dynamic ARP inspection prevents this type of attack. It intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings.
The address binding table is dynamically built from information gathered in the DHCP request and reply when DHCP snooping is enabled. The MAC address from the DHCP request is paired with the IP address from the DHCP reply to create an entry in the DHCP binding table.
When you enable Dynamic ARP inspection, ARP packets on untrusted ports are filtered based on the source MAC and IP addresses stored in the DHCP snooping table. The switch forwards an ARP packet when the source MAC and IP address matches an entry in the DHCP snooping table. Otherwise, the ARP packet is dropped.
IP Source Guard
IP Source Guard provides security to the network by filtering clients with invalid or spoofed IP addresses. IP Source Guard is a Layer 2 (L2), port-to-port feature that works closely with information in the Dynamic Host Control Protocol (DHCP) snooping binding table. When you enable IP Source Guard on an untrusted port with DHCP snooping enabled, an IP filter entry is created or deleted for that port automatically, based on IP information stored in the corresponding DHCP binding table entry. When a connecting client receives a valid IP address from the DHCP server, a filter is installed on the port to allow traffic only from the assigned IP address. A maximum of 10 IP addresses are allowed on each IP Source Guard-enabled port. When this number is reached, no more filters are set up and traffic is dropped.
While Dynamic ARP Inspection blocks only ARP packets, IP Source Guard blocks all IP packets.
Cheers!
Image Credit: The Lánchid Bridge in Budapest Hungary at nightfall by Abel Leemans
Ken Lai says
Hi Michael
Actually BPDU filter and BPDU guard are different, though I know some vendors claim they are the same.
In brief, BPDU guard watches the interface and put it into the err-disable state once receiving a BPDU. BPDU filter just filters BPDUs in both directions.
I may misunderstand your sentence.
Michael McNamara says
Yes, agreed…
I guess I was trying to point out that while Cisco, Juniper and other call it BPDU guard, Avaya calls it BPDU filter. And yes I realize there is yet another featured called BPDU filter beyond BPDU guard.
Thanks for the comment!
Paul L says
I would venture to say that 99.9% of all network outages are self inflicted. Of that 99%, 90% of outages are caused by layer 1 issues, 5% misconfig, 5% extreme neglect.