Aaron’s Worthless Words

We run a large number of LANs all over the country that are “controlled” by the particular business unit. We manage the gear, but, since they have the money and have to pay for anything we do, they make the final decision on what gets put in. Sometimes that gets out of hand, as you can well imagine.

A good example came up a few months ago. It seems that, at some time in the past, one site needed some more LAN ports, but, instead of calling us and having us send them another switch, one of the “technical people” there brought in a hub from home. It really irks me to see a hub on the switched LAN, but we really have no control over those decisions. They plugged the hub into one of the existing drops somewhere in the building and plugged everyone in. It worked…until somebody moved one of the machines. The machine was at a desk near the hub, and the network cable was just unplugged and left lying there. A good Samaritan came by, saw that the hub was not plugged into the network, and plugged it back in for us — providing a nice second link from the hub to the switch stack in the closet. Take one switch stack, add a hub, insert a switching loop, bake at 350F for a few milliseconds, and you have a broadcast storm. If you don’t know already, broadcast storms are bad and eat switch CPU like the yummy cookies we baked. In this case, several 3750s were taken completely down.

How does one prevent such from happening again? Well, the first thing to do is to get the CTO to tell everyone that they can’t plug hubs into the network. That works about 0% of the time, though, so we had to find a solution that was enforceable. One of my coworkers found the traffic storm control mechanism built into Cisco switches. This mechanism allows you to set thresholds based on broadcast, multicast, and unicast traffic and take action when those are reached.

Here are the gory details. I need to mention, though, that storm-control is configured very differently across platforms and IOS versions. I would say your mileage may vary, but it’s probably more accurate to say that this won’t work on your switch. A 6500 is configured differently than a 4500. A 2900XL is different from a 2950. This will get you going, but you’re going to have to do some research on your own to find out what works on your platform.

interface FastEthernet 0/1
storm-control broadcast level 50
storm-control action shutdown

What just happened? Good question to ask. If broadcast traffic on F0/1 utilizes 50% of available bandwidth, the port is shutdown. That means that if broadcast traffic takes up 50Mbps of bandwidth on this port, the port is admined down just as if you did a shutdown on it.. You should probably do the same for multicast or unicast as well to make sure you don’t get bitten by those. If you don’t want to shut down the port, you can also use the trap action to just send an SNMP trap with the port and information, but that doesn’t prevent very much; the storm will probably wreak havoc before an email for the trap lands on your Crackberry.

Here’s another big disclaimer. Finding a good level for a port can be very, very difficult. A linux box is going to have very different broadcast/multicast/unicast traffic than a Windows box which is different than a Mac. You may have to spend a lot of time analyzing SNMP counters to find out what a good level is.  God help you if you have a hub like we did with mixed computer platforms on it.

• Leave a comment... (2)

In my professional life at some point, I came across someone who had a stack of Catalyst 2950 switches all trunked together with their Internet routers connected to the top of the stack. This was all well and good until they kept adding hosts to the “middle” of the stack, then they had all sorts of latency and packet loss.

The old adage of your chain only being as strong as your weakest length holds true in this case. Here, the weakest link is actually the most-congested trunk, though. Let’s step through to see. A 2950 is a 10/100 switch, so a single trunk can handle 100Mbps of traffic. We have 10 of these guys, Switch1 to Switch10, all trunked to the one above and below. If a server in the center of the stack on Switch5 is sending a lot of data to the Internet routers on Switch1, the trunks off of Switch5 will start to get saturated. Switch4 has a few hosts doing the same thing, so traffic from both Switch4 and Switch5 heads towards Switch1, further filling the trunks. Same for Switch3. Same for Switch2. Next thing you know, there’s 184Mbps or so trying to go across a 100Mbps link.

I fixed the problem using EtherChannel. EtherChannel, sometimes called trunking (not Cisco trunks…don’t get confused) or bonding, takes up to 8 interfaces of a switch and binds them logically as one Port-channel interface. The switch then load-balances (not really, but can be pretty close) the traffic across all the links, so, in essence, if you have 2 100Mbps ports in an EtherChannel, you get 200Mbps of bandwidth. If you put in 8 ports, you’ll get 800Mbps. Or, at least, close to it.

There are, as usual, stipulations for using it.

• All ports on the EtherChannel must terminate to the same device on both ends. You can’t have one port go to one switch and another to another switch.
• The ports must use identical media. You can’t have a copper port and a fiber port in the same group.
• The ports must have the same capabilities. You can’t put a 100Mbps port and a 1Gbps port in the same group.
• The ports must be configured identically or it won’t work. This is actually pretty easy to maintain since configuring the Port-channel actually sets the config on all participating ports.
• Both ends of the ports must be EtherChannel. You can’t run it on one switch but not the other.

