Tag Archives: VIDEO

CCNP SWITCH 300-115 2.1 Configure and verify switch security features

2.1.a DHCP snooping

In this segment we will cover DHCP, as well as DHCP Snooping. It seems the blueprint is remiss in mentioning DHCP in its own line item so we will briefly cover it here as you cannot have DHCP Snooping without DHCP.

DHCP is easy enough; there are only 2 requirements for it so long as you are using a single subnet, as we will do here for the sake of simplicity. The minimum requirements call for a default-router and a DHCP network for address assignment. You could establish a lease period, DNS, and many other delimiters,  but they are not minimum requirements. It is a good idea to include a domain-name but usually that has already been configured.

DHCP is the Dynamic Host Configuration Protocol. It eases administration by allowing clients to broadcast for Ip addresses and a default gateway, among other parameters. A lot easier than statically configuring a bunch of windows or linux boxes in any size environment. The usual method is for a dedicated server to handle the chore, but Cisco was kind enough to include it in its routers and switches, and on it’s exams.

So the first step  will be to set up a DHCP server. Keep in mind the acronym DORA, dis, off, req, ack and you can easily memorize the dhcp process. Discover, Offer, Request, Acknowledge.

Option 82 or the information option is a player in the VIRL canvas. Option 82 is turned on by default and does further fact checking for validity on untrusted ports especially in the case of relays. We can avoid this by turning off option 82 at the switch, or by enabling option 82 on the access ports, the untrusted ports, however, here we will turn it off on the switch. You can find out more detail about option 82 on the internet, in fact Petr Lapukhov has a great article about it on his INE blog. Just do a search for “option 82 Petr” and that should be your first hit.

Let’s get down to configuration.

Now that we have DHCP in place and operational, we can talk about DHCP Snooping. DHCP Snooping is designed to disallow rogue DHCP servers from inhabiting your network and dishing out false Ip addresses and gateways to your clients. This is performed by establishing a trust between authorized devices and thereby building a reference database for cross checking. Remember, only untrusted connections will be leased ip addresses and assigned to the snooping database, along with their associated mac’s and vlan’s. It is vital to understand that trusted connections are established between server and switch or router and switch or switch and switch, not switch and access ports.

There are three essential items to get DHCP Snooping operational. Of course there are other options but we will discuss the minimum. They

Turn on dhcp snooping

turn on dhcp snooping for the Vlan or Vlan’s

and establish trust between the server and switch.

here we go:





SWITCH 300-115 1.5 Configure and verify EtherChannels

1.5.d EtherChannel misconfiguration guard
Etherchannel misconfiguration guard is enabled by default and does what it says it does; helps prevent misconfiguration of etherchannels.
We know that the interfaces we bundle into a channel need to have matching configurations or they will not be suitable, but often enough they are mistakenly put together in a hurry without verifying both sides interfaces first. Etherchannel misconfiguration guard will place the channel in errdissable state and issues an error message if it detects a possible misconfiguration.
To verify that etherchannel guard misconfig is in place as the default use:
sh spann summ | i Ether
If you do break the etherchannel by purposely misconfiguring, or not, you can reenable the channel with shut/no shut or by adjusting the errdisable recovery time interval.

SWITCH 300-115 1.5 Configure and verify EtherChannels

1.5.a LACP, PAgP, manual
Etherchannel comes in three flavors, on, my preference often called static or manual,  whereby there is no negotiation of the channel and thus, no extra protocol traffic, PAGP or port aggregation protocol which is Cisco proprietary, and LACP or link aggregation protocol which is the open standard 802.3ad. It is interesting to note that PAGP is not supported on Cisco’s Nexus OS line and that LACP is the preferred method of aggregation from the data center side of the house.
They all have one thing in common, however, and that is to bundle together a group of ports on a switch with the net effect of increasing bandwidth between two connected switches. For instance switches will support 2 to  8 active members on each side of a connection; so considering they are 100 Meg each, a total of 1600 Meg bandwidth can be achieved between them.

Another 8 ports may be used as backup but only 8 may be active at one time. The aggregated ports of a channel must be setup on the individual switch but the ports do not have to be contiguous, and they can cross modules in the event of a chassis type switch or a stack. Also the channel numbers on either side do not have to match, but I advise making it a practice of matching the sides as it makes for easier documentation, and more intuitive troubleshooting.

Another inherent benefit is lessening the impact of Spanning-tree on the network. The etherchannel or port-channel is treated as a single link by STP, therefore there can be no blocking of individual links within the channel, although multiple redundant channels between switches would still be governed by spanning-tree.
A caveat in the creation of a channel is that both sides port configurations need to be exactly the same or the channel will not form. This is one reason why care should be taken when using on or manual mode because without negotiation, there will be no warning in the event of misconfiguration. Another thing to keep in mind is that there is no mixing of channel protocols. For instance, PAGP can use desirable/auto, desirable/desirable, but not auto/auto, similar to DTP. LACP can be act/passive, active/active but not passive/passive. On mode is simply on for both sides.