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

Advertisements

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

 

Interconnection Between 10GE Interfaces of S12708 and S5700 Switches Fails

Issue Description

In the customer’s central equipment room in building 3, two S12708 switches set up a cluster using CSS2 technology to act as the core node. After all 100M access switches in building 3 are replaced by S5700-52X-PWR-LI-AC gigabit access switches, the access switches fail to communicate with the S12708 cluster through 10GE interfaces.

Network topology:
QQ图片20170804142856

Symptom:

1. Interconnection test in the equipment room: An S5700 switch can normally communicate with another S5700 switch (loopback connection) and the S12708 cluster through 10GE interfaces.

2. Interconnection test between the equipment room and a different floor (optical distribution frames used, less than 150 m of distance): An S5700 switch cannot communicate with another S5700 switch or the S12708 cluster through 10GE interfaces.

3. Interconnection test between the equipment room and a different floor (no optical

distribution frames used, less than 150 m of distance): Indicators on the interconnected 10GE interfaces between two S5700 switches or between an S5700 switch and the S12708 cluster may stay on for a short period, during which many packets are dropped and the transmission delay is long.

Alarm Information

The interconnected interfaces cannot go Up, or the interfaces go Up but their indicators blink abnormally.

Handling Process

Collect and save device information after obtaining permission from the customer.

Connect the 10GE interfaces using new optical fibers (model: DTT-GJ-12A1, multimode, 62.5/125 um). The following figure shows specifications of the optical fibers.
QQ图片20170804142949

  1. When 10GE interfaces of the S5700 and S12708 switches are connected using 150 m new fibers, the 10GE interfaces should not go Up. Theoretically, fibers of this model can transmit data at 10 Gbit/s only within a distance of 33 m. In the interconnection test, however, the interfaces connected using 150 m fibers of this model go Up. This test result is abnormal.

    2. When 10GE interfaces of the S5700 and S12708 switches are connected using 20 m new fibers, the 10GE interfaces can go Up and can be pinged successfully. The test result is normal because the distance between the 10GE interfaces is within the maximum transmission distance (33 m) supported by the fibers.

    3. When 10GE interfaces of two S5700 switches are connected using 150 m new fibers, the 10GE interfaces cannot go Up. The test result is normal because the distance between the 10GE interfaces exceeds the maximum transmission distance supported by the fibers.

    4. When 10GE interfaces of two S5700 switches are connected using 20 m new fibers, the 10GE interfaces can go Up. The test result is normal because the distance between the 10GE interfaces is within the maximum transmission distance supported by the fibers.

    5. When GE interfaces of the S5700 and S12708 switches are connected using 150 m new fibers, the GE interfaces can go Up. Theoretically, fibers of this model can transmit data at 1 Gbit/s within a distance of 275 m. The actual distance between the GE interfaces is within this range, so the test result is normal.

    6. When GE interfaces of the S5700 and S12708 switches are connected using 20 m new fibers, the GE interfaces can go Up. Theoretically, fibers of this model can transmit data at 1 Gbit/s within a distance of 275 m. The actual distance between the GE interfaces is within this range, so the test result is normal.

    7. When GE interfaces of two S5700 switches are connected using 150 m new fibers, the GE interfaces can go Up. Theoretically, fibers of this model can transmit data at 1 Gbit/s within a distance of 275 m. The actual distance between the GE interfaces is within this range, so the test result is normal.

    8. When GE interfaces of two S5700 switches are connected using 20 m new fibers, the GE interfaces can go Up. Theoretically, fibers of this model can transmit data at 1 Gbit/s within a distance of 275 m. The actual distance between the GE interfaces is within this range, so the test result is normal.

    Use original optical fibers (of the same model as the new optical fibers) used in the equipment room to perform the tests:

    9. When 10GE interfaces of the S5700 and S12708 switches are connected using 150 m original fibers, the 10GE interfaces cannot go Up. The test result is normal because the distance between the 10GE interfaces exceeds the maximum transmission distance supported by the fibers.

    10. When GE interfaces of the S5700 and S12708 switches are connected using 150 m original fibers, the GE interfaces cannot go Up. Theoretically, fibers of this model can transmit data at 1 Gbit/s within a distance of 275 m. The actual distance between the GE interfaces is within this range, so the test result is abnormal.

    11. When 10GE interfaces of two S5700 switches are connected using 150 m original fibers, the 10GE interfaces cannot go Up. The test result is normal because the distance between the 10GE interfaces exceeds the maximum transmission distance supported by the fibers.

    12. When GE interfaces of two S5700 switches are connected using 150 m original fibers, the GE interfaces cannot go Up. Theoretically, fibers of this model can transmit data at 1 Gbit/s within a distance of 275 m. The actual distance between the GE interfaces is within this range, so the test result is abnormal.

Root Cause

  1. In test scenario 10, interconnected GE interfaces between S5700 and S12708 switches cannot go Up. The receive power (Current Rx Power(dBm) field) on GigabitEthernet2/2/0/36 of the S12708 cluster is -26.58, which is below the normal range considering the receiver sensitivity of the optical transceiver on the interface. Although the fiber length (150 m) is shorter than the maximum transmission distance, the optical fiber may attenuate to a low value due to other factors on the link.

    2. In test scenario 12, interconnected GE interfaces between S5700 switches cannot go Up. The receive power on XGigabitEthernet0/0/3 is -26.02, below the normal range. The optical power may attenuate due to other factors on the fiber link.

    3. It has confirmed that optical transceivers used on the interfaces have been certified by Huawei and no quality issues were found on the optical transceivers. The model of optical transceivers on the switches is: OMXD30000 optical transceiver, SFP+, 10G, multi-mode module (850 nm, 0.3 km, LC). If the required 10 Gbit/s transmission distance exceeds 100 m, OM3 (50/125 um) or OM4 optical fibers must be used. The current optical fibers used in the equipment room do not meet the requirement.

    4. Datang DTT-GJ-12A1 optical fibers (12-core, multimode, 62.5/125 um) are used in the equipment room, which are not OM3 or OM4 optical fibers.

    According to the preceding test results, the current optical fibers cannot meet transmission requirements in the equipment room.

Solution

Replace the optical fibers with OM3 optical fibers.

Suggestions

  1. If you cannot determine whether an interface-Down issue is caused by optical transceivers or fibers, test the interface connections in different scenarios to locate the problem.

    2. When interconnected interfaces cannot go Up, check whether the parameters of the optical fibers match the optical transceivers or whether the optical fibers and optical transceivers are qualified.

    3. You also need to check whether the transmit power and receive optical power on the interconnected interfaces are within the normal ranges or whether the power values are close to the receiver sensitivity.

    4. Ensure consistent configurations on the interconnected interfaces.

    5. Ensure consistent working modes (duplex mode and rate) on the interconnected interfaces.

 

 

How to configure built-in portal service with local user

Issue Description

Customer bought our AC6605 and need to deploy portal authentication. But they do not have external portal and radius server. This case provides one example using built-in portal authentication with Local user.

Alarm Information

None

Handling Process

1. Configuration and topology
PC –Wireless — AP —(GigabitEthernet0/0/1) AC6605

pki realm default
enrollment self-signed
#
ssl policy default_policy type server
pki-realm default

http secure-server ssl-policy default_policy
http server enable
http secure-server enable
#
portal local-server ip 1.1.1.1
portal local-server https ssl-policy default_policy port 3000

aaa
local-user portaluser password cipher %@%@K>Z@=”2WAQ3fC1GF<{cDi22f%@%@         ///Local portal authentication user.
local-user portaluser service-type web     ///Service type for portal authentication user.

interface Vlanif1000            ///For AP management
ip address 192.168.100.254 255.255.255.0
dhcp select interface
#
interface Vlanif1001            ///For Wireless user
ip address 192.168.1.254 255.255.255.0
dhcp select interface

interface GigabitEthernet0/0/1                       ///Connect to AP
port link-type trunk
port trunk pvid vlan 1000
port trunk allow-pass vlan 1000 to 1001

interface Wlan-Ess1
port hybrid pvid vlan 1001
port hybrid untagged vlan 1001
portal local-server enable                               ///Enable Local portal server service
permit-domain name default
force-domain name default

wlan
wlan ac source interface vlanif1000
ap-region id 10
ap-auth-mode no-auth
ap id 0 type-id 19 mac f84a-bfed-cb60 sn XXXXX
wmm-profile name wmm id 1
traffic-profile name traffic id 1
security-profile name security id 1
service-set name test id 1
wlan-ess 1
ssid HCNA-AC
traffic-profile id 1
security-profile id 1
service-vlan 1001
radio-profile name radio id 1
wmm-profile id 1
ap 0 radio 0
radio-profile id 1
service-set id 1 wlan 1

2. Test Result
a. Wirelss PC can search and connect to the SSID
QQ图片20170726160834

Get IP address

QQ图片20170726161001
b.Before finishing portal authentication, client cannot access network even gateway

QQ图片20170726162723

Just can ping portal server IP 1.1.1.1

QQ图片20170726162807

c.Open internet browser and input portal server IP:port

QQ图片20170726162836

Input the local user and password. Finish the portal authentication.

d.After portal authentication, the wireless client can access network

QQ图片20170726163042

Contact information:

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

FIB exhausted leads to directed route failure

Issue Description

QQ图片20170724151524

The topology is shown as above, Huawei S9306 run BGP with up-link router. But S9306-1 cannot ping through S9306-2 when added a new link.

Alarm Information

None

Handling Process

1. Checking interconnected physical link, the status is up
XGigabitEthernet2/0/15 current state : UP
Line protocol current state : UP
Description:connect to Mail9706-2
Switch Port, PVID : 102, TPID : 8100(Hex), The Maximum Frame Length is 9216
IP Sending Frames’ Format is PKTFMT_ETHNT_2, Hardware address is ac4e-914d-a4b0
Last physical up time : 2013-10-10 11:00:28
Last physical down time : 2013-10-09 14:15:17
Current system time: 2013-10-10 11:17:54
Port Mode: COMMON FIBER
Speed : 10000, Loopback: NONE
Duplex: FULL, Negotiation: DISABLE
Mdi : NORMAL

2. Checking ARP table, S9306 can learn peer ARP
===============================================
===============display arp===============
===============================================
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE
VLAN/CEVLAN
——————————————————————————
211.x.x.226 ac4e-914d-a4bb I – Vlanif100
211. x. x.225 e468-a356-b5d5 20 D-0 XGE2/0/0
100/-
211. x. x.218 ac4e-914d-a4bc I – Vlanif101
211. x. x.217 e468-a356-b5cd 16 D-0 XGE3/0/0
101/-
211. x. x.213 ac4e-914d-a4bd I – Vlanif102
211. x. x.214 ac4e-9148-d8fd 3 D-0 XGE2/0/15
102/-

3. Checking routing tale, there is direct route to peer S9306-2
#
211. x. x.212/30 Direct 0 0 D 211. x. x.213 Vlanif102
211. x. x.213/32 Direct 0 0 D 127.0.0.1 Vlanif102
#

4. Check FIB information using “display fib”, there is no FIB entry regarding 211. x. x.212/30. Suspect the route entry too large to load in FIB table. Checking routin-table, 63948 routes in it.
============================================================
===============display ip routing-table===============
============================================================
Route Flags: R – relay, D – download to fib
——————————————————————————
Routing Tables: Public
Destinations : 63672 Routes : 63948

Checking LPU model, it only support 16K FIB entry. The root cause is FIB entry on this LPU exhausted, new added route cannot be loaded in FIB.

QQ图片20170724151726

5. Aggregate the BGP route within 16K on S9306, the new added route can be loaded in  FIB and the network get through.

Root Cause

Direct connected network barrier is generally caused by the following reasons:
1 interconnected physical link problem
2. ARP learning problems
3 Direct routing problem
4. FIB table issues
5. Hardware forwarding failures

Suggestions

Trouble shoot directly connected network unreasonable can follow these steps:
Check the physical link -> check the ARP-> check the direct route -> Check FIB table -> hardware forwarding failures

Contact information:

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

Fan speed can’t be modified cause of temperature alarm

Issue Description

S9303(V100R001C02B118)’s  Fan run at  100% speed all the time,  and there are error notice occurred when try to regulate the speed by manually.

Alarm Information

[S9303]set fan-speed slot 6 percent 30
ERROR: Can not Set Fan Speed Because of Alarm, error code: 0x70d9!
[S9303-hidecmd]dis alarm all
—————————————————————————-
Level          Date        Time                Info
Warning      2009-04-10  14:04:31    PWR board[7] is absent.
Warning      2009-04-10  14:04:14    The “2.5V” voltage sensor of MCU  board[5](entity) exceed lower minor limit.
Warning      2009-04-10  14:04:14    The “1.8V” voltage sensor of MCU board[5](entity) exceed lower minor limit.
Warning      2009-04-10  14:04:14    The “1.25V_A” voltage sensor of MCU board[5](entity) exceed upper minor limit.
Warning      2009-04-10  14:04:14    The “1.2V” voltage sensor of MCU board[5](entity) exceed upper minor limit.
Warning      2009-04-10  14:04:14    The “3.3V” voltage sensor of MCU board[5 ](entity) exceed upper minor limit.
Warning      2009-04-10  14:04:14    The “CLK_DET_125M” sensor12 of MCU board5] detect clock signal fault.
—————————————————————————-

Handling Process

1、Use “disp cdev slot 5” of hidden view  we found  that  the board type was “BoardExtType 3”, which is correct.
2、Use “dis dsms variable slot 5′ we found the info like this “BoardExtType 7” which should be modified.
3、Modify the board type like this,set boardid <slot-id> <type-id>
[S9303-hidecmd]set boardid 5 3
2、Reset CBUS with commands
[S9303-hidecmd]reset cbus slot  5 cold
3、Renew  the software and SDR file of CBUS.
<S9303>upgrade slavempu jtag startup canbus_app
<S9303>upgrade slavempu jtag startup canbus_sdr
5、Then temperature alarm disappeared, Fan speed can be automatically regulated to 27%.

Root Cause

1、Backup SPU (Slot 5)’s board type is incorrect  and  lead to temperature alarm.
2、The fan run with 100% speed because of the  temperature alarm  and can’t regulate it manually.
3、Modify the board type and reset CBUS, The problem can be solved.

Suggestions

If there is a alarm refer to temperature he FAN will run with 100% speed.  But sometimes  this alarm will be caused of other reasons, so we would better deal with it  immediately  to make the fun speed become normal.

Huawei S9700 switch:

S9703

S9706

S9712