Aerohive BR200-WP 3G/4G Backup Testing

-

This is just a quick note about some interesting things I found out about the Aerohive BR200-WP today when I was having a look at our demo kit for a possible customer solution. 

The BR200-WP is a great little branch router/switch/AP platform. It boasts a single AP radio (5GHz or 2.4GHz, 3x3:3!!!) and has 5 x 1Gbps switched Ethernet ports (one is the WAN uplink). If you throw-in in the fact that its cloud managed and has all of the usual powerful HiveOS features (VPN, firewall, AVC, airtime fairness...etc,. etc.), you've got a great branch-router platform. (Oh yes, I forgot to mention that it has 2 x POE ports too!)

But in addition to the mass of great features outlined above, the BR200-WP has one more trick up its sleeve: 3G/4G backup. The unit has a USB 2.0 port which can be used to attach a 3G/4G dongle to provide WAN backup in the event that the main WAN link should fail. This was the area I was interested in taking a look at in my testing.

You'll have to excuse my ignorance in the area of 3G/4G backup in this article. There are probably a few things in here which may be very obvious to most folks, but I hadn't really come across them before.

I connected my BR200-WP up to an ADSL connection and gave it a basic configuration (via HMOL). This gave me an SSID to attach to and some basic Internet connectivity via a test wireless client. I configured the interfaces to (hopefully) provide a resilient WAN link.

My first action (like most engineers) was to insert my existing 3G dongle in to the USB port of the BR200WP and see 'what would happen'. Unfortunately, not too much did happen. I got the standard WAN (ADSL) connection up and working, but when I failed it, the 3G backup didn't kick in - back to the drawing board (well, time to read the manual actually).

After checking the datasheet, I realised that not all 3G dongles are created equal. Only certain models of dongle are supported for use with the BR200-WP. Apparently, different dongles use different command sets, which makes universal support tricky. So, I got on to Amazon and bought myself an unliocked Huawei E220 3G dongle. There are a range of 3G and 4G dongles that are supported by the BR200-WP, but I'll leave you to check them out on the datasheet (as the range of supported dongles will no doubt extend over time).

