For the impatient – bug id 5572.
A colleague called the other day – one of our machines had rebooted, and quite a number of network interfaces were not working. This particular machine has quite a number of vlans connected to it – most of them can’t work. The primary interface (eth0), still works fine; only eth0.xxx interfaces were affected.
Tcpdump shows that the arp requests were being made to the vlan interfaces, and replies were sent. However, the replies were not getting to other machines. After quite some troubleshooting, we decided to downgrade the kernel. That fixed the problem!
Seems like a bug has crept into tg3 kernel module in the 2.6.18-308 kernel. Hope this helps someone.
Recently, we had a bit of a puzzle over VTP pruning. We have two switches, S1 and S2. Both of them are VTP Clients in the same domain and have pruning enabled. There is no VTP server in that domain (don’t ask).
We needed to add a VLAN to S1, but since it is a VTP client, that is not going to happen. We decided to change S1 VTP domain name to something else first, then change it a Server in the new domain. This is to prevent the S1 from changing the vlans for other clients in the old VTP domain (S2).
However, changing the VTP domain resulted in HSRP of S1 and S2 breaking. After some troubleshooting, we found out that it was caused that by us pruning vlans!
Basically, when pruning is switched on, broadcasts in a vlan are not sent to a downstream switch if that switch has no client ports in that vlan. We suspect that active vlans information of a downstream switch are propagated by VTP in a domain. When we changed the VTP domain of S1, it would have appeared to S2 that S1 has no active VLANs, thereby pruning all traffic to it! 🙂
The solution? Set S1 to VTP mode transparent. Then you can make all the changes you want to it, and it will not partake in any VTP. Should have known better, I think this is in CCNA.