Monthly Archives: January 2017

Issue Description

1. Topology

2. After configured, the sub ring status is preforwarding on S7700
RRPP Ring      : 2
Ring Level     : 1
Node Mode    : Edge Transit
Ring State     : PreForwarding
Is Enabled     : Enable                             Is Active: Yes
Primary port   : Ethernet2/0/2                 Port status: UP
Ethernet2/0/3                 Port status: UP
Secondary port : Ethernet2/0/5              Port status: BLOCKED

Alarm Information

None

Handling Process

Check all configuration on device. Found that RRPP working-mode is GB on S7700, but on S57 it is HW mode. Because of different mode, there are different node and configuration on Switch.
Let customer change RRPP working-mode to HW same with S5700 and test it works fine.

Root Cause

1. Wrong Configuration
2. RRPP calculation Issue

Suggestions

1. Changing RRPP working-mode needs to disable RRPP first and delete the old configuration
2. On S5700, RRPP only supports HW  working-mode and cannot be configured. S7700 supports both modes.

Share

Issue Description

There are situations where we need to find out the corespondence between the ifindex and the interface names. For instance, if we receive a log on the switch that is refereing to a ifindex number but does not mention the exact interface name, we would need to know this corelation in order to indentify where the problem resides.

Example:

Feb  9 2016 08:47:12 xxxx %%01IFNET/4/BWRATE_OUT_RESUME(l)[0]:Interface output flow bandwidth usage was restored to the log threshold. (Interface=10, BandWidthUsage=85, LogThreshold=90)

Solution

To indentify the interface index of the interfaces, I can suggest the following solutions:

–Ru-Run the display rm interface command to check the ifindex of the intenterface directly in the CLI . By running this command the ifindex is shown in hex and you would need to convert it to decimal :

Example:

[R6_U11_S5710]display rm interface

Name: GigabitEthernet0/0/5

Physical IF Info:

IfnetIndex: 0xA         //  convert the hex value to decimal to obtain the ifindex (0xA = 10 )

State: DOWN BCA MULT

Hardware Address: F84A-BFF0-2E70

Slot: 0(Logic Slot: 9)

IntType: 36, PriLog: 0, MTU: 1500, Reference Count: 1

Bandwidth: 0, 100000000

Baudrate: 0, 100000000

Delay: 0, Reliability: 0, Load: 0

LDP-ISIS sync capability: disabled

LDP-OSPF sync capability: disabled

InstanceID: 0, Instance Name: Public

Age: 88548sec

-Use the below public OIDs to query the name and the ifindexes of the interfaces

ifName is Oid .1.3.6.1.2.1.31.1.1.1.1 and ifIndex is oid .1.3.6.1.2.1.2.2.1.1

Share

Issue Description

1. Topology
Client — L3VPN — NE40E(PE) —- S5700HI-1(P) — S5700HI(PE) —– Access Switch — Server

2. Problem description
Configure VLL service between NE40E and S5700HI. Found some servers can ping and some cannot ping from client.

Alarm Information

None

Handling Process

1. Ping Server from access switch and it is ok.
2. Ping from NE40E and it is failed. Make traffic statistics on access switch to check icmp pakcet reach or not.
Result: No icmp packet reach
3. Check that there is no ARP table on NE40E. So the problem is ARP learning issue. Make ARP pakcets statistics on access switch. No arp request arrives.
4. on S5700HI P devices, capture packets on the port connects to NE40E. And found there is no arp packet.
5. Check the port configuration on NE40E. Customer configure QinQ sub interfaces. One command “arp broadcast enable” is missed.
interface Virtual-Ethernet1/1/1.100
control-vid 310 qinq-termination
qinq termination pe-vid 1002 ce-vid 310
ip binding vpn-instance l3v-sermgmt
ip address X.X.X.X 255.255.255.128
arp broadcast enable

Root Cause

1.Configure Issue
2. Network Issue

Suggestions

For sub interface and QinQ sub interface, command “arp broadcast enable” must be configured. Or device cannot send out the arp packets.

Share

Issue Description

When the issue happened, S5700 stack member cannot be accessed intermittently. Status information about this stack member cannot be obtained through commands and this fault cannot be automatically rectified. After powered off and restarted the stack member, the fault was disappeared.
The command output showed that information about a stack member cannot be obtained. The following uses the display environment command as an example.

S5700

The preceding command output shows that temperature information about all stack members except the device with SlotID4 can be obtained normally. That is, obtaining temperature information about the stack member with slot ID 4 failed.

Alarm Information

None

Handling Process

