Author Archives: Thunder link International

When Users Fail Wireless Portal Authentication by the S12708 and Policy Center 

Wireless Portal authentication is configured on the S12708 and Policy Center. The VPN instance XX is bound to VLANIF 256 of the switch for communication with the Portal server.

Authentication fails and no authentication records are displayed on the Portal server.

The configuration on the switch is as follows:

sysname Core_S12708
#
set net-manager vpn-instance XX
#
ip vpn-instance XX
ipv4-family
route-distinguisher 65535:4
vpn-target 65535:4 export-extcommunity
vpn-target 65535:4 65535:3 65535:5 65535:6 65535:7 65535:8 65535:9 65535:10 import-extcommunity
vpn-target 65535:11 import-extcommunity
#
radius-server template radius_huawei
radius-server shared-key cipher %@%@MhYHRn’xG)G`2&)0kQb@w#B:%@%@
radius-server authentication 172.16.2.146 1812 vpn-instance XX source ip-address 10.66.1.1 weight 80
radius-server accounting 172.16.2.146 1813 vpn-instance XX source ip-address 10.66.1.1 weight 80
radius-server authorization 172.16.2.146 shared-key cipher %@%@>U:l~MJa=C8^U’9fmZ-4+q=4%@%@
#
url-template name urlTemplate_0
#
web-auth-server huawei
server-ip 172.16.2.146
port 50200
shared-key cipher %@%@1s9zQui#nH`s%U47Ce~–%rA%@%@
url http://172.16.2.146:8080/portal
#
aaa
authentication-scheme default
authentication-scheme radius_huawei
authentication-mode radius
authorization-scheme default
accounting-scheme default
accounting-scheme radius_huawei
accounting-mode radius
domain default
authentication-scheme radius_huawei
accounting-scheme radius_huawei
radius-server radius_huawei
domain default_admin
#
interface Vlanif256
ip binding vpn-instance XX
ip address 10.66.1.1 255.255.255.0
#
#
authentication free-rule 1 destination ip 172.16.2.146 mask 255.255.255.255
#

WLAN configurations are omitted.

The configuration on the Policy Center is as follows:

User account setting:

modify account

modify account

Access device setting:

modify device

modify device

Authorization rule setting:

Authorization rule

Authorization rule

Handling Process

Step 1 Run the test-aaa command to test the authentication account on the switch. User authentication fails. Enable debugging of RADIUS packets on the switch. The switch receives a message with the error code 4117, indicating that account authorization fails.

<Core_S12708>test-aaa 123 Admin123 radius-template radius_huawei
<Core_S12708>
Error: User name or password is wrong.
<Core_S12708>
Apr 23 2015 13:30:25.115.1 Core_S12708 RDS/7/DEBUG:
RADIUS Sent a Packet.
<Core_S12708>
Apr 23 2015 13:30:25.115.2 Core_S12708 RDS/7/DEBUG:
Server Template: 0
Server IP   : 172.16.2.146
Protocol: Standard
Code    : 1
Len     : 156
ID      : 118
[User-Name                          ] [5 ] [123]
[CHAP-Password                      ] [19] [c1 45 ee 4e 8a 81 68 5e 5c bf 55 16 f7 18 2e e0 08 ]
[CHAP-Challenge                     ] [18] [a6 de 82 54 33 fb 6d 61 d8 75 2c 98 a3 e5 3f 6a ]
[Service-Type                       ] [6 ] [2]
[Framed-Protocol                    ] [6 ] [1]
[NAS-Identifier                     ] [13] [Core_S12708]
[NAS-Port-Type                      ] [6 ] [15]
[Acct-Session-Id                    ] [37] [Core_S1000000000000002dd550f3001055]
[NAS-IP-Address                     ] [6 ] [10.66.1.1]
<Core_S12708>
Apr 23 2015 13:30:25.145.1 Core_S12708 RDS/7/DEBUG:
RADIUS Received a Packet.
<Core_S12708>
Apr 23 2015 13:30:25.145.2 Core_S12708 RDS/7/DEBUG:
Server Template: 0
Server IP   : 172.16.2.146
Server Port : 1812
Protocol: Standard
Code    : 3
Len     : 34
ID      : 118
[Reply-Message                      ] [14] [ErrCode:4117]
<Core_S12708>

