Category Archives: Networking

EAPoL forwarding on NEC VoIP phones

This posting is ~2 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

A customer is running their PCs behind their VoIP phones. Nothing unusual, most VoIP phones I know have an embedded ethernet switch, so that you only need one cable to connect PC and VoIP phone to your network.

Martinelle/ pixabay.com/ Creative Commons CC0

As part of a network security project, my colleague and I implemented IEEE 802.1X port-based Network access control at one of our customers networks. The setup consists of multiple Alcatel-Lucent Enterprise OmniSwitches (6450-P10 and 6860/E) and Aruba ClearPass.

We noticed, that mac-address based authentication worked all the time, but 802.1x fails constantly if the client was connected to a VoIP phone (NEC DT700). The phones does not do any port authentication. We use a device classification rule and User Network Profiles to get them to their correct VLAN. But the connected PCs should do a 802.1x based port authentication.

Wireshark FTW!

We used Wireshark to take a look at the communication. We created a packet trace on a client behind a VoIP phone, and we mirrored the traffic of the port, to which the phone was connected. Our assumption was that the VoIP phones drop the EAP packets from the connected PC.

This is a packet trace from my ThinkPad X250 which was connected to the phone.

Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0

You can see the repeating “Request, Identity” from the switch, and the answer from my laptop (Response, Identity). The destination for the response is a multicast mac-address. But this frame was not captured behind the VoIP phone! It was missing. On the packet trace, that was created my mirroring the switch port to which the phone was connected, the “Request, Identity” was seen, but not the “Response, Identity”. The phone was dropping the EAP packets of my laptop!

RTFM!

The customer called the company who was maintaining the phones. But they did not understood our problem, so they enabled 802.1x on the phones. We disabled this instantly again.

I decided to take a look into the manual of the NEC DT700 and I found a point called “EAPoL forwarding” in the advanced network settings. After enabling this setting, EAP started working instantly.

Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0

This is again a packet trace from my laptop, taken while it was connected to a VoIP phone. As you can see, the last EAP packet is “Success”!

EAPoL forwarding did the trick. :)

Bypass stateful firewall on a Sophos XG

This posting is ~3 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Usually, bypassing a firewall is not the best idea. But sometimes you have to. One case, where you want to bypass a firewall, is asymmetric routing.

MichaelGaida/ pixabay.com/ Creative Commons CC0

What is asymmetric routing? Imagine a scenario with two routers on the same network. One router offeres access to the internet, the other router provides access to other sites with site-2-site VPN tunnels.

Asymmetric Routing

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Host 1 uses R1 as default gateway. R1 has static routes configured to the networks reachable over the VPN, or it has learned them dynamically using a routing protocol from R2. A packet from host 1 arrives at R1, is routed to R2, and is sent over the VPN tunnel. The answer to this packet arrives at R2, and is sent directly to host 1, because host 1 is the destination. This works because R2 and host 1 are on the same network. This is asymmetric routing, because request and answer go different ways.

In case of routing, this is not a problem. But if R1 is a firewall, this firewall might be stubborn, because it does not see the whole traffic.

Bypass the stateful firewall

I recently had such a setup due to some technical debts. The firewall dropped that “Invalid Traffic”. Fortunately, there is a way to bypass the statefull firewall. You can create advanced firewall rules using the CLI. There is no way to create these rules using the GUI. And this only applies to the Sophos XG (former Cyberoam products).

Login to the device console and select option 4. Then enter on the console the following commands, one per destination:

Console> set advanced-firewall bypass-stateful-firewall-config add source_network 192.168.99.0 source_netmask 255.255.255.0 dest_network 192.168.20.0 dest_netmask 255.255.255.0

Make sure that you have a static or dynamically learned route to the networks. This is not a routing entry, it only tells the firewall what traffic should bypass the stateful firewall.

DOT1X authentication failed on HPE OfficeConnect 1920 switches

This posting is ~3 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

The last two days, I have supported a customer during the implementation of 802.1x. His network consisted of HPE/ Aruba and some HPE Comware switches. Two RADIUS server with appropriate policies was already in place. The configuration and test with the ProVision based switches was pretty simple. The Comware based switches, in this case OfficeConnect 1920, made me more headache.

blickpixel/ pixabay.com/ Creative Commons CC0

The customer had already mac authentication running, so all I had to do, was to enable 802.1x on the desired ports of the OfficeConnect 1920. The laptop, which I used to test the connection, was already configured and worked flawless if I plugged it into a 802.1x enabled port on a ProVision based switch. The OfficeConnect 1920 simply wrote a failure to its log and the authentication failed. The RADIUS server does not logged any failure, so I was quite sure, that the switch caused the problem.

DOT1X/6/DOT1X_AUTH_FAILURE: -IfName=GigabitEthernet1/0/1-UserName=DOM\USERNAME; DOT1X authentication failed

After double-checking all settings using the web interface of the switch, I used the CLI to check some more settings. Unfortunately, the OfficeConnect 1920 is a smart-managed switch and provides only a very, very limited CLI. Fortunately, there is a developer access, enabling the full Comware CLI. You can enable the full CLI by entering

_cmdline-mode on

after logging into the limited CLI. You can find the password using your favorite internet search engine. ;)

Solution

While poking around in the CLI, I stumbled over this option, which is entered in the interface context:

[1920-GigabitEthernet1/0/1] dot1x mandatory-domain RADIUS

RADIUS is the authentication domain, which was used on this switch. The command specifies, that the authentication domain RADIUS has to be for 802.1x authentication requests. Otherwise the switch would use the default authentication domain SYSTEM, which causes, that the switch tries to authenticate the user against the local user database.

I have not found any way to specify this setting using the web GUI! If you know how, of if you can provide additional information about this “issue”, please leave a comment.

Notes about 802.1x and MAC authentication

This posting is ~3 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Open network ports in offices, waiting rooms and entrance halls make me curious. Sometimes I  want to plugin a network cable, just to see if I get an IP address. I know many companies that does not care about network access control. Anybody can plugin any device to the network. When talking with customers about network access control, or port security, I often hear their complains about complexity. It’s too complex to implement, to hard to administrate. But it is not sooo complex. In the easiest setup (with mac authentication), you need a switch, that can act as authenticator, and a authentication server. But IEEE 802.1x is not much more complicated.

A brief overview over IEEE 802.1x

