With more than 18 billion devices in use and 4.2 billion more to be shipping in 2022, the sheer size of existing Wi-Fi deployments worldwide is just mind-boggling. In view of the new Wi-Fi 6E and 6GHz adoption push, it is critical to evaluate what are the best ways to do a migration from existing Cisco on-prem legacy networks into the new world of 6GHz deployments.
For Cisco Enterprise customers, there are several aspects that need to be evaluated for any successful migration planning:
- Existing controller type:
- is it AireOS?
- Model? (Basically, can it run 8.5 or 8.10?)
- is it IRCM capable (2504/wism2 can’t do mobility to 9800)
- Access point Inventory:
- Are there any 802.11n models still in use? (per example, 2600, 3600, 1520, 1600, etc)
- Are there any Wave1 APs? (last generation of IOS, per example 1700, 2700, 3700)
- Mesh deployments?
- PoE support:
- What is the maximum supported power standard? (802.3bt, 802.3at, etc)
- Any power budged constraints per port?
- Or APs are powered by power injectors?
- Current 5GHz TX power
- Is my network running on average at power level 3-4?
- or it is around 1-2?
6GHz adoption is only supported in the Catalyst 9800 IOS-XE controllers, running 17.7 or higher. This imposes some additional considerations either on controller type migration, or about legacy access points that may need to either be migrated, or supported through Inter Release Controller Mobility (IRCM) solutions
Legacy Access Points
 |
| Figure 1. Legacy APs |
If a network that for any reason is still running devices 2 generations away (for example, a 2602 AP), and now needs to include new 802.11ax models (for example 9130) or jump to the 9136/9166/9164 for 6GHz support, this will need more complex migration paths.
When there are multiple generation gaps, if the legacy controllers can support IRCM to the IOS-XE 9800, it is perfectly possible to design a migration plan, without the need to do a “forklift” installation. This will ensure very little pain to users, and keep the network running until everything is migrated to the new hardware and standards
In the following table, we can see a summary of software support ranges and migration options for most access points models from 11n generation models:
| Model/Series | Last AireOS Support | IOS-XE support | IOS-XE AP equivalent | Migration Notes |
| 700/700W Series | 8.10 | Not supported | 9105 | Migration through IRCM |
| 1040 | 8.3 | Not supported | 9115 | AP needs to be replaced |
| 1260 | 8.3 | Not supported | 9115 | AP needs to be replaced |
| 1600 | 8.3 | Not supported | 9115 | Either 8.5 IRCM, or Hardware replaced |
| 1700 | 8.10 | 17.3 | 9115 | Migration through IRCM |
| 2700 | 8.10 | 17.3 | 9120 | Migration through IRCM |
| 3700 | 8.10 | 17.3 | 9130 | Migration through IRCM |
| 1810/1810W | 8.10 | Up to 17.3 | 9105 | Hardware replaced or IRCM between IOS-XE versions |
| 1830/1840/1850 | 8.10 | Supported | 9105 | Directly supported |
| AP802/AP802H | 8.5 | Not Supported | ISR10xx | Migration through IRCM |
| 2600 | 8.5 | Not Supported | 1920 | Migration through IRCM |
| 2800/3800/4800 | 8.10 | Supported | Directly supported | |
| 1540 | 8.10 | Supported | Directly supported | |
| 1550 | 8.5 | Not supported | Migration through IRCM | |
| 1560 | 8.10 | Supported | Directly supported | |
| 1570 | 8.10 | Up to 17.3 | Migration through IRCM |
For a complete list, you can check the Cisco Wireless Solutions Software Compatibility Matrix, alternatively, you can run the Wireless Config Analyzer Express, to check your migration readiness
Figure 2. AP Migration Decision Flow
Legacy Controllers
 |
