Sometimes we can meet such situation on a router or a switch:

 [labnario]display users
  User-Intf    Delay    Type   Network Address     AuthenStatus    AuthorcmdFlag
+ 34  VTY 0   00:00:00  TEL    172.29.12.226             pass           no      Username : huawei
  35  VTY 1   00:08:01  TEL    172.29.12.226             pass           no      Username : labnario
  36  VTY 2   00:07:38  TEL    172.29.12.226             pass           no      Username : killer
  37  VTY 3   00:07:00  TEL    172.29.12.226             pass           no      Username : killer
  38  VTY 4   00:01:34  TEL    172.29.12.226             pass           no      Username : labnario

By default, on Huawei device, there are 5 vty lines available. If all these lines are occupied by users, no other user is able to access the device. Such situation can appear in 2 cases:

1. The device is fully occupied by telnet users.
2. All telnet sessions are hang.

The first case is normal and it can often happen. Sessions will be deleted when users log out from the device or their sessions’ idle-timeout expires. By default idle-timeout is set to 10 minutes.

The second case can be caused by idle-timeout of vty lines set to 0:

#
user-interface vty 0 4
 authentication-mode aaa
 idle-timeout 0 0
#

It means that this session never expires. If a user forget to log out from a device, vty line is still being occupied. This causes that a next user has no possibility to telnet the device.

If you have access by console port or you are already logged in by telnet, you can delete all unnecessary telnet sessions:

<labnario>free user-interface vty 4
Warning: User interface VTY4 will be freed. Continue? [Y/N]:y
 [OK]
<labnario>display users
  User-Intf    Delay    Type   Network Address     AuthenStatus    AuthorcmdFlag
+ 34  VTY 0   00:00:00  TEL    172.29.12.226             pass           no      Username : huawei
  35  VTY 1   00:13:14  TEL    172.29.12.226             pass           no      Username : labnario
  36  VTY 2   00:12:51  TEL    172.29.12.226             pass           no      Username : killer
  37  VTY 3   00:12:13  TEL    172.29.12.226             pass           no      Username : killer

To avoid such situation, configure idle-timout for vty lines different than 0:

#
user-interface vty 0 4
 authentication-mode aaa
 idle-timeout 15 0
#

You can also set maximum-vty sessions to 15 and configure the same parameters for all vty lines:

[labnario]user-interface maximum-vty 15 
[labnario]user-interface vty 0 14
 authentication-mode aaa
 idle-timeout 15 0

Now you have 16 vty lines available.

Maybe it should have been shown at the beginning of this blog…

As you probably know, Huawei datacom devices are divided in 2 segments: Telco and Enterprise. But what you decide to choose depends on you. You do decide which device you want to use, regardless of it is intended for telco or enterprise. You know the best which device is appropriate for your network. Having detailed technical specification you are able to choose the device which meets your requirements.

For those who don’t know where to find information about Huawei’s portfolio, I am sending direct links to proper pages:

Huawei Telco

I decided to spend my vacation without access to internet, only wife, children, beach and windsurfing. I succeeded, September 3rd was the first day, after 3 weeks of my vacation, when I opened my mail box. Sorry for the delay in replying for your emails.

Last time I was asked about a procedure how to upload files through console port. The procedure is simple and I will try to show it in this post. Taking Huawei’s S3300 switch as an example I will show you how to upload file through console port, upgrading bootrom at the same time. Notice that uploading files by console is very slow and it is better to use it only for small files, unless you do not have any other choice.

Please use HyperTerminal to upload files by console port.

Power on the switch and enter into bootrom mode by pressing CTRL+B (default password huawei):

BIOS LOADING ...

Copyright (c) 2008-2010 HUAWEI TECH CO., LTD.
(Ver329, Aug 17 2010, 02:01:19)
Press Ctrl+B to enter BOOTROM menu ... 2
password:

BOOTROM  MENU