IEEE 802.1X offers authentication and authorization in wired or wireless networks. The supplicant (client) requests access to the network by providing a username/ password, or a digital certificate to the authenticator (switch). The authenticator forwards the provided credentials to the authentication server (mostly RADIUS or DIAMETER). The authentication server verifies the credentials and decides, if the supplicant is allowed to access the network.

802.1x uses the Extensible Authentication Protocol (EAP RFC5247) for authentication. Because EAP is a framework, there are different implementations, like EAP Transport Layer Security (EAP-TLS), or EAP with pre-shared key (EAP-PSK). Because it is only a framework, each protocol, that uses EAP, has to encapsulate it. Typical encapsulations are EAP over LAN (that is what 802.1x uses), RADIUS/ DIAMETER can use also use EAP. Protected EAP (PEAP) encapsulates EAP traffic into a TLS tunnel. PEAP is typically used as a replacement for EAP in EAPOL, or with with RADIUS or DIAMETER.

IEEE 802.1x EAP

Wikipedia/ wikipedia.org/ Public domain image resources

So far nothing special. It’s more a security thing, but an important one, if you ask me. But many customers avoid 802.1x, because of complexity. It’s perfect to keep you out of your own network, if something fails. And not all devices can act as supplicant.

But there is another benefit of 802.1x: RADIUS-Access-Accept messages can be used to dynamically assign VLAN memberships (RADIUS Extensions, RFC6929). To assign a VLAN membership to a port, to which a supplicant is connected, the RADIUS server adds three attributes to the Access-Accept message:

  • Tunnel-Type (VLAN)
  • Tunnel-Medium-Type (802)
  • Tunnel-Private-Group-Id (VLAN ID)

The authenticator uses these attributes to dynamically assign a VLAN to the port, to which the supplicant is connected.

MAC authentication

How does MAC authentication fit into this? If a client does not support 802.1x, the authenticator can use the mac-address of the connected device as username and password. The RADIUS server can use these credentials to authenticate the connected device. If you use a windows-based NAP (Windows Server NPS role), you have to create a user object in your Active Directory or local user database, that uses the mac-address as username and password. Depending on the switch configuration, the format of the username differes (xx:xx:xx:xx:xx:xx or xxxxxx-xxxxxx etc.). It’s a security fail, right? Yes, it is. So please:

  • Use MAC authentication only when needed, and
  • make sure that your authenticator uses PEAP

PEAP uses a TLS tunnel to protect the CHAP messages.

Another important part is your authentication server, mostly a RADIUS or DIAMETER server. Make sure that it is highly available. You should have at least two authentication server. I would not load balance them through a load balancer (Citrix NetScaler etc.). Simply add two authentication servers to your switch configuration. If your authentication server uses a user database, like Microsoft Active Directory, make sure that this database is also highly available. As I said: It is perfect to keep you out of your own network.

Sample config for ArubaOS (HPE ProVision based switches)

Here’s a sample config for a Aruba 2920 switch, running ArubaOS WB.16.04. 802.1x and MAC authentication are configured for the ports 1 to 5. If the authentication failes, VLAN 999 will be assigned to the port. VLAN 999 is used as unauth VLAN, which is used for unauthenticated clients.

radius-server host 192.168.1.10 key "T0p5ecr3t"
radius-server host 192.168.1.11 key "T0p5ecr3t"
aaa authentication port-access eap-radius
aaa authentication mac-based peap-mschapv2
aaa port-access authenticator 1-5
aaa port-access authenticator 1 client-limit 32
aaa port-access authenticator 2 client-limit 32
aaa port-access authenticator 3 client-limit 32
aaa port-access authenticator 4 client-limit 32
aaa port-access authenticator 5 client-limit 32
aaa port-access authenticator active
aaa port-access mac-based 1-5
aaa port-access mac-based 1 addr-limit 32
aaa port-access mac-based 1 unauth-vid 999
aaa port-access mac-based 2 addr-limit 32
aaa port-access mac-based 2 unauth-vid 999
aaa port-access mac-based 3 addr-limit 32
aaa port-access mac-based 3 unauth-vid 999
aaa port-access mac-based 4 addr-limit 32
aaa port-access mac-based 4 unauth-vid 999
aaa port-access mac-based 5 addr-limit 32
aaa port-access mac-based 5 unauth-vid 999

If 802.1x fails, the authenticator, will try MAC authentication. If this fails too, VLAN 999 is assigned to the switch port.

In this case, the client was authenticated by 802.1x.

SW1(config)# show port-access auth client 1 detailed

 Port Access Authenticator Client Status Detailed

  Port-access authenticator activated [No] : Yes
  Allow RADIUS-assigned dynamic (GVRP) VLANs [No] : No
  Dot1x2010 Mode [Disabled] : Disabled                Use LLDP data to authenticate [No] : No

  Client Base Details :
   Port            : 1
   Client Status   : Authenticated         Session Time    : 9 seconds
   Client name     : [email protected]           Session Timeout : 0 seconds
   IP              : n/a                   MAC Address     : 643150-7c7c9f

  Access Policy Details :
   COS Map         : Not Defined           In Limit Kbps   : Not Set
   Untagged VLAN   : 2500                  Out Limit Kbps  : Not Set
   Tagged VLANs    : No Tagged VLANs
   Port Mode       : 1000FDx
   RADIUS ACL List : No Radius ACL List

This is the output for MAC authentication.

SW1(config)# show port-access mac-based clients 1 detailed

 Port Access MAC-Based Client Status Detailed

  Client Base Details :
   Port            : 1
   Client Status   : authenticated         Session Time    : 14 seconds
   MAC Address     : 643150-7c7c9f         Session Timeout : 0 seconds
   IP              : n/a

  Access Policy Details :
   COS Map         : Not Defined           In Limit Kbps   : Not Set
   Untagged VLAN   : 1                     Out Limit Kbps  : Not Set
   Tagged VLANs    : No Tagged VLANs
   Port Mode       : 1000FDx               Auth Mode       : User-based
   RADIUS ACL List : No Radius ACL List

In both cases, VLAN 1 was dynamically assigned by RADIUS-Access-Accept messages.

Enable IPv6 SLAAC on HPE OfficeConnect 1920 switches

This posting is ~4 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

The HPE OfficeConnect 1920 switch series is designed for SMBs. The switch is perfect for small environments, that require features like VLANs, routing or 802.1x. This switch is smart-managed, so it has “only” a web interface and only a limited CLI.

