become an IT expert with #humanITy


My name is Tomek De Wille. I’m the owner of humanITy, a small IT training shop for all those of you who want to change their lives and believe they can.

I used to be a language teacher but in 2009 I had a sudden change of heart. I knew I could do more than teach. I joined Nokia as a technical editor and started learning about networks. Fast forward to 2017 and i’m a senior network engineer, troubleshooting networks all around the globe. Because I still love teaching, i’ve created humanITy – a home for anyone who wants to become an IT expert. We run IT courses on Saturdays and Sundays in the beautiful city of Wroclaw, the very heart of Europe.

For a very brief (and very true) explanation of why we founded humanity, see this 3minute youtube video

If you speak English and would like to start a successful career in IT, have a look at our site http://www.humanity.pl

Follow our blog for discount codes, information on new and exciting IT courses and much, much more.

Upgrades can be risky


I’ve recently upgraded a client switch 4500 with sup 6l-e to the latest software and it was one of the worse decisions i’ve taken in my life. Without going into too much details, a lot of people had to go home on two days in a row because of problems with dot1x authentications of APs and ip phones.

A word of advice, therefore: do not be too hasty in your upgrades. Wait until others have upgraded, read forums, talk to other admins. If there’s a serious vulnerability in your current software, try to make sure it cannot be exploited via some other measures than an upgrade to a possibly unstable version.
Ideally, create a test lab where you test client configurations.

***do not use version 15.2(2)E7 on your 4500s.***

It’s a bug.


Today I was troubleshooting an ”almost-successful” upgrade on a 4506 sup 6l-e. An almost-successful upgrade from an 15.1 sg6 release to a brand new 15.2.2e7.

Oh my god. The switch started crashing big time every few hours. Show platform crashdump shows dot1x memory allocation problems with a large number of authentications. This caused a 15 minute outage for a whole floor 4 times.

Seriously, one should not apply the latest software without extensive testing.


IOS upgrade checks


Recently i’ve had to upgrade a large number of devices and the ios was quite new and therefore risky. We came up with some checks to make sure that post-upgrade the device will be usable.

Step 1:

I collect as much output as possible:

show vlan brief | redirect
show cdp nei | redirect
show int status | redirect
show arp | redirect
show module | redirect

show run | redirect
show power inline | redirect
show mac address-table | redirect
show etherchannel summary | redirect

show int trunk | redirect
show authentication sessions | redirect

Step 2

I make sure there is enough room on the flash. If there is, I download the new image to the flash (or bootflash). If there isn’t, i delete the existing image.

Step 3

I verify the new image (verify /md5 flash:thenewimage.bin)

Step 4

I delete the old boot system variable (no boot system) and add the new boot system variable to point to the new .bin file.

Step 5

I make sure with the command show bootvar that config-register is 0x2102 so that the boot system variable is taken into account upon the reload

Step 6

I write the config (wr)

Step 7

I reload the switch and keep my fingers crossed

Step 8

When the device reloads, I check the log buffer, I collect all the output from show commands once again to have something to compare the pre-reload files with. Finally, I monitor the reloaded device for 24 hours to make sure it doesn’t crash.


And if it does crash… well.. it’s a different story entirely.

Paranoid IOS upgrade checks


Today I’m at work and i’m doing paranoid upgrade checks before equally paranoid (amount-wise) upgrades.

Let’s say that before the upgrade you want to check how many CDP neighbors you have. Your naming plan for your infrastructure is simple:

  • names of switches begin with SWT
  • names of APs begin with AP
  • names of phones begin with SEP
  • etc

Of course we run the command show cdp neighbor to display the number of neighbors. We want to do two things before an upgrade:

  • count the number of neighbors
  • export the output of the command to some backup server


You can count the number of neighbors with:

show cdp neighbor | count ^(SWT|AP|SEP)

Number of lines which match regexp = 44


You can export the output of any command with the redirect option:

show cdp neighbor | redirect

and then after the upgrade:

show cdp neighbor | redirect




Eigrp built-in safety


Here’s an interesting case. I run eigrp on all routers. On R7 i check what path it has to the loopback of R6. In theory it should have one route but it should be aware in eigrp topology of two paths (an extra theoretical path via R3). But it is not. It only has one path to loopback of R6, that is through R6. Why is that?



Let’s check R3:

R3#show ip route
Routing entry for
Known via „eigrp 100”, distance 90, metric 435200, type internal
Redistributing via eigrp 100
Last update from on Ethernet0/0.37, 00:05:27 ago
Routing Descriptor Blocks:, from, 00:05:27 ago, via Ethernet0/0.37
Route metric is 435200, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
*, from, 00:05:27 ago, via Ethernet0/0.13
Route metric is 435200, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

It load balances between R7 and R1. This is the answer. If I go through you, I won’t send you information that you could even in theory go through me because we might cause a loop.

It is enough for R3 to add some extra delay on the link to R7 and it will choose one path only (via R1). Then it will be able to send a routing update to R7 about the path through R1. Now R7 is aware of two possible paths: through R6 and R3.

Another solution would be to add a lot of delay on R7 on the link between R7 and R6. This will also cause R3 to stop load-balancing, send info to R7, and R7 will now have two possible paths in its eigrp topology table.


IOS deprecates commands and causes confusion


Today i was playing with some eigrp summary route scenarios and one thing got me laughing. You know that summary routes in eigrp have a distance of 5 so when you set up a summary route, it installs a route for the whole summary to null0.

So I tried increasing the distance to 111 for the summary route so that I can send to this router a summary from some other router in e.g. ospf which has 110 as its distance.

I remembered that the option to change the distance of the summary was there somewhere…but it’s not there anymore. Only the leak-map option is left.

R5(config-subif)#ip summary-address eigrp 100 ?
leak-map Allow dynamic prefixes based on the leak-map

but what if we do it anyway?

R5(config-subif)#ip summary-address eigrp 100 20
%EIGRP: summary-address accepted but distance option deprecated; use summary-metric command for distance.

ROFL. Why would they deprecate this in favour of ”summary-metric”? This so doesn’t make sense…

Anyways, this also proves true in other cases so if you know a command should (once was?) there, try to use it anyway but be careful when upgrading ios because deprecated means it might be gone in the next release and you will be in trouble when you upgrade and cause an outage because of this 😉

In this case IOS was nice and converted the deprecated command automatically to:

summary-metric distance 20

btw if you don’t want to install a route to null0, use distance 255:

summary-metric distance 255

Note that in some ios versions doing this prevents the summary from being sent out AND it prevents more specific routes from being sent out either. So it’s like a distribute list with a < deny all routes from this router>. Of course, routes from other routers are still forwarded.