| Figure 3. Legacy Controller |
Depending on the existing controller type, the migration may take different paths. Some scenarios will be simple, allowing a smooth transition. Others may need additional steps to successfully migrate into a Wi-Fi 6E network
What to expect:
◉ “Generation 1” controllers: 5508, 8510. They can support up to 8.5 AireOS version, which will allow mobility scenarios between them and new IOS-XE 9800 controllers (Inter-release Controller Mobility, IRCM support). Also, they will support both IOS and AP-COS access points, from 1700 to 3800 models (Wave1, Wave2 802.11ac )
◉ “Generation 2” controllers: 5520, 8540, 3504 . All of these can support up to 8.10 AireOS, also allowing IRCM scenarios with 9800. AP support will additionally include 802.11ax models, like the new Catalyst 9105, 9120, and 9130. etc.
◉ “Generation 1” controllers without IRCM: 2504, WiSM2, vWLC, 7510. No mobility is possible between them and IOS-XE, so additional steps with different migration scenarios are needed
Figure 4. Controller Migration Decision Flow
Migration Scenarios
In general, we should try to migrate “per RF blocks”, defining it as a roaming area or domain where clients can move normally between access points, before hitting idle timeout. Basically, move these RF blocks completely, into the new APs, and IOS-XE controllers. For example, either move a building or a complete floor into the new hardware and software. We should avoid “salt & pepper” deployments, mixing APs on different controllers at the same time. Not because it is not supported, but because mobility will be more complex, and it may lead to issues sooner or later (just a problem prevention action)
For scenarios where it is impossible to break the RF environment into differentiated blocks (for example a very large building like an airport, or a fully open space office), we will have to either set up artificial boundaries based on roaming frequency and usage or do a forklift upgrade
Figure 5. Example of RF area/building migration
What happens if the AP model is not supported in any IRCM version?
This could be the scenario of a legacy controller, still working in 8.3, with some AP models that are not supported beyond that version. For example, the scenario of 20 APs of 2700 Series, and 10 APs of 1042 Series.
The 1040s are not supported in 8.5. In this case, the preferred option is to prioritize the replacement of those APs first, moving the impacted area into 9800 as the first step. Sometimes, customers have mixed models across a given building. For example, the mix of 2700 and 2600. In those scenarios, the best option is to consolidate models per supported version, moving all APs of a given type together, so they are contained in a specific RF space in order to facilitate migration in blocks
Scenario 1: Legacy Controller supports IRCM
This will be the most common scenario, where we have either 8.5 (5508/8510) or 8.10 (5520/3504/8540) AireOS controller. The migration picture will start with the creation of IRCM setup between AireOS and 9800 controllers, then either replace APs in RF areas connecting them to the new controller, allowing mobility to act when a client needs to roam between legacy and new RF areas.
This method allows the smooth coexistence of both controllers, with RF areas migrated as needed, without any overnight switchover.
Things to keep in mind:
◉ If the controller is limited to 8.5 (5508, 8510), we will need a special IRCM version (8.5.182.104), to connect them to IOS-XE
◉ In general, it is best to split the RF network into different areas, configuring different RF group names between the legacy and IOS-XE controllers. This way each group can do the best calculations that their respective version allows. We should make sure that “Avoid Foreign AP Interference” is enabled on RRM/DCA configuration (it is by default)
◉ Always configure the primary/secondary controller name in access points. The new controllers will reject unsupported APs, but if any AP could work in both controller types, this will avoid APs joining the wrong one, or flip-flopping between them, until the migration is ready to proceed
Scenario 2: Legacy Controller not supporting IRCM
If the legacy network is running on a controller model WiSM2, 2504, 7510, vWLC, it is not possible to establish an IRCM connection between the old controller to the new 9800 handling the 6E APs. This limits significantly the options that are available, and it forces a more aggressive migration process
Migration alternatives:
◉ Keep the two networks separated, and migrate physical RF areas as new APs are added, replacing the old ones. No roaming is possible, and it is very important to keep client VLANs different between controllers, to avoid ARP proxy issues between both controllers. During this process, we must take care on preventing roaming events as client identity, address, etc, will be lost on the change between controller types. For example, the ideal scenario is to move a complete building from one controller to the new one, doing a forklift AP replacement overnight.
◉ Avoid migrations “per floor”, as in most building types, it is normal to see clients roaming between APs on different floors
◉ Temporarily, replace the legacy controller with one that supports IRCM
Scenario 3: AP is supported up to 17.3 but not in later versions
This will happen when “Wave1” APs are still present, for example, 1700/2700/3700 AP models. For this type of migration, it is possible to move all APs into IOS-XE, with the 17.3 release, then add a secondary wlc to host the new Wi-Fi 6E APs, using 17.9, and establish an IRCM link between both controllers.
On this option, it is possible to do a graceful AP replacement from Wave1, into Wi-Fi 6E models, always trying to do the technology migration, per physical roaming RF area as described (per building, floor, etc). Once all APs are migrated, the 17.3 controllers can be decommissioned
In some instances, the customer may deploy a 9800-CL in 17.3 as a temporary controller to host the legacy APs
6GHz RF Coverage vs 5GHz. AP replacement scenarios
One common discussion point is: How different is going to be the cell coverage, in 6GHz, when compared to a 5GHz AP?
People will want to take a 5GHz AP and do a 1:1 replacement with a 6GHz supported AP, this may seem reasonable, but there are some aspects to consider:
◉ As WiFi-6E uses a higher frequency, the propagation characteristics are different, the signal drops slightly faster in 6 than in 5GHz. The difference should be around 2 dBm on measurements over the same distance. Material absorption will be different as well.
◉ 6GHz has different regulatory power constraints than 5GHz. Currently, most deployments will be using Low Power APs (for simplicity sake’s, let’s say 24dBm in FCC, 23 dBm in ETSI). This means that depending on the current network AP radio’s power levels, using 6GHz may result in a slightly lower power output
Rule of thumb:
◉ If your power level average is around 3-4, it is possible to do a 1:1 AP replacement, and have a similar coverage level in 5 and 6 GHz
◉ If the power level is in 1-2, then you may need around 10 to 20% additional access points
The easiest way to know the average power level per site is to use WCAE tool and check the “Channel Stats 5GHz” tab. This will present a summary per channel, either at controller, or site tag level, of the average power levels (among other information). For example, this is a network where migration to 6GHz may need additional access points:
Figure 6. Example of site with low 5GHz coverage
Versus this other one, where the deployment is running on low power, so fitting without issues into 6GHz requirements:
Figure 7. Example of site with good 5GHz coverage
If you use the latest version (0.9.11) of WCAE, you can also get a “6GHz predictive” view of how the power distribution, Nearby relationships, and RSSI for clients would look, if you replaced your current APs with 6GHz capable hardware. The tool will match ETSI or FCC regulatory requirements, adapting powers and differences as needed. This is useful to get a taste of how the network would look, doing a direct migration, without adding any APs.
Figure 8. 6GHz Predictive RRM modeling
For complex or demanding deployment scenarios, the recommendation will always be: do a site survey
Source: cisco.com
Posts
0 comments:
Post a Comment