Labnario Huawei From Scratch

To start using IPv6 in our labs, I decided to prepare a short introduction of it. As it is a broad topic I had to split it into several parts. Let’s start from the beginning.

Short IPv6 history

First IPv6 protocol specification was introduced in late 1995 in RFC1883, so it was 18 years ago! About one year later 6bone network was started as a virtual network over the IPv4-based Internet (using IPv6 over IPv4 tunneling). The mission of the 6bone was to establish the IPv6 environment for testing purposes.  In 1999 IPv6 Forum was founded and registries started assigning IPv6 prefixes to ISPs. In 2000, many vendors began to bundle IPv6 into their mainstream product lines. 2009 – first serious IPv4 address shortage in developed countries.

What about IPv5?

IPv5 was an experimental Resource Reservation Protocol, intended to provide QoS for multimedia and defined as the Internet Stream Protocol version 2 (ST2). It was designed to coexist with IPv4 and use the same addressing scheme, not as a replacement of IPv4. ST2 was designed to coexist with IPv4 on each node. The main role of the ST2 was to transfer a real-time multimedia, where IPv4 could be used for the transfer of traditional data and control information. ST2 is described in RFC1819.

Let’s assume that you have U2000 NMS server to monitor Huawei devices. We can manage these devices in 2 ways: outband or inband management. Outband management means that you have a separate DCN network to manage devices. It is commonly used for critical nodes, for example for backbone routers. Unlike to backbone network, it is difficult to implement DCN for mobile backhaul networks, where the number of devices reaches hundreds or even thousands. In such situation inband management is implemented to reduce cost. Then the decision how to send SNMP packets to the NMS server is based on routing protocols. The packets travel through the monitored network and are susceptible to all turbulences, which can appear in the network. This may lead to the fact that some SNMP packets may be lost by the network.

Let’s imagine such case. A link between a router and NMS is “DOWN”. No redundant link is established. The router sends SNMP trap to the NMS server but the server is not available. The SNMP packet is lost. Then the link is going to “UP” state and the router send SNMP trap to U2000. This trap is then dropped by U2000 because there is not related “DOWN” trap, which was lost before.

And what’s next?

U2000 synchronizes alarms with devices every 30 minutes and NMS server receives “DOWN” trap from the router, which was lost earlier. As the clearing trap was dropped, this “DOWN” alarm will not be cleared anymore. Then we have “DOWN” hanging (not cleared) alarm in U2000.

Our blog topics touched access lists ACLs, used on Huawei devices. We talked about ACLs in traffic policies, ACLs and their matching order, ACLs in PBR and so on and so forth.

As ACLs are widely used, I decided to prepare a simple cheat sheet, that describes three kinds of ACLs (the most often used) and their usage scenarios.

Additionally a new page has been opened. I will upload new cheat sheets there, when they are ready.

Have a suggestion for a cheat sheet? Create your own? Let us know in comments.

We have to remember that traffic policy consists of 3 parts:

• Classifier
• Behavior
• Traffic-policy

In brief, to configure a traffic policy:

• define traffic class
• define action to be applied to the traffic class
• associate traffic classifiers and behaviors
• apply the traffic policy to an interface.

Let’s start from ACL.

We have possibility to configure many rules in an ACL. If the ACL is specified in if-match clause, then a packet is matched against multiple rules. If the packet matches a rule in the ACL, then it stops checking against the next rules.

• In a case of DENY action in the ACL, the matched packet is denied, regardless of what traffic behavior defines.
• When PERMIT action is defined in the ACL, then traffic behavior is applied to the matched packet.

How to protect Huawei switches against ARP flood attack?

DoS attack is an attempt to make a network resources unavailable to its intended users. There are several different types of DoS attacks, but most of them rely on spoofing and flooding techniques. Some of these attacks can be hard to defend against, because DoS packets may look exactly like normal packets.

One common method of attack involves saturating the target device with a flood of request packets, so that this device cannot respond to a legitimate traffic or responds so slowly, as to be unavailable.

Attackers often use ARP protocol to attack network devices, because it is easy to use and has no security mechanisms built in. Flooding a network device with ARP request packets can lead to insufficient CPU resources to process other services, when processing a large number of ARP packets. To protect the device, ARP rate limiting mechanism can be used. On Huawei switches this feature can be implemented in the following ways:

• Limiting the rate of ARP packets globally, in a VLAN or on an interface
• Limiting the rate of ARP packets based on the source MAC address
• Limiting the rate of ARP packets based on the source IP address