1. Boot with default mode
2. Enter serial submenu
3. Enter startup submenu
4. Enter ethernet submenu
5. Enter filesystem submenu
6. Modify BOOTROM password
7. Reboot
Enter your choice(1-7): 2

SERIAL  SUBMENU

1. Update BOOTROM system
2. Download file to Flash through serial interface
3. Modify serial interface parameter
4. Return to main menu

Enter your choice(1-4): 3

1: 9600(default)
2: 19200
3: 38400
4: 57600
5: 115200

Select an appropriate baud rate:

Enter your choice(1-5): 5

Baud rate is 115200 bps. Please change the terminal's speed to 115200 bps

Now disconnect your session and change terminal’s speed to 115200 bps and connect again:

Send the necessary file by xmodem. You can choose 1 or 2, depends on what you want to do, updating the bootrom or downloading the file to flash only.

SERIAL  SUBMENU

    1. Update BOOTROM system
    2. Download file to Flash through serial interface
    3. Modify serial interface parameter
    4. Return to main menu

Enter your choice(1-4): 1

Please select file.

XMODEM downloading ...CC   Downloading file to SDRAM succeeded.
Warning: Don't Power-off or Reset the Device!!!
Update bootrom system ... done !

SERIAL  SUBMENU

    1. Update BOOTROM system
    2. Download file to Flash through serial interface
    3. Modify serial interface parameter
    4. Return to main menu

Enter your choice(1-4): 3
1: 9600(default)
2: 19200
3: 38400
4: 57600
5: 115200

Select an appropriate baud rate:
Enter your choice(1-5): 1
Baud rate is 9600 bps. Please change the terminal's speed to 9600 bps

Disconnect your session again and come back to previous terminal’s speed.

Huawei NE40E OSPF basic configuration:

#ospf 1 router-id 1.1.1.1
 area 0.0.0.0
  authentication-mode simple plain labnario
  network 10.0.0.0 0.0.0.3
  network 1.1.1.1 0.0.0.0
#

How to display OSPF neighbour:

[NE40E-1]display ospf peer

         OSPF Process 1 with Router ID 1.1.1.1
                 Neighbors

 Area 0.0.0.0 interface 10.0.0.1(GigabitEthernet3/0/0)'s neighbors
 Router ID: 2.2.2.2          Address: 10.0.0.2
   State: Full  Mode:Nbr is  Master  Priority: 1
   DR: 10.0.0.2  BDR: 10.0.0.1  MTU: 0
   Dead timer due in 34  sec
   Retrans timer interval: 5
   Neighbor is up for 00:33:07
   Authentication Sequence: [ 0 ]

How to display OSPF routing:

[NE40E-1]display ospf routing

         OSPF Process 1 with Router ID 1.1.1.1
                  Routing Tables

 Routing for Network
 Destination        Cost  Type       NextHop         AdvRouter       Area
 10.0.0.0/30        1     Transit    10.0.0.1        2.2.2.2         0.0.0.0
 2.2.2.2/32         1     Stub       10.0.0.2        2.2.2.2         0.0.0.0
 1.1.1.1/32         0     Stub       1.1.1.1         1.1.1.1         0.0.0.0

 Total Nets: 3
 Intra Area: 3  Inter Area: 0  ASE: 0  NSSA: 0

Configuring OSPF neighbour relationship you have to remember that:

1. Each router ID must be unique.
2. Interfaces between two neighbouring routers must belong to the same area.
3. Network mask, except P2P network, of all interfaces in the same network must be the same.
4. Authentication type must match in the same area.
5. Authentication key must match in the same network.
6. When configuring stub or NSSA, configuration must be the same on all routers in the area.
7. For NBMA, peer must be configured manually.

Most failures in OSPF area are caused by neighbour’s relationship. The first thing we should do is to check OSPF errors:

[NE40E-1]display ospf error

         OSPF Process 1 with Router ID 1.1.1.1
                 OSPF error statistics

