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!
Reggle 
HSRP authentication … as it may seem quite pointless it’s also a way to make L2 attacks visible. Main reason one wants to implement it, is because of misconfig or malicious config by a third party. I can imagine vlan’s containing provider equipment and your own equipment both running HSRP. When there is no HSRP authentication, the provider (or you) could become a part of the HSRP group and claim the active IP. This way all traffic is routed through the “malicious” device, making it possible to capture it. When done properly users will even not notice the active IP has jumped to another device.
When HSRP authentication is active, this will not be possible, moreover users will start complaining their network is degraded and one can easily identify the problem by looking at the routerlogs.
Personally I would always use HSRP authentication as a countermeasure for illegal activities in your ‘shared’ L2 Lan’s and misconfiguration.
Futhermore, why not post some images of your testenvironment. I’m curious what equipment you use 🙂
Thanks for the clarification from someone in the field!
As soon as I have a working camera, I’ll take pictures 😉