Why Ping Packets Especially Large Ping Packets Are Lost Sometimes?

Issue Description

FAQ-Why Ping Packets Especially Large Ping Packets Are Lost Sometimes?

Alarm Information

None

Handling Process

FAQ-Why Ping Packets Especially Large Ping Packets Are Lost Sometimes?

This problem is caused by the CPU protection mechanism. The CPU protection mechanism processes ICMP packets as follows:

The software limits the rate of ICMP packets.
The icmp rate-limit { total | interface interface-type interface-number [ to interface-number ] } threshold threshold-value command limits the rate of ICMP packets on each GE interface to 20 pps and on the device to 100 pps by default. When the number of ICMP packets sent by an interface every second exceeds the rate threshold, the system delivers an ACL. The ACL discards all the ICMP packets with the MAC address as the device’s MAC address. After two minutes, the device is restored. This process continues. You can run the undo icmp rate-limit { total | interface interface-type interface-number [ to interface-number ] }} command to cancel rate limiting.
The system limits the rate of ICMP packets sent to the CPU.
The rate limit of ICMP packets sent to the CPU is 128 kbit/s. Assume that the packet size is 1024 bytes. Only 16 packets can be sent to the CPU within 1s, that is, a packet is sent every 62.5 ms. If a packets is sent at the rate grater than 62.5 ms, the packet is discarded. Assume that the packet size is 64 bytes. Only 256 packets can be sent to the CPU within 1s, that is, a packet is sent every 4 ms.

Root Cause

None

Suggestions

None

For more solution:

Contact information:

Telephone: 852-30623083
Email: Sales@Thunder-link.com
Supports@Thunder-link.com
Website: http://www.thunder-link.com

Advertisements

Route Flapping Caused by an IP Address Conflict

Issue Description

Applicable Products and Versions:
In this example, the switches support OSPF. Table 4-2 describes the versions and products that support OSPF.
Table 4-2 Product and version support for OSPF

QQ图片20170831092338

Networking:
As shown in Figure 4-2, OSPF is configured on SwitchA, SwitchB, SwitchC, and SwitchD, and router IDs and IP addresses have been configured for the devices.
Figure 4-2 IP address conflict on a network

QQ图片20170831092420

Route Flapping Caused by an IP Address Conflict.

Alarm Information

The following problems may occur due to IP address conflicts between interfaces on different devices:

The CPU usage is high. You can run the display cpu-usage command to check the CPU usage. The command output shows that the ROUT task consumes much more CPU resources than other tasks.

Route flapping occurs.

Handling Process

  1. Run the display ospf lsdb command on each switch once per second to check information about the OSPF link state database (LSDB) on the switches.Collect the command output on each switch.

    2.  Locate the fault based on the collected information.

Scenario 1

The aging time (Age field) of a network LSA is 3600 on a switch or the switch does not have the network LSA, and the Sequence value increases quickly.

On the other switches, the aging time of the same network LSA frequently alternates between 3600 and smaller values, and the Sequence value increases quickly.

If the preceding conditions are met, LSA aging is abnormal.

The following provides a command output example:

<HUAWEI> display ospf lsdb

OSPF Process 1 with Router ID 3.3.3.3
Link State Database

Area: 0.0.0.0
Type      LinkState ID    AdvRouter          Age  Len   Sequence   Metric
Router    4.4.4.4         4.4.4.4              2  48    8000000D       1
Router    3.3.3.3         3.3.3.3              6  72    80000016       1
Router    2.2.2.2         2.2.2.2            228  60    8000000D       1
Router    1.1.1.1         1.1.1.1            258  60    80000009       1
Network   112.1.1.4       4.4.4.4            121  32    80000001       0
Network   112.1.1.2       1.1.1.1           3600  32    80000015       0
Network   222.1.1.3       3.3.3.3            227  32    80000003       0
Network   111.1.1.1       1.1.1.1            259  32    80000002       0

AS External Database
Type      LinkState ID    AdvRouter          Age  Len   Sequence   Metric
External  33.33.33.33     4.4.4.4            206  36    800001D7       1
External  125.12.1.2      4.4.4.4            206  36    80000032       1