General packet errors:
 0     : IP: received my own packet     0     : Bad packet
 0     : Bad version                    0     : Bad checksum
 0     : Bad area id                    0     : Drop on unnumbered interface
 0     : Bad virtual link               0     : Bad authentication type
 0     : Bad authentication key         0     : Packet too small
 0     : Packet size > ip length        0     : Transmit error
 0     : Interface down                 0     : Unknown neighbor

HELLO packet errors:
 0     : Netmask mismatch               0     : Hello timer mismatch
 0     : Dead timer mismatch            0     : Extern option mismatch
 0     : Router id confusion            0     : Virtual neighbor unknown
 0     : NBMA neighbor unknown          0     : Invalid Source Address

DD packet errors:
 0     : Neighbor state low             0     : Router id confusion
 0     : Extern option mismatch         0     : Unknown LSA type
 0     : MTU option mismatch

LS ACK packet errors:
 0     : Neighbor state low             0     : Bad ack
 0     : Duplicate ack                  0     : Unknown LSA type

LS REQ packet errors:
 0     : Neighbor state low             0     : Empty request
 0     : Bad request

LS UPD packet errors:
 0     : Neighbor state low             0     : Newer self-generate LSA
 0     : LSA checksum bad               0     : Received less recent LSA
 0     : Unknown LSA type

Opaque errors:
 0     : 9-out of flooding scope        0     : 10-out of flooding scope
 0     : 11-out of flooding scope       0     : Unkown TLV type

Retransmission for packet over Limitation errors:
 0     : Number for DD Packet           0     : Number for Update Packet
 0     : Number for Request Packet

Receive Grace LSA errors:
 0     : Number of invalid LSAs         0     : Number of policy failed LSAs
 0     : Number of wrong period LSAs

Configuration errors:
 0     : Tunnel cost mistake
0	: The network type of the neighboring interface is not consistent.

This is very helpful command and analysing output of this command you have a clue what to do next. The only thing you have to do is to check OSPF and OSPF interfaces configuration to eliminate the configuration’s mistakes. For example:

[NE40E-1]display ospf error

         OSPF Process 1 with Router ID 1.1.1.1
                 OSPF error statistics

General packet errors:
 0     : IP: received my own packet     18    : Bad packet
 0     : Bad version                    0     : Bad checksum
 0     : Bad area id                    0     : Drop on unnumbered interface
 0     : Bad virtual link               18    : Bad authentication type
 0     : Bad authentication key         0     : Packet too small
 0     : Packet size > ip length        0     : Transmit error
 0     : Interface down                 0     : Unknown neighbor

How to display OSPF configuration:

[NE40E-1]display current-configuration configuration ospf
#
ospf 1 router-id 1.1.1.1
area 0.0.0.0
  network 10.0.0.0 0.0.0.3
  network 1.1.1.1 0.0.0.0

[NE40E-2-ospf-1]display this
#
ospf 1 router-id 2.2.2.2
 area 0.0.0.0
  authentication-mode simple plain labnario
  network 2.2.2.2 0.0.0.0
  network 10.0.0.0 0.0.0.3
#
Return

As we can see authentication is not configured on one of the routers.

That was to be expected. Poland is out of Euro Cup. The only thing we can do is to come back to the real world :).

Today I will show you how to use ACLs and traffic policies for packets’ lost troubleshooting in a network.

Huawei ACL and traffic policy configuration

Let’s assume that we have such topology:

What we have to do is to check end-to-end connectivity between CE and R2 Loopback100 interface, to find where packets are being lost.

• Configure routing protocol to ensure communication between all devices. R1 configuration as an example:

#
interface GigabitEthernet3/0/0
 undo shutdown
 ip address 10.0.0.1 255.255.255.252
#
interface GigabitEthernet1/0/9
 undo shutdown
 ip address 172.16.0.1 255.255.255.252
#
interface LoopBack100
 ip address 1.1.1.1 255.255.255.255
