The book is finally out, at least on Safaribooks. I’ve read 1/3 so far and it’s a nice little refresher of things i read a long time ago and managed to forget, like what happens if you have MST between 2 switches with 2 links connecting them. Now you map vlan 10 instance 1 but leave vlan 20 in instance 0. Then you try to load balance the traffic by putting vlan 10 on upper link and vlan 20 on lower link only. Of course the vlan 20 traffic will be blocked because IST is a member of all interfaces 😀 so you end up with connectivity only on vlan 10 and hosts in vlan 20 lose connectivity. Of course, why would you not map all vlans to mst instances other than 0 ? laziness, i guess. I’ll try to read the whole book this week to see if it’s any good. I kind of expected more depth, but maybe this is the idea of the ”core” book? to keep it simple?
Anyways, i’ve been playing with very random things recently, like dmvpn with ikev2 and certificates between ASRs and new shiny c1116s. Something that is worth testing in gns3 is a weird situation where a branch router is reloaded and dmvpn gets stuck in NHRP state. What i’ve found is that the hub router mistakenly deletes both the old IKE and the new IKE, so it can never decrypt the data. It’s only when DPD on the branch router reinitializes IKE that NHRP starts working properly. So a quick and dirty fix of this bug is to lower DPD to 30 seconds but the bug is still there whenever a branch site loses power. oh well.
Another activity that i’ve been lucky to be assigned to was testing of 9336 nexus switches for a server block with an emphasis on vPC. It’s rare that you can get a free lab so I tried to test a lot of vPC features, like vPC autorecovery, layer3 peer router, peer switch etc. All in all the best assignment i’ve had in months.
Finally, i’d like to share a hilarious ”team work” situation i’ve seen recently; it’s quite recent so i hope nobody feels offended but i can’t help myself: the client reports (6 months ago) that a company laptop may have been stolen and asks the firewall team to block an internal IP from talking with the enterprise network. The brave fw team blocks this one IP and the matter is put to sleep. Now fast forward to October. A client PC can’t connect to certain IPs. The brave fw team receives the incident and logs a comment saying that everything is fine, because this deny action is as per client request 6 months earlier. The confused NOC team asks to remove the rule because it is no longer needed, the laptop was never stolen in the first place, and this is quite possibly a different laptop that happened to receive the same IP because this IP is in the dhcp scope. This request is rejected by the fw team who says that the IP address in question should simply be excluded from the DHCP scope instead because the rule was created based on customer request so it should stay. The ticket then detiorates into a senseless ping-pong (my opinion is so much better than yours etc.).
It is so sad that each team lives in their antinuke silo where everything is comfy and warm, with thick ITIL carpets and linen. And you do not leave your silo because your friends are inside and outside there could be wolves! and dragons! or worse – blood traitors! Giving in to your enemy request once is like inviting a vampire into your home. One never knows what will happen. It’s best to barricade the door and wait for the postnuclear winter. You can only leave your bunker according to ITIL rules. Does ITIL say to eat? No? then die of hunger we shall!