Motorola Wireless Networks Based on WING5 Architecture

In connection with the appearance of a decent number of articles on Cisco, Aruba, Ubiquiti and even Juniper, I decided to add an article on Motorola, with which I work very closely. Ideally, there will be a series of articles - from an overview of the architecture, to the configuration and features. Let's see how to take off. In this part we will conduct a general overview of the architecture.

WiNG5 ( Wi reless N ext G eneration) is the fifth generation of Motorola wireless networks. The latest stable version is 5.4.4, but the description is based on beta 5.5, which is due out in the fall. Version 5.5 greatly expands the possibilities from the architectural side. In addition, I was able to touch her at work - although not without glitches, but the declared chips are present and generally work.

Compared to the fourth version, the architecture has been radically changed, including the software base, the configuration model, and the user interface - this is, in fact, a new software product. Understandably, there was a lot of pain from users and integrators who had to relearn. What led a rather conservative corporate vendor to take such a radical step?

')

And why is it needed?

The main difference of WiNG5 from previous generations is the departure from strict controller dependency towards distributed networks. This is caused by several obvious factors:

• Wi-Fi networks are getting faster and faster . With 802.11n / ac, it is not reasonable to pump all traffic through the controller in a slightly larger network, and the cost of upgrading the wired segment to deliver all this traffic to the controller will also be quite considerable. For the sake of interest, count the total bandwidth of, say, hundreds of 802.11n-450 dots with two radios. WiNG5 allows you to very flexibly choose where to send traffic: switch / route directly at a point, send to the controller, send to another point (more on that later). Thus, the controller is no longer a bottleneck, and the network can easily grow and develop.
• Networks are getting bigger, incl. including remote sites. If earlier the idea of ​​“a separate site = a separate controller” was quite acceptable (since there were 5-10 sites), now there are hundreds of sites. I don’t want to manage them separately or with the help of an additional “hinged” control system. WING5 allows you to manage a bunch of controllers, points and sites (up to 10,000 devices, up to 4,000 sites) from a single controller console with the same ease with which one single site is managed. Also, there is a rather flexible mechanism of aliases and inheritance, which allows not to produce entities in the config file unnecessarily, we will also consider it below.
• Remote sites should work normally without communication with the central controller. The past-generation architectures allowed the points to work without a controller, but at the same time the single Network fell into many separate points — no coordinated control over the coverage, tracking of roaming, transfer of firewall sessions, etc. In WING5, remote sites continue to operate as complete networks, even if communication with the center is lost. Plus, a lot of attention is paid to optimizing the WAN bandwidth.
• Nevertheless, small implementations still have a place to be , so the architecture should work at a small level (and grow with the network without having to throw everything out and replace it with a completely different platform). WING5 allows you to start from one point and grow to thousands of sites with controllers without the need to drastically retrain: the same product, CLI, UI, control model, you just need to train a couple of new commands.

All this led to the need to release a radically new product. Other Tier1 vendors (Cisco, Aruba) for about a year tried to somehow adapt their controller-specific architectures to the new requirements (Aruba Instant, Cisco FlexConnect - renamed and slightly doped H-REAP). But in the end, Aruba did announce the transition to the new MOVE architecture, and Cisco, in addition to the software upgrade, made the hardware (plus, bought Meraki, so now Cisco has 5 different WLAN platforms).
So, whether you like it or not, but to work with modern 802.11n and 802.11ac networks you will have to learn the hardware again - these are the modern realities.

To work under WiNG5, Motorola has released a decent amount of new products - points and controllers, some old models are supported. Since the focus of this article is architecture, not iron, the following is a very brief description of controllers and points for a general understanding. But if there is interest, I will write a separate article with tables and pictures, as well as a description of the features (model coding, unlocked radio modules, lifetime warranty, RadioShare, marketing experts' tricks, etc.).

Controllers:

• RFS series: RFS4000 / 6000/7000 - WLAN controllers with a bias in network services. In addition to supporting up to 144/256/1024 points, respectively, perform the functions of L3 switching, routing (NAT, OSPF) and other network services (IpSec, L2TP, RADIUS, WIPS, etc). Some models support PoE, SFP, etc.
• NX Series: NX45xx / 65xx / 9150 - WLAN controllers with slopes in application services. In addition to supporting up to 144/264/10240 (this is not a typo!) Points, it also supports advanced application services (analytics, content caching, IP-PBX, etc.) and virtualization based on Xen hypervisor (details below). The NX45 / 65 is available with an integrated LAN switch with PoE (NX4524 / 6524) or without it (NX4500 / 6500). The functions of the RFS line are also present, but the power / scalability is a bit lower. NX45 / 65 are positioned as “all-in-one” boxes for a small or medium office, and NX9510 - as an extra powerful central controller for a huge distributed network (worth accordingly :)).

