For those of you not in the Beta program Cambium has broken tradition and widely announced a new RC for ePMP on some of the Facebook forums. For those of you running ePMP, this is a significant upgrade for just an RC. Some highlights for me in the changelogs.
Highlights
Keep in mind 4.4 is a point upgrade. For those of you who don’t know you have Major Versions (ie 4.x), Minor (4.4) and Patches (4.3.2 and hotfixes (4.3.2.1). On top of these numberings, you have different builds Alpha, Beta, Release Candidate (RC), and others depending on the vendor. I expect an RC to have a higher build number by the time it is released to even Beta testers. This means the internal team and their test networks have gone through some pretty solid feedback loops. So on to why 4.4 is an important thing, especially to ePMP users. 4.4 is a minor release with significant improvements.
•QoS ePMP3000 now supports Quality of Service to support traffic prioritization. This is the first phase of QOS implementation supporting traffic prioritization at the individual SM/AP. Future additions will cover features such as station priority.
•ePMP3000 now supports maximum information rate further allowing the operator to manage traffic profiles for end customers.
•This release now supports trial configuration that allows a user to try a configuration change without applying the configuration.
•This release now supports cnMaestro Zero-Touch.
So let’s talk about each of these.
QOS. This is where we can get into some debate. How much QOS should you be doing at the Subscriber module? How much of it should be handed off to an ISP managed router? I am under the philosophy an SM should be doing as little overhead of non-radio things as it can. If you want to do QOS do a very basic QOS set, if at all. If you do not do managed routers, then you almost have to do QOS at the radio. Same goes for the traffic profiles. This is something you must decide for your self. I have my philosophies and gladly share them. What works for me may not fit with your methods.
Trial Configuration. This has been a feature of UBNT that has been super awesome. You can apply your settings and if you lock yourself out you just have to wait until the settings are reverted. I have not tried this yet, but it is an exciting thing.
Zero-Touch. This has been a long time coming. This reinforces the cnMaestro ecosystem this much further. At one point you will have enough automation setup where a new AP that comes online will have all of its settings pushed down to it without you ever having to log in to the device.
Bugs Addressed in 4.4.0-RC23
•FC ACG-5846 [FC] F300-25 could not connect to e2K in first attempt. Cause – INA RETRIES EXHAUSTED
•[F130] enable IPv6
•Downlink Frame Utilization always shows 0%
•Fragmentation improvements
•[MIR] MIR Profile Rules does not work
Known Issues in 4.4.0-RC23
•[FC] SMs are disconnected from AP with Reason: 48 (COMMUNICATION LOST) when traffic is transmitted
•PPPoE MTU size limits should depend from Ethernet MTU
What are some of my tips for getting the most out of your ePMP deployment (or any vendors deployment)?
If you are running 3k don’t run mixed mode in production just yet unless you are prepared to submit tickets and bug reports. Also, 3k users run the latest beta firmware. Signup for the beta and READ the changelogs. One of the things on a recent thread on the Facebook Cambium Users group was some users being vocal about a small number of things fixed. If they read the changelog you would see a lot more was mentioned.
A good rule of thumb is your APs and SMs should be the same firmware version. Not everyone in your whole network has to be the same. You can have one tower or sector on version 4.4.0-RC23 and another sector on 4.3.2.1. The key is each SM attached to an AP should be the same version as the AP. Once you start mixing weird results can happen.
Read the changelogs. In the current changelog for 4.4.0-RC23 I count 47 bug fixes and 14 known issues, some of the highlights I mentioned above. With a point upgrade like this, I would expect some major improvements and lots of them. I always like to mention highlights in my posts like this because it helps those of you who are busy to pick out some significant things which may interest you. There may be some I don’t mention which are essential as well. You should have someone on your team who reads the changelogs. Reading changelogs can save you much heartache, especially when it comes to known issues. One of the things I like about the Cambium changelogs is they mention the tracking number. If you have opened up a case and it is a verified bug you will receive a tracking number. This tracking number allows you to keep the vendor accountable. If you don’t see this in your other vendors, push them to do this. The vendor may already be doing this internally. Most software devs have ways to track their bugs internally. Push them to publish known and fixed issues, with tracking numbers in their changelogs.
Some of the issues in changelogs may never affect you and may be nitpicky things. A good vendor will not “pad” their changelogs with fluff like “changed a spelling error here”. These are fairly insignificant and just add to the reason why some users ignore changelogs.
How has this helped me in the real world? Knowing what was fixed in a changelog allows me to decide if this is a software version which needs to be rolled out. Do the pros outweigh the cons? Is this a bleeding edge platform where I need to be running the latest in order to get the best benefit? You will find the new kid on the block is the one who gets the most development time. The platform needs to reach a certain level of maturity as fast as it can. If you have these in production or are testing then running the latest code is the way to go. As the platform becomes more mature, running the bleeding edge code isn’t as desirable. You reach a point where you can wait longer between software upgrades.
I have always been of the philosophy where my devices are doing as little as they possibly can. What do I mean by this? I have dedicated functions to devices in the network. My Access Points are not doing firewalling, QoS, and other things. If they are it is at a very basic level. I want each device to excel at its function. This leaves more horsepower to do its core function(s). It also lessens bugs and conflicts between software processes. This is where many of the bugs show up. If your device is doing 4 things, then you have times the problem than if it’s doing just one thing. However, this is the real world and you have to stretch your budget as far as you can. Just be aware of adding more functions to a device can cause compatibility issues. Keep It Simple Stupid (KISS). Network design and philosophy play a huge role in how a device behaves.
By combining all of the above you can work out an internal philosophy which allows you to tailor it to your business needs. If you are running the latest hardware platform in production for whatever reason then have it do dedicated functions until the software is mature. This will lessen the impact of bugs. As the product matures you can turn on more functions. Turns the dials and knobs as some would say. If you are just testing it then turn it all on and try and make it break. But submit tickets to the vendor. This may seem like you are doing “their job” but this is part of the investment in the platform.
While this article started out being about Cambium, you can apply the philosophies to any vendor you want to put in your network.