I have two switches in my lab: A 1910-8G and the successor, a 1920-24G. Although the device supports IPv6, it doesn’t support SLAAC (Stateless Address Autoconfiguration) by default. The switch does not send router advertisements (RA). I’m using IPv6 in my lab (Stateless DHCPv6 + SLAAC), so the missing RAs were a problem for me, or at least, annoying. Fortunately you can change the default behaviour.

Enable router advertisements (RA)

To change the default behaviour of the HPE 1920, you have to use the CLI. The CLI is very limited, but there’s a hidden CLI command, which enables access to nearly all available features. If you are familiar with HPEs Comware based switches, you will notice, that the switch is a Comware-based device.

login as: admin
[email protected]'s password:

******************************************************************************
* Copyright (c) 2010-2016 Hewlett Packard Enterprise Development LP          *
* Without the owner's prior written consent,                                 *
* no decompiling or reverse-engineering shall be allowed.                    *
******************************************************************************

<1920-24G>_cmdline-mode on
All commands can be displayed and executed. Continue? [Y/N]y
Please input password: Jinhua1920unauthorized
Warning: Now you enter an all-command mode for developer's testing, some commands may affect operation by wrong use, please carefully use it with our engineer's direction.
<1920-24G>sys
System View: return to User View with Ctrl+Z.

After switching to the system-view, we can change the default behaviour for each VLAN interface. I have multiple VLAN interfaces and each VLAN interface has an IPv4 and an unique local address (ULA) IPv6 address.

[1920-24G]interface Vlan-interface 3
[1920-24G-Vlan-interface3]display this
#
interface Vlan-interface3
 ipv6 address FDDA:28AD:487:3:FFFF:FFFF:FFFF:FFFE/64
 ip address 192.168.200.94 255.255.255.224
 dhcp select relay
 dhcp relay server-select 0
#
return

[1920-24G-Vlan-interface3]undo ipv6 nd ra halt
[1920-24G-Vlan-interface3]ipv6 nd ra prefix FDDA:28AD:487:3::/64 86400 3600
[1920-24G-Vlan-interface3]display this
#
interface Vlan-interface3
 ipv6 nd ra prefix FDDA:28AD:487:3::/64 86400 3600
 undo ipv6 nd ra halt
 ipv6 address FDDA:28AD:487:3:FFFF:FFFF:FFFF:FFFE/64
 ip address 192.168.200.94 255.255.255.224
 dhcp select relay
 dhcp relay server-select 0
#
return
[1920-24G-Vlan-interface3]quit

The first command enables router advertisements. The second command adds the prefix which should be announced. That’s it. Don’t forget to save the changed configuration with “save force”. If you have more than one VLAN interface, enter this command in each VLAN interface context you wish to change.

I’m routing on the edge…

This posting is ~4 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

In my last post (Routed Port vs. Switch Virtual Interface (SVI)), I have mentioned a consequence of using routed ports to interconnect access and core switches:

You have to route the traffic on the access switches.

Routing on the network access, the edge of the network, is not a question of performance. It is more of a management issue. Depending on the size of your network, and the number of subnets, you have to deal with lots of routes. And think about the effort, if you add, change or remove subnets from your network. This is not what you want to do with static routes. You need a routing protocol.

The experiment of the week

We have a core switch C1, consisting of two independent switches (C1-1 and C1-2) forming a virtual chassis. S1 and S2 are two switches at the network access. This is a core-edge design. There is no distribution layer. Each switch at the network access has two uplinks: One uplink to C1-1 and one uplink to C1-2. The ports on each end of the links are configured as routed ports.

Please ignore the 40 GbE ports (FGE) between C1-1 and C1-2. These ports are used for the Intelligent Resilient Framework (IRF), which is used to create a virtual chassis.

routed_links_1

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

These are the interfaces on the core switch, that are working in route mode. GE1/0/1 and GE2/0/1 are the uplinks to S1, and GE1/0/2 and GE2/0/2 are the uplinks to S2.

[C1]display interface brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.0.0.1
GE1/0/2              UP   UP       10.10.0.1
GE2/0/1              UP   UP       10.1.0.1
GE2/0/2              UP   UP       10.11.0.1
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.1
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --

These are the interfaces on the access switch S1, that are working in route mode. GE1/0/1 and GE1/0/2 are the uplinks to C1. As you can see, GE1/0/1 on C1 and  GE1/0/1 on S1 belong to the same /30 network. The same applies to GE2/0/1 on C1 and GE1/0/2 on S1. There are also two SVIs, one on VLAN 1 (192.168.1.0/24) and another on VLAN 2 (192.168.2.0/24). These VLANs are used for client connectivity.

[S1]display interface brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.0.0.2
GE1/0/2              UP   UP       10.1.0.2
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.2
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --
Vlan1                UP   UP       192.168.1.1
Vlan2                UP   UP       192.168.2.1

These are the interfaces on S2, that are working in route mode. GE1/0/1 and GE1/0/2 are the uplinks to C1. The interfaces GE1/0/2 on C1, and  GE1/0/1 on S2 belong to the same /30 network. The same applies to GE2/0/2 on C1 and GE1/0/2 on S2. There are also two SVIs, one on VLAN 1 (192.168.10.0/24) and another on VLAN 2 (192.168.20.0/24).

You might wonder, because the same VLAN IDs are used on both access switches. They don’t care, because there is no layer 2 connectivity between these two switches. The only way from S1 to S2 is over the routed links to the core switch.

[S2]display interface brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.10.0.2
GE1/0/2              UP   UP       10.11.0.2
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.3
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --
Vlan1                UP   UP       192.168.10.1
Vlan2                UP   UP       192.168.20.1

Now let’s have a look at the Open Shortest Path First (OSPF) routing protocol.

Single Area OSPF

The Open Shortest Path First (OSPF) routing protocol is an interior gateway protocols (IGP), and also a link-state routing protocol. The calculation of the shortest path for each route is based on Dijkstra’s algorithm. I don’t want to annoy you with details. Take a look at the Wikipedia article for OSPF.

The simplest OSPF setup is a “Single Area OSPF”. This is an OSPF configuration, which has only a single area. This is the area 0, or the backbone area.

The configuration on the core switch looks like this:

[C1]ospf 1
[C1-ospf-1]display this
#
ospf 1
 area 0.0.0.0
  network 1.1.1.1 0.0.0.0
  network 10.0.0.0 0.255.255.255
#

