Wired Intelligent Edge (Campus Switching and Routing)

Reply
Highlighted
Aruba Employee

Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

Overview
I 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).

8206 before migration.jpg

 

Planning
Work 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+.

 

Preparation
Work through the existion 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 servers 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:

  • old port --> new port
  • cable details (they are all labelled, right?!)
  • VLANs
  • port types: fibre, copper, 10Gb, etc
  • special or critical systems (like our SM fibre connection to the outside world)

8206to5406R spreadsheet port mapping.png

 

Make sure you do the appropriate change controls!

 

Config Analysis
Analyse the existing switch config. Some of these commands will be useful:

  • show run
  • show lldp info remote
  • show ip route
  • show vlan
  • show mac-address
  • show arp
  • show span

Elements to check include:

  • Physical (space, mounting, power, cable connections and reach)
  • L1 (connection types, special connections including low or high-speed, transceivers, etc)
  • L2 (VLANs, multicast)
  • L3 (routing)
  • Security (ACLs, AAA, remote access, etc)

Staging and New Config
Ideally, 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.

 

Control Plane

8206 (config) # control-plane-protection enable

5406R (config) # copp traffic-class all limit default

Cloud Management
The 5406R could be cloud-managed with Central, but I don't want that, so those functions have been disabled.

aruba-central disable
activate provision disable

Fault-Finder
This 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 MVRP
Unfortunately 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.

 

Openflow
I 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.

 

OOBM
The 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.

oobm
   ip address dhcp-bootp
   exit

Site Prep

  1. Tools at hand (lifter, screwdrivers, cage-nut tool, etc)
  2. Caps for cables and optics
  3. Hook-and-loop/velcro straps
  4. Extra cables
  5. Disconnect and remove any cables that are listed in the spreadsheet
  6. Get the new switch ready (IP addresses changed if required, saved and backed-up config, powered off and ready to mount)

Deployment/Cutover
Once all the planning and preparation has been done, the actual cutover should be pretty straightforward.

The basic process I usually follow is:

 

  1. Power off and unpatch old switch
    8206to5406R unpatched.jpg

     

  2. Remove old switch (taking all the modules out first makes it lighter and easier to manage single-handed)8206to5406R lifter.jpg
  3. Mount new switch

    8206to5406R new switch mouting.jpg

     

  4. Power on and repatch critical ports (eg OOBM, uplink LACP)

    8206to5406R critical connections.jpg

     

  5. Test system connectivity
  6. Patch remaining ports
  7. Testing

 

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!

8206to5406R installed.jpg

 

 



Richard Litchfield, HPE Aruba
Consulting System Engineer
Network Ambassador
MVP Expert

Re: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

Well done! out of curiosity...what is the SSC Core? I did something similar but I was dismissing a glorious HP ProCurve Routing Switch 9308m with an uptime of (only!) 3115 days...I was forced to follow another approach (since it was acting as the core and providing little or no downtime was a critical business requirement I had the opportunity of not just replacing but first pairing with a 5412R zl2 before dismissing)...and fragment the downtime to downstream devices before the Core switch-over...indeed was much more a switchover than a substitution...anyway I was able to do the (routing) switchover with a total loss of 1 ping only...not bad. That's the pretty part of our jobs...doing also something physical!
MVP Expert

Re: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

3115 Days ? Nice ! (but not for security...)




PowerArubaSW: Powershell Module to use Aruba Switch API for Vlan, VlanPorts, LACP, LLDP... More info


PowerArubaCP: Powershell Module to use ClearPass API (create NAD, Guest...) More info


PowerArubaCX: Powershell Module to use ArubaCX API (get interface/vlan/ports info)


PowerArubaIAP: Powershell Module to use Aruba Instant AP




ACMP 6.4 / ACMX #107 / ACCP 6.5
MVP Expert

Re: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

@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? 

Aruba Employee

Re: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

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:

  1. replace the Comware 5900CPs with the AOS-CX 8320s
  2. swap the old Comware pair with the now available 5900CPs for the HIT pod
  3. the 8400 will be the connection into the networking pod
  4. the Composable Fabric (aka Plexxi) switches will be a new pod dicrectly connected to the 8320s

But, like all plans, it could change at the drop of a hat! Luckily in a lab environment, uptime is not the primary consideration.



Richard Litchfield, HPE Aruba
Consulting System Engineer
Network Ambassador
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: