Home lab: My GRE tunnel endeavors.

This article is not really written with knowledge usable for a production network in mind. It’s more of an “I have not failed. I’ve just found 10,000 ways that won’t work.” kind of article.

I’m currently in a mailing group with fellow network engineers who are setting up GRE tunnels to each others home networks over the public internet. Over those networks we speak (external) BGP towards each other and each engineer announces his own private address range. With around 10 engineers so far and a partial mesh of tunnels, it gives a useful topology to troubleshoot and experiment with. Just like the real internet, you don’t know what happens day-to-day, neighborships may go down or suddenly new ones are added, and other next-hops may become more interesting for some routes suddenly.

But of course it requires a device at home capable of both GRE and BGP. A Cisco router will do, as will Linux with Quagga and many other industrial routers. But the only device I currently have running 24/7 is my WS-C3560-8PC switch. Although it has an IP Services IOS, is already routing and can do GRE and BGP, it doesn’t do NAT. Easy enough: allow GRE through on the router that does the NAT in the home network. Turns out the old DD-WRT version I have on my current router doesn’t support it. Sure I can replace it but it would cost me a new router and it would not be a challenge.

Solution: give the switch a direct public IP address and do the tunnels from there. After all, the internal IP addresses are encapsulated in GRE for transport so NAT is required for them. Since the switch already has a default route towards the router, set up host routes (a /32) per remote GRE endpoint. However, this still introduces asymmetric routing: the provider subnet is a connected subnet for the switch, so incoming traffic will go through the router and outgoing directly from the switch to the internet without NAT. Of course that will not work.

So yet another problem to work around. This can be solved for a large part using Policy-Based Routing (PBR): on the client VLAN interface, redirect all traffic not meant for a private range towards the router. But again, this has complications: the routing table does not reflect the actual routing being done, more administrative overhead, and all packets originated from the local switch will still follow the default (the 3560 switch does not support PBR for locally generated packets).

Next idea: it would be nice to have an extra device that can do GRE and BGP directly towards the internet and my switch can route private range packets towards it. But the constraint is no new device. So that brings me to VRFs: split the current 3560 switch in two: one routing table for the internal routing (vrf MAIN), one for the GRE tunnels (vrf BGP). However, to connect the two VRFs on the same physical device I would need to loop a cable from one switchport to another, and I only have 8 ports. The rest would work out fine: point private ranges from a VLAN interface in one VRF to a next-hop VLAN interface over that cable in another VRF. That second VRF can have a default route towards the internet and set up GRE tunnels. The two VRFs would share one subnet.

Since I don’t want to deal with that extra cable, would it be possible to route between VRFs internally? I’ve tried similar actions before, but those required a route-map and a physical incoming interface. I might as well use PBR if I go that way. Internal interfaces for routing between VRFs exist on ASR series, but not my simple 8-port 3560. But what if I replace the cable with tunnel interfaces? Is it possible to put both endpoints in different VRFs? Yes, the 15.0(2) IOS supports it!

The tunnel interfaces have two commands that are useful for this:

• vrf definition : just like on any other layer 3 interface, it specifies the routing table of the packets in the interface (in the tunnel).
• tunnel vrf :  specifies the underlying VRF from which the packets will be sent, after GRE encapsulation.

With these two commands, it’s possible to have tunnels in one VRF transporting packets for another VRF. The concept is vaguely similar to MPLS-VPN,  where your intermediate (provider) routers only have one routing table which is used to transport packets towards routers that have the VRF-awareness (provider-edge).

interface Vlan2
ip address 192.168.2.1 255.255.255.0
interface Vlan3
ip address 192.168.3.1 255.255.255.0
interface Tunnel75
vrf forwarding MAIN
ip address 192.168.7.5 255.255.255.252
tunnel source Vlan2
tunnel destination 192.168.3.1
interface Tunnel76
vrf forwarding BGP
ip address 192.168.7.6 255.255.255.252
tunnel source Vlan3
tunnel destination 192.168.2.1