Enough of that. Let’s configure. The scenario is that you have SwitchA and you want to bind F0/1 and F0/2 into an EtherChannel. Of course, you want to carry traffic from all VLANs, so let’s make it a trunk.

int F0/1
channel-group 1

int F0/2
channel-group 1

int Port-channel 1
speed 100
duplex full
switchport trunk encapsulation dot1q
switchport mode trunk

Easy as pie. Do the same thing on the other end and you have a 200Mbps, bonded trunk.

• Leave a comment... (0)

VLAN Trunk Protocol (VTP) is a little gem on Cisco switches that allows you configure VLANs in one place and have them appear on all of your switches. This is great for large enterprises with 8457839 switches all trunked together because who wants to configure the new VLAN for that one-off application on all 8457839 switches?

VTP works by having designated VTP servers (not real servers like your Linux box, but a switch) tell the rest of the switches in the network with what VLANs they should be configured. All the designated VTP clients say “OK” and configure themselves with those VLANs. When you take a VLAN out of the server, all the clients take it out; when you add a new VLAN, all the clients add it as well. The server and client designation is known as the VTP mode, and there’s one more to mention. When a switch is in VTP transparent mode, he will see VTP from the servers but will ignore them and pass them on to the next switch as if nothing ever happened.

To configure VTP, you have to define the VTP domain, which is a name for a group of switches that exchange VTP information. In general, in an enterprise, all your switches will probably be in the same VTP domain, but there are situations where you have multiple VTP domains on a LAN (like production and test networks). Next, you set the mode on the switch — server, client, transparent. I would suggest you configure a password as well to at least appear as though you’re practicing good security practices (I’m not sure it’s actually secure or not since every switch has the same password and the hash is sent in every packet…somebody enlighten me, please).

Get on your configuring gloves while I give you some more detail. VTP only works over 802.1q or ISL trunks. Also, VTP packets are Ethernet frames with the VTP stuff shoved into the data section. A switch can only be in one VTP domain at a time and can only be in one mode at a time. You can have more than one VTP server for a domain if you’d like (via a revisioning mechnism where the latest update always wins).

Here’s your scenario. You have SwitchA’s port G1/1 plugged into SwitchB’s G2/1. You want SwitchA to be the VTP server and SwitchB to be the client. Let’s get the config in place.

SwitchA(config)#interface G1/1
SwitchA(config-if)#switchport trunk encapsulation dot1q
SwitchA(config-if)#switchport mode trunk
SwitchA(config-if)#exit
SwitchA(config)#vtp mode server
SwitchA(config)#vtp domain VTP-DOMAIN
SwitchA(config)#vtp password VTP.PASS

SwitchB(config)#interface G2/1
SwitchB(config-if)#switchport trunk encapsulation dot1q
SwitchB(config-if)#switchport mode trunk
SwitchB(config-if)#exit
SwitchB(config)#vtp mode client
SwitchB(config)#vtp domain VTP-DOMAIN
SwitchB(config)#vtp password VTP.PASS

Both switches are now in VTP domain “VTP-DOMAIN” and share the password “VTP.PASS”. When you add a VLAN to SwitchA, it automatically gets added to SwitchB. When you add a VLAN to SwitchB, it actually errors out and says something like “Dude, I’m a VTP client. You can’t update me.”

At work, we have a large number of ports but a small number of switches. We also make very few changes to VLANs, so the work needed to maintain the VLANs is very low. Because of that, we actually do use transparent mode on all the switches. I’m also a bit of a purist, and configuring VLANs is something I like to do by hand; in my opinion, some things, especially mechanisms that can take whole networks down, are better left to the human. That’s just me, though.

• Leave a comment... (0)

Let’s keep going with our example setup on the ASA 5505 and set up DHCP on this guy. You can set it up to either forward (relay) DHCP requests to a DHCP server somewhere or have it be the DHCP server. Let’s do it.

To set up DHCP forwarding, you have to configure where the DHCP server is and then enable the relaying on the proper interfaces. Let’s say we have a DHCP server on the inside interface at 192.168.14.11 and we want it to serve IPs to the guests network. Setting up the DHCP server is beyond the scope here, so you’ll have to look elsewhere on how to set that up.

dhcprelay server 192.168.14.11 inside
dhcprelay enable guests

Another piece of cake, right?

Setting up the 5505 to be the DHCP server requires a few more lines, but, again, it’s easy. In the simplest setup, you only have to define your DHCP scopes and enable it on an interface. Let’s set up a DHCP scope for the inside interface of 192.168.14.101 - 120.

dhcpd address 192.168.14.101-120 inside
dhcpd enable inside

You probably want to serve a DNS server to the DHCP clients as well. You have two options — you can provide your own DNS server or have the 5505 serve the DNS servers it got from the upstream provider (like your cable modem provider) via DHCP. To serve out your DNS server at 192.168.14.12, just do this.

