I have now personally shown that risen stress levels lead to lessened blogging. But that’s another story (as is all the stuff that’s happened since the last post) because i’m back on the ICND track, now on the second Interconnecting Cisco networking devices course. In my previous write-ups about the ICND, i know i’ve been rather messy. I’m mainly writing so that i can remind myself later what i’ve been learning. So my apologies for the incoherence. Here’s more of it.

If the ICND 1 was a mix of repetition and good tidbits, this course, at least judging from the first day, is drinking from the information fire hose. The fire hose, as you may guess, only has two settings: off and full, and this one’s been on full all day.

Today we had two topics: recap of ICND 1 and All About VLANs. Here are some unconnected bits. First…

ICND 1 in a nutshell

Cisco are taking into account that information can be stored in a myriad of places. Thus, you should specify if your storage is on the system, flash, tftp or anywhere else, and not just relying on the defaults. What used to be wr became copy running-config startup-config and now should be written copy system:running-config nvram:startup-config. Likewise, you should not type wrt when you mean show running-config.

A switch is a switch is a switch is either a Layer 2 switch or a Layer 3 switch (L2/L3). I absolutely need to recap the L2/L3 stuff so that it becomes second nature to me, otherwise things are going to go over my head a lot. On a multi-layer device, a switch port becomes an L2 port through the command switchport (short: sw) and an L3 port by issuing no switchport. An L2 “switchport” would be related to commands sw mode access and sw access vlan number, or sw mode trunk. Lots of that to come. An L3 “no switchport” would gain an ip address x.x.x.x m.m.m.m.

The Cisco (proprietary) Discovery Protocol or cdp will announce and gather information from neighbouring devices, which can be a Really Useful thing. On newer Cisco devices, the Logical (or Local?) Link Layer Discovery Protocol (LLDP) will do the same, but in a non-proprietary way.

To wake up a switch port, do this:

enable
conf t
int vlan 1
ip address aa.bb.cc.dd mm.aa.ss.kk
ip default-gateway n.n.n.n
no shutdown

The last bit is kind of funny. To enable the interface, you “un-shut-it-down”.

To factory reset a router, erase nvram:startup-config (or write erase) and reload.

To factory reset a switch, write erase (or delete config.text) then delete vlan.dat and finally reboot. If you don’t delete the vlan.dat file, the vlan information will be re-read when the machine reboots and you effectively don’t have a factory reset switch.

A Cisco device will try to translate typos into hostnames. To remove the name lookup service, assign a no ip domain lookup.

When you initially configure your device, you’ll receive a bunch of error messages because things just aren’t up yet. If you don’t want to read this stuff, issue a no logging console and remember to get logging back when you’re a bit closer to done.

To crack in to a switch, unplug the power, hold down the mode button when re-plugging the power. Wait for the switch to boot. Run load_helper, then delete flash:config.text and boot.

VLANs

Cisco knows of two VLAN technologies, the old ISL and the new dot1q. To activate VLAN (which you will), set a port to a VLAN port statically by conf t, int this-or-that and sw acc vlan n. Then set it to use dot1q. Check the documentation

A trunk port will forward traffic from multiple VLANs and is used to connect network equipment (switches and routers) together. An access port is used to connect “end equipment” such as PCs and printers to the net. An access port will only convey traffic of a single VLAN.

And this is where the Wizard Tools started to show. If you use dot1x RADIUS authentication, you can dynamically assign a port to a vlan. Nifty, but requires some black belt magic. Previously, Cisco pushed the (proprietary) VLAN Port Management Server (VPMS) but this is thankfully being phased out. /me likes open standards.

In a perfectly tuned VLAN network, all traffic is tagged to some VLAN. In reality, some stuf ain’t. This untagged network traffic is assigned to VLAN 1 and assigned as “native” VLAN traffic. To increase security (including the inadverted wiping of all your VLAN data), you should set the native VLAN another VLAN ID, such as 99. You can then route VLAN 99 into a black hole and voila, there is security (if not a lot of functionality).

Cisco also uses the “native” VLAN in association with Voice over IP (VoIP). A Cisco VoIP phone has two Ethernet jacks; one’s an uplink to the network and the other goes to your PC (who the heck has only one PC on their table anyway? :). The VoIP stuff is tagged with a VVID (voice-something-id) which is kind of like a VLAN tag except that it isn’t. Thus, you can connect a VoIP phone and a PC to a regular, un-trunked switch access port.