Run the display ospf routing command on each switch once every second. If route flapping occurs but the OSPF neighbor relationship does not flap, IP address conflicts or router ID conflicts have occurred. Based on the display ospf lsdb command output, it is determined that the IP address of the designated router (DR) conflicts with that of a non-DR.

Locate one switch that uses the conflicting IP address based on the AdvRouter value and then find the conflicting interface on the switch. The other switch is difficult to find based only on OSPF information. You need to check interface IP addresses against the IP address plan to locate this switch.

In this example, first determine that the conflicting IP address is 112.1.1.2, and the router ID of a conflicting device is 1.1.1.1. However, the other conflicting device (3.3.3.3) cannot be located based on OSPF information.

Scenario 2

If the LinkState ID values of two network LSAs are both 112.1.1.2 on a switch, the aging time of the two network LSAs is short, and the Sequence value increases quickly, then an IP address conflict has occurred between the DR and BDR.

<HUAWEI> display ospf lsdb

OSPF Process 1 with Router ID 3.3.3.3
Link State Database

Area: 0.0.0.0
Type      LinkState ID    AdvRouter          Age  Len   Sequence   Metric
Router    4.4.4.4         4.4.4.4             17  48    8000011D       1
Router    3.3.3.3         3.3.3.3             21  72    8000015A       1
Router    2.2.2.2         2.2.2.2            151  60    80000089       1
Router    1.1.1.1         1.1.1.1           1180  60    8000002A       1
Network   112.1.1.2       3.3.3.3              3  32    8000016A       0
Network   112.1.1.2       1.1.1.1              5  32    80000179       0
Network   222.1.1.3       3.3.3.3            145  32    8000002D       0
Network   212.1.1.4       4.4.4.4             10  32    80000005       0
Network   111.1.1.2       2.2.2.2            459  32    80000003       0

AS External Database
Type      LinkState ID    AdvRouter          Age  Len   Sequence   Metric
External  33.33.33.33     4.4.4.4             30  36    800001DC       1
External  125.12.1.2      4.4.4.4             30  36    80000037       1

3.  Change the IP address of a conflicting device based on the IP address plan.

Root Cause

On an OSPF network, IP address conflicts between interfaces may cause frequent aging and generation of link-state advertisements (LSAs), which results in network instability, route flapping, and high CPU usage.

Suggestions

On an OSPF network, IP address conflicts between interfaces may cause frequent aging and generation of LSAs, which results in network instability, route flapping, and high CPU usage.

Therefore, configure IP addresses for interfaces according to the plan, and do not modify planned network parameters. If an IP address conflict occurs, locate the conflicting devices and rectify the fault in a timely manner.

For more solution support please check http://www.thunder-link.com

 

X Customer U2000 NMS was unable to access a cluster of 32 NEs of RTN 900 Microwave Network

Issue Description

U2000 NMS of RTN 900 Microwave was unable to manage a cluster of 32 NEs .

Alarm Information

Unable to Telnet the remote router

Handling Process

From the Cause analyse it was decide to send Onsite Engineer at the remote End to Login the remote router and check the IP route .
The On site Engineer reached at the site and confirmed tha IP route at the remote route is deleted due to Power resett .

Root Cause

We perform the follwoing Steps

1.Perfomr the Ping test of locan router (result was successfull)
2.Perform the remote router Ping test (result was successfull)
3.Perform the GNE Ping test (result was successfull)
4.Check the local Router configuration (result was successfull) but it was not saved ,at same time configuration is saved .
4.Perform the Telnet test of remote router (result was not successfull).

It was doubt that remore router IP route is deleted by some reson.

Suggestions

Becarefull :
1 Power should not be off (power backup must be there)
2 When configure the Router IP routes the configuration must be saved because if we will not saved the configuration then due to NE resett the configuration will be lost.

More relative solution:

http://www.thunder-link.com/support/IManager-U2000-LCT-Install-Guide.html

http://www.thunder-link.com/support/Import-Or-Update-U2000-License.html

Link Aggregation Cannot Be Implemented Between an S5700 and a Non-Huawei Device

Issue Description

