Sunday, February 22, 2015

Access Control Lists (ACLs) for VLANs in HP ProCurve Switches (K.15.14.xxxx)

Besides the usual port-based ACLs (which are applied to switch ports or static trunks and filter only inbound traffic), ProCurve switches running K.15.14.xxxx also support ACLs which can be applied to a VLAN interface.

Configuration of VLAN-based ACLs

To create a VLAN-based ACL, an access list needs to be created just the way it is created for a port-based ACL (PACL). For example the following access list will block all IP packets from host 192.168.2.10 to host 192.168.2.50, while allowing all other traffic:

HP-3500yl-24G (config)# ip access-list extended TESTVACL
HP-3500yl-24G (config-ext-nacl)# deny ip host 192.168.2.10 host 192.168.2.50
HP-3500yl-24G (config-ext-nacl)# permit ip any any
HP-3500yl-24G (config-ext-nacl)# exit

Suppose that both source and destination IP addresses in the ACL above are in VLAN 2 (192.168.2.0/24). Then the ACL TESTRACL can be applied to the VLAN 2 interface this way:

HP-3500yl-24G (config)# vlan 2
HP-3500yl-24G (vlan-2)# ip access-group TESTVACL vlan
HP-3500yl-24G (vlan-2)# exit

Notice the keyword vlan at the end of the ip access-group command. This keyword has to be used when both source and destination IP addresses belong to the same VLAN. In this case, the ACL is called a VLAN ACL, or VACL. If, instead of the keyword vlan, the keyword in is used like below:

HP-3500yl-24G (config)# vlan 2
HP-3500yl-24G (vlan-2)# ip access-group TESTVACL in
HP-3500yl-24G (vlan-2)# exit

Then the ACL will not filter out anything and host 192.168.2.10 can still talk to host 192.168.2.50.

The keywords in and out only work when the source and destination IP addresses belong to different VLANs. In this case the ACL is called a Routed IP ACL (RACL). Consider the example below:

HP-3500yl-24G (config)# ip access-list extended TESTRACL
HP-3500yl-24G (config-ext-nacl)# deny ip host 192.168.2.10 host 192.168.3.150
HP-3500yl-24G (config-ext-nacl)# permit ip any any
HP-3500yl-24G (config-ext-nacl)# exit

In this case the source host is in VLAN 2 (192.168.2.0/24) while the destination host is in VLAN 3 (192.168.3.0/24). We can apply this ACL as follows:

HP-3500yl-24G (config)# vlan 2
HP-3500yl-24G (vlan-2)# ip access-group TESTRACL in
HP-3500yl-24G (vlan-2)# exit

Applied as a RACL (using the in keyword), the TESTRACL ACL will filter out traffic coming from host 192.168.2.10 to host 192.168.3.150. Interestingly enough, the keyword vlan also works when source and destination belong to different VLANs.

To sum it up:


Question: In the figure above, VACL works for both cases. So what's the point of RACL?
Answer: VACL (and PACL as well) only filters INBOUND traffic, while RACL can filter both INBOUND and OUTBOUND traffic.

Monitoring ACLs

To view the number of packets that hit an ACL and went through the filtering process, there are 2 methods.

- Using the show statistics command as in the example below. Notice that this command displays both the number of denied packets and the number of permitted packets. The log keyword at the end of the deny statement in the ACL definition is not necessary in this method.


- Using the debug command. To use the debug feature to view the activities of an ACL, the deny statements under an ACL have to be configured with the log keyword at the end, as shown in the example below:

HP-3500yl-24G (config)# ip access-list extended TESTRACL
HP-3500yl-24G (config-ext-nacl)# deny ip host 192.168.2.10 host 192.168.2.50 log
HP-3500yl-24G (config-ext-nacl)# permit ip any any
HP-3500yl-24G (config-ext-nacl)# exit

The next step is to configure the debug feature as below:

HP-3500yl-24G (config)# debug destination session
HP-3500yl-24G (config)# debug destination logging (use this command if you want the ACL messages sent to a Syslog server)
HP-3500yl-24G (config)# debug acl

The default waiting time for logging "deny" matches is approximately 5 minutes. Use the command access-list logtimer to change the default value in seconds. The log messages will appear on the CLI as follows. Notice that only denied packets are reported.

Sunday, February 8, 2015

Selective Mirroring in HP ProCurve Switches (K.14.01 and Later)

Mirroring is a technique to copy traffic from one switch port (source port) to another (destination port), mostly for the purpose of capturing traces.

In selective (aka intelligent) mirroring, specific traffic can be selected to be mirrored to the destination port instead of all traffic at the source port. Below are two examples on how to configure classifier-based mirroring for a local session and for a remote session.

Classifier-based mirroring for local session:

In this example, all Echo Reply ICMP messages (Type 0) coming into Port C1 will be mirrored to Port B3:

mirror 1 port B3
class ipv4 EchoReplyClass
    10 match icmp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 0
    exit
policy mirror EchoReplyPolicy
    10 class ipv4 EchoReplyClass action mirror 1
interface C1
    service-policy EchoReplyPolicy in
    exit


Classifier-based mirroring, remote session:

In the example below, traffic from subnet 10.28.31.0/24 coming into VLAN 10 at switch A (10.10.40.4) will be mirrored to Port A1 in switch B (10.10.50.5). In this case switch A is considered the source switch and switch B the destination switch.

The destination switch (switch B) must be configured first:

Switch-B (config) # mirror endpoint ip 10.10.40.4 9200 10.10.50.5 port a1

(9200 is the UDP port number to be used for the session on the source switch. It is recommended that the port number is in the range from 7933 to 65535)

The next step is to configure the source switch (Switch A) as follows:

mirror 1 remote ip 10.10.40.4 9200 10.10.50.5
class ipv4 ServerClass
    match ip 10.28.31.0/24 any
    exit
policy mirror ServerPolicy
    class ipv4 ServerClass action mirror 1
    exit
vlan 10 service-policy ServerPolicy in

Wednesday, February 4, 2015

SDN Support in HP ProVision and Comware Switches

In ProCurve Switches, support for OpenFlow is as below:

K/KA.15.10: OpenFlow 1.0 support is added to 3500, 3500yl, 3800, 5400 with V1 and V2 modules, 6200 yl, 6600, 8200 zl with V1 and V2 modules.

WB.15.12: OpenFlow 1.0 support is added to 2920.

K/KA/WB.15.14: OpenFlow 1.3 is supported.

To configure OpenFlow, enter the configuration mode then enter the command openflow. An example of the basic OpenFlow configuration is given below:

configure
     openflow
          controller-id 1 ip 192.168.56.7 controller-interface vlan 192
          instance "vlan10"
          member vlan 10
          controller-id 1
          version 1.3
     enable
     exit


Switches running Comware 7 support OpenFlow 1.3. See the full list at the HP SDN Switches Portfolio. To configure openflow, enter the system view mode and use the command openflow. Below is an example of basic OpenFlow in Comware:

openflow instance 1
          description vlan10
          classification vlan 10
          controller 1 address ip 192.168.56.7
          activate instance


Contrary to the ProCurves, where only 1 VLAN can be assigned to an instance (unless aggregate instance is used), in Comware multiple VLANs can belong to one single instance. The command classification associates VLAN(s) to a given instance.

Tuesday, February 3, 2015

Broadcast Storm Containment in HP ProCurve Switches (K/KA/KB 15.15.xxx)

Broadcast storms can severely degrade network performance, even crash a network. They are mostly caused by loops at Layer 2. They may also be caused by DoS smurf attacks, or simply by a fault in NICs. For example, it has been known that certain Intel NICs continuously send out ICMPv6 packets and flood the network with these packets while the host machines are in sleep mode.

In HP ProCurve switches, a number of techniques can be used to restrict broadcast traffic while the root cause of the broadcast storm is being tracked down.

Using the fault-finder command:

From K.15.15.xxx the fault-finder command has more options for broadcast traffic.

The general syntax is:

fault-finder broadcast-storm port-list action [warn | warn-and-disable seconds] [percent percent | pps rate]

Where:

- “percent” is the threshold level as a percentage of bandwidth of the port.
- “pps” is the threshold level in number of broadcast packets per second.
- “warn” is the action of logging the event only.
- “warn-and-disable” is the action of logging the event and disabling the port.
- “seconds” is the waiting period before re-enabling the port, ranging from 0 to 604800 seconds. The zero
value means the port cannot be re-enabled automatically.

For example, “Fault-finder broadcast-storm A1-A10 action warn-and-disable 10 percent 40” will issue a warning and disable ports A1-A10 when a broadcast storm is detected at 40% port capacity. The ports will be re-enabled after 10 seconds.

To verify this configuration, use the command:

show fault-finder broadcast-storm

For the example above, the output will be as follows:


Limiting outbound broadcast traffic:

In the port context, the following command can be used to limit the OUTBOUND broadcast traffic in port capacity percentage. For example, the following command will allow outbound broadcast traffic up to 1 percent of the capacity of port A11. If port A11 is a 1G port then the outbound broadcast traffic is limited to 10 Mbps.

interface A11
    broadcast-limit 1


The range for “broadcast-limit” is 0 to 99. A value of zero disables broadcast limiting on the specified port.

To verify this configuration, use the command “show interfaces brief A11” and notice the last column:


Limiting inbound broadcast traffic

For limiting INBOUND broadcast traffic on specific ports, use the following command in the port context. For example, the command below limits inbound broadcast traffic to 10% of the port capacity:

interface A12
    rate-limit bcast in percent 10


To verify this configuration, use the command “show rate-limit bcast”. For example: