OverviewI installed an 8206 in the Sydney Solution Centre (SSC) many years ago. It is getting on a bit now, and is missing some key features like POE+, latest AOSS firmware updates, V3 module support, etc.
This switch is a key component in the SSC, acting as the aggregator for multiple downstream switches (especially ones without any fibre connectivity), and all of those devices with a single network connection that are not connected directly to the core (such as APs, ILOs, test systems, etc).
PlanningWork out what the replacement device (and modules) will be, and make sure it will fit, cables will reach, etc.
In this case, the ProCurve 8206 will be replaced by its direct successor in the model line-up, the ArubaOS-Switch 5406R. It is actually 2 rack-units smaller than the 8206, so I have some blanking panels on hand to fill in the gap. Many of the ports were unused, so a different combination of V3 modules will provide at least the same number of fibre ports, and a smaller number of RJ45 10/100/1000 ports - now with POE+.
PreparationWork through the existing switch config and remove any unneccessary or unused protocols or features, and unnecessary port-specific config. Take the time to validate any advanced features such as ACLs, PBR, AAA, etc. Remove anything that no longer serves a purpose, as a simpler, streamlined configuration will require less work to migrate and less chance of missing something.
Take the time to build a spreadsheet with key elements defined, such as:
Make sure you do the appropriate change controls!
Config AnalysisAnalyse the existing switch config. Some of these commands will be useful:
Elements to check include:
Staging and New ConfigIdeally, you will be able to build the switch online with different IP address(es). This could be temporary or permanent, depending on the enironment. Even just DHCP on the OOBM port makes this easier. (If you do change IP address(es), make sure the appropriate updates are made in systems like ClearPass, Airwave and IMC.)
Build the new config based on the port allocation spreadsheet and configured feature list.
For this migration, much of this config was the same; the operating system was the same (K15.xx vs KB16.xx), and the platforms pretty similar. Examples of the key differences or changes are listed here.
8206 (config) # control-plane-protection enable
5406R (config) # copp traffic-class all limit default
Cloud ManagementThe 5406R could be cloud-managed with Central, but I don't want that, so those functions have been disabled.
activate provision disable
Fault-FinderThis was enabled on the 5406R globally, and on most ports for broadcast-control.
fault-finder all sensitivity high
fault-finder broadcast-storm all action warn percent 10
Note that the broadcast-storm control will need to be disabled on ports being added to a trunk (aggregation) group.
GVRP vs MVRPUnfortunately the MVRP implementation in AOSS is not compatible with GVRP, so I have had to stick with GVRP to support the older downstream switches that only support GVRP.
OpenflowI removed all the Openflow config. The 5406R supports Openflow the same as the 8206, but this is no longer a focus, and the Openflow applications and demos I had are no longer in place.
OOBMThe 5406R has an out-of band management port (OOBM) which provides a completely separate connection point to the switch - just like an ILO port on a server. It is separate, not on the backplane, so there are no issues with loops.
ip address dhcp-bootp
Deployment/CutoverOnce all the planning and preparation has been done, the actual cutover should be pretty straightforward.
The basic process I usually follow is:
Because I was mounting the 5406R 2RU higher, I had to lengthen the power cables, and repatch some of the ethernet cables.
Total off-line time for critical systems (ie firewall + upstream LACP) was approx 35min. Total replacement time was just over 2 hours. And now the new 5406R switch is in and running!
3115 Days ? Nice ! (but not for security...)
@alagoutte: Yeah, I agree with you 100% (now things are differents)...but consider that - from a specific security standpoint - that particular chassis was already out-of-support [*] before it last started to accumulate that uptime...so security was - let me say - the last thing anyone before me really worried about (Hardware failure was the first!) and, luckily, the first thing I did was to decommission it at first opportunity!
[*] Last firmware released on 2010?
The current SSC core is a pair of Comware 5900CP switches stacked with IRF. Two pods feed into that: my networking pod with a pair of AOS-CX 8320s (when they aren't being "borrowed") and an HIT pod with another older Comware pair.
My aim is:
But, like all plans, it could change at the drop of a hat! Luckily in a lab environment, uptime is not the primary consideration.
The migration for the 5900CP IRF to 8320 VSX pair is now posted
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.