by Patrick Swackhammer (swackhap)
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. 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 ------------ ----------------- ------- ----------- ---- ------ ------------- 10.20.20.125 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.
Switch:
ip-profile default-gateway 10.22.16.1 controller-ip vlan 221 vlan "221" interface-profile switching-profile "vlan221" access-vlan 221 interface-profile tunneled-node-profile "tunnel-local-controller" controller-ip 10.20.20.125 backup-controller-ip 10.20.20.123 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 10.22.17.200 netmask 255.255.240.0
Local Controller:
vlan 220 "Backbone" vlan 221 wired aaa-profile "s3500aaa" interface vlan 220 ip address 10.20.20.125 255.255.255.0 tunneled-node-address 10.20.20.125 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:
tunneled-node-address 0.0.0.0
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 ------------ ----------------- ------- -------- ---- ------ ------------- 10.20.20.125 00:1a:1e:10:fb:c0 GE0/0/2 complete 0221 4094 0000
Many thanks to Jeanie Kedia (@genieki) for the opportunity to share my experience with you. Check out my blog at http://swacknet.blogspot.com and hit me up on Twitter (@swackhap).
