Wednesday, August 8, 2012

Unifying Wired and Wireless Edge with Aruba Tunneled Nodes

Anyone familiar with modern lightweight access points (APs) knows and understands the basics: Client connects to AP, AP tunnels traffic back to controller, and administrators can specify all sorts of useful policies in the controller.  Aruba Networks has taken this concept of the wireless edge and extended it to the wired edge of the network with their Tunneled Nodes and Mobility Access Switches. The company I work for has very old closet switches and, since we're pretty heavily invested in Aruba wireless, I'm intrigued by the concept of unifying wired and wireless edges.

With a sample switch acquired from my account team, I spent a couple hours with my SE getting the basic introduction to Aruba's Ethernet switches.  The goal of the session was to get the switch set up as a "wired AP" connected to a local controller, and when a laptop would connect to a particular port, the switch would then build a GRE tunnel to the local controller where the laptop's traffic would get dumped out onto the specified VLAN.  Unfortunately, we weren't able to complete the setup, so my SE and I agreed to engage the TAC for further assistance. 

My experience with the TAC was less than stellar this time around, but I believe it was mostly due to how new this technology is and that many TAC engineers haven't had time to learn it inside and out yet.  Eventually I was able to reach an engineer that could identify a fix, and it turned out to be fairly simple. In addition, a high-level support supervisor called me personally to apologize and really listened to my recommendations for how to improve service.

Before the big reveal, here are the technical details of the setup.

We used a test laptop connected to port 2 of the Aruba switch, which was uplinked to a Cisco switch at my desk via an access-port on vlan 221.  That Cisco switch was connected through a trunked 802.1q LAN to the local controller. See the diagram for a topology overview.

When we first set things up, the tunneled-node (a.k.a. the laptop in this case) showed a state of “in-progress” (see output of “show tunneled-node state” command) and would never get to the “complete” state.

In problem state:
(ArubaS3500) #show tunneled-node state

Tunneled Node State
IP           MAC               Port    state       vlan tunnel inactive-time
--           ---               ----    -----       ---- ------ ------------- 00:1a:1e:10:fb:c0 GE0/0/1 in-progress 0221 4094   0000

Here are the most important parts of the configurations of the switch and controller below.

   controller-ip vlan 221

vlan "221"

interface-profile switching-profile "vlan221"
   access-vlan 221

interface-profile tunneled-node-profile "tunnel-local-controller"

interface gigabitethernet "0/0/1"
   switching-profile "vlan221"

interface gigabitethernet "0/0/2"
   tunneled-node-profile "tunnel-local-controller"
   switching-profile "vlan221"

interface vlan "221"
   ip address netmask

Local Controller:
vlan 220 "Backbone"
vlan 221 wired aaa-profile "s3500aaa"

interface vlan 220
        ip address


aaa profile "s3500aaa"
   initial-role "authenticated"

aaa authentication wired
   profile "s3500aaa"

The core problem ended up being the “tunneled-node-address” command on the controller.  We had set it as the IP address of the controller itself, but the TAC identified this as the problem and changed it to all-zeros, like this:


Finally, the tunneled-node came up in the “complete” state (see output below) and I was able to get a DHCP address on the laptop and connect to the rest of the network.

When problem was fixed:
(ArubaS3500) #show tunneled-node state

Tunneled Node State
IP           MAC               Port    state    vlan tunnel inactive-time
--           ---               ----    -----    ---- ------ ------------- 00:1a:1e:10:fb:c0 GE0/0/2 complete 0221 4094   0000

Hit me up on Twitter (@swackhap) or leave your feedback below.

No comments:

Post a Comment