Simple Troubleshooting VLAN Wireless internet switch

In the wireless network composition, the use of a lot of equipment is worth a detailed understanding. So today we're going to talk about the problem of VLAN wireless internet switch failures. The following is a netizen's experience sharing: Unit one office area where the two departments VLAN appeared a very strange problem, some websites on the internet can be normal access, and some sites are inaccessible; it's normal to receive mail via Outlook or Foxmail, and sending small messages without attachments is normal, However, sending a large message or a message that contains an attachment cannot be sent normally. The other office area of the unit to the Internet normal.

Fault analysis of VLAN Wireless internet switch

The office area where the user's PC is located is about 2~3 km from the core switch, which has two departments, which are in different VLANs, so we placed the Annette Network management switch AT-8024 in the office area, which is connected to our core switch Cisco 6509 via fiber and a pair of optical transceivers ( Cisco 6509 is configured as: Super Engine SUP720, a 16-port Gigabit Optical Module Ws-x6816-gbic, a 48-port fast switching module ws-x6548-rj-45). Trunk on the corresponding port of the 6509 and Annette Switch connected to the optical transceiver, the Annette switch is divided into two VLANs, respectively 172.25.6.0/24 (hereinafter referred to as VLAN6) and 172.25.7.0/24 (hereinafter referred to as VLAN7), The machines of the two departments are connected to their respective VLANs. The convergence layer switch (Cisco 3550) in other office areas is connected directly to the 6509 Ws-x6816-gbic optical module via the optical module.

The entire network uses an IBM X235 server as a NAT and DHCP server, and all VLAN data accesses the internet via the edge router after the NAT address translation.

Having encountered these strange problems, we initially suspected that NAT and 6509 settings were out of the question, but after checking, the VLAN6 and VLAN7 configurations were exactly the same as the routing configurations in other office areas. Because other VLANs are completely normal on the Internet except for these two VLANs, we have taken the following troubleshooting steps.

(1) The VLAN6 and VLAN7 VLAN information in the Annette Network management switch All deleted, all the ports are zoned in the normal VLAN1 of the Internet, which they completely and VLAN1 the same. But the problem remains the same, while the users in other office areas VLAN1 the Internet.

(2) from the Step (1) inferred that the problem is not the VLAN division, we began to suspect that the optical transceiver or Annette Switch has problems, so the other office area using a normal optical transceiver or Annette switch, the problem remains.

(3) is the link quality problem? Hurriedly find two PCs, one on the Annette Switch, the optical transceiver connected to 6509 of the network cable unplug, directly connected to another machine, configure the same network segment IP, send the largest packet 65500b ping, but the result let us down, The delay is only a few milliseconds, which means there is no problem with the link.

(4) At the time of our "wits", we again connect the optical transceiver and 6509, still use the PC on the Annette to ping the VLAN on the 6509 gateway 172.25.6.210, the problem arises, with small packet ping, basically no delay, but with a large packet ( Close to 18024b,cisco supported maximum packets) there was a drop in the ping when the problem was definitely here.

(5) To re-examine the configuration of Annette and 6509 and NAT servers, we found a problem: the command to configure VLAN6 and VLAN7 on Annette and add the corresponding ports to the VLAN is: Add VLAN 6 ports=23 frame=untagged ( Add Port 23rd to the VLAN6, note that the frame=untagged in this case does not frame the packet at this time, and we have trunk on the Annette Switch and the Cascade Port of 6509 (the first port), and the data is forced to frame, as follows: Add VLAN 1 Ports=1-24 frame=tagged (that is, we have forced the frame of all packets forwarded through the Cascade port, we know that the Annette switch enclosure frame type is IEEE 802.1Q VLAN tag). We then proceed to check the configuration of 6509, enter the interface between VLAN6 and VLAN7, and perform the trunk configuration of the port as follows:

6509#conf T

Enter configuration commands, one per line. End With cntl/z.

6509 (config) #interface gigabitethernet 3/48-into the cascading interface

6509 (config-if) #switchport trunk? -View the situation after trunk

Allowed set allowed VLAN Characteristicswhen interface is in trunking modenative set trunking

Native characteristics when interface was in Trunking modepruning Set

Pruning VLAN characteristics When interface was in trunking mode

Troubleshooting of VLAN Wireless internet switch

As you can see from the above, the port cannot force an IEEE 802.1Q trunk setting, and the other interface conditions are the same. At this point, think of the Super engine SUP720 module, there is an interface is not used to see if it can be forced to seal the frame. Enter the trunk configuration for this 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 was in trunking mode

Encapsulation Set trunking encapsulation when interface was in trunking mode

Native Set trunking native characteristics when interface was in T runking mode

Pruning Set pruning VLAN characteristics when interface was in trunking mode

The bottom line is marked with a encapsulation option than the one seen on the Gigabitethernet 3/48 interface, which shows that the trunk settings for IEEE 802.1Q can be enforced on the interface of the Super engine module.

Enter the following command:

6509 (config-if) #switchport trunk encapsulation? Get:

Dot1q Interface uses 802.1q trunking encapsulation when trunking

ISL Interface uses only ISL trunking encapsulation when trunking

Negotiate Device'll negotiate trunking encapsulation with peer on interface

Go on:

6509 (config-if) #switchport trunk Encapsulation dot1q carriage return;

6509 (config-if) #end

6509#write

Building configuration ...

[OK]

* Note: Version 12.2 (17a) SX is used for the 6509 versions of iOS.

We will jumper to the interface, and then test the network, the original problem has ceased to exist. Users within these two VLANs are returning to normal Web pages, and messages with attachments can be easily sent.

Experience summary of VLAN wireless internet switch failure

As the 48-port fast switching module on Cisco's 6509 core switches is the default for IEEE 802.1Q frames for the trunk lines, our Annette Network Management switch enforces IEEE 802.1Q frames for the trunk line, which is the product of two manufacturers, Therefore, packet transmission may result in protocol negotiation without a good match.

At this point we thought that our network was normal for a long time before this problem occurred, and at the time our approach was: At first only the transceiver was connected to the 6509 Super Engine SUP720 module Gigabitethernet 5/2, we enforced IEEE on this interface 802.1Q frame, later, due to the 48-port fast switching module has a free interface, we will change it to the Gigabitethernet 3/48, the use of the default IEEE 802.1Q frame, but the network use has been normal. This time we made some adjustments to the network and restarted our core switch, and that was the problem. This means that if you first force the Super engine to the IEEE 802.1Q trunk setting, after the network is stabilized, and then the jumper is connected back to the Gigabitethernet 3/48 interface, Cisco 6509 will use the default IEEE 802.1Q frame. With Annette to negotiate the main line, so that packets in the transmission of the agreement on the negotiations will not be a problem, VLAN6 and VLAN7 can be normal access to the Internet. We tried this again, and it turned out to be true.