Step 2 Test the Portal authorization policy based on configuration requirement. Compare the policy reported to the RADIUS server and the preset customized condition for wireless access on the Policy Center. The result shows that the value of NAS-Port-Type in the preset customized condition is different from the value of [NAS-Port-Type] [6] [15] in reported packets. Delete the customized condition and run the test-aaa command again to test the account. The account passes the test, but users still fail the Portal authentication.

modify cunstomcondition

modify cunstomcondition

Step 3 Obtain packets on the Portal server. The analysis shows that the Portal server sends three Challenge requests to the switch but receives no response. The Portal server also sends logout request packets to the switch but receives no response. No RADIUS authentication request is initiated further. No relevant RADIUS authentication logs of this account are displayed on the Portal server. As a result, the switch configuration needs to be verified.

switch configuration

switch configuration

Note: A relevant Portal plug-in needs to be installed to filter packets. If the Portal plug-in is not installed, you can filter packets as follows: Packets staring with 0201 and 0205 indicate REQ_CHALLENGE and REQ_LOGOUT packets respectively.

packets

packets

Step 4 Verify relevant switch configuration. If the switch communicates with the Portal server through a VPN instance, check whether the VPN instance is bound to the Portal server template. If not, bind the VPN instance XX to the Portal server template and test the Portal authentication again. The authentication succeeds.

#
web-auth-server huawei
server-ip 172.16.2.146
port 50200
shared-key cipher %@%@1s9zQui#nH`s%U47Ce~–%rA%@%@
url http://172.16.2.146:8080/portal
vpn-instance XX
#

Root Cause

Account authentication and authorization fail because the configuration of the Portal server authorization template is incorrect.

The switch fails to respond to the server’s Portal packets because no VPN instance is bound to the Portal server template.

Suggestions

Portal packet exchange process is as follows:

Portal packet exchange process

Portal packet exchange process

1. A Portal user initiates an authentication request using the HTTP protocol. The access device allows the HTTP packet destined for the Portal server or a preset free-of-charge website to pass through. The access device redirects the HTTP packet destined for other addresses to the Portal server. The Portal server pushes a web page for the user to enter the user name and password for authentication.

2. The Portal server exchanges information with the access device to implement CHAP authentication. If PAP is adopted, this step is omitted.

3. The Portal server assembles the user name and password entered by the user into an authentication request packet, sends the packet to the access device, and starts a timer to wait for an authentication reply packet.

4. The access device exchanges a RADIUS protocol packet with the RADIUS server.

5. The access device sends an authentication reply packet to the Portal server.

6. The Portal server sends an authentication success packet to the client to inform that the client authentication succeeds.

7. The Portal server sends an authentication reply acknowledgment packet to the access device.

8. The client exchanges security information with the Policy Center server. The Policy Center server checks whether antivirus software and unauthorized software are installed and whether the virus library and operating system patches are updated to verify the security of the access terminal.

9. The Policy Center server allows the user to access authorized resources based on the user security. The access device uses the authorization information that is stored in the device to control user access.

Note: Steps 8 and 9 describe the extended Portal authentication function.

TwitterLinkedInGoogle+FacebookPinterestTumblrStumbleUponRedditShare

When Can not login S5700 after S5700 power on?

Issue Description

After a customer upgraded the software version to V200R005C00SPC500 and the latest patch V200R005SPH011 from V200R005C00SPC200, he could login S5700 by telnet. Then the S5700 was powered off due to power outage. After he powered on S5700 again, he couldn’t login S5700 by telnet.

The topology is simple:

 

Here are the detail steps:

(1)   In the old software version V200R005C00SPC200, the customer can login S5700 by telnet.

(2)   After a customer upgraded the software version to V200R005C00SPC500 and the latest patch V200R005SPH011, he can login S5700 by telnet. When he checked the configuration, he found the following configuration, which didn’t exist in the configuration of V200R005C00SPC200.

#

telnet server enable

#

user-interface vty 0 4

protocol inbound telnet

#

 

(3)   But then S5700 was powered off due to power outage. After S5700 was powered on again, the customer couldn’t login S5700 by telnet. When he login S5700 by console interface, he found the there was no above configuration.

Alarm Information

None

Handling Process

(1)   After the S5700 was power on, the customer login S5700 by console interface, then he added the following configuration, he can login S5700 again by telnet.

#

telnet server enable

#

user-interface vty 0 4

protocol inbound telnet

#

Root Cause

(1)  In V200R005C00SPC200, the telnet server is enabled by default. So in the configuration of SPC200, there is no such command “telnet server enable” by default, but you can login S5700 by telnet.

(2)    In V200R005C00SPC500, the telnet server is disabled by default.  So in the configuration of SPC500, if there is no command “telnet server enable”, you can’t login S5700 by telnet.

(3)   During the upgrade of  S5700 from SPC200 to SPC500+patch V200R005SPH011,  S5700 will do this configuration translation. (it found that the last software version is SPC200, but the new one is SPC500, so it will do the configuration translation)

(4)   So when S5700 is running with SPC500 for the first time, in the current running configuration, you can see “telnet server enable”, and you can login S5700 by telnet. But in the saved  configuration, it’s still the  same configuration as SPC200 where there is no such command “telnet server enable”.

In this situation,

(1.1)    If the configuration was not “save”, after S5700 was rebooted( by manually, by power on-off button or by power outage) again, the  S5700 will not do the configuration translation again, and will run with that configuration which was used in SPC200, and for this configuration, there is no “telnet server enable”. But for SPC500, if there is no “telnet server enable” in the running configuration, you can’t login S5700 by telnet.

(1.2)    If the configuration was  “save”, the command “telnet server enable” will be saved to the saved configuration.  After S5700 is rebooted again, in the running configuration, there is ““telnet server enable”, so you can login S5700 by telnet.

Solution

(1)   After the software version of S5700 was upgraded to V200R005C00SPC500 and the latest patch V200R005SPH011 from V200R005C00SPC200, you need “save” the current configuration.

(2) Or you need configure the following commands for telnet.

#

telnet server enable

#

user-interface vty 0 4

protocol inbound telnet

#

Suggestions

After the software version of S5700 was upgraded to V200R005C00SPC500 and the latest patch V200R005SPH011 from V200R005C00SPC200, you need “save” the current configuration.  If not, after S5700 was rebooted or power on again, you can’t login S5700 by telnet.

 

How Is MAC Address Authentication Configured on the S5700?

Issue Description

Version: V100R005C01SPC100
Question: How is MAC address authentication configured on the S5700?

Alarm Information

None

Handling Process

Answer: Local MAC address authentication can be configured as follows:
[Quidway]mac-authen
[Quidway]mac-authen username macaddress format with-hyphen
[Quidway]aaa
[Quidway-aaa]
[Quidway-aaa]local-user f0de-f163-76d5 password simple f0de-f163-76d5
[Quidway]int ethe0/0/4
[Quidway-Ethernet0/0/4]mac-authen

When MAC address authentication fails, the switch does not learn the PC’s MAC address. View the authentication status.
[Quidway]display mac-authen int Ethernet 0/0/4
Ethernet0/0/4 state: UP.  MAC address authentication is enabled
Maximum users: 256
Current users: 0
Authentication Success: 6, Failure: 18
Guest VLAN is disabled
Silent MAC info:
f0de-f163-76d5
1 silent mac address(es) found, 1 printed.

When MAC address authentication succeeds, the switch learns the PC’s MAC address. View the authentication status.
[Quidway]display mac-authen int Ethernet 0/0/4
Ethernet0/0/4 state: UP.  MAC address authentication is enabled
Maximum users: 256
Current users: 1
Authentication Success: 5, Failure: 17
Guest VLAN is disabled
Online user(s) info:
UserId   MAC/VLAN            AccessTime              UserName
——————————————————————————
37       f0de-f163-76d5/1    2008/01/01 00:37:08     f0de-f163-76d5
——————————————————————————

Root Cause

None

Suggestions