The networks, that should be associated with this area, are specified with a wildcard mask. The wildcard mask is the opposite of the subnet mask. The wildcard mask 0.255.255.255 corresponds to the subnet mask 255.0.0.0. Because I have used multiple /30 subnets at the core switch, I can summarize them with a single entry for 10.0.0.0.

The same configuration applies to the access switches S1 and S2.

[S1]ospf 1
[S1-ospf-1]display this
#
ospf 1
 area 0.0.0.0
  network 1.1.1.2 0.0.0.0
  network 10.0.0.0 0.255.255.255
  network 192.168.0.0 0.0.255.255
#
[S2]ospf 1
[S2-ospf-1]display this
#
ospf 1
 area 0.0.0.0
  network 1.1.1.3 0.0.0.0
  network 10.0.0.0 0.255.255.255
  network 192.168.0.0 0.0.255.255
#

With this simple configuration, the switches will exchange their routing information. They will synchronize their link-state databases, and they will be fully adjacent. If a link-state change occurs, OSPF will handle this.

The core switch has two links to each access switch. The router ID represents the access switches. 1.1.1.2 is a loopback interface IP address on S1, 1.1.1.3 is a loopback interface IP address on S2.

<C1>display ospf peer

         OSPF Process 1 with Router ID 1.1.1.1
               Neighbor Brief Information

 Area: 0.0.0.0
 Router ID       Address         Pri Dead-Time  State             Interface
 1.1.1.2         10.0.0.2        1   37         Full/DR           GE1/0/1
 1.1.1.3         10.10.0.2       1   36         Full/DR           GE1/0/2
 1.1.1.2         10.1.0.2        1   38         Full/DR           GE2/0/1
 1.1.1.3         10.11.0.2       1   35         Full/DR           GE2/0/2

The same applies to the access switches, in this case S1. The access switches have also two active links to the core switch.

<S1>dis ospf peer

         OSPF Process 1 with Router ID 1.1.1.2
               Neighbor Brief Information

 Area: 0.0.0.0
 Router ID       Address         Pri Dead-Time  State             Interface
 1.1.1.1         10.0.0.1        1   31         Full/BDR          GE1/0/1
 1.1.1.1         10.1.0.1        1   32         Full/BDR          GE1/0/2

If one of the links fail, the access switch has another working link to the core switch, and OSPF will recalculate the shortest paths, taking the link-state change (link down between core and an access switch) into account.

This is the OSPF routing table of the core switch, based on the example above.

<C1>display ospf routing

         OSPF Process 1 with Router ID 1.1.1.1
                  Routing Table

 Routing for network
 Destination        Cost     Type    NextHop         AdvRouter       Area
 192.168.10.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.10.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 10.10.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.11.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.0.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 10.1.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 1.1.1.1/32         0        Stub    0.0.0.0         1.1.1.1         0.0.0.0
 1.1.1.2/32         1        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 1.1.1.2/32         1        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 1.1.1.3/32         1        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 1.1.1.3/32         1        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.1.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.1.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0

 Total nets: 17
 Intra area: 17  Inter area: 0  ASE: 0  NSSA: 0

What if I add a new subnet on S1? Let’s create a new VLAN and add a SVI to it (VLAN 3 and 192.168.3.1).

[S1]dis int brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.0.0.2
GE1/0/2              UP   UP       10.1.0.2
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.2
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --
Vlan1                UP   UP       192.168.1.1
Vlan2                UP   UP       192.168.2.1
Vlan3                UP   UP       192.168.3.1

Without touching the OSPF configuration, the core switch C1, and the other access switch S2, added routes to this new subnet.

<C1>display ospf routing

         OSPF Process 1 with Router ID 1.1.1.1
                  Routing Table

 Routing for network
 Destination        Cost     Type    NextHop         AdvRouter       Area
 192.168.3.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.3.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 192.168.10.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.10.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 10.10.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.11.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.0.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 10.1.0.0/30        1        Transit 0.0.0.0         1.1.1.2         0.0.0.0
 1.1.1.1/32         0        Stub    0.0.0.0         1.1.1.1         0.0.0.0
 1.1.1.2/32         1        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 1.1.1.2/32         1        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 1.1.1.3/32         1        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 1.1.1.3/32         1        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.10.0.2       1.1.1.3         0.0.0.0
 192.168.20.0/24    2        Stub    10.11.0.2       1.1.1.3         0.0.0.0
 192.168.1.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.1.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.0.0.2        1.1.1.2         0.0.0.0
 192.168.2.0/24     2        Stub    10.1.0.2        1.1.1.2         0.0.0.0

 Total nets: 19
 Intra area: 19  Inter area: 0  ASE: 0  NSSA: 0
<S2>display ospf routing

         OSPF Process 1 with Router ID 1.1.1.3
                  Routing Table

 Routing for network
 Destination        Cost     Type    NextHop         AdvRouter       Area
 192.168.3.0/24     3        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 192.168.3.0/24     3        Stub    10.11.0.1       1.1.1.2         0.0.0.0
 192.168.10.0/24    1        Stub    0.0.0.0         1.1.1.3         0.0.0.0
 10.10.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.11.0.0/30       1        Transit 0.0.0.0         1.1.1.3         0.0.0.0
 10.0.0.0/30        2        Transit 10.10.0.1       1.1.1.2         0.0.0.0
 10.0.0.0/30        2        Transit 10.11.0.1       1.1.1.2         0.0.0.0
 10.1.0.0/30        2        Transit 10.10.0.1       1.1.1.2         0.0.0.0
 10.1.0.0/30        2        Transit 10.11.0.1       1.1.1.2         0.0.0.0
 1.1.1.1/32         1        Stub    10.10.0.1       1.1.1.1         0.0.0.0
 1.1.1.1/32         1        Stub    10.11.0.1       1.1.1.1         0.0.0.0
 1.1.1.2/32         2        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 1.1.1.2/32         2        Stub    10.11.0.1       1.1.1.2         0.0.0.0
 1.1.1.3/32         0        Stub    0.0.0.0         1.1.1.3         0.0.0.0
 192.168.20.0/24    1        Stub    0.0.0.0         1.1.1.3         0.0.0.0
 192.168.1.0/24     3        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 192.168.1.0/24     3        Stub    10.11.0.1       1.1.1.2         0.0.0.0
 192.168.2.0/24     3        Stub    10.10.0.1       1.1.1.2         0.0.0.0
 192.168.2.0/24     3        Stub    10.11.0.1       1.1.1.2         0.0.0.0

 Total nets: 19
 Intra area: 19  Inter area: 0  ASE: 0  NSSA: 0