#
ospf 1 router-id 1.1.1.1
 area 0.0.0.0
  network 10.0.0.0 0.0.0.3
  network 1.1.1.1 0.0.0.0
  network 172.16.0.0 0.0.0.3
#

• Configure ACL that permits ICMP traffic from CE to R2 Loopback100 IP address and from R2 to CE (the same ACL for R1 and R2):

#
acl number 3000
 rule 5 permit icmp source 172.16.0.0 0.0.0.3 destination 2.2.2.2 0
 rule 10 permit icmp source 2.2.2.2 0 destination 172.16.0.0 0.0.0.3
#

• Configure traffic policy that permits traffic matched by the ACL (the same for R1 and R2):

#
traffic classifier labnario operator or
 if-match acl 3000
#
traffic behavior labnario
#
traffic policy labnario
 statistics enable
 classifier labnario behavior labnario
#

Notice that default behaviour for the traffic is to permit (default parameters are not displayed in configuration). Remember to use “statistics enable” command to be able to display traffic policy statistics.

• Assign this traffic policy to all interfaces on the path between CE and R2 (for both inbound and outbound direction):

R1:

#
interface GigabitEthernet1/0/9
 undo shutdown
 ip address 172.16.0.1 255.255.255.252
 traffic-policy labnario inbound 
 traffic-policy labnario outbound
#
interface GigabitEthernet3/0/0
 undo shutdown
 ip address 10.0.0.1 255.255.255.252
 traffic-policy labnario inbound 
 traffic-policy labnario outbound

R2:

#
interface GigabitEthernet3/0/0
 undo shutdown
 ip address 10.0.0.2 255.255.255.252
 traffic-policy labnario inbound   
 traffic-policy labnario outbound

• Ping from CE to R2 Loopback100 IP address:

<CE>ping -c 100 -t 100 2.2.2.2
  PING 2.2.2.2: 56  data bytes, press CTRL_C to break
    Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=254 time=15 ms
    Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=254 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=254 time=10 ms
    .
    .
    .
    Reply from 2.2.2.2: bytes=56 Sequence=100 ttl=254 time=21 ms

  --- 2.2.2.2 ping statistics ---
    100 packet(s) transmitted
    100 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 9/12/52 ms

• Display traffic policy statistics for all interfaces on the path between CE and R2 (for inbound and outbound):

R1:

<R1>display traffic policy statistics interface GigabitEthernet 1/0/9 inbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet1/0/9
Traffic policy inbound: labnario
Traffic policy applied at 2012-06-20 10:31:42
Statistics enabled at 2012-06-20 10:31:42
Statistics last cleared: 2012-06-20 11:42:42
Rule number: 5 IPv4, 0 IPv6
Current status: OK!

Classifier: labnario operator or
 if-match ACL 3000
  rule 5 permit icmp source 172.16.0.0 0.0.0.3 destination 2.2.2.2 0
    10,200 bytes, 100 packets
    Last 30 seconds rate 0 pps, 0 bps
  rule 10 permit icmp source 2.2.2.2 0 destination 172.16.0.0 0.0.0.3
    0 bytes, 0 packets
    Last 30 seconds rate 0 pps, 0 bps

<R1>display traffic policy statistics interface GigabitEthernet 1/0/9 outbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet1/0/9
Traffic policy outbound: labnario
Traffic policy applied at 2012-06-20 10:31:45
Statistics enabled at 2012-06-20 10:31:45
Statistics last cleared: 2012-06-20 11:42:45
Rule number: 5 IPv4, 0 IPv6
Current status: OK!

Classifier: labnario operator or
 if-match ACL 3000
  rule 5 permit icmp source 172.16.0.0 0.0.0.3 destination 2.2.2.2 0
    0 bytes, 0 packets
    Last 30 seconds rate 0 pps, 0 bps
  rule 10 permit icmp source 2.2.2.2 0 destination 172.16.0.0 0.0.0.3
    10,200 bytes, 100 packets
    Last 30 seconds rate 0 pps, 0 bps