1. If MAC address authentication uses the user name and password, the configuration is as follows:
[Quidway]mac-authen
[Quidway]mac-authen username fixed cc pass cc
[Quidway]aaa
[Quidway-aaa]
[Quidway-aaa]local-user cc password simple cc
[Quidway]int ethe0/0/4
[Quidway-Ethernet0/0/4]mac-authen
2. By default, the number of MAC address authentication users supported by a port is 256, and that supported by a switch is 1024.

 

When meet Issue about RRPP ring status on S7700 .

Issue Description

1. Topology

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.

 

How to check the ifindex of an interface on the switch?

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

When cannot ping the server through S5700HI VLL network.

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.

 

How to add an ethernet interface on Solaris Operating Syster?

Issue Description

Q:

How to add the new ethernet interface on Solaris Operating system?

Alarm Information

Null

Handling Process

A:

There are some steps to do this configuration in the Solaris base system.
Step 1:-Login to Operating system as a root user.
Step 2:-
Find the network interface by using the following command.
bash-2.05$ more /etc/path_to_inst  | grep net
“/pci@1f,700000/network@2″ 0 “bge”
“/pci@1f,700000/network@2,1″ 1 “bge”
“/pci@1e,600000/network@2″ 0 “ce”
“/pci@1d,700000/network@2″ 2 “bge”
“/pci@1d,700000/network@2,1″ 3 “bge”
bash-2.05$
Suppose you want to configure the ce0 interface.
#ifconfig ce0 plumb
Step 3:-
Set the ip address and subnet mask of the interface.
#ifconfig ce0 inet  <ipaddress> netmask <subnet mask>
Step 4:-
make the interface up.
#ifconfig ce0 up
Step 5:
Create/add the entry of ip address in the hostname file
#vi /etc/hostname.ce0
Add the ip address of ce0 /etc/hostname.ce0
<ip address of ce0>
Step 6:-
Add the entry of ip address in the /etc/hosts file.
#vi /etc/hosts
Add the following line in the file.
<ce0 ip address>    ce0
Step 7:-
Add the entry of subnet mask in the /etc/netmask file.
#vi /etc/netmask
Add the following line in the file.
<ce0 network>    <subnet mask>
Step 8:
Add the static route for the new interface network.
Permanent route.
-#cd /etc/rc2.d
#vi Sstaticroute
Add the following line in the file.
#route add -net <ce0 network> <gatway IP address>
Step 9:-
Temporary route.
#route add <ce0 network> <gatway IP address>

Root Cause

Adding the ethernet interface for expension/new netwrok expenssion.

Suggestions

No need to restart the server after adding the ethernet interface on Solaris based system.

 

If 5700 stack member fall out caused by A large number of MAC entries delete.

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

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

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

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.

 

How much buffer we need on the VDSF board to convert VDSL2 frame?

Issue Description

Q:
The MA5606T should design some buffer for frame converting.Customer has asked us how much buffer we need on the VDSF board to accomplish this request.

Alarm Information

Null

Handling Process

A:
that the upstream buffer is 2M bytes and the downstream is 16M bytes.

Root Cause

Null

Suggestions

Null

When cannot log-in MSUITE of U2000V1R3.

Issue Description

After installation of U2000V1R3 in my laptop, the U2000 installation software would automatically create the U2000 Server, U2000 Client, U2000 system monitor as well as the U2000 MSuite function.

During training, I was sucessful in log-in all the above application such as the U2000 Server, U2000 Client and U2000 Sytem monitor funtions.

However, I can never log-in the U2000 MSuite.

Alarm Information

Log-in fail

Handling Process

Procedure to start U2000V1R3 MSUITE Application

00001. Go to C:\HWENGR\engineering

00002. Double click “msserver “

00003. Double click “ startserver “

00004. Log-in MSUITE application.

00005. Username = admin

00006. Password  = admin

 

Root Cause

I download all relevant U2000V1R3 installation & operation manuals from the Huawei support web-site.

After detail self-study & investigation, I manage to successfully log-in the MSUITE of U2000V1R3.

Suggestions

The Huawei U2000V1R3 installation & operation manual does not clearly explain the correct prodecure to start the MSUITE.

Perhaps, with my confirmed research result, please modify & improve our Huawei documentation in this aspect.

Hopefully, my knowledge sharing would help many Huawei engineers & customers as well.