Pretty cool, isn’t it?

Any downsides?

This is only an example with a single core switch and two access switches. OSPF can be pretty complex, if the size of the network increases. The Dijkstra’s algorithm can be really CPU intensive, and the size of the link-state databases (LSDB) increase with adding more routers and networks. For this reason, larger networks have to be divided into separate areas. It depends on the network size and the CPU/ memory performance of your switches/ routers, but a common practice is a maximum of up to 50 switches/ routers per area. If you have unstable links, the area should be smaller, because each link-state change is flooded to all neighbors and consumes CPU time.

You need a good subnet design, otherwise you have to touch your OSPF configuration too often. You should be able to summarize subnets.

Conclusion

Routing at the network access is nothing for small networks. There are better designs for small networks. But if your network has a decent size, routing at the edge of the network can offer some benefits. Instead of working with SVIs and small transfer VLANs, a routed port is more simple to implement. Routed links can also have a shorter convergence delay, and you can reduce the usage of Spanning Tree Protocol to a minimum.

Routed Port vs. Switch Virtual Interface (SVI)

This posting is ~4 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Many years ago, networks consisted of repeaters, bridges and router. Switches are the successors of the bridges. A switch is nothing else than a multiport bridge, and a traditional switch doesn’t know how to pass traffic to a different broadcast domains (VLANs). Passing traffic between different broadcast domains, is a job for a router. A router has an IP interface in each broadcast domain, and the IP interface is used by the clients in the broadcast domain as a gateway.

Switch Virtual Interface

A Switch Virtual Interface, or SVI, is exactly this: An virtual IP interface in a broadcast domain (or VLAN). It’s used by the connected clients in the broadcast domain to send traffic to other broadcast domains.

This is how a SVI is created on HPE Comware 7. It’s similar to other vendors.

[C1]interface Vlan-interface 1
[C1-Vlan-interface1]ip address 10.100.100.1 30
[C1-Vlan-interface1]display this
#
interface Vlan-interface1
 ip address 10.100.100.1 255.255.255.252
#

At least one port is assigned to this VLAN, and as soon as at least one port of this VLAN is online, the SVI is also reachable.

What happens, if you connect two switches with a cable? The broadcast domain spans both switches. Layer 2 traffic is transmitted between the switches. And what would happen if you connect a second cable between the same two switches? As long as you are running Spanning Tree Protocol (STP), or another loop detection mechanism, nothing would happen. But one of the two connection would be blocked. No traffic would be able to pass over this connection. If you want to use multiple, active connections between switches, you have to use Link Aggregation Groups (LAG), or things like Multiple Spanning Tree Protocol (MSTP) and Per VLAN Spanning Tree (PVST).

Routers don’t know this. Multiple connections between the same two routers can’t form a loop. Loops and STP (an some other crappy layer 2 stuff) are legacies of the bridges, still alive in modern switches. Loops are a typical “bridge problem”.

Routed Ports

Some switches offer a way, to change the operation mode of a switch port. After changing this operation mode, a switch port doesn’t act like a bridge port anymore. It’s acting like the port of a router, that only handles layer 3 traffic.

This is again a HPE Comware 7 example. I know that Cisco and Alcatel Lucent Enterprise also offer routed ports.

This is a normal switch port. Please note the “port link-mode bridge”.

[C1]int XGE1/0/49
[C1-Ten-GigabitEthernet1/0/49]display this
#
interface Ten-GigabitEthernet1/0/49
 port link-mode bridge
 combo enable fiber
#

To “convert” a switch into a routed port, simply change the link-mode of the port.

[C1-Ten-GigabitEthernet1/0/49]port link-mode route
[C1-Ten-GigabitEthernet1/0/49]ip address 10.10.10.1 30
[C1-Ten-GigabitEthernet1/0/49]display this
#
interface Ten-GigabitEthernet1/0/49
 port link-mode route
 combo enable fiber
 ip address 10.10.10.1 255.255.255.252
#

As you can see, you can now assign an IP address directly to the port.

Example

Let’s try to make this clear with an example. C1-1 and C1-2 are two HPE Comware based switched, configured as an IRF stack (virtual chassis). These two switches form the core switch C1. S1 and S2 are two access switches, also HPE Comware based. Each access switch has two uplinks: One uplink to C1-1 and another uplink to C1-2, the two chassis that form C1. The 40 GbE Ports between C1-1 and C1-2 are used for IRF. Please ignore them.

The uplinks between the switches, all ports are Gigabit Ethernet (GE) ports, are configured as routed ports.

Without routed ports, the uplinks must be configured as a LAG, or STP would block one of the two uplinks between the core switches and the access switch. But because routed ports are used, no loop is formed. Most layer 2 traffic can’t pass the routed ports (broadcasts, multicasts etc.)

routed_links_1

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

THe Link Layer Discovery Protocol (LLDP) traffic can pass the routed port. This is what the core switch (C1) “sees” over LLDP.

[C1]display lldp neighbor-information list
Chassis ID : * -- -- Nearest nontpmr bridge neighbor
             # -- -- Nearest customer bridge neighbor
             Default -- -- Nearest bridge neighbor
System Name          Local Interface Chassis ID      Port ID
S1                   GE1/0/1         34ce-d3a9-0300  GigabitEthernet1/0/1
S2                   GE1/0/2         34cf-0690-0400  GigabitEthernet1/0/1
S1                   GE2/0/1         34ce-d3a9-0300  GigabitEthernet1/0/2
S2                   GE2/0/2         34cf-0690-0400  GigabitEthernet1/0/2

Each routed port as an IP address assigned. The same applies to the routed ports on the access switches. Each uplink pair (core to access) uses a /30 subnet.

As you can see, the interfaces working in bridge mode start counting at GE1/0/3.

[C1]display interfaces brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP       10.0.0.1
GE1/0/2              UP   UP       10.10.0.1
GE2/0/1              UP   UP       10.1.0.1
GE2/0/2              UP   UP       10.11.0.1
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)    1.1.1.1
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   --       --

Brief information on interface(s) under bridge mode:
Link: ADM - administratively down; Stby - standby
Speed or Duplex: (a)/A - auto; H - half; F - full
Type: A - access; T - trunk; H - hybrid
Interface            Link Speed   Duplex Type PVID Description
FGE1/0/53            UP   40G     F(a)   --   --
FGE1/0/54            UP   40G     F(a)   --   --
FGE2/0/53            UP   40G     F(a)   --   --
FGE2/0/54            UP   40G     F(a)   --   --
GE1/0/3              DOWN auto    A      A    1
....
....