Access points

There are a great number of access points available - they are divided into several lines, modifications with external or internal antennas are almost always available, many variations on performance (internal / external / special), radio module performance, controller dependency (Independent / Dependent) - you can always choose something suitable.

• Low-end: AP6511 / AP6521 / AP621 - the most simple and cheap platform, one 2x2: 2 MIMO radio, minimal scalability, some features are not available. AP621 - Dependent-modification AP6521 (details about Dependent below). AP6511 is a special performance, I wrote about it earlier .
• Mid-range: AP6522 / AP622 / AP6562 - Mention, two radio modules 2x2: 2, but without restrictions inherent in low-end points. In fact, the same point in different versions: AP6521 - Independent, AP622 - Dependent, AP6562 - outdoor execution.
• Upper mid: AP650 / 6532. Slightly more productive version due to radio 2x3: 2. They are mainly used where there is a benefit from 2x3 MIMO (working with low-power mobile devices, etc.) - sometimes it turns out that it is possible to provide the same coverage using 30-40% fewer points. For everything else, there is a series 622/6522
• High-end: AP7131 / 7161/7181, AP8132 - top models with 2 or 3 radio modules (WIPS sensor, 3G modem), 7xxx series - 3x3: 2, 81xx series - 3x3: 3 (450Mbps). AP7161 and AP7181 are designed for outdoor use, while the AP7181 is a real monster with a special antenna design, with a range of up to 25 km and the ability to power IP cameras from itself and so on. In general, equipment to cover entire areas of the city.
• 802.11ac: AP82xx series. So far, only announced, not yet seen live. One high-end point, and two mid-level promises.

And how does it all work?

For the first acquaintance, let's consider the options for architecture / implementations that are available with WiNG5.5, at the same time explaining in general terms how and when the above mentioned goodies and usefulness are achieved. The picture below shows the growth and evolution of the network on WING5.

1. One site: separate points.

No fiction - sketched points, they work, each on its own, do not communicate with each other (you can make it to communicate, but there is a better option). The meaning of this solution is only when the points are exactly one thing - for the rest there is the next item.

2. One site: a virtual controller.

One of the points is assigned to the “ Virtual Controller (VC)” and controls the rest of the points.

• You can control the entire pad from one console,
• you do not need to adjust the points separately,
• the points communicate with each other, providing features such as coverage management (RRM, in Motorola terminology “SMART RF”), seamless roaming with Stateful firewall session transfers, etc.

Limitations:

• up to 24 points
• only one platform (you can put on 24, but the system will think that all points on one platform)
• all points must be of the same model
• Some highly advanced features like traffic tunneling, Role-Based Firewall (RBAC), etc. are not available.

So, it is quite possible to build a grid with a RADIUS backend looking in Active Directory, hotspot and Mesh into the bargain - this is for a small implementation.

3. One site: full controller

If there are more than 24 points or you want advanced features, you need a full-fledged controller. Somehow classic controller circuit, but with a number of significant improvements. The controller does not work the same way as in the networks of the previous generation: points can send traffic to the controller (if it’s more convenient, for example, in a warehouse with 50 data collection terminals working with Telnet) or can switch / route the traffic themselves (if it’s faster, say, for VoIP). Moreover, this choice is rather flexible - separately for each VLAN, WLAN, and some types of service traffic. For example, AAA traffic can be proxied through the controller (so as not to configure a bunch of RADIUS clients on the server), and send the data packets directly to the network.

Thus, the controller acts as a Feature Server and management system. In addition, the above-mentioned features of the type of coating control will continue to work without a controller - one of the devices on the site, which is assigned the role of RF Domain Manager (RFDM), is responsible for their work . Usually, if there is a controller on the site, it will be RFDM, but if there is no controller (or it dies and there is no cluster), the RFDM position will be appointed by one of the access points. At the same time (from version 5.5), point-RFDM can coordinate the work of up to 128 devices (including itself). There is an exception - the points of the lower price category support up to 24 devices (not enough power).

