It’s starting to become a tradition for me to list up the things I’ve learned in the past week. I’ve been able to dedicate some time to my lab the past days, and again I’m happy I’ve made the purchase. You just encounter too much details with the real material that aren’t covered by any book. Also, I tend to learn faster by doing, and actually seeing the output of all the ‘show’ commands helps, as well as figuring out what I did wrong this time. If you’re reading this, trying to get certified and don’t have a lab yet: get one. Now. I can proudly say I haven’t failed a single exam so far, and I intend to keep it that way.

Back on topic: here’s my list of this week’s surprising discoveries.

My 2970 has no LLDP support. I didn’t expect that from a gigabit switch. I’m going to check out, when I have the time, whether this depends on the IOS or not.

Private VLANs can’t be combined with a voice VLAN. Not completely surprising given PVLANs were designed with server- and ISP-infrastructure in mind, but it’s a missed chance I’d say. Maybe this will change in the future.

A badly formatted DHCP packet will make a DHCP client reject IP addresses. I’m referring to my experiments with DHCP options: if one of the options contains the wrong information, the DHCP client will reject all information, even if a valid IP, default-router and DNS are offered. A Windows client will then default to a 169.254.0.0/16 IP, which gives the impression no DHCP negotiation took place at all. Luckily, Wireshark clearly identifies this problem.

Again DHCP: if a Cisco router or switch (SVI) uses DHCP, the received default-router is added to the routing table as a next hop of a default route, with AD 254. This is quite useful for rapid deployment, and the high AD makes sure it doesn’t interfere with the routing protocols.

IP Phones can ping but don’t respond that well to it: on average they take 60ms to respond, other hops not included. My guess is the echo reply must be done in software, and the IP Phone has a low speed processor. Probably voice encodings are done with an ASIC, or just don’t need that much processing power. But I’m no voice expert.

Also, when pinging, the advertised TTL is that of the return-path. This means it depends on the target device TTL which value you’ll see, and in case of a different return-path, the TTL is not accurate.

I’ve always wondered why Cisco switches don’t have a CST (Common Spanning-Tree) option, just MST, PVST and RPVST. Now I know: MST in it’s basic setting (one instance for all VLANs) acts just like CST. So just configure MST in a multi-vendor environment and it should work. If I ever have the chance, I’ll test it to be sure.

And finally: for some reason port costs in MST are not the same as in (R)PVST. This means you have to be careful when migrating from one STP implementation to the other, especially when port costs are configured.

Advertisements