The same applies to STP. The ports, that were configured as routed ports, are not listed in the output. STP is not active on these ports.

[C1]display stp
-------[CIST Global Info][Mode MSTP]-------
 Bridge ID           : 0.34a9-6908-0100
 Bridge times        : Hello 2s MaxAge 20s FwdDelay 15s MaxHops 20
 Root ID/ERPC        : 0.34a9-6908-0100, 0
 RegRoot ID/IRPC     : 0.34a9-6908-0100, 0
 RootPort ID         : 0.0
 BPDU-Protection     : Disabled
 Bridge Config-
 Digest-Snooping     : Disabled
 Root type           : Primary root
 TC or TCN received  : 0
 Time since last TC  : 0 days 0h:27m:23s

----[Port4(GigabitEthernet1/0/3)][DOWN]----
 Port protocol       : Enabled
 Port role           : Disabled Port
 Port ID             : 128.4
 Port cost(Legacy)   : Config=auto, Active=200000
 Desg.bridge/port    : 0.34a9-6908-0100, 128.4
 Port edged          : Config=disabled, Active=disabled
 Point-to-Point      : Config=auto, Active=false
 Transmit limit      : 10 packets/hello-time
 TC-Restriction      : Disabled
 Role-Restriction    : Disabled
 Protection type     : Config=none, Active=none
 MST BPDU format     : Config=auto, Active=802.1s
 Port Config-
 Digest-Snooping     : Disabled
 Rapid transition    : False
 Num of VLANs mapped : 1
 Port times          : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 0s RemHops 20
 BPDU sent           : 0
          TCN: 0, Config: 0, RST: 0, MST: 0
 BPDU received       : 0
          TCN: 0, Config: 0, RST: 0, MST: 0

What are the implications?

The example shows redundant links between access and core switches. There are no loops, but there’s also no layer 2 connectivity. VLANs are only located on the access switches. There are no VLANs spanning multiple switches. What does this mean? How can a client on S1 reach a server on S2? The answer is simple: You have to route the traffic on the access switches. But that’s a topic for another blog post.

Redundancy on the first hop – VRRP

This posting is ~4 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

The Virtual Router Redundancy Protocol (VRRP) was developed in 1998 as an open standard protocol. VRRP is the result of an Internet Engineering Task Force (IETF), and it’s described in RFC 5798 (VRRPv3). VRRP was designed as an open standard protocol, but it uses some patents from Cisco. Its function is comparable to Cisco Hot Standby Router Protocol (HSRP), or to the Common Address Redundancy Protocol (CARP). VRRP solves a very specific problem at the network edge: It offers highly available virtual router interfaces, or in simple words: A highly available default gateway. Its home is the network edge, and because of this, VRRP is a so called first hop redundancy protocol. When moving towards network core, VRRP loses importance. If you move from the network edge to the core, redundancy is primarily offered by dynamic routing protocols and redundant links.

Fun fact: Its home is the network edge, but most edge switches, doesn’t support VRRP…

As already mentioned, VRRP is comparable to HSRP, CARP, Cisco Gateway Load Balancing Protocol (GLBP), or the Extreme Standby Router Protocol (ESRP).

VRRPv3 supports IPv6 and IPv4.

How does it work?

 Pretty easy:

  • at least two routers or switches that support VRRP
  • a virtual IP address
  • a virtual mac address

Okay, maybe it’s not that easy.

Key point is the virtual router. A virtual router is defined on each physical router or switch that should offer high availability for a virtual IP address. A virtual router is defined on a per-vlan base, and it consists of a virtual router identifier (VRID), one or more virtual IP addresses, and a statement that declares a router or switch as a master or backup virtual router.

The virtual mac address is build upon the VRID. The mac address is always 00-00-5E-00-01-xx, in which xx is the VRID in hexadecimal format.

The interface IP address, or switch virtual interface (SVI), that is configured for a specific VLAN, and the virtual IP address of a virtual router configured for the same VLAN, must belong to the same subnet.

Master, Backup, Owner

A router or switch can have one of two roles:

  • master virtual router
  • backup virtual router

You can have one master, but multiple backup virtual router. The master virtual router answers to ARP requests and forwards packets for the virtual IP address. The backup virtual router comes into play, in case of a failure of the master virtual router. If a backup virtual router doesn’t receive packets from the master virtual router (a period longer than three times of the advertisement time), the backup virtual routers assume that the master virtual router is dead. An election process is then initiated, to select a new master virtual router.

Master and backup virtual routers communicate via multicast using the multicast IP address 224.0.0.18.

The virtual IP address must also be a real interface IP address on a router or switch. This router or switch is called IP address owner. The IP address owner has always the priority 255. Because of this. the IP address owner will always become the master virtual router, regardless what the configuration says.

vrrp_owner_master_backup

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

As you can see, R1 has the IP 10.0.0.1/24 and the virtual IP address (VIP) is also 10.0.0.1. In this case, R1 is the master virtual router and the IP address owner.

Some vendors allow a no owner design.

vrrp_no_owner_backup_backup

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

As you can see, R1 and R2 are both configured as backup virtual router, but R1 has a higher priority. In this case, R1 will answer to ARP requests and will forward packets for 10.0.0.254. Another interesting fact: The VIP is a true VIP, and it’s not a real interface IP address of any of the participating routers or switches.

Not all vendors seem to support such a design, and RFC 5798 has no references to it. According to some other vendor docs and RFC 5798, VRRP requires that the master virtual router has the virtual IP address configured as a physical IP address, which means that the master virtual router must also the IP address owner (as mentioned above).

VRRP-E – extended VRRP

Brocade and HPE offer VRRP-E, an extended and proprietary version of VRRP. Extended means, that it overcomes limitations of VRRP (told by Brocade and HPE).

VRRP-E doesn’t know the concept of master and backup virtual routers. All routers are acting as backup virtual routers. A priority value is used to determine, which router will act as master virtual router. Furthermore, VRRP-E doesn’t know the concept of the IP address owner.

Brocade states in one of their docs:

The most important difference is that all VRRP-E routers are Backups. There is no Owner router. VRRP-E overcomes the limitations in standard VRRP by removing the Owner.

