Monday, March 23, 2009

IOS Access Control Lists

In this video demonstration, we show an example of writing IOS Access Control Lists (ACL's) on a home router. We use the revision control system (RCS) to maintain the master ACL file and push the ACL's to the router via TFTP. This is similar to many production networks, where maintaing comments and old revisions of ACL's is a requirement. We also show examples explaining the "don't care bit" format of IOS ACLs. Many network engineers mistakenly refer to the format as inverse-netmask, but that is incorrect.
PIXes, FWSMs, and ASA's use a netmask format for ACLs. It is vitally important not to make the mistake of accidentally pushing a netmask format ACL line to an IOS device. That sort of error could result in an unplanned hole in your firewall and a serious security incident.


Sunday, March 22, 2009


IOS routers can act as DHCP clients and DHCP servers. They can also function as Network Address Translation (NAT) devices. In this video we show a demonstration using a 2621 as a DHCP client, server, and NAT translation device for my home network.
It's important to understand that most IOS routers have relatively slow CPU's. An IOS router is fine as a DHCP server for a few dozen clients. But if you try to serve thousands of DHCP clients you are likely to fail and suffer an outage.
IOS routers can also work as a network address translation devices. IOS NAT is "ok" but for real high capacity NAT (thousands of users) you want to use a device designed to handle high capacity NAT. PIXes, FWSMs, and ASA's are excellent NAT devices.

Saturday, March 21, 2009

Hot Standby Router Protocol

In this episode we show a video demonstration of the hot standby router protocol. This is a Cisco proprietary redundancy protocol. The purpose is to allow two routers to share one virtual IP address on an access subnet/vlan. Hosts on the subnet can use the virtual IP for their default route. This way if one router goes down the redundant router will assume the virtual IP address, preventing a loss of connectivity to the hosts on the net.
HSRP is configured with the "standby ip" group of commands in interface configuration mode on the router.
VRRP is the virtual router redundancy protocol. It is similar to HSRP but is vendor independent.
GLBP is the generic load balancing protocol. It can also replace HSRP and is vendor independent. It has the added ability to load-balance the traffic between both routers. Using this feature you could configure approximately half the traffic to use each redundant router.
Almost all enterprise networks use HSRP, VRRP, or GLBP to provide virtual IP addresses for each access subnet.


Saturday, March 7, 2009

Rapid Spanning Tree 802.1w

This video demonstrates layer-2 convergence in less than 2 seconds thanks to rapid spanning-tree.
Rapid per-vlan spanning-tree is configured with "spanning-tree mode rapid-pvst".
The rapid spanning tree protocol, 802.1w, is the answer to the slow convergence time of the historic 802.1d spanning-tree protocol. Rapid spanning tree replaces timers with triggered updates. Switches almost never wait for a timer to expire. When converging on a new switch-to-switch link they will start with the port in the discarding state. The upstream switch (closest to the root bridge) will send a proposal to the downstream switch. The downstream switch will put all other downstream switch-to-switch (P2P) ports into the discarding state (preventing a loop) and then accept the proposal. Once the proposal is accepted, the switches will forward on the new link. Then the downstream switch will repeat the procedure on each downstream P2P link. While seemingly complex, because none of these actions wait for a timer to expire, the end result is spanning-tree reconvergence in seconds. Edge ports (going to end hosts) are known because they are configured with "spanning-tree portfast". Edge ports never go into the discarding state because they cannot create a bridging loop.
Rapid spanning-tree incorporates improved versions of the backbonefast and uplinkfast improvements, making configuration of those features unnecessary. It is still possible to configure bpduguard, rootguard, and loopguard. Configuring portfast is essential to identify edge ports.


Monday, March 2, 2009

Etherchannels and the port aggregation protocol

When you have two different links between the same two switches, normally spanning tree will forward on one and block on the other. This means half of your bandwidth is sitting idle. An etherchannel is a way to bind two links into one logical link with twice the bandwidth. In addition to increased bandwidth, etherchannels fail over in a fraction of a second. So the failure of one physical link in a multi-link etherchannel will not result in a significant outage.
The port aggregation protocol (PAgP) is a Cisco proprietary protocol that switches use to determine whether to bundle multiple links into an etherchannel. PAgP is similar to DTP, in that it has "desirable" and "auto" modes. One difference is that ports configured in etherchannel "on" mode do not speak the PAgP protocol, resulting in a mismatch with a PAgP-speaking switch at the other end of the link.
The link aggregation control protocol (LACP) is a standards-based replacement for PAgP. If you want to dynamically negotiate etherchannels with non-Cisco gear (including some servers), LACP is the way to go.
One big advantage of dynamically negotiating etherchannels is that the negotiation protocols will help prevent etherchannel mismatches. Setting the etherchannel to "on" can get you into trouble if the two channel members go to different switches, or go to a switch without etherchannel configured.


Sunday, March 1, 2009

VTP Vlan Trunking Protocol

VTP is the VLAN trunking protocol. It's used to disseminate uniform vlan information between switches over 802.1q or ISL trunks. It can also "prune" vlans, dynamically removing unneeded VLANs from trunks. This decreases unneeded frame flooding.
VTP can eliminate outages thanks to the uniform VLAN configuration. But it can also cause outages if incorrect VLAN information is uniformly distributed.
We also attempt a loopguard demonstration, but it doesn't work out well. We'll have to revisit the documentation because it's obvious loopguard is not acting as I expect.