I say definitely to Summit. A very peculiar device, that amazed me instantly.

It is one of the products of Extreme Networks, don’t know how big of a company, but I got to love their solution. Even one of the smallest and lowest performance solution they have (Summit48si)  distinguished by its loads of features, performance, ease of configuration and, above all, STABILITY, something I haven’t found at the mighty Cisco solution that everybody loves.

A while back I needed to do something very specific: I wanted to separate traffic coming from two networks on trunks. My device should have reunited all this traffic and forward it to a different machine that would NAT it forward on to my servers. Each done by any device easily. But – what I wanted more was at the authentication level. I wanted to do 802.1x authentication on trunks and forward the authenticated traffic to a secondary device that would do EAPoverUDP for some of the traffic and WebAuth for the rest of the traffic, all based on the ACLs configured on a separate Radius (ACS) server. Now, I won’t get into details about the EoU, WebAuth, nor ACS configuration, but rather describe what I have managed to do with Summit.

First of all, unlike other devices, this one allows the premises of my topology: it lets me configure 802.1x on a trunk port – which I wasn’t able to obtain from Cisco after long hours of pain and swearing. So, traffic is coming from my supplicants, on 3 ports of this Summit device, let’s say 1,2 and 3. Ports 1 and 2 carry only 802.1x authenticated traffic, while port 3 is a combination of 802.1x, EoU and WebAuth. So, I have defined 4 vlans: 1,2,3 and 4. As part of my traffic is only authenticated with 802.1x, I left the first 2 ports authenticated in 802.1x on vlan 1, and assigned the next port (3) on all of the other 3 vlans: 2,3 and 4. This is this the access portion of the topology.

The second part, I have to switch all this traffic through another device, that deals with EoU and WebAuth, so I have defined 5 “exit” ports: 1 for the 802.1x authenticated traffic that wouldn’t need any other authentication (this traffic I trust to be secure only as part of the Summit authentication), 2 ports for the mixed-authentication traffic (this traffic I have authenticated via 802.1x in Summit, and I trust it), and 2 more ports for the traffic I want to further re-authenticate: 1 for the mixed traffic that has 802.1x and EoU and that I intend to authenticate via EoU and 1 port for the mixed 802.1x and WebAuth traffic that I intend to authenticate via WebAuth further on. The scenario would look something like this:

—where:

-’vlan 1′ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via EoU here

- ‘vlan 2′ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via WebAuth here

Some of the traffic is only authenticated via EoU and WebAuth, so I have to let it pass through Summit without asking it for credentials.

From these 2 vlans, the traffic passes back into the internal network where the servers reside – this is of no further interest in this case. Still, I had to create 2 vlans, because of the default gateways that I need to assigned to my supplicants. One would be the layer 3 address of vlan 1 and the second would be the layer 3 address of vlan 2.

The cool part of this entire topology is how to fragment the traffic in Summit, in order to make sure that each type of authentication takes place where it is supposed to.

Of course, the ports belonging to vlans 1 and 2 are “access mode” untagged ports. Ports from 11 to 15 on the Summit device are also untagged ports, while ports 1 and 2 are untagged in a specific 802.1x vlan (let’s say 111), ports 3, 4 and 5 are double-tagged on a separate vlan (as they have mixed traffic that is to be authenticated on EoU and WebAuth separately further on, let’s say 117 for traffic that is to be forwarded to EoU authentication ports and 118 for traffic that is to be forwarded to WebAuth authentication ports) and untagged on vlan 113 – also an 802.1x enabled access vlan (as they also carry 802.1x information). Now, all this funky division is necessary for the netlogin information (as Summit calls the 802.1x authentication).

And the actual config looks like this:

# Network Login Configuration

enable netlogin port 1 vlan v111

enable netlogin port 2 vlan v111

enable netlogin port 3 vlan v113

enable netlogin port 4 vlan v113

enable netlogin port 5 vlan v113

configure netlogin base-url “network-access.net”

configure netlogin redirect-page “http://www.extremenetworks.com”

disable netlogin Session-Refresh  3

enable netlogin logout-privilege

disable netlogin web-based

enable netlogin dot1x

The show netlogin command shows, at any moment, the status of the port (per un/tagged vlan), looking something like this:

> sh netlogin ports 1 vlan v111

Port: 1 Vlan: v111

Port State:     Not Authenticated

Temp IP:        Unknown

DHCP:           Not Enabled

MAC                IP address      Auth   Type      ReAuth-Timer User

——————————————————————

When in non-authenticated state. When actually authenticating a supplicant, the command displays the MAC address, IP (if the case), auth type and name of the user.

And, to actually be able to _authenticate_ users, I have to define  a Radius server where to connect:

# Radius configuration

#

enable radius

configure radius primary shared-secret encrypted “ABC”

configure radius timeout 30

configure radius primary server 1.2.3.4 1645 client-ip 1.2.3.5

configure radius primary server 1.2.3.5 timeout 30

disable radius-accounting

The “1.2.3.5″ IP is the Summit IP address, that I have assigned on a separate vlan. Of course, ACS should have defined this IP as a client with a password of “ABC” – encrypted form and profiles for my users.

But about ACS in the next episode

Tags: 802.1x, ACS, authentication, EoU, Summit Extreme, techie, WebAuth