dhcpd dns 192.168.14.12

Serving the same DNS servers that the firewall got from the provider via DHCP is a little weird. Who puts underscores in commands? Assuming your outside interface is toward your ISP, just do this.

dhcpd auto_config outside

There’s the basics, but you can do all sorts of stuff with it. Change the lease time. Set the default search domain. Set a WINS server. Notice one thing, though; there’s no way to configure a default gateway. The ASA 5505 (and the rest of the 5500 series) only serve their own IPs as the default gateway, so be aware.

• Leave a comment... (0)

I’ve had my ASA 5505 in place at home on my Comcast cable for a few weeks now, and, let me tell you, this thing rocks. I did, however, have a few problems finding a clear answer on how I could set up my VLANs. It turns out that the base license on the ASA 5505 comes with a few restrictions with regards to VLANning — in particular the number of VLANs and the number of trunks.

When you have the base license and the ASA is in routed mode (you have IPs on interfaces), you can have three VLANs configured. One of them, however, has to be configured to not forward to one of the other VLANs. I had to go over that a few times before I got what the doc was saying. Basically, you have two VLANs that are fully functional and one that can only initiate traffic to one of the others. At home, I consolidated my network down to three VLAN — outside (I’net), inside (Users), and a DMZ (Guests). The inside interface can initiate connections to both outside and the DMZ, but the DMZ can only talk to the outside VLAN. This is probably not a very big deal to an average user, but I’m a network guy and will add networks just to say I’ve got one more subnet than you do.

I also had some confusion over the number of trunks available on this guy. My Aironet 1231 is set up to tag multiple bridged VLANs to the Ethernet so that I could have multiple SSIDs on it with each in their own VLAN. I did this by making the switch port on the 2950 into a tagged trunk. With the base license on the 5505, you don’t get any trunks. I didn’t find any docs that said you couldn’t, but it’s pretty obvious from the “show version” info.

VLAN Trunk Ports : 0

This really puts a damper on my AP setup. I had to reconfigure it to just use a single, untagged bridged interface with a single SSID. If I wanted to implement the Aironet 1231 the way I had it beforehand, I would have to upgrade my license on the 5505. I’m not paying any more money for this thing, so I’ll have to get one of my lab APs in place for guests. Thank God for eBay.

So, how do you configure this thing? First, let decide on our VLANs — say VLANs 11, 12, and 13. The configuration is just like any PIX 7.X

interface Vlan11
description OUTSIDE
nameif outside
security-level 0
ip address dhcp setroute
!
interface Vlan12
description GUESTS
no forward interface Vlan13
nameif guests
security-level 10
ip address 192.168.13.1 255.255.255.0
!
interface Vlan13
description USER
nameif inside
security-level 100
ip address 192.168.14.1 255.255.255.0

The interface VLANs are what handles the IP addresses. We’ll put specific ports in the VLANs in a minute, so hold tight. The configuration is pretty self-explanatory with VLAN11 being the outside (I’net), VLAN 12 being the DMZ (guests), and VLAN13 being the inside (users).  There is, however, the one line that reads no forward interface Vlan13. This is the line  that makes dictates which VLAN is a DMZ with respect to the base license and that this VLAN (VLAN12) can’t initiate connections to VLAN13. You also might have noticed the line ip address dhcp setroute. You can read one of the earlier articles on that guy.

The last thing you do is to put ports in VLANs. The ports on the 5505 are labeled Ethernet0/0 - 7, and you treat them just like an IOS switch with the switchport access vlan X command. At home, you would plug your cable modem (or whatever) into one of the interfaces (say, Ethernet0/0) and put that port into VLAN11.

interface Ethernet0/0
switchport access vlan 11

Plug all your stuff in, put the ports in the right VLAN, and enjoy.

• Leave a comment... (1)

Believe it or not, I got a request for an article on how to configure GLBP. I’m as shocked as you are, so here it goes.

The Gateway Load Balancing Protocol (GLBP) is another Cisco-proprietary protocol for providing highly-available gateways on a network…but there’s a twist. GLBP, as you can figure out from the name, load-balances the traffic going through the participating routers. With HSRP and VRRP, one host is the active peer and handles all the traffic until it dies, then another peer takes over. With GLBP, all the routers accept traffic.

The key is the virtual MAC address. When you configure a router to use GLBP, it discovers all the other routers configured for GLBP, and an election is held. The winner is called the Active Virtual Gateway (AVG) and assigns virtual MAC addresses to all the members in the group (called Active Virtual Forwarders or AVFs). When a host on the network ARPs for the virtual IP, the AVG answers the request with one of the virtual MAC addresses of the AVFs. The next ARP request gets another virtual MAC, etc. Do this a few times, and the hosts are the network are splitting their traffic among all the AVFs.

Config time!

