If I edit a zoneset on a switch that has other switches in the VSAN and they are connected via an ISL, what exactly happens when I activate the Zoneset? This is on a switch with the default zoneset propagation policy of activeZoneSet?
Also, what happens if I have a VSAN across a number of switches and I want to merge one other switch with the same VSAN number. All VSAN have items in it. Lets say two are already joined via ISLs and I want to add the third switch and eventually a fourth switch and it needs to merge with the existing VSAN to create a larger VSAN? I have to build a VSAN that is spread across three datacentres. All the VSAN items need to communicate.
Hi Stephen I hope sunny Canberra is treating you well!
I have a question for you in regards to q1) Are you performing the change on the principal switch? It wont really matter, but I think its good to iterate best practice when we can.
Basically, the new zoneset will get propagated to the other switches. This can be quite dangerous.
I have seen a few organisations "accidentally" perform zone changes on switch A and then activate the zoneset on switch B which has a super super old zoneset saved on it.
In answer to your second question, do these "new" switches actually have zonesets active on them? If so, it might be worth to configuring the correct zones on the principal switch in the fabric before joining them and de-activate the zoneset on the "new" switch.
It would be slightly labour intensive but it could be scripted pretty simply and it is a nice way of performing an audit on the new switches.
I am confused. I always thought that when I edit a zoneset and then activate it, it automatically distributed to all switches in the VSAN. That is what I wanted to do as I know what I am doing or so I thought. However, I recently took over a new fabric as part of a merger and noticed that the switches in the VSAN had different zonesets when I looked at them in the cli. I then noticed that one switch had a highlighted zoneset in GUI and it was different to the other switches. What could cause that to happen?
Do you imply that editing the zoneset on a non principal switch and then activiting it wont send the config to all switches in that VSAN? What then is the sure fire way of getting the zoneset on all switches? Activate and then distribute?
Canberra is getting chilly.. Work is driving me up the wall.
I think I will just add a clean switch to the VSAN and add the old stuff. It wont take long and it reduces the chance of any muckups.
It does distribute it but does not the zoneset is not saved to the startup-config (at least in older sanos versions i'm not to sure in more recent versions these days!) so if a switch reboots it can activate (depending on switch piority) an old/wrong zoneset.
Depending on the size of the zoneset it would be pretty safe to add them to the running zoneset, activate and then add the new switches cleanly.
Melbourne is still cold and windy also... Plenty of work down here at the moment! :)
Somewhere over the last 4 years, I have missed something very important and I have been relatively lucky to say the least. I have alway set a principal switch and edited the zoneset from the principal. I never really looked at the other switches. I just had a look at some of my VSAN's and noticed that the switches other than my principals had no zoneset information at all. Once I distributed the principal switches zoneset, the other switches had the zoneset information.
This is just so much different to Brocade where you activate the zoneset and all the switches get it no matter what. Brocades concept of a principal switch is basically something that keeps the time and thats about it.
I had a look at the startup on the switches in the VSAN and the principal and the other switches are quite different. The principal has all the VSAN info and the others none. So what happens when the principal changes or an the VSAN gets segmented?
I will be in Melbourne on the June long weekend. My wifes daughter is getting married. Woo hooo..
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...