1. Check the process of obtaining stack member status information in a stack.
In an S5700SI stack, the master switch obtains status information through Remote Process Call (RPC), and stack members exchange data by sending Interprocess Communication (IPC) messages. Because temperature information about a stack member cannot be obtained, a fault occurred during RPC invoking. RPC uses IPC messages to exchange information, so the IPC message exchange process may be abnormal.

2. Analyze the IPC processing flow.
When the stack member was restarted, the software was re-initialized, and the fault was rectified. Therefore, an error occurred during software processing. Additionally, powering off and restarting the stack member can rectify the fault, indicating that the fault occurred on the stack member.
View message queue statistics on the master switch.

S5700

The preceding command output shows that messages were accumulated in VLAN, L2MA, and CXQO queues. The L2MA message queue (MAC synchronization task message queue) was full of messages, indicating that the IPC tasks of stack members were suspended and cannot process IPC messages. As a result, messages were accumulated on the master switch.

4. Analyze the reason for IPC task suspension.
Because the fault occurred on a stack member, we checked the black box of the stack member.

S5700

The preceding command output shows that an infinite loop existed. Detailed information about the infinite loop is as follows:

[s5700_ST_5ET-diagnose]display deadloop 20 slot 4

============ Task Infinite Loop Information Begin ============
Dopra Version                    = DOPRA V100R006C09CP0671
Application Version              = UnConfig
Task Infinite Loop Type          = Task overrun
Task Infinite Loop Handle        = Reset system
Task Infinite Loop CpuId         = 0
Overrun Task Name                = DELM
Overrun Task VOS ID              = 21
Overrun Task Osal ID             = 0×06299840
Task Overrun Threshold           = 30000 (ms)
Task Has-run Time                = 30000 (ms)
Task Infinite Loop Occur Time    = [2014.05.28  18:14:02]
Task Infinite Loop Occur Cputick = [0x00023868, 0x456585a5]

The task experiencing an infinite loop is DELM, which is used to delete MAC addresses. When an infinite loop occurs, the mv_l2_del_addr_by_port function occupies the semaphore of MAC entries. When other tasks, for example the IPC task, need to operate MAC entries, these tasks will be suspended because no semaphore is available. However, the infinite loop cannot be broken. Subsequently, the IPC task is always suspended, resulting in the fault.
5. Analyze the reason for an infinite loop.
After a code walk-through was performed, messages notifying the deletion of MAC addresses were accumulated in the message queue when a large number of MAC entries were triggered in a short period. Due to a software processing bug, the DELM task was always reading the message queue status when the messages were accumulated. Consequently, an infinite loop occurred on the DELM task.
The infinite loop occurred because of the deletion of MAC entries. After analyzing logs, we found that S5700s often received STP TC messages from Eth-Trunk 5. After an S5700 received TC messages, it deletes MAC entries of the related interfaces.
6. conclusion
When a device was triggered to delete a large number of MAC entries, a software bug caused other tasks unable to apply for the semaphore of MAC entries. The IPC task was then suspended when applying for the semaphore, and the master switch cannot access other stack members.
7. After implement the workaround that run the stp edged-port enable command on the related ports to reduce TC messages, the issue is disappeared
8. The patch for this software bug will be released at the end of July. 2014 to resolve this issue completely.

Root Cause

1. High CPU usage
2. Stack cable problem
3. Software bug

Suggestions

When run STP on switches, configure stp edged-port on interfaces which connect to PCs and servers to avoid MAC addresses fresh frequently.

Share

Issue Description

S5700-X-LI-28P using software V200R003C00SPC300.

Traffic belonging to multiple multicast source are forwarded to all host, even if the
”display igmp-snooping port-info” command didn’t show any entry.

Alarm Information

We don’t have to configure ”multicast-vlan enable” and ”multicast-vlan user-vlan <vlan-id>” to get multicast to an interface where customer-vlan and multicast-vlan is added simultaneously and I can’t see any groups beeing joined using ”display igmp-snooping port-info” (almost seems like igmp-snooping isn’t working).

Handling Process

To  discard unknown multicast packets in VLAN 10, we can configure like this.
<HUAWEI> system-view
[HUAWEI] vlan 10
[HUAWEI-vlan10] multicast drop-unknown

Root Cause

By default switch broadcast all unknown mcast packets, this could explain why you get multicast traffic but no entry under “display igmp snooping port-info”
Unknown multicast flows are multicast data flows that match no entry in the multicast forwarding table. By default, the switch broadcasts unknown multicast flows in the corresponding VLAN. we can use the multicast drop-unknowncommand to configure the switch to discard unknown multicast flows, which reduces instant bandwidth usage compared with the broadcast mode.

Suggestions

Share