So I configure two tunnel interfaces, both in the main routing table. Source and destination are two IP addresses locally configured on the router.  I chose VLAN interface, loopbacks will likely work as well. Inside the tunnels, one is set to the first VRF, the other to the second. One of the VRFs may be shared with the main (outside tunnels) routing table, but it’s not a requirement. Configure both tunnel interfaces as two sides of a point-to-point connection and they come up. Ping works, and even MTU 1500 works over the tunnels, despite the show interface command showing an MTU of only 1476!

Next, I set up BGP to be VRF-aware. Logically, there are two ‘routers’, one of which is the endpoint for the GRE tunnels, and another one which connects to it behind it for internal routing. Normally if it were two physical routers, I would set up internal BGP between them since I’m already using that protocol. But there’s no difference here: you can make the VRFs speak BGP to each other using one single configuration.

router bgp 65000
address-family ipv4 vrf MAIN
neighbor 192.168.7.6 remote-as 65000
network 192.168.0.0 mask 255.255.248.0
neighbor 192.168.7.6 activate
exit-address-family
address-family ipv4 vrf BGP
bgp router-id 192.168.7.6
neighbor 192.168.7.5 remote-as 65000
neighbor 192.168.7.5 activate
exit-address-family

A few points did surface: you need to specify the neighbors (the IP addresses of the local device in the different VRFs) under the correct address families. You also need to specify a route distinguisher under the VRF as it is required for VRF-aware BGP. And maybe the most ironic: you need a bgp router-id set inside the VRF address-family so it differs from the other VRF (the highest interface IP address by default), otherwise the two ‘BGP peers’ will notice the duplicate router-id and it will not work. But after all of that, BGP comes up and routes are exchanged between the two VRFs! For the GRE tunnels towards the internet, the tunnel vrf command is required in the GRE tunnels so they use the correct routing table for routing over the internet.

So what makes this not production-worthy? The software-switching.

The ASIC can only do a set number of actions in a certain sequence without punting towards the switch CPU. Doing a layer 2 CAM table lookup or a layer 3 RIB lookup is one thing. But receiving a packet, have the RIB pointing it to a GRE tunnel, encapsulate, decapsulate and RIB lookup of another VRF is too much. It follows the expected steps in the code accordingly, the IOS software does not ‘see’ what the point is and does not take shortcuts. GRE headers are actually calculated for each packet traversing the ‘internal tunnel’ link. I’ve done a stress test and the CPU would max out at 100% at… 700 kBps, about 5,6 Mbps. So while this is a very interesting configuration and it gives an ideal situation to learn more, it’s just lab stuff.

So that’s the lesson, as stated in the beginning: how not to do it. Can you route between VRFs internally on a Cisco switch or router (not including ASR series)? Yes. Would you want to do it? No!

Advertisement

A little bit of everything.

Yes, a bit of everything, that’s what it has been lately. First, I’m upgrading my home lab switches with more recent IOS versions. The 3560 on my desk can now run EIGRP for IPv6. My 2970 gigabit switch will follow tomorrow, with a K9 IOS this time to make it accessible via SSH.

Second is that I’ve been fine tuning my knowledge of layer 2 security features, using my 3560 desk switch and a 3750 test switch as subjects. RA Guard works great, and so does DHCP Snooping. DHCP Snooping has revealed a third functionality to me, next to countering rogue DHCP servers and preventing DHCP flooding: it also detects when a MAC address that sends an INFORM cannot be present on that port according to the mac address-table. It will generate a ‘%DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL’ message and drop the frame. Seems to be a functionality related to ARP Inspection.
And ARP Inspection, on the other hand, requires some planning of your DHCP servers: if multiple are present and they all reply at the same time, the DHCP Snooping feature, on which ARP Inspection relies, sometimes picks the wrong packet to add to it’s binding table. The client device selects another packet of the ones it received to configure itself, and thus ARP Inspection thinks there’s spoofing going on. I’m still figuring out how to effectively counter that.

Third is that I’ve ordered the CCIE Routing and Switching Certification Guide, 4th Edition hardcover, so I have a lot of reading to be done soon. I have to admit that I don’t like to read ebooks on a big screen so far, and I’m reluctant to buy a reader.
Yesterday I also tried a MPLS lab for the first time, with BGP-MP in GNS3. It did take me several hours but I managed to get it running. Not bad for never having done anything MPLS related before. Still, it’s a huge topic and I’ll need to learn a lot more about that.