VRRP and dynamic routing protcols

If VRRP is used together with dynamic routing protocols, like OSPF, there’s a worth mentioning fact: Not a single dynamic routing protocol like it, if the IP address, which is used to build adjacencies, moves to another router. It’s not the IP address that is the problem, but perhaps the not matching routing protocol configuration, a changed router ID or similar. Because of this, the VRRP VIP must not be used in the configuration for dynamic routing protocols. A no owner design can have some benefits if you have to use VRRP and dynamic routing protocols on the same router or switch. In this case, the real interface IP addresses can be used for the dynamic routing protocol configuration, and not the floating VIP.

Changing DHCP server config on AOS 7

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

The embedded DHCP server on AOS 7 and AOS 8 is a less known feature. But it’s pretty handy in some cases, e.g. if you have no servers on premises, or you don’t want that a a non redundant firewall or router acts as DHCP server. Because you can run two or more switches as a virtual chassis, you can easily make the DHCP server role highly available.

Configuring the DHCP server

The configuration is pretty easy.

-> cd /flash/switch
-> cp dhcpd.conf.template dhcpd.conf
-> vi dhcpd.conf

Edit the dhcpd.conf as necessary. Then start the DHCP server.

-> dhcp-server enable
-> dhcp-server restart

The “enable” enables the DHCP server, but it’s not started. “restart” is used to start or restart the DHCP server.

Change the dhcpd.conf

But how do you change the dhcpd.conf? Sure, simply use VI and edit it. Not quite… After starting the DHCP server, the owner of the dhcpd.conf changes from “admin” to “root”. So with your normal “admin” user, you don’t have the permission to write the file.

In order to change the dhcpd.conf, we need an account with more privileges. In this case, the maintenance shell can help.

Maintenance Shell commands should only be used by Alcatel-Lucent Enterprise personnel or under the direction of Alcatel-Lucent Enterprise.
-> su
Entering maintenance shell. Type 'exit' when you are done.
TOR #-> vi /flash/switch/dhcpd.conf

With higher privileges it’s no problem to edit the dhcpd.conf. Make sure to leave the maintenance shell after the change, and don’t forget to restart the DHCP server.

-> dhcp-server restart

I assume that this behaviour is caused by a bug. I don’t know, if AOS 8 shows the same behaviour. I will update this blog post with further information, as soon as I get them.

Dynamic VLAN assignment with AOS 6

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Manually assigning ports to VLANs can be a time consuming and error prone process. Depending on the size of the network, there is a point where it doesn’t make sense to do this manually. Especially in SMB networks, VLANs are assigned manually, because the effort of automating the VLAN assignment exceeds the effort for manually assigning VLANs. Those environments are often very static. I know many SMB networks where VLAN have not been addressed for a long time. With declining costs for Layer 3 switches, the separation of workloads in VLANs for SMB customers became affordable. Server virtualization was another mainspring for VLANs and inter-VLAN routing. To be honest: I’m talking about SMB customers, not enterprise customers or enterprise-grade SMB customers (latter is my special term for SMB customers with enormous IT budgets…). But the main driver for VLANs was Voice over IP (VoIP). With the increasing proliferation of VoIP, even the smallest SMB customer were forced to use VLANs. But this led to situations, where customers had to change the switch config every time a new client or IP phone was added to the network. Common workarounds:

  • pre-configuring switches, eg. port 1 to 12 for clients and 13 to 24 for IP phones
  • connecting clients behind IP phones and pre-configuring all switch ports (untagged client and tagged VoIP VLAN)

Suitable for small environments, but difficult to handle if environments grow over time. And I’m not a friend of connecting clients behind IP phones… Enterprise, or enterprise-grade SMB customers tend to implement 802.1x to manage access to their network. With 802.1x it’s possible to assign ports to VLANs depending on the user identity. But 802.1x is complex. If you have the the knowhow, the time and the budget, please do 802.1x! But you should take the complexity into account. Today I want to show options, offisde of 802.1x, to dynamically assign ports to VLANs with Alcatel-Lucent Enterprise OmniSwitches.

First of all: We have to differ between AOS 6, AOS 7 and AOS 8. Alcatel-Lucent Enterprise (ALE) currently uses three different software releases, depending on the switch platform.

Switch modelAOS release
OmniSwitch 6250AOS 6
OmniSwitch 6350AOS 6
OmniSwitch 6450AOS 6
OmniSwitch 6850EAOS 6
OmniSwitch 6855AOS 6
OmniSwitch 6860(E)AOS 8
OmniSwitch 6900AOS 7
OmniSwitch 9000(E)AOS 6
OmniSwitch 9900AOS 6
OmniSwitch 10KAOS 7

