Which VLAN Assignment Methods Do S Series Switches Support

Issue Description

Which VLAN Assignment Methods Do S Series Switches Support?

Solution

Table 1 lists the VLAN assignment methods supported by different switch models of different versions.

Table 1 VLAN assignment methods

QQ图片20170915100321

 

Advertisements

Which VLAN Do DHCP Users Connected to a Switch Interface Obtain IP Addresses From If MAC Address Authentication Is Enabled and a Guest VLAN Is Configured on the Interface

Issue Description

Which VLAN Do DHCP Users Connected to a Switch Interface Obtain IP Addresses From If MAC Address Authentication Is Enabled and a Guest VLAN Is Configured on the Interface?

Solution

When a user without VLAN tag passes MAC address authentication, the user obtains an IP address from the VLAN matching the interface PVID. When a user with a VLAN tag passes MAC address authentication, the user obtains an IP address from the VLAN matching the VLAN tag.

If a user fails MAC address authentication, the user obtains an IP address from the guest VLAN on the interface where the user accesses.

Contact information:

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

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

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