No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

The communication was interrupted by problem of mac-Learning for VE interface

Publication Date:  2012-07-27 Views:  57 Downloads:  0
Issue Description
1. Version: CX600V600R001C00SPC800
2. Topology: PC-1 <---->CX600<---->PC-2
3. Connection Description:
     3.1  CX600 enable the VE interface feature connecting to PC-1.
     3.2  CX600 connect to PC-2 with normal way.
4. PC-1 can't ping PC-2 mutually.

Alarm Information
Null

Handling Process
 In order to change the MAC which responds ARP for L3VE interface, we can use the command: set access-ve-mac in slot view, the command likes this way to configure:

<HUAWEI> system-view
[HUAWEI] slot 1
[HUAWEI-slot-1] set access-ve-mac 0001-0001-0001



Root Cause

1. The PC-1 can learn the ARP entry for GW, but the CX600 can't learn the PC-1 ARP entry.
2. The PC-2's ARP learning is normal.
3. Due to L2VE and L3VE interfaces  were using the Bridge MAC as own MAC, so when CX600 received the ARP replay from PC-1 with the destination  MAC as Bridge MAC, after the ARP request with source MAC as Bridge MAC sent out by CX600, thus the ARP reply will be sent to CX600's CPU and then drop them.
4. The Bridge MAC is just used for the communication with it, such as: BPDU, the Bridge MAC is not in change of processing ARP, Normally, the source MAC of ARP request should be L3 interface's MAC, not Bridge MAC.



Suggestions
This kind of problem will be taken place in L2VPN access into L3VPN or other scenarios with VE interface.

In addition, we have to plan the appropriate VE MAC to avoid MAC conflict.



END