More wizard tools: the VLAN Trunking Protocol (VTP) will announce the VLAN configuration to other VTP-enabled devices, as well as receive VLAN configuration. A VTP box can either be set as a server, a client or as transparent. A VTP Server can send and receive VTP updates, a VTP Client will receive them, and a Transparent box will only relay VTP configuration. A problem will arise if you plug a new switch into a network, since it by default will be a VTP server and may thus overwrite all other VTP boxes of the same VTP Domain – including a blank or non-assigned name — if the newly connected box’s update revision number happens to be higher than that on the rest of the network. For that, you should always set a VTP domain to your network if you’re going to use VTP. For starters, you may want to run vtp transparent and vtp client to reset the update revision number on the new box, then set the vtp domain to match your network. VTP messages are only relayed through trunk ports, not access ports.

VTP Pruning is another nifty feature: a switch (or a router, supposedly) running vtp pruning will not convey broadcast and multicast traffic down a port which it knows does not have the recipient VLAN connected to it. This is pretty much what a switch should do anyway, but now it does so on VLAN traffic too.

The next wizard tool is the Dynamic Trunking Protocol (DTP — and yes, it’s another Cisco-proprietary protocol). If you connect two Cisco boxes together and unless they are explicitly configured not to, they will exchange DTP information to see whether there’s a trunking port on the other side, and configure themselves accordingly. At least the other side has to be configured switchport mode dynamic desirable while the other can be set to switchport mode dynamic auto. Also, if the other side is set to sw mode trunk, a port set to dynamic desirable or dynamic trunk be able to get the right settings.

Real Network Administrators will connect their switches and routers with multiple parallel network cables. In a normal world, this would lead to a network loop, a broadcast storm and the whole network coming to a screeching halt, melting all equipment connected to it. In the world of Real Network Administrators, such cables are grouped as an EtherChannel™ (ungh) for redundancy and, more importantly, throughput. 802.1Q trunks go well through EtherChannels, if properly administered by Real Network Administrators. So there.

Back to the basics of trunking. If you have a box capable of both VLAN standards, first set a switchport manually and statically to use only 802.1Q by saying sw trunk encapsulation dot1q. After that, you can set your port to switchport mode { access | dynamic { auto | desirable } | trunk }.

Adding VLANs is easy: conf t, then vlan n. After this you can assign your VLAN a name saying name somename. Check your settings saying show vlan {brief}. Make sure your VLAN exists on other network equipment too, otherwise your traffic will just end up on the floor.

In a large network, you will need to buy the IPservices “feature pack” which will enable all four thousand-and-something (some VLANs are reserved) VLANs. The IPservices pack will cost you about as much as the switch you are buying it for. With only the Basic IP pack, you are “only” going to get fourty or sixty someting VLANs, which probably will be quite enough for any network i’ll administer.

To get traffic from one VLAN to another, it needs to be routed. In a small example environment, a Cisco 35xx will handle VLANs internally (and not disclose this information elsewhere) using the following magic

ip routing
int vlan 1
ip add 10.1.1.1 255.255.255.0
int vlan 2
ip add 10.2.2.0 255.255.255.0

…and assign int fa0/1 sw acc vlan 1, int fa0/2 to sw mode trunk and int fa0/3 to sw acc vlan 2. Traffic on fa0/1 or fa0/3 going from one vlan to the other wil be L3-routed (ip routing) internally.

In a slightly more realistic environment, you can do VLAN-to-VLAN routing employing a “router on a stick” (where a “stick”) means one interface on the router. For that, you enable a sub-interface for each VLAN you want to route between, on the same port (”stick”). On, say, interface 0/0, you disable the “main” and actual interface, then create two sub-interfaces doing the routing, thusly:

interface fa0/0
no ip address
int fa0/0.1
encapsulation dot1q native
ip address 10.1.1.1 255.255.255.0
int fa0/0.2
encapsulation dot1Q 2
ip address 10.2.2.1 255.255.255.0

You’ll need to fill in the blanks yourself, but this will route the “native” untagged VLAN 1 on the FastEthernet 0/0.1sub-interface and properly 802.1Q-tagged VLAN 2 on sub-interface 0/0.2.

Throw in one recap-of-ICND1-lab and another about VLANs and trunking, and that’s about the size of it! Tomorrow, we’ll handle spanning trees and link aggregation (that’s right, EtherChannels), among a bunch of other things. Phew!