GLBP0(config)#interface f0/0
GLBP0(config-if)#ip address 192.168.0.10 255.255.255.0
GLBP0(config-if)#glbp 0 ip 192.168.0.1

GLBP1(config)#interface f0/0
GLBP1(config-if)#ip address 192.168.0.11 255.255.255.0
GLBP1(config-if)#glbp 0 ip 192.168.0.1

GLBP2(config)#interface f0/0
GLBP2(config-if)#ip address 192.168.0.12 255.255.255.0
GLBP2(config-if)#glbp 0 ip 192.168.0.1

Very simple. This sets the IP on f0/0 of three routers and enables GLBP group 0 for the IP 192.168.0.1. The group number, 0 in this case, is the same as in HSRP; you can have more than one instance of GLBP on an interface, so you have to tell it what settings go with what group.

After a few seconds of yelling at each other, the routers will have decided who the active and backup AVGs are, who the AVFs are, and what the virtual MACs for the AVFs are. After convergence, you can run the show glbp brief command to see what the status is.

GLBP0#sh glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Fa0/0       0    -   100 Listen   192.168.0.1     192.168.0.12    192.168.0.11
Fa0/0       0    1   -   Listen   0007.b400.0001  192.168.0.12    -
Fa0/0       0    2   -   Active   0007.b400.0002  local           -
Fa0/0       0    3   -   Listen   0007.b400.0003  192.168.0.11    -

In our example, the IP 192.168.0.12 is the AVG (GLBP2) with 192.168.0.11 being the backup AVG (GLBP1). You can also see that three virtual MACs have been assigned — 0007.b400.001 - 3.

Those are the basics, but there are a few more things worth mentioning that you should look at on your own.

• By default, the load-balancing method is round robin, but you can set the GLBP balancing method to weighted, which uses configured weights on each router to determine who’s next in line for ARP replies. Use the load-balancing and weighting directives.
• You can set priorities for each router to better control which one becomes the AVG and backup AVG with the priority directive.
• You can have GLBP track objects just as you do with HSRP. Use the weighting track configuration to do so.
• You can put passwords on the GLBP group to protect yourself from random routers trying to participate and hose things up. Look at authentication.
• By default, a higher priority router won’t overthrow a lower one to become the AVG. You can turn this feature on with the preempt directive.

• Leave a comment... (1)

If you didn’t now already, trunks are connections between switches that carry traffic for all VLANs. It allows you to have, say, VLAN 10 and VLAN 20 on two switches appear as the same network. Unless you’re a really small shop, you’ve already dealt with trunks, so there’s no need for an introduction.

Let’s say we have a Catlyst 2950 switch with multiple VLANs connected to another 2950 configured with those same VLANs. We’ll say we have VLANs 10, 20, and 30 and that the switches are connected to port F0/24 of each switch. First, let’s turn on the trunk.

interface F0/24
switchport trunk encapsulation dot1q
switchport mode trunk

Quite easy there. With this configuration on each switch, the connection between them will carry traffic for all VLANs. The encapsulation directive tells the switches to use the IEEE standard 802.1Q for the trunk, which is VLAN tagging. Cisco has its own trunk encapsulation called ISL, but that’s not compatible with non-Cisco gear. If you have a mix of switches, just use the dot1q encapsulation so you don’t hurt yourself later.

A note on the word “encapsulation” here. Dot1q does not actually encapsulate; it adds 4 bytes to the frame header that marks the VLAN the frame is for. ISL, however, does encapsulate; it takes the whole frame, shoves it into an ISL frame, and sends it on. Since Cisco’s preferred method for a trunk is an encapsulation method, we have the directive “encapsulation” in the configs.

At this point, all VLANs are being carried across the trunk, but what if you want to use multiple trunks and send different traffic across each one? For example, let’s say that you want to have VLAN 10 traffic use a second trunk while the other VLANs use our original trunk. To do that, you get into pruning.

interface F0/24
…
switchport trunk allowed vlan 20, 30

interface F0/23
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10

The switchport trunk allowed vlan directive says that only traffic on VLANs 20 and 30 are allowed across F0/24 and only VLAN 10 across F0/23. I use this type of setup to give high-bandwidth VLANs (like VLANs for backups) their own trunk so they won’t eat all the bandwidth of the other VLANs. To use the terminology, F0/24 is pruned to VLANs 20 and 30, while F0/23 is pruned to VLAN 10.

I also want to mention that the word trunking is used differently across different platforms. We have a nearly-totally Cisco LAN, and trunks are the connections that carry all VLANs as described. On other LAN gear, trunking is actually the act of combining port, links, cables, whatever, together to form a single logical connection (Cisco calls this EtherChannel). VLAN tagging is what other manufacturers call a Cisco trunk. It makes sense if you remember that 802.1Q simply tags the frame.

• Leave a comment... (0)