Wired

last person joined: an hour ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

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

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

    Posted Sep 15, 2019 09:17 AM

    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 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:

    • 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

     

     



  • 2.  RE: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

    Posted Sep 15, 2019 01:11 PM
    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!


  • 3.  RE: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

    Posted Sep 16, 2019 04:26 AM

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



  • 4.  RE: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

    Posted Sep 16, 2019 08:33 AM

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



  • 5.  RE: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

    Posted Sep 18, 2019 07:55 AM

    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 directly 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.



  • 6.  RE: Howto: Real-world Migration from ProCurve 8206 to ArubaOS-Switch 5406R

    Posted Jan 18, 2020 02:31 AM