Chinese
English
Description of the problem
The network is a typical 3G Unicom network, and the wireless service carried on the EMS4 board of OSN3500 equipment has a flash-off phenomenon, and the flash-off time is very short, and there is no alarm for transmission.
Processing
1. After analyzing the latest collected data, it is confirmed that the services moving through site EMS4 are configured with hub spoke function, which will not generate a loop.
:ethn-get-workmode-ex:$bid#,0xff,ip1&&ip$portnumber#
ethn-get-workmode-ex:$bid#,0xff,ip1&&ip$portnumber# ETH VBLP-HUBSPOKEN STATE.
BOARD-ID VB-ID PORT-ID HUB/SPOKEN
13 1 lp1 spoken
13 1 lp2 hub
13 1 lp3 spoken
13 1 lp4 spoken
13 1 lp5 spoken
13 1 lp6 spoken
13 1 lp7 spoken
13 1 lp8 spoken
2. We analyzed the business configuration of EGS4 at the Unicom site, and although we didn't find the business, we can be sure that it's not the bridge business configured, so there won't be any loops.
failed! cmd:0xd2a9 error:0x9b1d NSERR_ETH_VB_NOT_EXIST
failed! cmd:0xd2a9 error:0x9b1d NSERR_ETH_VB_NOT_EXIST
3, the most recent data collection, the move through the mac address learning table collected 100 times, analyze the mac address learning jumps were not found, which further indicates that there is no loop.
4, analyze the data of the three returned Metro1000 sites that frequently flash off, the port was not found to have eth_los alarm, which inferred that NodeB should not reset the port.
Analyze the transmission is not a problem, call the wireless, data to work together to develop a program:
1, collect the data before and after the flash, no packet loss recorded in the black box;
2, in the equipment flash report, VCTRUNCK32 and VCTRUNCK40 two services corresponding to the EFT board reported ETHLOS alarms. Duration 4S. conference call to discuss whether it is a problem with the interface between the device and the Ethernet veneer. The conference call was held to discuss whether it was a problem with the interface between the device and the Ethernet board.
Analyze the data after packet capture:
From the packets on the CE, the destination mac address of the last normal request message and the first abnormal request message have been changed. Submit the problem to the wireless and CE for analysis, and confirm the cause : the device enables the ARP proxy function, and the network network meets the conditions for the ARP proxy function to start, resulting in a device incorrectly proxying the MAC address of other base stations, which leads to the ARP table entries of the other devices on the router being seized, and the devices are unable to interact with the router in a normal way.
Root Cause
The device enables the ARP proxy function and the network grouping meets the conditions for the ARP proxy function to start, resulting in a device incorrectly proxying the MAC addresses of other base stations, which causes the ARP table entries of other devices on the router to be seized and prevents them from interacting with the router with normal messages.
Solution
The following conditions are required for the device ARP proxy function:
1. The source IP address of the received ARP message is in the same network segment as an address on the interface.
2. The source IP address is not in the same subnet as the destination IP address.
3. The outgoing interface of the route is not the same as the incoming interface of the ARP request message.