Another interesting feature of architectures with a controller is the ability to tunnel traffic between each other (TD controller or TD-TD) using the proprietary service protocol MiNT. This avoids messing around with wiring trunks on wired switches and setting them up when adding new WLANs, which significantly saves time and nerves. MiNT allows you to set up tunnels on Layer 2 and Layer 3 and tunnel L2 traffic (wired and wireless) as you please.

Also, the use of the controller allows you to save on points: instead of the “full-fledged” model, you can buy a “lightweight” (Dependent in Motorola terminology). They cost significantly (~ -30%) cheaper than full-fledged ones, they have all the same functions, but they refuse to work without a controller (there is a certain interval, a few minutes, after which the points arrange a strike). Accordingly, a number of functions required only in autonomous scenarios (RADIUS server, virtual controller, etc.) at these points are disabled as unnecessary.

4-6. Several sites: without a local controller or with it

If there is not enough one site, you can have several. It is not necessary (but possible) to put on each of them on the controller - everything can be controlled from the center.

Points on each remote site find a controller (local or remote), find each other, choose RFDM and happily live together. Since RFDM is located on the local site, all operational functions are fully operational, and the controller essentially plays the role of a monitoring and control system. At the same time, the control process is pretty cool: the connection with the remote controller (via MiNT) supports only RFDM, the other points proxy requests through it. In such a situation, inside the MiNT, the two-level routing a la IS-IS automatically rises. Again, if RFDM is dead, another one is dynamically selected and everything continues to work.

A bunch of WAN mechanisms are supported: IPSec, NAT (with failover), L2TPv3, L2NAT, PPPoE, VRRPv2 / v3, and even OSPFv2 and PBR (Policy-Based Routing), but usually all traffic is tunneling through MiNT protected by VPN tunnel (rises semi-automatically - you need to register with your hands PSK or certificate).
This architecture is scaled to 128 points on a remote site without the need to purchase and install a local controller, and the points do not have to be the same model (but these should be full points, if necessary, so that they continue to work after, say, uplink failure).

If there is a controller (or cluster) at the remote site - no problem. It also connects to the central controller in the same way, receives the central control unit from it and starts to steer the site. At the same time, on the center console everything is displayed in a beautiful two-level model. Of the nice touches - site controllers (Site Controller in Motorola terminology) can “occupy” licenses for points at the central controller, if there are not enough of their own. These licenses are held for a long time and are going through rebuses, so you can generally put them on the central controller only.
If you wish (and quite simply), you can make it so that at a remote site the points and the controller are enough to be taken out of the boxes and plugged into the network. Similarly, if something went ALL completely wrong - the controller / points on the remote site are simply reset to the default settings and everything is automatically re-configured.

Plus, there are a lot of smart chips to automate the connection of points, minimize the WAN channel load during normal operational activities and, say, update the firmware or distribute custom web pages for the host server - let's talk about it separately (some other time).

Other models and features

Remote sites do not have to be remote - if I have a hefty campus with 15 buildings with 129 points in each - you can create “virtual” sites (RF Domain in Motorola terminology) and charge to manage the entire central controller. It is made by one daw.

Cloud Controller. Fashionable theme today. If you do not use MiNT tunneling on the controller (you can still use between TDs), you do not need to buy controller hardware. Instead, you can use the controller as a VM (XEN) or as a PaaS service from Motorola.

Mesh. Motorola has two Mesh-technologies: traditional, like most vendors, and its own proprietary - MeshConnex (MCX) - after which you don’t want to use traditional. MCX supports two-level routing, several mechanisms for fault tolerance and load balancing and scales to hundreds of nodes in the network (I was told about 1400, but I did not see :)).

Virtuals / application services. Motorola has a line of NX45xx / 65xx / 95xx controllers that can host virtual machines. The main applications are hosting additional services from Motorola (AirDefense Service Platform, Secure Access Server, a bunch of voice servers), or an all-in-one option for a remote site. Nothing hinders any BDC on a Windows Server or Linux with a transparent caching web proxy based on Squid (although the latter seems to have already been screwed into 5.5 directly) on the NX65xx.


Thus, starting from one point, you can grow to a virtual controller, then adding a “real” controller to the network, simply reconfigure the points to work with it, then you can grow to ~ 4000 sites from 10,000 points and controllers on them (total) working, in principle, with the same product, the same CLI / GUI and the same principles of configuration and deployment. This is one of the unique Motorola chips, because other vendors usually offer a complex of different products that need to be studied and integrated with each other. In Motorola, firmware points and controllers are assembled from the same source code (certain features are turned on / off and scalability limits are set), so in fact you always work with the same product and interface. Nowadays, ADSP integrates into the WiNG at a brisk pace - many functions are directly accessible. But I suspect that at least until next year we will still see sticking “ends” here and there :)

And how to set it up?

From the point of view of configuration, WING5 looks quite interesting, but at first glance it is difficult - a lot of options and it is not clear where to start. There is a Wizard that, for all its simplicity, allows you to configure trunks on the controller / point, routing with NAT, and wireless networks with external RADIUS support.

Considering the scalability and flexibility of the solution, the configuration model is not so difficult - there are only five types of elements and a multilayer scheme for combining them with inheritance and redefinition - it is very similar to the PLO. However, starting to write a description and configuration example, I realized that this is another 5-8 pages of text with illustrations. Therefore, this time let's restrict ourselves to screenshots of the GUI and Wizard (under the cat), and in the next article we will discuss the configuration model in detail and configure a small network with the controller, PSK and external RADIUS. Separately, I want to devote an article to setting up a WLAN, since the number of options and interesting features just goes off scale.

In general, I must say that the solution from Motorola, although not without flaws (which we will discuss in the course of setting up), looks very much against the background of other competitors. It does not have a huge number of features for all occasions like Aruba, it does not have strong documentation and powerful iron support like Cisco, lack of wired switches managed from the same controller as Aruba / Meraki / Aerohive. But on the other hand, it is much easier to configure (which I have yet to prove :)) and it scales well without requiring a total replacement of all the iron - in terms of flexibility and friendliness to the admin and Cisco and Aruba, Motorola is still far away (although my favorite here is Aerohive, but they have not yet reached Tier1). It can be said that the “80/20” rule applies to Motorola in the phrase “ Set up 80% of Cisco / Aruba features with 20% of Cisco / Aruba hemorrhoids ”, not counting the unique features that are unique to Moto.

Thanks for attention.

PS And how much does it cost?

In the comments asked a sacramental question, which I, fascinated by technical details, forgot to highlight. :)

The answer very much depends on the task and the level of equipment (in general, I do not understand how some people manage to declare “We are on average XX% cheaper” - this is the average temperature in the hospital).

Access points, in principle, are not very different in price from other vendors, since and Cisco and Aruba have set up a low-end release, with the Aruba AP-68 out of competition at all (if that’s your point) :) But, usually, money is made not on points, but on controllers and licenses. Here Motorola stands out very well: controllers are very inexpensive, and licensing is quite simple - there is a license for the number of points (as usual, wholesale is cheaper) and two licenses for add. chips (bought on the controller, regardless of the number of points). Everything else is already included in the firmware.

Accordingly, everything depends on the requirements of the customer. For example, Cisco has not so many features in the controller, and often you need to buy additional hardware / software. Then, if you put certain favorable conditions, Cisco may be two, three, and five times more expensive. And if the customer already has a full Cisco fleet, it may turn out to be the opposite :) Similarly with Aruba, which has more complicated licensing (especially, let's say, a license for N PoE ports ...). If you stupidly need a grid with PSK, then the difference will be less noticeable. Also, it is useful to take into account the cost of support contracts - Motorola has a rather advantageous Service From The Start offer, with a good discount (if you take the service right away).

If one of the readers dares to formulate a sane TZ and calculate the specification for Cisco / Aruba - I will try to give an analogue to Motorola. And then - Google helped find the prices, but I can not guarantee their relevance and correctness. Draw your own conclusions.

Aruba:
www.kernelsoftware.com/products/catalog/aruba.html
www.peppm.org/Products/aruba/price.pdf

Cisco:
www.kernelsoftware.com/products/catalog/cisco.html
www.peppm.org/Products/cisco/price.pdf

Motorola:
www.kernelsoftware.com/products/catalog/motorola.html
www.peppm.org/Products/Motorola/price.pdf