Depending on the specific AOS release, there are various ways to enable dynamic VLAN assignment. The main reason for the different AOS releases is, that ALE shifts its networking core platform from Windriver VxWorks (AOS 6) to Linux (AOS 7 and AOS 8) (source #1, source #2).

This blog post will focus on

  • OmniSwitch 6250/ 6350/ 6450 running AOS 6.7.1

I plan to publish similar blog posts for

  • OmniSwitch 6900/ 10k running AOS 7.3.4
  • OmniSwitch 6860/ 6860E running AOS 8.2.1

Dynamic VLAN assignment with AOS 6

In general, there are three different ways to dynamically assign ports to VLANs with AOS 6:

  • VLAN mobility
  • User Network Profiles (UNP)
  • LLDP Media Endpoint Detection (LLDP-MED)

Let’s take a look at VLAN mobility. VLAN mobility is used to dynamically assign one or more VLANs to a port, based on traffic characteristics that were received on that port. The following information can be used to classify traffic:

  • 802.1Q VLAN ID tag
  • DHCP MAC address
  • DHCP MAC range
  • DHCP port
  • DHCP generic
  • MAC address
  • MAC address range
  • Network address
  • Protocol
  • Port

You can’t use VLAN mobility on ports that

  • is an 802.1Q tagged port
  • belongs to a Link Aggregation Group (LAG)
  • has Spanning Tree enabled and the BPDU ignore status is disabled
  • is used to mirror traffic

To allow the switch to dynamically assign ports to VLANs, VLAN mobility has to be enabled. By default, all ports are non-mobile ports. A non-mobile port is statically assigned to a specific VLAN.

To enable VLAN mobility for a port:

vlan port mobile 1/1

You can also use a port range.

vlan port mobile 1/1-22 2/1-22

To disable VLAN mobility use the “no” form of the command.

vlan no port mobile 1/1-22 2/1-22

If a device sends ethernet frames with a 802.1Q VLAN ID tag, you can use the VLAN ID tag to dynamically assign a port to a VLAN. With VLAN mobility enabled, you only have to enable the “mobile-tag” option for the desired VLAN.

vlan 199 mobile-tag enable

As soon as the switch receives a frame with a 802.1Q VLAN ID tag for VLAN 199, the port that received this frame is dynamically assigned to VLAN 199. That’s VLAN mobility based on 802.1Q VLAN ID tags. But you can also use VLAN rules. VLAN rules are created per VLAN. You can have one or more rules per VLAN. You can use the

  • Source MAC address
  • Source MAC address ranges
  • Switch ports, or
  • the DHCP request itself

to dynamically assign a port to a VLAN. This rule matches to DHCP requests from a single MAC address.

vlan 199 dhcp mac 68:F7:28:FA:A0:D5

If a DHCP request with the specified MAC address is received, the port is dynamically assigned to VLAN 199. Because managing MAC addresses is not very handy, you can use MAC address ranges:

vlan 199 dhcp mac 68:F7:28:FA:00:00 68:F7:28:FA:FF:FF

To use all DHCP requests on a specific port, use the DHCP port rule:

vlan 199 dhcp port 1/1-22 2/1-22

To use all received DHCP requests, use the DHCP generic rule:

vlan 199 dhcp generic

To remove a rule, use the “no” form of the command.

vlan 199 no dhcp ...

Once the device has received an IP address from the DHCP server, the VLAN port assignment is dropped! Because of this, you can combine DHCP and network address rules. A network address rule dynamically assigns the VLAN depending on the IP subnet.

vlan 199 ip 192.168.20.0 255.255.255.0

This rule assigns VLAN 199 to a port, that receives traffic from a client in the subnet 192.168.20.0/24. If the DHCP server in VLAN 199 assigns IP addresses from this subnet, you can easily combine the DHCP and network address rule.

A MAC address rule assigns the VLAN depending on a single MAC address

vlan 199 mac range 68:F7:28:FA:A0:D5

 or on a range of MAC addresses.

vlan 199 mac range 68:F7:28:FA:00:00 68:F7:28:FA:FF:FF

Less frequently used are port and protocol rules. A port rule doesn’t require incoming traffic to trigger dynamic VLAN assignment. The specified mobile port is immediately assigned to the specified VLAN. Port rules only apply to outgoing broadcast traffic. You still need rules for the incoming traffic. To create a VLAN port rule:

vlan 199 port 1/1

A protocol rule uses the protocol type in an ethernet frame to assign VLANs to ports. Valid values for the port type are:

  • IP Ethernet-II
  • IP SNAP
  • Ethernet II
  • DECNet
  • AppleTalk
  • Ethertype
  • DSAP/SSAP
  • SNAP

A protocol rule is created by issuing

vlan 199 protocol ip-snap

As always, the “no” form of the command removes the rule.

vlan no 199 protocol ip-snap

or

vlan no 199 mac range 68:F7:28:FA:00:00 68:F7:28:FA:FF:FF

User Network Profiles (UNP) is a feature of Access Guardian. Access Guardian refers to security functions, like

  • Authentication and Classification
  • Host Integrity Check (HIC)
  • User Network Profiles (UNP), and
  • Virtual Network Profile (VPN)

UNP are available in AOS 6, AOS 7 and AOS 8. In AOS 6 we need a

  • policy condition
  • policy action
  • policy rule, and a
  • policy list

These four characteristics belong to the QoS feature of AOS. But a UNP needs a policy list, more specific the policy rules that are part of the policy list, to classify traffic and devices. The policy condition is necessary to identifiy a devices on which this policy should match.

policy condition ip_phones source mac 68:F7:28:00:00:00 mask 00:00:00:FF:FF:FF

Beside the MAC address, you can use source and destionation IP addresses, switch ports, source and destination TCP/ UDP ports, VLANs and many more. To use one or more IP addresses, simple use a network group.

policy network group sales 192.168.20.0 mask 255.255.255.0 192.168.30.0 mask 255.255.255.0

The group “sales” consists of two subnets. To remove a subnet, use the “no” form of the command.

policy network group sales no 192.168.20.0 mask 255.255.255.0

The policy action is used to determine, what should happen with the traffic. In this case: Priorize the traffic.

policy action high_prio priority 7 802.1p 7

The rule binds condition and action.

policy rule rule_voip condition ip_phones action high_prio log no default-list

A policy list is used to group one or more policy rules.

policy list qos_list_voip rules rule_voip

A UNP binds a name, a VLAN and a policy list together.

aaa user-network-profile name voip vlan 199 policy-list-name qos_list_voip

A third way to dynamically assign ports to VLANs is LLDP Media Endpoint Detection (LLDP-MED). LLDP Media Endpoint Detection was developed to increase the interoperability of VoIP devices with other devices on the network (eg. PC, switches etc). AOS uses LLDP-MED network policies to advertise information to devices. A network policy contains information about VLAN ID and L2/ L3 priorities. First, we have to enable network policy support, either for a port or for the chassis.

lldp 1/1 tlv med network-policy enable

To enable network policies for the chassis use the keyword “chassis” instead of a port.

lldp chassis tlv med network-policy enable

To create a network policy enter:

lldp network-policy 1 application voice vlan 100 l2-priority 5 dscp 46

The created policy (ID 1) will advertise the VLAN 100, L2 priority 5 and DSCP 46 to voice devices. The next step is to bind the policy to a port or the chassis.

lldp chassis med network-policy 1

Or for a specific port.

lldp 1/1 med network-policy 1

Furthermore, you need to enable VLAN mobility on the ports. If the IP phones sends tagged VLAN frames, you also have to enable the “mobile tag” feature for the VLAN.

vlan 100 mobile-tag enable

The IP phone receives the configuration information over of the network policy. VLAN mobility and “mobile tag” will make sure, that the VoIP phone is pushed to the correct VLAN.

Summary

Manually assigning VLANs can be a time consuming and error prone process. AOS 6 offers

  • VLAN mobility
  • User Network Profiles, and
  • LLDP-MED

to dynamically assign ports to VLANs. Each of the options has its pros and cons. Especially the combination of VLAN mobility and LLDP-MED is really easy to implement. I will publish more blog posts about the same topic, but with AOS 7 and AOS 8.