And last, I tested an Aruba Remote Access Point (RAP). I’ve already tested Instant Access Points. The RAP works different: once booted, it needs an internet connection. When connecting a computer (it has LAN interfaces, just like a consumer-grade router), it redirects to a setup page, where you have to enter the public IP address of a Wireless LAN Controller (WLC). It then tries to negotiate a tunnel through NAT-T over UDP port 4500 to that WLC. It works by encapsulating IPsec in a UDP header, bypassing any NAT devices that are incapable of keeping the NAT state of IPsec.
The RAP tries to authenticate itself at the WLC using his MAC address. After whitelisting it and configuring a wireless profile (which contains the list of SSIDs to send out), I had to reboot the RAP. I ended up rebooting it several times, thinking it didn’t work, but eventually it turned out my cable had broken due to all the times I plugged it in and out again. The RAP booted fine and started sending out the correct SSIDs. Initially, the wireless connection didn’t hand out an IP to me, but after five minutes, everything suddenly got an IP and started working as if there had never been a problem. Not sure why this happened, although I suspect my NAT router of dropping some of the UDP packets (which wouldn’t be the first time).

A little bit of everything indeed.

Knowledge gained this week.

The past weeks have been very informative for me and I learned a lot about many network-related things. As you may have noticed, I’ve been giving my attention to OpenBSD mostly, as I am determined to learn and control this system. It’s low cost allows for some home use.

More parts will follow, however, I’ve run into problems and my OpenBSD’s do not react as expected for the moment, and sometimes don’t react at all. I’m unsure what is causing it, but it appears to be related to the fact that I’m running all my OpenBSD’s in VMware Workstation 8. They don’t accept certain packets destined for them, even though they show up in tcpdump. I added firewall rules in pf and eventually even disabled pf entirely (the command: ‘pfctl -d’ for disabling and ‘pfctl -e’ for enabling), but it didn’t change anything.

I’ve also sold part of my home lab: two 2611’s and the 2900XL, as well as a console cable, a serial cable, and some Ethernet cables. Stuff I don’t really need anymore, but provide a decent CCNA lab to another motivated network engineer-to-be out there.

And finally, I’ve had the chance to do BGP troubleshooting, when it was discovered a local ISP didn’t provide routing for certain IP prefixes. A very important tool in this is a Looking Glass Server, which is a router that has an iBGP session with an ISP BGP router, on which you can query for the reachability of routes on the internet. Useful, even for single-homed connections, to see if there is an ISP problem. The Looking Glass I use are those of Level 3 Communications: http://lg.level3.net/.

That’s it for this week. For next week: either more OpenBSD, or wireless and EIGRP, depending on what works and what not. Greetings!

New part for the home lab: access server.

My new equipment arrived before the weekend, but I didn’t notice until Christmas because my girlfriend wrapped it up again and put it as a present under the tree. She’s devious at that.

So what is it? Something I wanted for a long time: an access server. It consists of a 2611XM router, a NM-16A module, two octal cables and a console cable. The whole setup allows me to connect out-of-band to 16 other Cisco devices, so I will not have to plug console cables around ever again. How? Well, I could make a blog post about this, but it’s already explained quite perfectly here by David Davis.

I’ve been negotiating a long time for this (since mid-November), and was able to go under a third of the eBay listed prices for the separate components, so I’m very happy. I can now continue my studies.

Speaking of studies: my next study will be CCDA. I’m facing some uncertainties in my life right now and CCDA seems a more realistic short-term goal compared to CCIE. Not that I have abandoned the quest for Internetwork Expert, but the months to come may not give me enough time to properly study such a big project. Either way, CCDA continues the path, and I’ll be using my home lab to further refine my current CCNP skills. Still moving forward.

On popular demand: my home lab.

Yes, finally some pictures. Everybody kept asking me what my home lab looks like. I’m quite happy about it but it’s not perfect, so if you want to set your own lab, use my guide instead.

The pictures:

The first picture shows four 2611 routers and one Cisco Catalyst 2900XL in my rack. The 2611s have two 10 Mbps Ethernet interfaces, one (unused) ISDN interface and one DB60 serial interface. The 2611s run IOS version 12.3 IP Basic, which is the biggest IOS they can hold on their 8 MB flash. Which means support for RIP, OSPF, EIGRP, Frame Relay, NAT, Tunneling, HRSP, VRRP, GLBP, ACLs… But no IPv6.
The 2900XL is ancient: it has twenty-four 100 Mbps ports but runs an unofficial IOS version which just has basic spanning-tree, VLANs and a static port-channel. I tend to use it as a patch panel between the routers mostly.

The second picture shows my server on the bottom of the rack. It’s quite heavy and I don’t have a rack-mount kit. It’s an IBM xSeries 335 server: two 32-bits Xeon single cores clocked at 3.06 Ghz, 1.5 GB RAM, two SAS 36 GB 10k rpm hard drives (with hardware RAID support) and two 1 Gbps Ethernet interfaces. It used to run ESX with some virtualized Linux and Windows servers, but now it has become an Ubuntu with GNS3.

The third picture shows my laptop, an IP Phone, a Catalyst 2970, a Catalyst 3560 PoE and a 2503 router.
The laptop is a Pentium III 400 Mhz with a broken battery, no working USB port and no working wifi. But it has a COM port and provides console access without problem, as well as Wireshark and Putty for test through the 100 Mbps NIC.
The IP Phone is a Cisco 7912, powered by PoE. I have three of these now.
The WS-C2970-24T-E switch is my workhorse for heavy loads: twenty-four 1 Gbps ports with a 24 Gbps backbone, so it can support a full load at all ports at once. It’s IOS version 12.2, with support for MST, PVST, Rapid-PVST, LACP, PAgP, static port-aggregation, VLANs, VTP and security features like port security, DHCP Snooping, DAI and the like.
The WS-C3560-24P-S is a full layer 3 switch with twenty-four 100 Mbps ports and two 1 Gbps Small Form-Factor Pluggable Transceiver (SFP) ports. The 100 Mbps ports have Power over Ethernet (PoE) auto-detect. It has a more recent IOS 12.4 IP Services with crypto installed. At the time of writing, it’s still in production and supports all features of the 2970 plus layer 3 functionality like routing protocols, DHCP, IPv6, ACLs, and also QoS and Private VLANs. It even has a temperature sensor and auto-MDIX.
The 2503 router is the only survivor of a batch of five 2503s, which was my original CCNA home lab together with the 2900XL. It’s ancient, has two serial interfaces and one 10 Mbps Ethernet interface (with an AUI). It supports routing protocols in their basic configuration, NAT, ACLs. In reality, it reaches about 4 Mbps throughput in my lab, making it the only device I have with less throughput in Mbps than power consumption in Watts.

Not photographed: a WS-C3560-8PC-S. It’s an 8-ports 100 Mbps switch with a 1 Gbps uplink. Fanless, completely silent, but all functions of the 24-ports 3560, including PoE.

How to set up a home lab.

I’ve long considered this to be a useless post, because there are plenty of tutorials out there on the net with tips on how to set up your own home lab if you’re going for Cisco certifications, but since people keep asking me, and I’ve learned some things now, I’m going to write an article about this anyway.

Routers
I’m going to start with routers. Good news if you’re short on cash: you can do nearly everything related to routing on GNS3. I’ve already described how to configure it in another blog post. I recommend at least one real router, just to have a better understanding of it.

To look out for:

• A 2611XM, 2621XM, and 2651XM are great models for CCNA, CCNP, even CCIE level tasks. The ‘XM’ means they have extra flash and RAM, which allows them to run a lot of different IOSes. The non-XMs can’t run any IOS that supports IPv6, for example, unless you manually upgrade them. The last ‘1’ in the name means it comes with an extra ethernet interface: two instead of one. Keep in mind the 2611XM has Ethernet interfaces of 10 Mbps, which is fine in a lab environment but can be limiting at times.
• I’ve heard positive reviews about the 1700 and 3600 series routers, but they seem to be a bit more expensive.
• Modules: for extra ethernet ports, you can look out for a NM-1FE-TX, NM-1FE2W (one FastEthernet) or NM-2FE2W (two FastEthernet). A NM-16ESW gives 16 switchports.
• The NM-4A/S and NM-8A/S provide four and eight serial ports respectively, allowing you to configure a router as a frame-relay switch. WIC-1T and WIC-2T also provide serial ports. Keep in mind that a WIC-2T has ‘smart’ serial ports, which are smaller.
• Do not confuse them with an expensive NM-16A/S or NM-32A/S. These allow you to configure a router as a console server, giving out-of-band access to the console of all other lab devices (perhaps I’ll make a blog post about this later).
   
  WIC-1T on the left, WIC-2T on the right.

