Flapping event on Exchange (Zhuan)

Today we see a continuous log message on a three-layer exchange in school:

Host 00:e0:fc:09:bc:f9is flapping between fa0/x and fa0/y. Cisco's official explanation is: Error Message sw_matm-4-macflap_notif:host [enet] I n [chars] [Dec] is flapping between port [chars] and port [chars] The MAC address of a host swings between two ports. Explanation This message means that the switch found the traffic from the specified host flapping between the specified PO Rts. [Enet] is the host MAC address, [chars] [Dec] was the switch ID, and the first and second [chars] is the ports between WHI CH The host traffic is flapping. Recommended action Check the network switches for misconfigurations that might cause a data-forwarding loop. Cisco recommends that the switch In case there is a data transfer loop.

In a network environment where a single loop redundancy is only done on the access layer (backup line) and all running STP, I think there is no possibility of a loop.

There is no server network card between the two ports have done bonding (this situation is the performance of flapping only in two specific ports.) Solution Solutions

is to do Channal-group on the switch. ）

This analysis, the possible fault of the roadside is that the loop was ruled out. Then let's re-analyze the log information. Just now we are concerned about the flapping between, following the MAC address and the port can provide clues. These flapping ports, each time is not the same, but one feature is that all of Huawei's ports, God code port has not been involved. Guess, would it have something to do with some sort of agreement with Huawei? Check out the MAC address that's always in flapping. Host 00:e0:fc:09:bc:f9, Http://bbs.chinaunix.net/thread-1140740-1-1.htmlLZ also played customer service, Huawei -3com Technical Support (800-810-0504-3). The answer is: that's Huawei sends the virtual address used by the multicast for STP, Loopback-detection, NDP, STDP, gratuitous-arp-learning. In other words, all Huawei devices on the network are using that Mac to send messages. Http://www.2cto.com/net/201109/105182.html "The S3600 series switch turns on the STP feature, the peer-to-peer device may appear to report MAC address movement. Its original because the BPDU Packet of the S3600 series switches uses a fixed MAC address as the source Mac. This situation has no effect on normal business. In order to prevent the log information from affecting the normal log information, this kind of log information can be filtered by a function like log information filtering. The source MAC address of the S-series switch spanning Tree Protocol message is 00E0-FC09-BCF9 or 000F-E207-F2E0. "The above red and black League bloggers also said: because Multi-Vendor understanding of the protocol is different, the manufacturers in accordance with their own way to change the way to achieve, so should try to avoid the two-layer interconnection, the docking time must be tested well in advance to remain cautious. 51CTO also has a similar explanation for Http://ruilinux.blog.51cto.com/4265949/870195H3C defined LACP messages (dmac=0180c2000002, H3C Equipment Smac=000f-e207-f2e0,) is also a kind of BPDU message. Because the V3 platform switch does not have its own MAC address set per port, the BPDU source Mac uses the above fixed special Mac as the source MAC address. However, the latest version of the S3600/5600 series switches is supported by using the PORT-MAC command in System view. for fixed source MAC addresses, the H3C switch is the source Mac that does not learn BPDU messages, but some of the friend devices are learning from the source Mac of BPDUs, so the MAC address drift Alarm is sometimes recorded on the friend device. Blogger recommends: for V3 platform switches such as S3600/5600 series switches can be upgraded to the latest version via the PORT-MAC command to change the source MAC address of the BPDU message. However, it is important to note that if there is no loop in the network, then this behavior does not affect business use, so it is not recommended to use the PORT-MAC command to make changes. The reason is clear. Daniel has tried to pass the loopback-detection will not appear similar log. However, it is true that Huawei has a lot of things, and I found that there are similar fixed MAC addresses: http://bbs.c114.net/thread-479741-1-1.html 01-80-c2-00-00-00 is the purpose of the STP, loopback detection MacUse and principle of http://www.cnitblog.com/windforce/archive/2013/04/17/87310.htmlloopback-detection loopback monitoring take H3C switch as an example 1. Turn on global monitoring >loopback-detection enable2, open the corresponding port monitoring >int gig 1/0/1 Loopback-detection Enable3, such as trunk port,    The 1 and 2 steps can only be monitored on the trunk port's default VLAN, requiring monitoring of all VLANs loopback-detection Per-vlan EN4, such as trunk port, Discovery loop only escalation error, need to set port controlled, access port not required. Loopback-detection Control enThe loopback-detection monitors whether a message from the port is returned to the device via the port, and is used to determine if there is a loop on the port's hanging network. on the access port, the Mac list is removed, the block port, the trunk port is escalated, and the port is not disabled.

This problem, which has plagued the two days, can finally come to a conclusion.

Sum up Access layer Huawei equipment upstream port Loopback-detection closed just fine, other usual. Through this thing, under the guidance of the teacher, in various forums, I also have some sentiment bar 1. The two-tier equipment in the campus network is as unified as possible, otherwise certain services to close certain ports will be determined according to show log. 2. For any changes in the network, all to ensure that the network unblocked for the primary purpose. Traffic is more normal, congestion and delay is not serious when, do not act rashly. 3.STP still does not turn off.

Flapping event on Exchange (Zhuan)