02-08-2017 03:25 PM
Need to remove very old switch from fabric, which unfortunatelly is a principal switch.
As far as I am concerned, Fabric Build process, invoked by forcing voting for a new switch by using fabricprincipal, may cause (or will it cause for sure?) interruption to IO within fabric (not sure about that).
What would've happened if I was to simply disable switch I want to remove?
Would it be a dirty trick and not something that one would advise?
Would fabric automagically invoke new voting process anyway and move on with new switch selection with less disruption to IO?
Solved! Go to Solution.
02-09-2017 12:05 AM
First, a build fabric (BF) is not disruptive in itself to IO in the fabric. People have often seen BF, which where caused by - for
example - a principal ISL went down: The principal ISL going would of course cause any frames on ISL to be lost and cause
disturbance to impacted hosts. But a BF in itself is not disruptive - but the root cause for the BF might very well cause
I would select the new principal switch - centrally in the fabric, high FOS level (if different), and larger / powerful (more CPU).
And then make it the new principal switch using the fabricprincipal command and force a fabric build (BF) with
switch:admin> fabricprincipal -f 1
Principal Selection Mode enabled (Forcing fabric rebuild)
And once the new fabric principal is selected, then you can remove the old switch. The fabric principal CLI will not cause
More information is in the attached white paper (old but valid) - you can start from the section "The Fabric Reconfiguration Myth" on page 14
02-09-2017 08:04 AM - edited 02-20-2017 08:33 AM
Just used it with both my fabrics without any issues.
fabricshow was not showing up anything for couple of seconds afterwards (almost got heart attack!) but it got back with no issues.
Principal function followed to a switch of my choice. Perfect.
Thanks for reassurance once again