A little bit of everything.

Yes, a bit of everything, that’s what it has been lately. First, I’m upgrading my home lab switches with more recent IOS versions. The 3560 on my desk can now run EIGRP for IPv6. My 2970 gigabit switch will follow tomorrow, with a K9 IOS this time to make it accessible via SSH.

Second is that I’ve been fine tuning my knowledge of layer 2 security features, using my 3560 desk switch and a 3750 test switch as subjects. RA Guard works great, and so does DHCP Snooping. DHCP Snooping has revealed a third functionality to me, next to countering rogue DHCP servers and preventing DHCP flooding: it also detects when a MAC address that sends an INFORM cannot be present on that port according to the mac address-table. It will generate a ‘%DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL’ message and drop the frame. Seems to be a functionality related to ARP Inspection.
And ARP Inspection, on the other hand, requires some planning of your DHCP servers: if multiple are present and they all reply at the same time, the DHCP Snooping feature, on which ARP Inspection relies, sometimes picks the wrong packet to add to it’s binding table. The client device selects another packet of the ones it received to configure itself, and thus ARP Inspection thinks there’s spoofing going on. I’m still figuring out how to effectively counter that.

Third is that I’ve ordered the CCIE Routing and Switching Certification Guide, 4th Edition hardcover, so I have a lot of reading to be done soon. I have to admit that I don’t like to read ebooks on a big screen so far, and I’m reluctant to buy a reader.
Yesterday I also tried a MPLS lab for the first time, with BGP-MP in GNS3. It did take me several hours but I managed to get it running. Not bad for never having done anything MPLS related before. Still, it’s a huge topic and I’ll need to learn a lot more about that.

And last, I tested an Aruba Remote Access Point (RAP). I’ve already tested Instant Access Points. The RAP works different: once booted, it needs an internet connection. When connecting a computer (it has LAN interfaces, just like a consumer-grade router), it redirects to a setup page, where you have to enter the public IP address of a Wireless LAN Controller (WLC). It then tries to negotiate a tunnel through NAT-T over UDP port 4500 to that WLC. It works by encapsulating IPsec in a UDP header, bypassing any NAT devices that are incapable of keeping the NAT state of IPsec.
The RAP tries to authenticate itself at the WLC using his MAC address. After whitelisting it and configuring a wireless profile (which contains the list of SSIDs to send out), I had to reboot the RAP. I ended up rebooting it several times, thinking it didn’t work, but eventually it turned out my cable had broken due to all the times I plugged it in and out again. The RAP booted fine and started sending out the correct SSIDs. Initially, the wireless connection didn’t hand out an IP to me, but after five minutes, everything suddenly got an IP and started working as if there had never been a problem. Not sure why this happened, although I suspect my NAT router of dropping some of the UDP packets (which wouldn’t be the first time).

A little bit of everything indeed.

Advertisement

Testing two Aruba IAP.

The title may sound familiar. This time, I was able to test two Aruba Instant Access Points. Both come with a virtual controller, and when they are plugged in on the same network, the fun begins. But first, a rough sketch of my lab lay-out:

The two Aruba’s are connected on different switches, 15 meters apart. Connected to the same switch as the first is a Linksys 802.11b/g AP running DD-WRT, connected to the other switch is a Motorola Docsis 3.0 802.11n. But once all devices are plugged in, I only see three wireless networks, not four: the Aruba’s detect each other and automatically use the same settings. That’s right: everything is the same: SSIDs, encryption,…

How did this happen? Well, the Aruba’s send out probing frames on the local subnet, which search for other Aruba devices. Since these are layer 2 frames without IP address, it’s somewhat similar to CDP or LLDP. Once an IAP sees such a probe frames of another IAP, ARP information is requested for layer 3 communication, and the Aruba’s start communication with UDP port 8211 (both source and destination) over IP. They use the PAPI protocol, or Aruba AP control protocol. Settings are transferred from one AP to the other. Since one was configured before and the other one was not, the unconfigured one inherited the settings of the other. I’m not sure what other parameters are used to decide which settings are valid and which not.

Since both Aruba’s are now connected, I can log in to the management page on instant.arubanetworks.com, which takes me to the ‘master’ IAP. It shows the same information as before: how many clients are connected, which networks are giving interference,… Only, this time, it show the connected clients per IAP, and interference is also shown per IAP, allowing for some geographical tracking of the clients and access points:

Compared to the lay-out, the stronger signal indicates the access point is closer. The Linksys is detected on both Aruba’s, the Motorola is just out of reach of one, and has a weaker signal in general.

Because of the copied settings, layer 2 roaming is flawless. The only time frame errors start to occur is when closer than 1 meter from an IAP, which is normal because too close causes echo in the frame transmissions.

Well, nothing really new this time to learn, but some really interesting things about wireless, and the closest I can get to a WLC (Wireless LAN Controller) in my home lab.

Testing an Aruba IAP.

Once again, I was presented the opportunity to test out a device my work borrowed me. This time: an Aruba IAP 105.

It’s an Instant Access Point, which comes with a built-in virtual controller. Aruba usually makes Lightweight Access Points (LAPs) which need a central WLC or Wireless LAN Controller to function. Since this one contains the controller function inside the device, I can go experimenting. Yes, it’s like a consumer-grade access point now, with a web GUI to configure it, but compared to the average consumer-grade AP, this one comes with more functionality.

First the standards: it supports 802.11a/b/g/n, with n in both 2.4 Ghz and 5 Ghz frequencies. It also supports 802.3af PoE, or an external power supply, and has support for 802.1q trunking. So as far as compatibility goes, this device supports it all.

After applying PoE to it, it boots up. Since it’s an IEEE compliant power device, and I have a Cisco ILP powered IP Phone on the same switch, this gives a nice comparison:

This shows the IAP as a Class 3 power device, and the IP Phone as Cisco proprietary. The IP Phone gets a slight advantage here as it can tell by CDP how much it needs, thus drawing less power budget. I did not detect any CDP or LLDP support for the Aruba IAP by the way.

Back to the IAP: after booting up and receiving an IP through DHCP, it sends out a default network. After connecting to it, I’m automatically redirected to the login page (Windows 7 even shows an event message ‘Please open your browser’). After entering the default login and password I’m asked in which country I am, likely to comply with local radio regulations.

The main page in the web GUI show some graphs, indicating signal strength, throughput, and number of users connected. Clicking around, I discover noise levels, transmission errors, even individual reports for each client device, as well as a mobility trail, to check the roaming patterns between multiple access points. As I only have one, there’s no useful information there.

The noise levels do indicate a problem:

Reason: there are several other access points nearby, one of which is on the same channel 6 as the Aruba. After setting the channel static to 11 (it was automatically searching first), the problem did go away.

Apart from that, there’s also an IDS tab that showed more details about other access points in the area: how far away they are, channel, 802.11 mode, connected clients,… Strangely enough, my own AP is the only one marked as ‘rogue’. Since it’s also the only AP to be in the physically same network as the Aruba, I assume it has some mechanism of finding out unauthorized APs. Maybe it has found the AP’s MAC address in the same VLAN?

As far as configuring SSIDs goes, it have plenty of options too: multiple VLANs are supported, each with it’s own security features. There’s support for WPA, WPA2, WPA2 through RADIUS, MAC filtering, also optionally through RADIUS, 802.1x WEP, and open network. There’s also the option to do a redirect to a login webpage, either hosted on the IAP itself or on an external web server. Network access can be done either through NAT on the IAP, direct access to the uplink (access port) or VLAN tagged to a trunk link. The last one is very useful and what it’s usually all about: by mapping different SSIDs to different VLANs, and connecting the Aruba IAP with a trunk link, one can give access to different subnets through one AP. The authentication (usually by RADIUS) then checks whether access to a certain VLAN is allowed or not. On top of that, it’s possible to set up a per-SSID access list to deny access to certain resources or networks from the IAP.

I did ran into a few unexpected problems. First was that my 802.11n capable laptop could not pick up any 5 Ghz signal, only 802.11n on 2.4 Ghz worked. Second was setting up the trunk link, which didn’t work at first until I realized I was acting too quickly and ‘spanning-tree portfast’ is not the same as ‘spanning-tree portfast trunk’, making the trunk link go through STP states.

And in case you were wondering: yes, the signal strenght of the device is great. I had no stability issues, connecting went fast and reliable.