Once I had my supported (E220) dongle, I switched my SIM card across to in to the E220 to try the 3G backup again. (Quick note: I didn't know you could switch SIMs around like this to put them in to a supported card. Prior to being told this, I spent a lonnnnnnng time looking at cell phone web sites trying to get a supported dongle-type to buy a new one - very embarrassing in retrospect) 

Unfortunately, I still didn't have any success when I failed the main WAN link and had to do a little more digging. Again, my ignorance of 3G backup shone through, and after a little Googling it became apparent that I had to configure the correct dial-up parameters in the BR200-WP for my 3G dongle provider. In my case, as I use Vodafone here in the UK, my parameters are:
  • APN: internet
  • Dialup number: ATD*99#
  • User ID: web
  • Password: web
These parameters will vary from provider to provider. If they aren't 100% correct, things won't work. I found a great site with the correct  strings for many 3G/4G providers and their various data plans here in the UK, which you may find useful if you are going through a similar exercise:

http://www.mobilez.org/support/apns/uk/

Now that I had the correct type of dongle and the correct dial strings etc., I was ready to roll! I'm pleased to report that things actually worked pretty smoothly once I had this all figured out. I fired up my test wireless client and connected to the Internet via my usual DSL connection. Then, I failed the DSL connection and after a few seconds, the 3G link kicked-in and I carried on working.

I took a screen shot of the AP configuration so that you can see how I had it all configured to provide the 3G WAN backup. I've highlighted the important areas with red boxes:



Just to run through the 5 highlighted areas:
  • WLAN interface: not really related to 3G backup at all (sorry), but still very interesting. I found out that the way you switch between 2.4GHz and 5GHz is by changing the radio profile - that isn't immediately obvious (I never even realised you could switch to 5GHz until I read the data sheet!)
  • Eth0 - Set this interface to a priority of primary (this is the default) - this will ensure that the WAN link connected via this port is used for all traffic during normal (non-failure) operation
  • USB - Set the priority to Backup1 (this is the default) - this will ensure that this interface is used when the main WAN link (Eth0) fails
  • Wireless USB Modem Settings - Connect As Needed: this will ensure that the 3G link only comes up when the WAN links fails, rather than being permanently dialled up.
  • USB Modem - ensure that the various 3G modem strings are entered as per your 3G provider requirements
One area that I struggled with was getting the 3G dialler parameters (APN, User ID etc.) correct. This was quite difficult and time-consuming to resolve by the usual method of making a change via HMOL and then pushing the change out. So, I improvised slightly and connected my console cable to the BR200-WP. I made a few small config changes to the BR200-WP configuration via the CLI to test the effect of various changes in real-time. I used the following CLI commands:

usbmodem modem-id huawei_e220 apn internet
usbmodem modem-id huawei_e220 dialup-number ATD*99#
usbmodem modem-id huawei_e220 dialup-password web
usbmodem modem-id huawei_e220 dialup-username web

Once I'd got them right via the CLI, I configured them on HMOL and pushed out the final, correct config. Making CLI changes isn't really generally recommended, but in this case, it saved me a lot of time!

One other area I became very familiar with when trying to get this going is the debugging available from the CLI of the AP. If you're trying to set this up and are having difficulties, it's well worth enabling some debugging to see what's going on. I used the following command (which gives you more information than you really need):

debug console all

This gave a log on my terminal screen of everything going on, but allowed me to see the BR200-WP attempting to dial up the 3G connection when the WAN link failed. Here is a partial dump of the log showing a successful fail-over to the 3G connection, which may be useful (I've changed a few IP addresses etc. for security reasons):

2013-05-21 16:49:42 info    registering with PM for pid=2576 name=[mod_name_pppd_mod_id_64] cmdline=[/sbin/pppd noaccomp nopcomp novj nobsdcomp noipdefault noauth defaultroute replacedefaultroute usepeerdns lock crtscts persist ah-pppousb linkname usb_modem0 ipparam 115200 /dev/ttyUSB0 user web password web connect  USE_DIALUP_NUM=ATD*99# USE_APN=internet /sbin/chat -t5 -v -E -f /etc/chatscripts/3g.chat]
2013-05-21 16:49:42 notice  pppd[2576]: pppd 2.4.3 started by root, uid 0
2013-05-21 16:49:43 info    chat[2583]: abort on (BUSY)
2013-05-21 16:49:43 info    chat[2583]: abort on (NO CARRIER)
2013-05-21 16:49:43 info    chat[2583]: abort on (ERROR)
2013-05-21 16:49:43 info    chat[2583]: report (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 5 seconds
2013-05-21 16:49:43 info    chat[2583]: send (AT&F^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: AT&F^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATE1^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATE1^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (AT+CGDCONT=1,"IP","internet"^M)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 10 seconds
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: AT+CGDCONT=1,"IP","internet"^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATD*99#^M)
2013-05-21 16:49:43 info    chat[2583]: expect (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATD*99#^M^M
2013-05-21 16:49:43 info    chat[2583]: CONNECT
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send ( ^M)
2013-05-21 16:49:43 info    pppd[2576]: Serial connection established.
2013-05-21 16:49:43 warn    mDNSResponder: interface change, mdnsd refresh interface list and service!!!
2013-05-21 16:49:43 info    kernel: [systop]: initializing AH dev for ifp ppp0!
2013-05-21 16:49:43 info    kernel: [mpi]: drop unsupported event 0x5 from ppp0
2013-05-21 16:49:43 info    pppd[2576]: Using interface ppp0
2013-05-21 16:49:43 notice  pppd[2576]: Connect: ppp0 <--> /dev/ttyUSB0
2013-05-21 16:49:44 info    pppd[2576]: CHAP authentication succeeded
2013-05-21 16:49:44 notice  pppd[2576]: CHAP authentication succeeded
2013-05-21 16:49:44 warn    pppd[2576]: kernel does not support PPP filtering
2013-05-21 16:49:47 warn    pppd[2576]: Could not determine remote IP address: defaulting to 10.x.x.x
2013-05-21 16:49:47 info    amrp2: receive kevent KEVT_IF_CHG type IF_UP from ppp0 index 20
2013-05-21 16:49:47 warn    ah_dcd: Interface ppp0 is up.
2013-05-21 16:49:47 info    ah_dcd: access interface ppp0 is up now
2013-05-21 16:49:47 info    capwap: CAPWAP receive kevent KEVT_IF_CHG, eventid = 16, size = 36
2013-05-21 16:49:47 info    kernel: [mpi]: drop unsupported event 0xd from ppp0
2013-05-21 16:49:47 info    kernel: [mpi]: ppp0 notify kevent KEVT_IF_CHG, type IF_UP(1)
2013-05-21 16:49:47 info    capwap: receive event vpn report responce capwap: eventid = 103: length = 30
2013-05-21 16:49:47 info    capwap: CAPWAP: receive vpn report responce capwap event!, length:30
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4135), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters 0.0.0.0, ifname
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4136), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters 0.0.0.0, ifname
2013-05-21 16:49:47 debug   ah_brd: WANFO: Added event BACKUP_WAN_CONNECTED
2013-05-21 16:49:47 debug   ah_brd: WANFO WANFO SM Engine: @ state:NOWAN + event:BACKUP_WAN_CONNECTED [0x3]

So, there you have it, a quick look at setting up the 3G backup on the BR200-WP. 

It's worth bearing in the mind the limitations of 3G connectivity as a backup medium. You're realistically limited to downstream connectivity speeds of around 2 to 4 Mbps, depending on your signal strength, with upload speeds being just a few hundred kbps. It's not going to provide you lightning connectivity, but it will keep you going. It will be fascinating to see how a 4G connection performs, potentially providing several tens of mbps in each direction (providing you can get the coverage!). The possibilities for the BR200-WP certainly increase significantly if a good cellular WAN speed can be achieved.

References:

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more