To avoid:

• Don’t go for any 2600 series without ‘XM’. It will run CCNA topics perfectly, but anything beyond that usually requires a larger IOS for which it has not enough RAM.
• Same for the 2500 series, these are even older, with one Ethernet interface (10 Mbps), leaving you with some basic configurations only.
• Modules: consider any specific module like ATM, BRI/ISDN, Coax… a useless add-on. Voice ports have no real use either.

Switches
For decent practice, you will need switches, as there are is no software that can completely replace them at this time. You will need one at the very minimum for CCNA, but two are better. CCNP needs two, best three, CCIE at least three.

To look out for:

• If you intend to go for just CCNA, maybe CCNP, you’ll need layer 2 switches. Preferred model is 2950: supports the commands, rather cheap on eBay. A 2960 is newer, has some more options (including limited layer 3 abilities and QoS), but is more expensive. A 2970 is like a 2950 but it has gigabit ports: although more expensive, you can use this one as a switch for gaming or in your home network too.
• For CCNP you’ll need two layer 3 switches. For CCIE you can even go for layer 3 switches only. A 3550 has the same advantages as the 2950: supports the commands, relatively cheap.
• For CCIE, I would recommend at least one 3560: vastly more expensive, but supports Private VLANs, better QoS, and these models are used on the official CCIE lab exam I’ve heard, so it’s a good thing to know the equipment.
• A 3750 is a 3560 with a stacking option: fun, but no need for in a lab, so the same value as a 3560.
• Not mandatory, but having a switch with PoE is fun for some extra commands, especially when you have multiple IP Phones in the lab (explained below). This is usually visible with ‘P’ in the model number, e.g. WS-C3560-24PS-S and WS-C3560-24TS-S: both the same model, except the first one is PoE. When in doubt, check the model number on cisco.com.
• The number of ports doesn’t matter for the IOS: an 8-port 3560 can run the same IOS as a 48-port one. The fewer ports, the fewer power they consume. I’ve heard of INE topologies requiring 9-10 ports being used on one switch, so it’s best to have at least two switches with 12 ports or more when going for CCIE.
  
  WS-C3560-8PC-S: no fan, 8 10/100 PoE ethernet ports, gigabit ethernet uplink.

To avoid:

• Any switch with ‘XL’ in the name (almost the opposite of routers, where ‘XM’ is good). These switches are old and don’t even support all commands needed in CCNA. They can be complementary in larger topologies, but that’s about it.
• A 1900 series switch. They’re 10 Mbps, and too old to support most commands, like the ‘XL’ ones.
• Modules: SPFs and GBICs can be useful, optionally, but really aren’t required in a lab.

Other devices
Some other devices can come in handy when setting up your lab. These are in no way mandatory, but if you happen to stumble upon on of these for a bargain, don’t hesitate:

• Cisco IP Phones. They can be pinged, interact with CDP, can mark frames with QoS, have port 80 reachable, and use just a few Watts of power on a PoE switch, and still less than a computer on external power. They’re cheap host computers really, so having one, maybe two, can come in handy, even if not going for a voice cert. The 7900 series are good.
• A rack. Once your lab grows in size, this can be useful because otherwise your lab will become a mess quickly. They’re not cheap though.
• A computer capable of virtualization. Useful for GNS3, or to run VMs, acting as hosts, to try out stuff. You can even consider running an ESX for a while to see what is does and experiment with trunking and port aggregation.
• A non-Cisco network device: networking isn’t purely Cisco, and it’s nice to test a multivendor environment sometimes, though not needed for the certifications. Some people have a Juniper (they have certifications too), I have a Vyatta running, others have HP switches.
• Ethernet cables & cable making gear: making your own ethernet cables is part of the experience. If you’ve never done it, try to practice it. It’s also cheaper than buying premade cables, and you will need a lot for your lab.
• Serial cables: for frame-relay mostly. A DB60 male-to-male DCE/DTE cable fits on the NM-4A/S, NM8A/S and WIC-1T modules.
• I’m just going to mention it: you won’t need fiber. Granted it would be fun to play with, but it’s expensive and above most budgets. A new 5 meter fiber can actually cost more than a second-hand 2621XM. And I wouldn’t recommend buying used fiber.
• A Cisco professional Access Point. I’m not an expert, but an Aironet 1200 series seems to be a reasonable price on eBay. It’s 802.11b/g, as wireless-n is too expensive. But it allows for wireless configurations, like multiple SSIDs mapped to a trunk link. These models work on PoE, so check if they come with a power injector if you don’t have a PoE switch.
• And last: a console cable! This one is mandatory. Try to get these for free first: they’re sometimes included in a sale, or ask the IT staff were you work if they have one to spare (a good way to meet the right people, too). Also, check if your pc has a COM port, or you’ll need a USB-to-COM converter too.
  
  A typical Cisco console cable.

Final advice
At last, some tips when looking for equipment:

• Don’t buy premade packages by IT companies on eBay. They tend to be more expensive than all elements apart.
• Negotiate and haggle. Some of these devices are rather common, so choose the cheapest, and negotiate the price. Perhaps see if they’re willing to throw in something extra, like a free cable.
• Pay attention if accessories are present. A standalone router is cheaper than a router with console cable and serial cable, but if you have to buy the cables separately, will it be more expensive in the long run?
• Take your time. The best bargains for me were those that I’ve waited months for. And if you can’t find something at a price you want to pay, just wait.
• Ask for a printout of the boot sequence. If the seller knows his stuff, he should be able to give that. If the seller doesn’t know what he’s selling, that may be a lucrative deal, but beware of risks. I usually ask if I can pick the device up at their house. If they willingly give the address, that’s a good sign too. The printout also shows if the router is fine: I’ve once seen a printout with one self-test of an interface missing. You know at that point at least one interface is damaged.
• As part of the printout, you should be able to see the IOS version. This is very important: some devices are sold with ‘interim IOS software’, which is not production-ready, or contains only an IP base IOS, while IP services provides the most. This is not such a problem if you have better IOSes yourself, but can influence the price.
• You don’t need to build an entire lab in one step. Build it one device at a time, and learn while doing it. There’s no need for three layer 3 switches if you don’t have a CCNA yet, plan that for later.
• Don’t be too greedy. There is certainly no need to throw money away, but the best way to pass the certification exams is hands-on experience. I honestly wouldn’t have made it without that, and if you don’t work with the equipment all day, you’ll need a lab, online or at home. And the online labs aren’t free, and don’t give the same experience, so it’s actually a well-made investment.

All the above is just my opinion and advice, based on personal experiences. Have anything to add? Let me know in the comments!

Server reconfiguration.

With CCNP SWITCH passed now I can focus on networking in general again now, instead of pure layer 2 stuff. I decided this would be a good moment to reconfigure my server.

When I was gathering materials for my home lab, I had to chance to pick up an IBM xSeries 335 server very cheap. Since it comes with two gigabit NICs and I had never worked with a rack server before, I decided to go for it. I originally installed ESX 3.5, allowing me to research virtual switching and basics of iSCSI, as well as run Windows Server and Red Hat on top of it.

Since I’m familiar with these topics now and not need them directly for my further studies, I decided to install a Linux on it now, and run Dynagen to emulate Cisco routers. Hard decision for me, as I have to admit that I’ve tried a lot with Linux in the past but never could find myself comfortable with it. I downloaded Ubuntu since this would be a relatively user-friendly choice.

Strangely enough for me, things worked out quite well so far: I installed Ubuntu, configured some network settings, installed OpenSSH server and Dynagen, and after about an hour I could log in remotely using SSH and get into Dynagen. I couldn’t do anything in it yet as I need IOS images on the Ubuntu, which I will transfer in the next days, and I’m going to have to read through the Dynagen tutorial, as well as figuring out how to easily create and edit the .net files it uses.

But all in all again a small step towards more labbing options.

Weekly progress.

A busy week it was once again. Special thanks to my friend Steve from Alfa+ who helped me finding half my current home lab, and delivered a rack on Tuesday to put all my networking stuff in. Now it’s less cluttery, it takes less space, and it’s more secure behind a locked door.

I’ve upgraded the remaining routers, bringing all my 2611 routers to IOS 12.3(22). No IPv6 support, but it’s the most recent IOS the flash can hold (2611’s have only 8MB flash), and they now support a range of commands, from QoS to VRRP. I’ve also cabled up the rack, and replaced faulty cables: one ethernet cable didn’t gave any signal anymore, and one power cable caused unpredictable reboots, so that’s solved too now. After that, some labs. I learned the following things this week:

If you make mistakes when configuring HRSP, it’s not always immediately visible in the network, but it often causes MAC address flaps on the switches, which gives an early warning that something is wrong. Also, when finetuning the timers, setting them too low will make the entire HRSP setup unstable because minor hiccups trigger many events.

HRSP with authentication is at times quite pointless. I’ve noticed instances of HRSP with the wrong authentication that kept being active on the network. It’s better to implement logging and alerting to warn when changes are detected, and the above MAC address flaps are noticed, because that’s a typical symptom if everything else seems fine. It’s not really something that can be solved easily: if router A uses HRSP with password Test01, and router B uses HRSP with password Test02, which one is the legitimate router, and which one isn’t? It seems both routers assume the other is wrong and start being an active HRSP router, ignoring the other.

ROMMON mode allows for the direct manipulation of boot settings. It’s never fully explained in any Cisco source for any certification, but it’s really worth looking into. If, no, when something goes wrong and you know your way around ROMMON, you can recover everything in no time. You can also boot an IOS from TFTP to test it, before downloading it to the local flash.

The ‘ip address dhcp’ command will make the router somewhat function like an end device and, depending on the IOS version in use, the received IP will be stored in the running-config, along with a default-gateway. IP options so far do not seem to be copied in running-config. Also, if your DHCP server is a Cisco device, it seems to recognize the difference between a Cisco router and a computer, because the lease time is set to infinite, despite that this is not defined in the DHCP pool. I’m not sure, but it seems to suggest these devices work together (perhaps with CDP?) to allow for speedy network deployment without the disadvantages of dynamic IP addresses. I would research it some more, but it’s really not a priority right now with the CCNP SWITCH exam in mind.

A 3560 switch, to my surprise, supports Auto-MDIX, allowing me to connect switches together using straight cables. It seems you can check it with a hidden command (not visible when using ‘?’): ‘show controllers ethernet FastEthernet0/1 phy’. Nevertheless, I’ll keep using my cross cables for the port aggregation labs, but I now can use my longest (straight) UTP from switch to switch, which comes in handy.

Hopefully next week I’ll make some more progress. Greetings!

New switch for home lab.

I picked up my new switch yesterday, for my home lab. It’s a WS-C2970G-24T-E, and will be replacing the old Catalyst 2900 XL in my lab. I was able to bargain the price well below average eBay listings. On top of that, it’s a full gigabit switch, so I’ll be using it for my home network and/or LAN parties as well. I’m also happy to see it supports a lot more commands compared to the 2900XL, which did not support MST, QoS, and had only limited Etherchannel capabilities, for example.

I’m now completely set to test out everything I need for the CCNP SWITCH exam. I already passed ROUTE, which should boost my confidence, but apart from that it also reminded me that this is not a walk in the park, so I need to be prepared. I hope to take the SWITCH exam in about six weeks. After that, I only have to face the TSHOOT exam and I’m CCNP certified.

For now my lab meets the requirements, but if I ever really go for CCIE, I’ll need to upgrade the routers, as they don’t have enough memory to support everything I need. They’re 2611’s, but no XM’s. I’m still figuring out if I’ll replace them, just buy an extra router with more memory, or if it’s possible to upgrade their flash and RAM. Either way, it’s not needed soon.