802.1Q Trunking Between Cisco and HP Switches

How to support different VLANs over a link between a Cisco switch and an HP Procurve switch could be confusing because of different terms and approaches used by the two vendors. This post aims to provide a short guide to make it work.

Notice that in the Procurve, the VLAN-port association is configured from the VLAN, while in Cisco IOS it is configured from the individual ports. Also "untagged" in the Procurve means "native" in Cisco terms, and "tagged" in the Procurve means "allowed" in Cisco terms. Now we can look at the actual configuration on both sides.

The configuration on the Cisco side should be:

On the Procurve side the configuration should be:

And yes, it worked:

PS: The last ping worked because I configured the default gateway on both switches (there is no VLAN 100 in the Procurve so the ping traffic has to be routed by the default gateways).

MAC-based VLANs in the ProCurve

In the ProCurve normally only one untagged VLAN is allowed on each switch port. Here’s the reason:

The VLAN ID is carried in the VLAN tag of the Layer 2 (Ethernet) frame, so as long as there’s a VLAN tag in the frame header we can tell which frame is associated with which VLAN. On the other hand in an untagged frame there is no VLAN tag, so there’s no way to tell directly from the frame header which VLAN the frame is associated with. However on a specific port we can always associate that “frame with no tag” with one single VLAN, and we do that by switch configuration. For example:

vlan 3
    name "VLAN3"
    untagged A1
    no ip address
    exit

From the above configuration we know that on port A1, an untagged frame is associated with VLAN 3. All untagged frames at all ports are associated with VLAN 1 by default, unless they are explicitly configured otherwise like in the above example.

Now, MAC-based VLANs (MBVs) use the source MAC address of an untagged frame as the basis for VLAN assignment. Therefore an untagged frame is no longer bound to a single configured VLAN. In this case each switch port can support untagged frames that belong to more than one VLANs.

In the ProCurve, MAC-based VLANs are not configurable, i.e. there is no command to enable or disable or modify it. This feature is used mostly for an authentication server such as RADIUS to allow multiple clients on the same switch port to receive different untagged VLAN assignments. The VLAN assignment for each client is done by the authentication server according to the configured server policy; and in case different untagged VLANs are assigned to clients attached to the same switch port, MBVs will automatically kick in.

A side-effect of this feature is that it allows egress traffic from one client’s VLAN to reach all untagged clients on the same port even though these other clients might not be in the same VLAN. For example, suppose clients A and B are both attached to the same switch port but untagged for different VLANs. Then if A is subscribing to a multicast stream then B will receive the same multicast stream as well.

An important point to remember is that MBVs are not supported on V1 hardware. They are only available on V2 or later hardware. When a situation arises where 2 clients are assigned different untagged VLANs on the same switch port and the switch hardware does not support MBVs, warnings about “untagged VLAN-id arbitration error” will appear in the event log.

Below is an interesting case study:

Two clients, an IP phone and a PC, were connected to the same switch port which was configured to do both MAC-based and 802.1X authentication. The RADIUS server policy was that once authenticated the phone should be assigned to VLAN 5 as tagged, while the PC should be assigned to VLAN 2 as untagged.

The problem was that there was always one client that failed authentication and was dropped from the switch port. In some cases the phone failed, in some other cases the PC failed. In the event log there were warnings such as:

W 07/14/17 09:35:48 02402 dca: macAuth client untagged VLAN-id arbitration error, MAC ………… port A1
W 07/13/17 08:02:27 02402 dca: 8021X client untagged VLAN-id arbitration error, MAC ………… port B2

What added to the puzzle was that out of 5 switches of the same model, 3 switches saw the issue while the other 2 did not.

Here’s what happened:

- The RADIUS server policy was misconfigured, instead of the phone to be put into VLAN 5 as tagged it was configured for VLAN 5 as untagged. This led to a situation where 2 clients were assigned to 2 different untagged VLANs on the same switch port. This was where MBV kicked in.

- However the MBV feature was available only on V2 hardware and later. So for switches that had V2 hardware there was no issue. The switches that had issues were the V1 switches

Local MAC Authentication in HP ProCurve Switches (K/KA.15.14)

Local MAC Authentication (LMA) locally performs MAC address-based authentication (as opposed to MAC authentication using a RADIUS server). Based on this authentication, devices can be assigned to appropriate VLANs and, optionally, CoS values. The usage of MAC OUI and MAC mask allows to group multiple devices under one single policy.

Configuring LMA using MAC groups:

Creating MAC groups and assign MAC addresses to each group. In the following example:

The first MAC group (“admin-pc-grp”) is assigned one single MAC address.
The second MAC group (“corp-pcs-grp”) is assigned 2 groups of addresses, each group is determined by the first 32 bits in the addresses.
The third MAC group (“corp-phones-grp”) is assigned all addresses carrying the same 24-bit OUI part of the MAC addresses.

HP-5406zl(config)# aaa port-access local-mac mac-group “admin-pc-grp” mac-addr 005056840161
HP-5406zl(config)# aaa port-access local-mac mac-group “corp-pcs-grp” mac-mask 002622bb/32 002622bc/32
HP-5406zl(config)# aaa port-access local-mac mac-group “corp-phones-grp” mac-oui 008011

Creating LMA profiles. In each profile, attributes such as VLAN (tagged or untagged) and QoS setting (CoS priority, aka 802.1p value) can be assigned.

HP-5406zl(config)# aaa port-access local-mac profile “admin-pc-prof” vlan untagged 2 cos 5
HP-5406zl(config)# aaa port-access local-mac profile “corp-pcs-prof” vlan untagged 3
HP-5406zl(config)# aaa port-access local-mac profile “corp-phones-prof” vlan tagged 5 cos 6

Linking profiles to MAC groups:

HP-5406zl(config)# aaa port-access local mac apply profile admin-pc-prof mac-group admin-pc-grp
HP-5406zl(config)# aaa port-access local mac apply profile corp-pcs-prof mac-group corp-pcs-grp
HP-5406zl(config)# aaa port-access local mac apply profile corp-phones-prof mac-group corp-phones-grp

Enabling LMA on ports:

HP-5406zl(config)# aaa port-access local-mac a1

Configuring LMA without MAC groups:

Creating LMA profiles just like in the previous section (using MAC groups). Again, in each profile attributes such as VLAN (tagged or untagged) and QoS setting (CoS priority, aka 802.1p value) can be assigned.

HP-5406zl(config)# aaa port-access local-mac profile “admin-pc-prof” vlan untagged 2 cos 5
HP-5406zl(config)# aaa port-access local-mac profile “corp-pcs-prof” vlan untagged 3
HP-5406zl(config)# aaa port-access local-mac profile “corp-phones-prof” vlan tagged 5 cos 6

Linking MAC addresses directly to profiles:

HP-5406zl(config)# aaa port-access local mac apply profile admin-pc-prof mac-addr 005056840161
HP-5406zl(config)# aaa port-access local mac apply profile corp-pcs-prof mac-mask 002622bb/32
HP-5406zl(config)# aaa port-access local mac apply profile corp-pcs-prof mac-mask 002622bc/32
HP-5406zl(config)# aaa port-access local mac apply profile corp-phones-prof mac-oui 008011

Enabling LMA on ports:

HP-5406zl(config)# aaa port-access local-mac a1

Question: What is the difference between LMA configuration using MAC groups and not using MAC groups?
Answer: LMA configuration not using MAC groups is a shortcut, useful when one has just a few MAC addresses for the same profile. When there is a lot of MAC addresses to be put under the same profile, MAC groups are recommended to avoid confusion.

LMA Monitoring:

After the LMA configuration shown above, when the client with the MAC address of 005056840161 accesses the switch at the specified port, it will be granted access. For monitoring LMA, enter the following command:

HP-5406zl(config)# show port-access local-mac active

The output will look like below. Notice that the authenticated client was put into VLAN 2 as untagged with CoS priority value of 5, just like what has been configured in the profile associated with that MAC address.

Other Features:

- The default MAC address format is “no delimiter”, for example "002622bba7ac" as shown in previous examples. To change the MAC address format, use the command:

HP-5406zl(config)# aaa port-access mac-based addr-format

MAC address format options include: no-delimiter (default), single-dash, multi-dash, multi-colon, no-delimiter-uppercase, single-dash-uppercase, multi-dash-uppercase, multi-colon-uppercase.

- By default, clients that cannot be authenticated will be dropped. However, an unauthenticated VLAN can be configured for these clients to access limited services. The administrator must implement measures to isolate the unauthenticated VLAN from restricted resources.

HP-5406zl(config)# aaa port-access local-mac unauth-vid 99

- On the other hand, if a client is successfully authenticated yet does not have a VLAN assignment in its profile, then it will be moved to an authorized VLAN which can be configured as below:

HP-5406zl(config)# aaa port-access local-mac auth-vid 10

- There are also a number of per-port parameters such as addr-limit (maximum number of authenticated local MAC addresses), logoff-period (period of time of inactivity that the switch considers an implicit logoff), quiet-period (period of time the switch does not try to authenticate), unauth-period (period of time the switch waits before moving the port to the VLAN for unauthenticated clients), which can be changed from their default values. For example:

HP-5406zl(config)# aaa port-access local-mac unauth-period 320

- When multiple authentication methods are configured concurrently on a single port, the order of precedence is: 802.1X, LMA, and Web Authentication / MAC Authentication.

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.