Unsolved
This post is more than 5 years old
157 Posts
0
12104
Zone conflict when re-ISL'ing 2 switches together
I've looked at similar discussions on this but just don't see the answer as to what the issue is. Originally I had 2 seperate DS300's and zoning them as seperate fabrics, no problem, with ECC. Then, in order to replace them with DS5100's as cores, I added a DS5100 to each fabric and they merged fine. After making sure both switches had the same zonesets, I migrated all hosts/storage from the 300s to the 5100s, and subsequently blocked the ports on the DS300s so they could be moved to different racks, etc. This all happened about 2 months ago. ECC was quite pissy about the missing switches, so I removed them from the SMI-S provider and rediscovered only the DS5100s, thus cleaning up ECC anyways. Several zone changes later and I'm now trying to link those DS300's back into the DS5100s. Sounds so simple I bet the monkey could do it but as soon as I connect them the switches log "zone conflict" and fabricshow only shows one switch in each fabric. They simply won't merge back. No domain IDs were changed, only the zonesets would have ever gotten changed.
Domain ID for sw1 is #97, sw2 is #1
The only thing I see is the DS300 (the one I am adding back in to a working fabric) has the lower WWN than the DS5100. I've played around with the fabricprincipal, but it seems to make no diff.
Anyone have any clues as to how to force these things to link back up into their previously happy state?
thanks!
Dave
downhill2
157 Posts
0
June 7th, 2011 14:00
well, not exactly, but it has all the NTP, SNMP, all the PITA stuff I really don't want to have to wipe it. I thought of that, but hey, this should be easy right?
I also tried pushing the same exact zoneset to the DS300 and then tried ISLing them, they wont merge (even though the sets are now identical on both).
Running 6.3.1b code on both.
thanks
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
June 7th, 2011 14:00
was DS300 in use somewhere else ? Could you just wipe it clean and then re-connect to 5100.
downhill2
157 Posts
0
June 7th, 2011 15:00
The effective zones are the same and I can’t make sense of the logs (which one specifically)?
Effective configuration:
cfg: CCWSAN01
zone: appbms004_12e8_1556_SPab1
10:00:00:00:c9:84:12:e8
50:06:01:69:39:a0:1f:5c
50:06:01:61:39:a0:1f:5c
zone: esx101dev_b6aa_1556_SPab1
50:06:01:61:39:a0:1f:5c
50:06:01:69:39:a0:1f:5c
10:00:00:00:c9:6e:b6:aa
zone: esx102dev_b69d_1556_SPab1
50:06:01:69:39:a0:1f:5c
10:00:00:00:c9:6e:b6:9d
50:06:01:61:39:a0:1f:5c
zone: vir203dev_4fcd_1556_SPab1
10:00:00:00:c9:5a:4f:cd
50:06:01:61:39:a0:1f:5c
50:06:01:69:39:a0:1f:5c
zone: vir204dev_135c_1556_SPab1
10:00:00:00:c9:89:13:5c
50:06:01:61:39:a0:1f:5c
50:06:01:69:39:a0:1f:5c
CCWSAN03:admin>
Effective configuration:
cfg: CCWSAN01
zone: appbms004_12e8_1556_SPab1
10:00:00:00:c9:84:12:e8
50:06:01:61:39:a0:1f:5c
50:06:01:69:39:a0:1f:5c
zone: esx101dev_b6aa_1556_SPab1
10:00:00:00:c9:6e:b6:aa
50:06:01:69:39:a0:1f:5c
50:06:01:61:39:a0:1f:5c
zone: esx102dev_b69d_1556_SPab1
10:00:00:00:c9:6e:b6:9d
50:06:01:69:39:a0:1f:5c
50:06:01:61:39:a0:1f:5c
zone: vir203dev_4fcd_1556_SPab1
10:00:00:00:c9:5a:4f:cd
50:06:01:61:39:a0:1f:5c
50:06:01:69:39:a0:1f:5c
zone: vir204dev_135c_1556_SPab1
10:00:00:00:c9:89:13:5c
50:06:01:61:39:a0:1f:5c
50:06:01:69:39:a0:1f:5c
CCWSAN01:FID128:admin>
It does not make sense.
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
0
June 7th, 2011 15:00
did you look in the logs, i think it should tell you what's causing the conflict. Can you export both zoneset into a file and compare the two (using something like WinMerge)
tonydcdi-ymiT1
70 Posts
1
June 7th, 2011 17:00
Instead of wiping the switch clean, have you tried just disabling the current config on the switch you are trying to add? i believe - cfgdisable "CCWSAN01" and then cfgclear. This will get rid of the zoning and then try to isl the switches back. Again do this on the switch you are trying to add and NOT the current running switch
downhill2
157 Posts
0
June 7th, 2011 18:00
Yes. I did that multiple times, and finally tried the configdefault but that did not help either.
tonydcdi-ymiT1
70 Posts
0
June 7th, 2011 19:00
As minute as it may sound the following zones:
zone: esx101dev_b6aa_1556_SPab1
10:00:00:00:c9:6e:b6:aa
50:06:01:69:39:a0:1f:5c
50:06:01:61:39:a0:1f:5c
zone: esx102dev_b69d_1556_SPab1
10:00:00:00:c9:6e:b6:9d
50:06:01:69:39:a0:1f:5c
50:06:01:61:39:a0:1f:5c
dont have the same order of membership. Meaning that the zones have members added in the wrong spot. According to brocade they need be 100% identicle:
----
Identical zone configuration is the most critical one, you need to edit both effective zone and make sure that each entry or object on each merging zone config are the same. They need to be identical, line by line object by object in the same order. Each zone need to have the same content in the same order.
----
try that...
Richard_Butler
84 Posts
1
June 8th, 2011 04:00
Hi,
It might also be worthwhile checking the default zoning behavior of each switch. It looks like for the 5100 you are using logical FID 128. So,
setcontext 128
defzone --show
Then see if the settings are the same for the switch that you are trying to join.
Best regards.
downhill2
157 Posts
0
June 8th, 2011 05:00
Dude, thanks for the advice but I need some real help. These are different because they are 2 different zones.
downhill2
157 Posts
0
June 8th, 2011 05:00
Hi Richard,
I don’t totally understand what this FID thing is. That is how the switch came up when it was installed by EMC. We don’t use any VSANs or any logical subdivision in any of our switches. I’ve wondered why that is seen on the cmd line on that switch but not our others. How do I remove that so I am dealing with the default settings?
If I run the command like you say, it shows me “nothing”…
CCWSAN01:FID128:admin> defzone --show
Default Zone Access Mode
committed - No Access
transaction - No Transaction
thanks
tonydcdi-ymiT1
70 Posts
1
June 8th, 2011 05:00
Maybe i wasn't clear... Check the zone membership on BOTH switches. notice that the members in the zones on switch one are different than that on switch two. understood they are different zones - as are all the zones in your zoneset..
Switch 1:
zone: esx101dev_b6aa_1556_SPab1
50:06:01:61:39:a0:1f:5c -> Member 1
50:06:01:69:39:a0:1f:5c -> Member 2
10:00:00:00:c9:6e:b6:aa -> Member 3
zone: esx102dev_b69d_1556_SPab1
50:06:01:69:39:a0:1f:5c -> member 1
10:00:00:00:c9:6e:b6:9d -> member 2
50:06:01:61:39:a0:1f:5c -> member 3
Switch 2:
zone: esx101dev_b6aa_1556_SPab1
10:00:00:00:c9:6e:b6:aa - Member 1 - should be member 3
50:06:01:69:39:a0:1f:5c - Member 2 - OK here
50:06:01:61:39:a0:1f:5c - member 3 - should be member 1
zone: esx102dev_b69d_1556_SPab1
10:00:00:00:c9:6e:b6:9d - Member 1 - should be member 2
50:06:01:69:39:a0:1f:5c - Member 2 - should be member 1
50:06:01:61:39:a0:1f:5c - Member 3 - Good here
---
Hence the zones don't match up.. What is even weirder is that the switchdisable, cfgdisable, cfgclear, cfgsave doesn't work.
downhill2
157 Posts
0
June 8th, 2011 05:00
I don’t think this is it. I think Richard is on to something. Lsconfig –show reports this 128 FID on the DS5100 but not the DS300s, so VF is obviously running on one and not the other. I think this is closer to the root.
downhill2
157 Posts
0
June 8th, 2011 05:00
Ok, I disabled VF on the switch and rebooted. The zoneshow shows me my correct effective zone on the DS5100. I have now both switches with same options enabled. Yet, even disabling and enabling the DS300 will not let it merge, still get “zone conflict” in the fabriclog. There is no effective zone on the DS300 at this time. So, do I keep trying to push the same zoneset to the DS300 and hope it merges or does this sound like a bug in the code?
thanks
Richard_Butler
84 Posts
0
June 8th, 2011 06:00
Hi,
FID 128 on the 5100 is the default logical switch when the virtual fabric feature has been enabled (a bit like VSAN 1 for MDS). So, you will probably find that all your switch ports are in FID 128 (which is fine, just like all the MDS ports being in VSAN 1 if you do not want to use the VSAN functionality).
It is also OK for FID 128 to connect to the DS300B (even though the DS300B does not itself have a virtual fabric feature (need correct ASIC support)).
So, I would log onto the 5100B (you will probably be directly on the logical switch, so probably no need to 'setcontext 128' - the CLI prompt will tell you). Once logged in run the 'defzone --show' command, and compare the output with the same command on the DS300B.
Let's see if they are different.....
downhill2
157 Posts
0
June 8th, 2011 06:00
I found a similar post in the Brocade forums which eventually led to a solution by Adreas which solved the problem. While I think there were several steps to the final solution, it took doing a "defzone --allaccess" followed by a cfgsave, switchdisable, switchenable to finally let them merge. I also in the process of getting what I was looking for as far as principal, set the fabricprincipal switch to be the DS5100 and disabled that on the DS300 thus forcing the DS300 to be the subordinate. Thanks to all who chimed in!
Dave