Labnario Huawei From Scratch

Let’s assume that a large number of packets are sent to CPU of a device. What will happen if most of these packets are malicious attack packets? CPU usage will become high, what can bring to services’ deterioration. In extreme cases it can lead the device to reboot. We can minimize an impact of the attack on network services, providing the local attack defense function. When such attack occurs, this function ensures non-stop service transmission.

Attack Defense Policy Supported by AR routers:

CPU attack defense:

• The device uses blacklists to filters invalid packets sent to the CPU
• The device limits the rate of packets sent to the CPU based on the protocol type
• The device schedules packets sent to the CPU based on priorities of protocol packets
• The device uniformly limits the rate of packets with the same priority sent to the CPU and randomly discards the excess packets to protect the CPU
• ALP is enabled to protect HTTP, FTP and BGP sessions. Packets matching characteristics of the sessions are sent at a high rate, that’s why session-related services are ensured.

Do you know the Private VLAN feature from Cisco switches? The same feature exists on Huawei switches and is called the MUX VLAN.

How does this feature work?

MUX VLAN allows isolating Layer2 traffic of different interfaces in the same VLAN, and still allowing access to common resources.

Look at the topology below. Let’s assume that we want to configure our labnariosw switch, so that:

• hosts in VLAN10 should be able to ping each other and ping server in VLAN30
• hosts in VLAN20 should be able to ping server in VLAN30 but not each other
• hosts in VLAN10 should not be able to ping hosts in VLAN20.

Topology Change (TC) packets are sent when MSTP-enabled interface in a network flaps. If a physical interface frequently alternates between Up and Down, the MSTP status of the device in the network becomes unsteady. As a result, a large number of TC messages are generated, ARP entries are frequently deleted and services are interrupted.

How to find the source of TC packets?

Let’s look at the log, generated on one of the switches in a network. Let’s take Huawei S9300 switch as an example:

Dec 19 2012 11:32:56+10:00 S9300 %%01MSTP/6/RECEIVE_MSTITC(l)[40922]:MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet6/0/0.

What can we find in this log?

The most important for us is the port number on which the switch received TC packet, in this case interface GE6/0/0. To troubleshoot this problem we have to go to the next switch, connected to interface GE6/0/0 and check logs of that switch. If the neighbouring switch receives TC packets as well, we have to do further troubleshooting. If we find in the logs that MSTP-enabled interface is flapping, we can consider that this interface is the source of the TC packet. If this interface is still flapping, just make it down, to avoid unsteady behaviour.

This article is a continuation of the basic BGP with Huawei CLI.

Today I want to explain you, why labnarioR5 router cannot ping BGP prefixes advertised by BGP AS50. Do you remember our BGP topology? I have configured BGP protocol as in the picture below:

There are three BGP Autonomous Systems: AS50, AS100 and AS55. All are connected via EBGP peering sessions. AS100 has three routers forming IBGP full mesh. LabnarioR1 router in AS50 advertises three prefixes:

• 11.10.10.0/24
• 12.10.10.0/24
• 13.10.10.0/24

All these prefixes are advertised by the routers in AS100 and pass to AS55. LabnarioR5 router has these prefixes in its BGP and routing tables, but cannot ping them. Why is it like that?

Today I would like to focus on SSH application. What I want to do is to configure SSH connection between two switches, using password and RSA authentication:

• Connection between stelnet client and SSH server
• Connection between SFTP client and SSH server.

Let’s look at the simple SSH topology: