Start with an abandoned project … DD-WRT-Controller

DD-WRT Controller

Two years ago, while I was still working for my previous company, I took care of the project to set up the company wireless network with a single primary requirement “Centralized Management”. At that time we were using SMB grade router, several LinkSys WRT54 that loaded with the 3rd party firmware DD-WRT, configured under one single SSID to support seamless roaming. These units worked quite well, and required minimum investment (only 40-50 euros per unit) by that time. Although these routers only support 802.11bg thus the bandwidth limits to only 54Mbps but that far more than enough for a company with less than 20 wireless user.About 4-5 routers were in use so the cost is roughly 250 euros only …

However the board demanded a better solution with centralized management,authentication against company Active Directory users, multiple SSID and support VoIP, also capability of providing HotSpot for guest …etc. Practically, DD-WRT can support almost every requirement, except the centralized management function. Each router must be configured individually. Although you can import a template configuration from a single router, but this task still need to be done per router. Also if there is any change (like extra SSID, or simply change SSID name …) every router must be tended to.

Thus in the end we abandoned the WRT54, and ended up with an enterprise solution from ARUBA network, which worked quite well but … horribly expensive. Since I am tied to the NDA after leaving the company, so could not disclose the exact price tag.  Let’s just say a thin access-point costs more than all the Linksys combined :) and we used several of them. That, is still without the WLAN controller.

The solution from ARUBA network is a neat one. One single WLAN controller (could have extra running in cluster for redundancy), that automatically discoveries, configures and pushes change to the client within the same network. It could also connect to the thin access-point  in VPN mode, so you basically can install an access-point at home and access to the company wireless. Config/administration support both WEB and CLI.

BUT IT IS EXPENSIVE !!! All most every WLAN controller from major vendor is. Let’s say if a company only have less than 10 routers and limited number of users, investing in the centralized solution is a no-go and thus leave the network admin with the frustrated task of maintaining 10 individual routers.

During the R & D phase for the project, I also looked up for a similar controller solution for DD-WRT and find none. It seem nobody has attempted to implement such a thing. DD-WRT remains popular with users and now support a wide range of home-routers. So I think it is time for me to start pick this project up and see how it goes. Not a programmer myself but I hope I can improve programming skill after this project …


Debugging LACP PDU …

Just recently we had a trouble with a customer at AMS-IX regarding LACP  (Link Aggregation Control Protocol) which resulted into a extended debugging session so  I think it interesting to write a bit about it …

So we have a 2x10G bundle between our switch and member switch

AMS-IX —- 2x10G LACP —- Member

LACP stand for Link Aggregation Control Protocols, which is a standard to bundle multiple ethernet interfaces together to form a logical link. This logical link is viewed from the ethernet switch as a single entity that administrator can assign logical address, or use as a trunk for multiple VLAN.

In short, LACP bundle is formed by exchange the LACP PDU between the two switches across the ethernet interfaces using multicast address 0180.c200.0002. As soon as two side exchange LACP PDU successfully the link is formed and traffic could be sent over. After that, switches periodically send LACP keep-alive message to confirm partner of link status. Up on not receiving these confirmation package, the link could be torn down.

Although LACP is a standardize protocol, debugging LACP is not a trivial task due to the way each vendor  implement the protocol. But to explorer around with the CLI and see if it has options to view the transmit and receive LACP PDU would help.

Inbound MAC filtering issue – Did you allow the Source MAC address of partner ?

The Destination MAC address for LACP PDU is  a common multicast MAC, but the Source of LACP PDU varies. Some vendor use the virtual-MAC of the bundle as source to send out the PDU, but some use the BIA (Burn-In Address) of individual physical interface as source. With the MAC address filtering scheme of AMS-IX, from time to time I see violation hit from frames that destined for LACP. So if you implement inbound MAC access-list on the interface, you should take care that source MAC address from your LACP partner is allow. In case they change hardware, the ACL should be updated accordingly.

Of course you can omit the ACL, there will be now issue with MAC ACL anymore. But the bundle will be prone to loop.

Number of LACP PDU exchange between partners – Is the number of LACP frames sent out the same with what partner receive on the other side ??

So one of the thing I have seen during the debug, is the number of LACP PDU exchange between our router and the member router. During the normal condition, if both side using the same time-out setting (LACP has long and short time-out) then the number of PDU exchange should be relatively the same. Like if A send B 100 PDU, then B should receive roughly the same amount. If you compare counters from both side and detect discrepancy, we should check why there is a LACP packet drop … The drop could result in the bundle timing-out and flapping on one side, as we have seen during the debug case.

Test one link at a time …

Since LACP could work with only one link, we could always isolate the issue by disable one of the link to check whether it work or not.