1. There are 10 Epson printers in the store, which are connected to the network through a wired connection, and print services are issued through a PC (layer 2 on the same network segment) or wireless Ipad (layer 3 across the network segment), and the printer cannot print normally;
2. When the printer is directly connected to the PC, the printer can print directly;
3. When the printer and PC are connected to a HUB at the same time, they can also print directly; when the hub is connected to the network immediately, it is found that it cannot print;
4. Another strange phenomenon, some ip addresses (10.127.46.13 and 11) cannot be printed. After changing the IP address, the printer can print; check the arp on the device side, the mac information is normal, and the device has no abnormal log printing.
For this scenario: connect the printer and PC to the L2SW, change the printer's IP address to 10.127.46.89, and the printer can print at this time.
In other words, the problem now is that after the switch is connected to the network, some specific addresses cannot be printed. The problem is very strange.
1. First, perform port mirroring and packet capture on the downstream port of L3SW connected to L2SW. Because everything is normal when the switch is not connected to the network, there should be no problem with the second layer. We first paid attention to whether there is an abnormality in the third layer network.
Capture packets successfully printed across L2:
Direct connection to successfully printed packets:
Unsuccessful packet capture when printing across L2:
After comparing the captured packets, it is found that in the captured packets that have not been successfully printed, when the TCP is disconnected, the PC sends a FIN, ACK message to the printer under normal circumstances, and the printer replies with a FIN, ACK message; but when the printing is not successful, the printer have not reply FIN，ACK packets.
2. Subsequent tests found that after the L2SW upstream interface was down, the fault disappeared. It is suspected that there are packets coming from the upstream interface affecting the printers of .11 and .13. This is verified by capturing packets on the upstream port. The 10.127.44.6 server has been sending packets to .11 and .13, and the fault disappeared after the server was isolated.
3.Because a server on the client site installed two types of printer drivers, the driver conflicts, and the client changed the security certificate of the server's default windows; as a result, a large number of TCP messages occupy the ports of a specific printer (11,13), affecting the printing business.
The server in question was powered off, a new server was enabled, the business was redeployed, conflicting drivers were avoided, the windows security certificate was not manually modified, the failure no longer recurred, and the test printing business was normal.