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>Search


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


Analysis of Alcatel NGN Connectivity to NE40E ARP Problem

Publication Date:  2012-07-27 Views:  104 Downloads:  0

Issue Description

The diagram above illustrates the topology of the NE40E and A7515 connectivity. Two VLANIFs are configured on R1, and R2. Both VLANIFs have the same VLAN ID, and both VLANIFs are configured with VRRP Backup Group. VRRP state of R1, R2 is Master, Backup respectively. Two ports are members of the mentioned VLAN on each NE40E; one port is on slot7 and the other port on slot3. The port on slot3 is also a member of an Eth-Trunk interface (Link Aggregation interface) between the two NE40Es.
A7515 links works in Active/Standby mode; both of them are physically up, but only is logically up.
Behavior of the NE40E and A7515 as follows:
1. R1, R2 are able to reach A7515, ping was used to test the connectivity
2. When the active link is disconnected, R1 is able to ping A7515, however R2 is unable to do so.
3. When ARP Table is reset or ARP aging timer is expired for A7515 on R2, connectivity is restored

Alarm Information

When the active link is disconnected, R1 is able to ping A7515, however R2 is unable to do so.

Handling Process

? Asks Alcatel to modify the ARP packet sent by A7515 to match the RFC 3344 criteria
? Make one port of LPU7 member of Eth-Trunk on LPU3 or make the Eth-Trunk member ports on LPU7, this way the previous ARP entries will exist on the board that receives the ARP packet
? Connect both links of A7515 on one NE40E, and configure the two ports on NE40E on the same VLANIF, this was the switchover will happen on the MAC-learning level.

Root Cause

1. R1, and R2 connectivity is fine to A7515
2. R1 has an ARP entry on both LPU7 and SRU, pointing out to Gig7/0/2 interface in order to reach A7515 (MAC+IP). R2has an ARP entry on both LPU3 and SRU, pointing out to Eth-Trunk interface in order to reach A7515 (MAC+IP). 
3. After we disconnect the active link between NE40E and A7515, R1 deletes its ARP entry on LPU7 and SRU since the interface is physically down. R2 still have the same old entry
4. After the switchover between the active and standby links of A7515; A7515 should send a Gratuitous ARP packet so R1 and R2 update their ARP Table.
5. A7515 sends a Gratuitous ARP packet, R2 receives the packet on LPU7 however it doesn't update it ARP table entries, since there was no entry before on LPU7 for A7515, and also R2 still have ARP entry for A7515 on LPU3 through Eth-Trunk, this is based in VRP implementation of NE40E.
6. However, with current VRP implementation; it must update its ARP table when receiving specifically Gratuitous ARP packet.
7. A debug of A7515 ARP packet showed that, the ARP header structure is different from what the characteristics of Gratuitous ARP packet should be like. In RFC 3344, Gratuitous ARP packet structure is described as follows:
RFC 3344 Section 4.6
A Gratuitous ARP [45] is an ARP packet sent by a node in order to spontaneously cause other nodes to update an entry in their ARP cache.  A gratuitous ARP MAY use either an ARP Request or an ARP Reply packet.  In either case, the ARP Sender Protocol Address and ARP Target Protocol Address are both set to the IP address of the cache entry to be updated, and the ARP Sender Hardware Address is set to the link-layer address to which this cache entry should be updated.  When using an ARP Reply packet, the Target Hardware Address is also set to the link-layer address to which this cache entry should be updated (this field is not used in an ARP Request packet).
But accordingly to the structure of the ARP packet A7515 sends, we notice it's different from the Gratuitous ARP structure, the Source Protocol Addresses in A7515 packet is all 1s (FF FF FF FF), where it should be the equipment IP address. Please find below the contents of the packet sent of A7515
*0.179268590 JBL_2.H ETH/8/eth_rcv:Slot=7;Receive an Eth Packet, interface : Vlanif204, eth format: 0, length: 80, prototype: 0806 arp, src_eth_addr: 0007-7203-b0e1, dst_eth_addr: ffff-ffff-ffff
JBL_2.H ETH/8/eth_verbose:Slot=7; FF FF FF FF FF FF 00 07 72 03 B0 E1 08 06 00 01
JBL_2.H ETH/8/eth_verbose:Slot=7; 08 00 06 04 00 02 00 07 72 03 B0 E1 0A D0 20 3E
JBL_2.H ETH/8/eth_verbose:Slot=7; 00 00 00 00 00 00 FF FF FF FF 0A A7 C0 B0 37 37


This document explains the link switchover problem of Alcatel A7515 MGW (hereafter referred to as A7515) when connected to Net Engine 40E (hereafter referred to as NE40E). A7515 sends a Gratuitous ARP message after switchover; however NE40E fails to update its ARP table, causing the communication to be lost between them. The reason being that Alcatel Gratuitous ARP packet does not comply to the RFC structure