In the composition of wireless networks, the use of many devices deserves a detailed understanding. Today we will talk about the failure of VLAN wireless Internet access switches. The following is an experience shared by a netizen: A strange problem occurs in the VLAN of the two departments where an office area is located. Some websites on the Internet can be accessed normally, but some websites cannot; emails received through Outlook or Foxmail are normal, and small emails without attachments are normal. However, large emails or emails with attachments cannot be normally sent. Internet access is normal in other office areas of the Organization.
VLAN wireless Internet access switch Fault Analysis
The Office Area of the user's PC is about 2 to 5 minutes away from the core switch ~ 3 km, the office area has two departments, which belong to different VLANs. Therefore, we have placed the annett Network Management Switch AT-8024 in the office area, connecting to our core switch Cisco 6509 through optical fiber and optical transceiver in the middle (Cisco 6509 configured as: super engine SUP720, a 16-port Gigabit Optical module WS-X6816-GBIC, A 48-port fast switching electrical module WS-X6548-RJ-45 ). Trunk is set up on the port 6509 connecting the optical transceiver and the corresponding port of the annett switch. The annett switch is divided into two VLANs, 172.25.6.0/24 (hereinafter referred to as VLAN6) and 172.25.7.0/24 (hereinafter referred to as VLAN7), machines in the two Departments are connected to their respective VLANs. The aggregation layer switch (Cisco 3550) in other office areas is directly connected to the 6509 WS-X6816-GBIC optical module through the optical module.
The entire network uses an IBM X235 server as the NAT and DHCP servers. The data of all VLANs is first converted to the NAT address before accessing the Internet through the edge router.
When we encountered the above strange problem, we initially suspected that there was a problem with the NAT and 6509 settings. However, after checking, the VLAN6 and VLAN7 configurations are exactly the same as those in other office areas. Because the Internet access of other VLANs except the two VLANs is completely normal, the following steps are taken.
(1) Delete All VLAN information of VLAN6 and VLAN7 on the annett Network Management Switch, and place all ports in VLAN1, which is completely the same as vlan1. However, the problem persists, while users in VLAN1 in other office areas still access the Internet normally.
(2) From step 1, we infer that the problem is not based on VLAN division. We suspect that the problem is caused by optical transceiver or annett switch, as a result, the normal optical transceiver or annett switch used in other office areas is replaced, and the problem persists.
(3) Is it a problem of link quality? Hurry up and find two PCs, one connected to annett switch, unplug the optical transceiver from the 6509 network cable, directly connect to another machine, configure the IP address of the same network segment, the maximum packet sent is B ping, but the result is disappointing. The delay is only a few milliseconds, which indicates that the link is correct.
(4) When We Were "poor at technology", we connected the optical transceiver and the 6509 again. We still pinged the gateway of the VLAN 172.25.6.210 on 6509 using a PC Connected to annett, the problem occurs. When ping with a packet, there is basically no latency, but packet loss occurs when ping with a large packet (close to 18024b, the maximum packet supported by Cisco). The problem must be found here.
(5) re-check the configurations of annett, 6509, and NAT servers. We found a problem: Configure VLAN6 and VLAN7 on annett, and add the corresponding ports to VLAN: add VLAN 6 ports = 23 frame = untagged (add port 23 to VLAN6. Note that frame = untagged indicates that the data is not encapsulated ), however, we set up a Trunk on the cascade port (Port 1) of the annett switch and port 6509, and forcibly set frames for the data. The command is as follows: add VLAN 1 ports = 1-24 frame = tagged (that is, We forcibly block all packets forwarded by cascade ports, we know that the frame type of the annett switch is IEEE 802.1Q VLAN tag ). Then, we continue to check the configuration of 6509, enter the interfaces connecting VLAN6 and VLAN7, and configure the Trunk for this port, as shown below:
6509 # conf t
Enter configuration commands, one per line. End with CNTL/Z.
6509 (config) # interface gigabitEthernet 3/48-enter the cascade interface
6509 (config-if) # switchport trunk? -View the Trunk status
Allowed Set allowed VLAN characteristicswhen interface is in trunking modenative Set trunking
Native characteristics when interface is in trunking modepruning Set
Pruning VLAN characteristics when interface is in trunking mode
VLAN wireless Internet access switch troubleshooting
It can be seen from the above: the port cannot be forcibly set to the Trunk of IEEE 802.1Q, and other interfaces are the same. In this case, another interface on the super engine SUP720 module is useless. Check whether the interface can forcibly block frames. Go to the Trunk configuration of the port and see the following information.
6509 # conf t
Enter configuration commands, one per line. End with CNTL/Z.
6509 (config) # interface gigabitEthernet 5/2
6509 (config-if) # switchport trunk?
Allowed Set allowed VLAN characteristics when interface is in trunking mode
Encapsulation Set trunking encapsulation when interface is in trunking mode
Native Set trunking native characteristics when interface is in t runking mode
Pruning Set pruning VLAN characteristics when interface is in trunking mode
The following figure shows an encapsulation option more than the one displayed on the gigabitEthernet 3/48 interface. It can be seen that the Trunk setting of IEEE 802.1Q can be forced on the interface of the super engine module.
Run the following command:
6509 (config-if) # switchport trunk encapsulation? Get:
Dot1q Interface uses only 802.1q trunking encapsulation when trunking
Isl Interface uses only ISL trunking encapsulation when trunking
Negotiate Device will negotiate trunking encapsulation with peer on interface
Continue:
6509 (config-if) # switchport trunk encapsulation dot1q press ENTER;
6509 (config-if) # end
6509 # write
Building configuration...
[OK]
* Note: the IOS Version 6509 is Version 12.2 (17a) SX.
We connect the jumper to this interface and test the network. The original problem no longer exists. Users in these two VLANs can access the webpage and send emails with attachments easily.
VLAN wireless Internet access switch fault Experience Summary
Because the 48-port fast switching electrical module on the Cisco 6509 core switch uses IEEE 802.1Q frame by default, our annett Network Management Switch forces IEEE 802.1Q frame sealing on the trunk line, this is the product of the two manufacturers. Therefore, it may lead to a situation where data packets cannot be well matched during protocol negotiation.
At this time, we thought that our network was normal for a long time before this problem occurred. At that time, our approach was: at first, only the transceiver was connected to the 6509 super engine SUP720 module gigabitEthernet 5/2 port. On this interface, we forced IEEE 802.1Q frame Sealing. Later, because of the 48-port Fast Switching Module's free-time interface, we changed it to the gigabitEthernet 3/48 port, and used the default IEEE 802.1Q frame, but the network usage has been normal. This time we made some adjustments to the network and restarted our core switch. This problem occurs. This indicates that if the super engine is forced to configure the Trunk of IEEE 802.1Q, And the jumper is connected back to the gigabitEthernet 3/48 interface after the network is stable, Cisco 6509 uses the default IEEE 802.1Q frame, negotiate the trunk line protocol with annett, so that the protocol negotiation during data transmission will not fail, and VLAN6 and VLAN7 will be able to access the Internet normally. We tried it again later, and it turns out to be true.
Edit recommendations]