Snake test is usually performed to check whether a device can handle traffic Tx/Rx to/from all active interfaces at line-rate. The snake test is usually performed as below;
Traffic SENDER—- 0/1(Router)0/2 —- 0/3(same router)0/4—-0/5(same router)0/6— Traffic RECEIVER
ports 0/1-2 are untagged(access ports) in a vlan; say vlan2
ports 0/3-4 are untagged(access ports) in a vlan; say vlan3
ports 0/5-6 are untagged(access ports) in a vlan; say vlan4
So, packets sent by the SENDER at line-rate will be received at the RECEIVER. Same can be done vice-versa. ie: line-rate traffic from RECEIVE to SENDER.
Problem: Packets sent by SENDER were not received at RECEIVER.
- Packets were received at the incoming interface 0/1. SRC MAC was learned on 0/1 in vlan2
- Using interface packet counters and BW usage, it was identified that packets were received on 0/3 but not sent out of interface 0/4.
- So, packets were dropped after received by 0/3. Checked the configuration for vlan3 and it was right.
- Checked the mac-address table and the SRC MAC of the packet was not learned on 0/3-vlan3 in the mac-address-table.
- Checked the cam-table(hardware) and the result was same. SRC MAC was not learned.
- Checked the interface configuration for any ACL/mac learning limit feature and it was not configured.
- For testing purpose, vlan3 was deleted and configured again. Syslog shows PVST new root was selected for vlan3. Catch.
- Checked the PVST port status of 0/3 in vlan3 and it was in BLK state. Reason being the port received its own switch BPDU from 0/2.
- Disabled PVST and mac-address was learned and packets were received at the RECEIVER. STP could be disabled in this case as loop was not formed, unless we manually connect the traffic RECEIVER and SENDER port (0/1 and 0/6) using a cable.
- As another workaround we can configure MSTP with each vlan mapping to each instance.