As I recently passed my CCNA I decided to jump right into the CCNP studies while the information was still fresh in my brain and while I was still on a high. I decided to start with the SWITCH exam (642-813) as my first goal .
I am starting by reading through the official cisco press book and so far (after 130 pages) I am happy with my understanding of the material, and it almost seems like the text up till now has been a refresher from the CCNA course, albeit a slightly deeper dive into switching fundamentals.
Tonight I fired up a couple of 3550’s so I could try out etherchannel, the concept seems fairly straight forward but I have not configured this before so I wanted to give it a try.
For ports to form an etherchannel they need to share the same characteristics, (port speed, duplex, trunk or access port) for example; you cant put an access port and a trunk port into the same etherchannel group.
I flattened the config on both switches as they were previously used for ccna studies. I have 3 crossover cables connecting both switches which automatically came up as trunk ports, because the default mode is dynamic desirable.
Then in interface mode on all trunk ports I configured channel-group 1 mode desirable on all the trunk links on both switches. This all went smoothly and I could see that the channel formed successfully by using show etherchannel (all without changing any of the defaults).
Since that was pretty easy, I thought as they are trunk ports I would setup VTP in a client server topology. Not thinking anything of it I configured the client first and then in turn enabled the server, I added some vlans to the server, checked the vtp status on the client and was surprised when they did not propagate to the vtp client.
Running a show vtp status on the server showed the following at the bottom of the output:
*** MD5 digest checksum mismatch on trunk: Po1 ***
A few minutes on google and I had dug up a link to this thread on the CLN (https://learningnetwork.cisco.com/thread/21771) which suggested that changing to transparent and then back to client mode again (effectively disabling VTP and re-enabling it) however this did not resolve the issue.
Further in the thread suggested that the quickest way to resolve the issue was to create a vlan and then remove it, this makes sense as it will force a vtp update. This happens because the change triggers a configuration revision number update which forces a vtp update to be sent to the client from the server. Checking the vtp status on the client switch confirmed that the vlans had propagated correctly, back on the server vtp status again confirms that MD5 error is gone as well.