<R1>display traffic policy statistics interface GigabitEthernet 3/0/0 inbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet3/0/0
Traffic policy inbound: labnario
Traffic policy applied at 2012-06-19 14:02:40
Statistics enabled at 2012-06-19 14:02:40
Statistics last cleared: 2012-06-20 11:43:40
Rule number: 5 IPv4, 0 IPv6
Current status: OK!

Classifier: labnario operator or
 if-match ACL 3000
  rule 5 permit icmp source 172.16.0.0 0.0.0.3 destination 2.2.2.2 0
    0 bytes, 0 packets
    Last 30 seconds rate 0 pps, 0 bps
  rule 10 permit icmp source 2.2.2.2 0 destination 172.16.0.0 0.0.0.3
    10,200 bytes, 100 packets
    Last 30 seconds rate 0 pps, 0 bps

<R1>display traffic policy statistics interface GigabitEthernet 3/0/0 outbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet3/0/0
Traffic policy outbound: labnario
Traffic policy applied at 2012-06-19 14:02:43
Statistics enabled at 2012-06-19 14:02:43
Statistics last cleared: 2012-06-20 11:43:36
Rule number: 5 IPv4, 0 IPv6
Current status: OK!

Classifier: labnario operator or
 if-match ACL 3000
  rule 5 permit icmp source 172.16.0.0 0.0.0.3 destination 2.2.2.2 0
    10,200 bytes, 100 packets
    Last 30 seconds rate 0 pps, 0 bps
  rule 10 permit icmp source 2.2.2.2 0 destination 172.16.0.0 0.0.0.3
    0 bytes, 0 packets
    Last 30 seconds rate 0 pps, 0 bps

R2:

<R2>display traffic policy statistics interface GigabitEthernet 3/0/0 inbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet3/0/0
Traffic policy inbound: labnario
Traffic policy applied at 2000-01-01 00:32:07
Statistics enabled at 2000-01-01 00:49:04
Statistics last cleared: 2000-01-01 23:20:42
Rule number: 5 IPv4, 0 IPv6
Current status: OK!

Classifier: labnario operator or
 if-match ACL 3000
  rule 5 permit icmp source 172.16.0.0 0.0.0.3 destination 2.2.2.2 0
    10,200 bytes, 100 packets
    Last 30 seconds rate 0 pps, 0 bps
  rule 10 permit icmp source 2.2.2.2 0 destination 172.16.0.0 0.0.0.3
    0 bytes, 0 packets
    Last 30 seconds rate 0 pps, 0 bps

<R2>display traffic policy statistics interface GigabitEthernet 3/0/0 outbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet3/0/0
Traffic policy outbound: labnario
Traffic policy applied at 2000-01-01 01:41:43
Statistics enabled at 2000-01-01 01:41:43
Statistics last cleared: 2000-01-01 23:20:39
Rule number: 5 IPv4, 0 IPv6
Current status: OK!

Classifier: labnario operator or
 if-match ACL 3000
  rule 5 permit icmp source 172.16.0.0 0.0.0.3 destination 2.2.2.2 0
    0 bytes, 0 packets
    Last 30 seconds rate 0 pps, 0 bps
  rule 10 permit icmp source 2.2.2.2 0 destination 172.16.0.0 0.0.0.3
    10,200 bytes, 100 packets
    Last 30 seconds rate 0 pps, 0 bps

As you can see from these outputs, packets are not being lost in the network. In case of any network problem you can use a similar traffic policy to find where packets are being lost. Of course this is one of the examples of using traffic policy. You can, for instance, use it to catch packets classified based on DSCP, 802.1p etc. I can say I use it very often in a routine work, not only for troubleshooting but also in another applications.

This example was done based on NE40E V600R001SPC800 software. Traffic policy configuration can vary depending on the devices and software you use.