As shown in Figure 2-1, links between the Huawei S5700 and Catalyst 3560 switches are bundled on the two switches, but the link aggregation function does not take effect.

Figure 2-1 Link aggregation between S5700 and Catalyst 3560 switches

QQ图片20170817100603

Link aggregation configuration on the S5700:

#
interface Eth-Trunk22
port link-type trunk
port trunk allow-pass vlan 2 to 4094
mode lacp   //The link aggregation protocol is LACP.
#
interface GigabitEthernet0/0/1
eth-trunk 22
#
interface GigabitEthernet0/0/2
eth-trunk 22
#
interface GigabitEthernet0/0/3
eth-trunk 22
#
interface GigabitEthernet0/0/4
eth-trunk 22
#

Link aggregation configuration on the Catalyst 3560:

!
interface FastEthernet0/1
channel-protocol pagp   //The link aggregation protocol is PAgP.
channel-group 22 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/2
channel-protocol pagp
channel-group 22 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/3
channel-protocol pagp
channel-group 22 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/4
channel-protocol pagp
channel-group 22 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk
!

Handling Process

According to the configuration on the two switches, the link aggregation failure is caused by incorrect configuration on the Cisco switch, rather than the S5700.

The customer needs to contact Cisco for the solution to this problem.

After the PAgP protocol is replaced by LACP on the Catalyst 3560, link aggregation can be implemented between the two switches.

The LACP-based link aggregation configuration on the Catalyst3560 is as follows:

!
interface FastEthernet0/1
channel-protocol lacp   /The link aggregation protocol is LACP.
channel-group 22 mode active   //The working mode is active.
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/2
channel-protocol lacp
channel-group 22 mode active
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/3
channel-protocol lacp
channel-group 22 mode active
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/4
channel-protocol lacp
channel-group 22 mode active
switchport trunk encapsulation dot1q
switchport mode trunk
!

Root Cause

The S5700 uses the standard LACP protocol to implement link aggregation and its configuration is correct.

The Cisco Catalyst 3560 switch supports both LACP and Cisco proprietary PAgP protocol. Actually, the Catalyst 3560 uses PAgP but not LACP on the network. As a result, link aggregation cannot be implemented between the two switches.

Suggestions

When a Huawei switch needs to be connected to a non-Huawei device through bundled links, check whether the peer device uses the standard link aggregation protocol.

Layer 2 Multicast Forwarding Entries Fail to Be Created for SSM Group Addresses on an S5700 Switch

Issue Description

After IGMP snooping is configured on an S5700 switch, the traffic volume sent from user-side interfaces is equal to the traffic volume received on the uplink interface. Actually, a downstream user requires only one multicast flow (about 10 Mbit/s).

The configuration on the S5700 switch is as follows:

vlan 100
igmp-snooping enable
igmp-snooping querier enable
#
interface Eth-Trunk1
port link-type trunk
port trunk allow-pass vlan 2 to 4094
#
interface GigabitEthernet0/0/36
port link-type access
port default vlan 100
#

Handling Process

1. Run the display interface brief command to check traffic statistics on uplink and downlink interfaces.

<Switch> display interface brief
Interface                   PHY   Protocol InUti OutUti   inErrors  outErrors
Eth-Trunk1                  up    up         43%     0%          0          0
GigabitEthernet0/0/45     up    up       0.01%  0.01%          0          0
GigabitEthernet0/0/46     up    up         87%  0.01%          0          0 //The uplink interface is an Eth-trunk, and its member interfaces work at 1000 Mbit/s.
……
GigabitEthernet0/0/5        up    up       0.01%    87%          3          0 //This interface is not connected to multicast users and it works at 1000 Mbit/s.
……
GigabitEthernet0/0/36       up    up       0.01%    87%          0          0 //This interface is connected to multicast users and it works at 1000 Mbit/s.
……
GigabitEthernet0/0/5 current state : UP
Line protocol current state : UP
……
Output:  5355181997 packets, 7400771612471 bytes
Unicast:                          0,  Multicast:                  5355181048
Broadcast:                      949,  Jumbo:                               0
Discard:                   13234141,  Pause:                               0
GigabitEthernet0/0/36 current state : UP
Line protocol current state : UP
……
Output:  937621743 packets, 1295759811022 bytes
Unicast:                          0,  Multicast:                   937607079
Broadcast:                    14664,  Jumbo:                               0
Discard:                   22114287,  Pause:                               0
GigabitEthernet0/0/46 current state : UP
Line protocol current state : UP
……
Input:  4607758512 packets, 6386285035581 bytes
Unicast:                          0,  Multicast:                  4607758512
Broadcast:                        0,  Jumbo:                               0
Discard:                          0,  Pause:                               0

The traffic statistics show that the traffic volume received on the uplink interface is the same as the traffic volume sent from user-side interfaces. The data packets are multicast packets, and non-multicast users also receive these packets. The possible cause is that these packets are unknown multicast packets and are broadcast to all the interfaces in the same VLAN.

2. By default, a switch broadcasts unknown multicast packets in a VLAN. After the switch is configured to drop unknown multicast traffic (using the multicast drop-unknown command in the VLAN view), the traffic volume on user-side interfaces should decrease. However, multicast users cannot receive the multicast traffic they request after the configuration is performed.

3. No (*, G) entries are available on the group member ports.
[Switch] display igmp-snooping port-info
Info: There is no group port information.
No Layer 2 multicast forwarding entries are available in the forwarding table.
[Switch] display l2-multicast forwarding-table vlan 100
Info: There is no forwarding-table information.

4. Packet information obtained on the multicast user’s client shows that the Report messages sent from the user are IGMPv2 Report messages but the group address in the Report messages is 232.0.21.40, a source-specific multicast (SSM) group address.

QQ图片20170817094225

Root Cause

V100R005 of fixed switches adds the support for IGMP snooping SSM mapping and SSM policy. According to RFC 4607, addresses on the 232/8 network segment (232.0.0.0-232.255.255.255) are SSM group addresses. Multicast forwarding entries can be created for multicast addresses on this network segment only when a source address is specified.

In V100R005 and later versions, a fixed switch cannot create multicast forwarding entries after receiving IGMPv2 Report messages with multicast addresses on the 232/8 network segment. After the switch is configured to drop unknown multicast traffic, users cannot receive multicast data they request.

Solution

  1. Run the igmp-snooping ssm-policy acl xxx command in the VLAN and specify an empty ACL in the command. Then all multicast addresses are considered non-SSM group addresses, and (*, G) entries can be created for 232.X.X.X groups.

    2. Run the igmp-snooping version 3 and igmp-snooping ssm-mapping enable commands in the VLAN to map 232.X.X.X group addresses to specified source addresses, so that (S, G) entries can be created for these group addresses.

    After solution 1 is used, the S5700 switch can create Layer 2 multicast forwarding entries and forward multicast traffic normally.

Suggestions

1. When a switch fails to create Layer 2 multicast forwarding entries, collect the following information for fault location:

a. Software version, model, and configuration of the switch.
b. Run the debugging igmp-snooping report command to enable IGMP snooping
Report message debugging and view the debugging information to check whether the switch has received   Report messages and how these Report messages are processed.

2. In V100R003 and earlier versions of the S series switches, multicast forwarding entries can be created based on IGMPv2 Report messages with SSM group addresses.

In V100R005 and later versions, multicast forwarding entries can be created based on IGMPv2 Report messages with SSM group addresses only when a source address is specified.

If a switch fails to create multicast forwarding entries, check whether the request group addresses are SSM group addresses.

Huawei S5700 Series switch:

S5700-28P-LI-AC

S5700-28P-PWR-LI-AC

S5700-10P-LI-AC

LAG Member Interfaces of the S5700 Are in Unselected State When the S5700 Connects to a H3C Switch Through an LAG

Issue Description

When the Huawei S5700 connects to an H3C switch through an LAG, the two devices fail to ping each other.

Handling Process

  1. Check member interfaces. The member interfaces are Up, and physical lines work properly.

    2. Run the display eth-trunk command to check the link aggregation interface configuration. All member interfaces of the S5700 are in Unselected state, and member interfaces of the H3C switch work properly. That is, link aggregation negotiation fails.

    3. Check the configuration at both ends.

    S5700 configuration:

    interface Eth-Trunk1
    mode lacp
    interface GigabitEthernet0/0/1
    eth-trunk 1

    H3C switch configuration:

    link-aggregation group 1 mode static
    interface Ethernet 1/0/1
    port link-aggregation group 1

    According to the preceding configuration, both the S5700 and H3C switch use the static LACP mode; however, the two devices cannot interwork in static LACP mode.

    4. Modification methods

    − Method 1:
    Run the undo mode command to change the link aggregation mode of the S5700 to manual. The member interfaces of the S5700 can work properly after the change.

    − Method 2:
    Change the link aggregation mode of the H3C switch to link-aggregation mode dynamic. The member interfaces of the S5700 can work properly after the change.

Suggestions

The manual link aggregation mode of the S5700 corresponds to the static LACP mode of the H3C switch.

The static LACP mode of the S5700 corresponds to the dynamic LACP mode of the H3C switch.

For more Huawei solution please contact:

Telephone: 852-30623083
Email: Sales@Thunder-link.com
Supports@Thunder-link.com
Website: http://www.thunder-link.com

IP Phone connected to S5700 cannot get voice IP address successfully

Issue Description

Customer connected one IP Phone to Huawei S5700 and he found the IP Phone cannot get IP address from voice vlan.
The port configuration is following. vlan 16 is voice vlan and Vlan 44 is data vlan.
interface GigabitEthernet0/0/4
description Phone-Data Access
port link-type hybrid
voice-vlan 16 enable
voice-vlan legacy enable
port hybrid pvid vlan 44
port hybrid tagged vlan 16
port hybrid untagged vlan 44

With above configuration, the IP Phone gets IP address from data vlan rather than voice vlan.
<Test>display lldp neighbor interface GigabitEthernet 0/0/4
GigabitEthernet0/0/4 has 1 neighbor(s):
…………………………….
Neighbor index :1
Chassis type   :networkAddress
Chassis ID     :X.X.44.X
Port ID type   :macAddress
Port ID        :0004-f242-cbc8
Port description    :1
System name         :Polycom SoundPoint IP 335
System description  :Polycom;SoundPointIP-SPIP_335;2345-12375-001,1;SIP/3.2.2.0477/18-Nov-09 13:58;BR/4.2.2.0710/24-Feb-10 16:39;
System capabilities supported   :bridge telephone
System capabilities enabled     :telephone
Management address type  :ipv4
Management address value :X.X.44.X
Expired time   :102s
…………………………….

Handling Process

1.For this kind of issue, we need to confirm how IP Phone get voice VLAN. There are several ways. Like LLDP, DHCP, CDP.Confirmed with customer. However, he cannot provide us the answer. In order to know how IP Phone get voice vlan. We use below command to capture packet on our s5700
[huawei]capture-packet interface GigabitEthernet 0/0/4 destination terminal  packet-len total-packet packet-num 30
In the capture, we find LLDP packet as following and S5700 provided the voice vlan to IP Phone.

QQ图片20170811170407

Using command “display lldp neighbor interface GigabitEthernet 0/0/4”, we also confirmed that IP Phone learned the voice vlan from LLDP.
<Test>display lldp neighbor interface GigabitEthernet 0/0/4

Media policy type   :Voice
Unknown Policy      :Defined
VLAN tagged         :Yes
Media policy VlanID      :16
Media policy L2 priority :5
Media policy Dscp        :46

Media policy type   :Voice Signaling
Unknown Policy      :Defined
VLAN tagged         :Yes
Media policy VlanID      :16
Media policy L2 priority :5
Media policy Dscp        :44
…………………………….

  1. Usually, when IP Phone got voice vlan from S5700, it will send packet with vlan 16. However, the IP Phone did not get IP from voice vlan. In capture, we found the packet from IP Phone did not bring the voice vlan. That is why the IP Phone got IP from data vlan.

QQ图片20170811170441

it proves that packet from IP Phone does not contain the voice vlan. In this situation, we have one command to solve it as following.

<HUAWEI> system-view

[HUAWEI] voice-vlan mac-address 0004-f242-cbc8 mask ffff-ff00-0000 description ipphone  // after this configuration all the packets coming from the phone will be identified as part of the  voice vlan

[HUAWEI] interface gigabitethernet 0/0/4

[HUAWEI-GigabitEthernet0/0/1] voice-vlan 16 enable include-untagged

  1. After made the change, customer confirmed that the IP Phone could get IP address from voice vlan correctly.

QQ图片20170811170611

<Test>display lldp neighbor interface GigabitEthernet 0/0/4
GigabitEthernet0/0/4 has 1 neighbor(s):
…………………………….
Neighbor index :1
Chassis type   :networkAddress
Chassis ID     :X.X.16.X
Port ID type   :macAddress
Port ID        :0004-f242-cbc8
Port description    :1
System name         :Polycom SoundPoint IP 335
System description  :Polycom;SoundPointIP-SPIP_335;2345-12375-001,1;SIP/3.2.2.0477/18-Nov-09 13:58;BR/4.2.2.0710/24-Feb-10 16:39;
System capabilities supported   :bridge telephone
System capabilities enabled     :telephone
Management address type  :ipv4
Management address value :X.X.16.X
Expired time   :102s
…………………………….

However, customer reported another issue with “included-untagged” parameter. The port connected to IP Phone is keeping flapping.

Oct 13 2015 22:35:28+13:00 DST TEST %%01IFPDT/4/IF_STATE(l)[0]:Interface GigabitEthernet0/0/4 has turned into UP state.
Oct 13 2015 22:35:24+13:00 DST TEST %%01IFPDT/4/IF_STATE(l)[1]:Interface GigabitEthernet0/0/4 has turned into DOWN state.
Oct 13 2015 22:34:20+13:00 DST TEST %%01IFPDT/4/IF_STATE(l)[2]:Interface GigabitEthernet0/0/4 has turned into UP state.
Oct 13 2015 22:34:17+13:00 DST TEST %%01IFPDT/4/IF_STATE(l)[3]:Interface GigabitEthernet0/0/4 has turned into DOWN state.
Oct 13 2015 22:33:13+13:00 DST TEST %%01IFPDT/4/IF_STATE(l)[4]:Interface GigabitEthernet0/0/4 has turned into UP state.
Oct 13 2015 22:33:10+13:00 DST TEST %%01IFPDT/4/IF_STATE(l)[5]:Interface GigabitEthernet0/0/4 has turned into DOWN state.
Oct 13 2015 22:32:07+13:00 DST TEST %%01IFPDT/4/IF_STATE(l)[6]:Interface GigabitEthernet0/0/4 has turned into UP state.

If customer deletes the “included-untagged” parameter, the port will not flapp however IP Phone cannot take IP address from voice vlan.

 

  1. Analyzed the process, “included-untagged” parameter should not affect the port behavior. It is just used for inbound packet from IP Phone. Port flapping should be caused by other issue. Made one remote troubleshooting with this new issue and we found that when Huawei switch replied LLDP packet, the IP Phone will release its IP address and send DHCP discover packet again. After that, the port is down.

QQ图片20170811170656

Based on above capture, we can see that some thing is wrong on IP Phone with strange behavior. In order to solve port flapping issue, we disable LLDP on port Gi0/0/4 which is connected to IP Phone

interface GigabitEthernet0/0/4

port link-type hybrid

voice-vlan 16 enable include-untagged

port hybrid pvid vlan 44

port hybrid untagged vlan 16 44

undo lldp enable

 

After that, the problem is solved completely.

Root Cause

  1. The IP Phone did not send packet in voice vlan after learned it from S5700. We could use “included-untagged” paramter to solve it.
  2. Strange behavior on IP Phone when it receives LLDP packet from S5700 with voice vlan enabled.

Solution

With below configuration, the problem is solved completely.

interface GigabitEthernet0/0/4

port link-type hybrid

voice-vlan 16 enable include-untagged

port hybrid pvid vlan 44

port hybrid untagged vlan 16 44

undo lldp enable

Huawei S5700 switch model:

S5700-28P-LI-AC

S5700-10P-LI-AC

S5700-24TP-SI-AC