cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3915
Views
0
Helpful
27
Replies

Another question about IVR

dynamoxxx
Level 5
Level 5

Hello guys,

Please answer my questions regarding IVR considering my design, see picture attached:

Considering all VSANs have unique id, so IVR-NAT is not required.

1) I am going to configure transit VSAN  30, this VSAN will only contain ports that provide DWDM connectivity ?

2) I will create transit VSAN ( VSAN 30) on both 9513 and 9222i switch, that will be the only VSAN allowd to be trunked, so essentially VSAN 30 will merge.

3) IVR is enabled on both 9513 and 9222i, VSAN 10 needs to be able to talk to devices on VSAN 110, VSAN 20 needs to be able to talk to devices in VSAN 200. When i run IVR Wizard for the very first time, do i need to select VSAN 10, 110, 20, 200 and VSAN 30 which is my transit VSAN ?

4) If i have a host that is directly plugged-in into my edge 9134, can it be IVR zoned to an array plugged-in directly into 9124e, considering 9134 and 9124e do not support IVR but they are connected to switches that have IVR enabled.

Looking at my design are there any questions that i should be asking ?

Thank you very much

@dynamoxxx
2 Accepted Solutions

Accepted Solutions

Yes you are correct in your configuration of a topology.

The steps are as follows:

1. Make sure FC Domain ID's are unique

2. enable ivr on 9513 and 9222i

"ivr enable"

3. Turn on CFS for IVR on both 9513 and 9222i

"ivr distribute"

4. Define IVR Topology (done on 1 switch)

Your topology is correct

5. Activate Topology  (done on 1 switch)

"ivr vsan-topology activate"

You only need to do the above from the switch you defined the topology on.

6. Create IVR zones:  (done on 1 switch)

ivr zone name ivrzone

member pwwn 21:00:00:00:00:00:00:00 vsan 10

member pwwn 21:00:22:22:33:33:33:33 vsan 20

7. Create IVR zoneset  (done on 1 switch)

ivr zoneset name ivrzoneset

member ivrzone

8. Activate IVR Zoneset  (done on 1 switch)

ivr zoneset activate name ivrzoneset

You need to have an active zoneset. If you don't then you need to add the "force" parameter to the above.  After you activate an IVR Zoneset, it will automatically add ivr zones to your current zones (for those VSAN's in  your topology)

9. Commit  (done on 1 switch)

ivr commit

So IVR modifies your zonesets, after running the above you can look at your activate zonesets and see what its done.

You are correct in that you don't actually define your transit VSAN as a way of communication, that is figured out automatically.

As far as running ivr vsan-toplogy activate and that automatically being pushed to the 9222i, that is accomplished via CFS, so you have to make sure you have enabled IVR and CFS on both switches.

View solution in original post

Ok, I see what your asking now.  The Port VSAN for those DWDM ports doesn't matter.  Although I typically make a TE VSAN and just put those in it.  It can be whatever you want, and yes you just want to trunk the Transit VSAN.

In general, you want default zone deny for all VSAN's in my opinion.  I rely on zoning.  You can make default zone permit, but I would advise against it in most situations and in the transit VSAN for sure since there are no members in that VSAN that should be originating or destinating any traffic.

I like default zone deny, so nothing can talk unless I specifically zone it.

View solution in original post

27 Replies 27

bfeeny
Level 1
Level 1

1) Yes

2) Yes

3) Yes

4) Yes, edge devices do not have to participate in IVR directly

There is really not too much to consider that you haven't covered.  You will of course need to create ivr zones and an ivrzoneset.  I have not used the FM Wizard.  When configuring via CLI you can do auto topology discovery or manual, I normally do manual, not sure what the wizard ends up doing.

Thank you Brian.

A couple more questions, let's say i decide to configure using the cli, do these steps make sense:

Let's assume that all VSANs are already created, transit vsan 30 has been merged.

1) Define which VSAN will participate in IVR ( these steps need to be done on 9222i and 9513 ? )

switch(config)# ivr vsan-topology database

switch(config-ivr-topology-db)# autonomous-fabric-id 1 switch 20:00:00:05:30:01:1b:b8 vsan-ranges 10,20,30 

switch(config-ivr-topology-db)# autonomous-fabric-id 1 switch 20:00:00:05:30:01:1b:b8 vsan-ranges 110,200,30

switch(config)# ivr vsan-topology activate

2) I don't see any option to define my vsan 30 (transit) as the way of "communication", will IVR automatically select VSAN 30 just because it's merged ?

3) If i am not running IVR auto mode, what would my next step to be ? Let's say i create an IVR zone on 9513, just because i ran "ivr vsan-topology activate" does not mean that it got pushed to 9222i right ? I have to manually "push" that to 9222i ? If yes, how do i do that ?

Am i missing anything else ?

Thank you

@dynamoxxx

Yes you are correct in your configuration of a topology.

The steps are as follows:

1. Make sure FC Domain ID's are unique

2. enable ivr on 9513 and 9222i

"ivr enable"

3. Turn on CFS for IVR on both 9513 and 9222i

"ivr distribute"

4. Define IVR Topology (done on 1 switch)

Your topology is correct

5. Activate Topology  (done on 1 switch)

"ivr vsan-topology activate"

You only need to do the above from the switch you defined the topology on.

6. Create IVR zones:  (done on 1 switch)

ivr zone name ivrzone

member pwwn 21:00:00:00:00:00:00:00 vsan 10

member pwwn 21:00:22:22:33:33:33:33 vsan 20

7. Create IVR zoneset  (done on 1 switch)

ivr zoneset name ivrzoneset

member ivrzone

8. Activate IVR Zoneset  (done on 1 switch)

ivr zoneset activate name ivrzoneset

You need to have an active zoneset. If you don't then you need to add the "force" parameter to the above.  After you activate an IVR Zoneset, it will automatically add ivr zones to your current zones (for those VSAN's in  your topology)

9. Commit  (done on 1 switch)

ivr commit

So IVR modifies your zonesets, after running the above you can look at your activate zonesets and see what its done.

You are correct in that you don't actually define your transit VSAN as a way of communication, that is figured out automatically.

As far as running ivr vsan-toplogy activate and that automatically being pushed to the 9222i, that is accomplished via CFS, so you have to make sure you have enabled IVR and CFS on both switches.

Brian,

can you please expand on step 8, i got a little lost there. So i have my IVR zoneset, i add my members to it and i activate my zoneset.  How is this process different from any regular zoneset activation ? I am trying to understand why would i need to add the "force" option?

Also what do you mean that "it will automatically add ivr zones to your current zones" ?  IVR Zones will reside in the IVR zoneset, they don't mess with existing zonesets in regular VSANs ?

8. Activate IVR Zoneset  (done on 1 switch)

ivr zoneset activate name ivrzoneset

You need to have an active zoneset. If you don't then you need to add the "force" parameter to the above.  After you activate an IVR Zoneset, it will automatically add ivr zones to your current zones (for those VSAN's in  your topology)

Thank you so much for taking the time to explains all this. Great help.

@dynamoxxx

yes,

So lets say you have the following:

WIN2B an initiator in VSAN20

J1A1 a target in VSAN10

You would like for these to talk to eachother.  You have configured a topology and now you must create your IVR zones and IVR zoneset.

MDS1#  show device-alias name WIN2B

device-alias name WIN2B pwwn 21:01:00:e0:8b:28:e5:af

MDS1#    show device-alias name J1A1

device-alias name J1A1 pwwn 21:00:00:04:cf:9c:d4:c7

Currently the zoneset for VSAN10 looks like this:

MDS1# show zoneset active vsan 10

zoneset name VSAN10 vsan 10

  zone name WIN1A-J1A-RW vsan 10

  * fcid 0x2020dc [pwwn 21:00:00:04:cf:9c:d4:c7] [J1A1]

  * fcid 0x200000 [fwwn 20:01:00:0d:ec:0e:b2:40] [WIN1A]

  * fcid 0x2020e0 [J1A2]

And the zoneset for VSAN20 looks like this:

MDS1# show zoneset active vsan 20

zoneset name VSAN20 vsan 20

  zone name WIN2B-RW vsan 20

  * fcid 0x0d00a7 [device-alias VJBOD3A1]

  * fcid 0x0caabb [device-alias WIN2B]

  * fcid 0x0d1721 [device-alias VJBOD3A2]

  * fcid 0x0d1a03 [device-alias VJBOD3A3 lun 0x0002]

  * fcid 0x0d0280 [device-alias VJBOD3A4 lun 0x0000]

When we create an IVR zone, and add it to an IVR Zoneset, and activate the IVR zoneset, the existing zonesets in your various VSAN's are modified.  This is done automatically by the activation of the IVR zoneset.  It automatically creates special zones within your existing zonesets.

If you do not have an existing zoneset in a VSAN, say for example you just had never configured one, the you must use the force option, because IVR can't identify an active zoneset to edit, so it must create one, and it will use a funky MDS generated name.

You can always tell what zones were automatically added by IVR in your VSAN's because they will be prefixed with IVRZ_

So, we have the above, here is what we would do:

MDS1#     conf t

Enter configuration commands, one per line.  End with CNTL/Z.

MDS1(config)# ivr zone name WIN2B-J1A1

fabric is now locked for configuration. Please 'commit' configuration when done.

MDS1(config-ivr-zone)# member device-alias WIN2B vsan 20

MDS1(config-ivr-zone)# member device-alias J1A1 vsan 10

MDS1(config)# ivr zoneset name IVRZONESET

MDS1(config-ivr-zoneset)# member WIN2B-J1A1

MDS1(config)# ivr zoneset activate name IVRZONESET

MDS1(config)# ivr commit

commit initiated. check ivr status

What this will do is it will modify my existing active zoneset in VSAN10 and my existing active zoneset in VSAN20, they will now look as follows:

MDS1# show zoneset active vsan 10

zoneset name VSAN10 vsan 10

  zone name WIN1A-J1A-RW vsan 10

  * fcid 0x2020dc [pwwn 21:00:00:04:cf:9c:d4:c7] [J1A1]

  * fcid 0x200000 [fwwn 20:01:00:0d:ec:0e:b2:40] [WIN1A]

  * fcid 0x2020e0 [J1A2]

  zone name IVRZ_WIN2B-J1A1 vsan 10

  * fcid 0x0caabb [device-alias WIN2B]

  * fcid 0x2020dc [device-alias J1A1]

MDS1# show zoneset active vsan 20

zoneset name VSAN20 vsan 20

  zone name WIN2B-RW vsan 20

  * fcid 0x0d00a7 [device-alias VJBOD3A1]

  * fcid 0x0caabb [device-alias WIN2B]

  * fcid 0x0d1721 [device-alias VJBOD3A2]

  * fcid 0x0d1a03 [device-alias VJBOD3A3 lun 0x0002]

  * fcid 0x0d0280 [device-alias VJBOD3A4 lun 0x0000]

zone name IVRZ_WIN2B-J1A1 vsan 20

  * fcid 0x0caabb [device-alias WIN2B]

  * fcid 0x2020dc [device-alias J1A1]

notice how the zones are automatically prefixed with IVRZ_
So you don't really ever need the "force" option unless you had a VSAN you were using that had no zoneset, AND you were adding IVR zones with members from that VSAN.  Since Transit VSAN has no members and no zones you don't have to worry about that, but if I had no zoneset active in VSAN10 for example, IVR can't modify a zoneset that doesn't exist, so it has to create one automatically (when you add the force option).
Typically the force option is not something you will need to worry about.
The IVR zones you create along with the IVR zoneset, serve as a blueprint for the MDS to go and modify existing real zonesets.  You maintain these and update these via the "ivr zone" and "ivr zoneset" commands/configuration.  They are pushed out from the activation into the appropriate zonesets. 
They differ, because in IVR you are not just specifying zone members, but zone members plus VSAN plus AFID.  You can just leave the AFID part off like I did above if your just using AFID 1 (default).  IVR looks at the VSAN's  you specified on the members, finds the active zonesets for those VSAN's and modifies them.
Brian

Here is the active ivr zoneset:

MDS1#    show ivr zoneset active

zoneset name IVRZONESET

  zone name WIN2B-J1A1

    * device-alias WIN2B            vsan   20 autonomous-fabric-id  1

    * device-alias J1A1            vsan   10 autonomous-fabric-id  1

now that's is very interesting. I have never heard of this, where IVRZ zones get created automatically.  On my 9222i i have IVR zoneset that consists of two devices from different VSANs. Let's say host is in vsan 10 and array is in vsan 20. Both array and host are IVR zoned to each other. I just doubled checked zoneset for vsan 10 and 20 and i don't see any zones that start IVRZ. I am running code 4.1.1b

@dynamoxxx

Was there any errors when activating the IVR Zoneset?  Did you remember to commit?

If the zones are not being automatically created, i would think either:

1) ivr is not enabled

2) cfs not enabled for ivr

3) ivr not activated

4) ivr not commited

If you want to post some of what you have done, i can check it.

this was setup a year ago

switch9222i-1# show ivr vsan-topology

AFID  SWITCH WWN                 Active   Cfg. VSANS           Switch-Name
-------------------------------------------------------------------------
   1  20:00:00:0d:ec:71:f0:80 *   yes      no  2,9,12,14
   1  20:00:00:0d:ec:71:f3:00     yes      no  2,9,14,30

switch9222i-1# show ivr zoneset

zoneset name ivr-active

  zone name sanutil4-vsan12-s2186_7e0-vsan14
      pwwn 10:00:00:00:c9:42:39:2c            vsan   12 autonomous-fabric-id  1
      pwwn 50:00:09:72:08:22:29:18            vsan   14 autonomous-fabric-id  1

switch9222i-1# show cfs status

Distribution : Enabled
Distribution over IP : Disabled
IPv4 multicast address : 239.255.70.83
IPv6 multicast address : ff15::efff:4653

I checked VSAN 12 and VSAN 14 and i don't see any IVRZ zones.

@dynamoxxx

So are you saying you have devices in VSAN 12 and VSAN 30 that need to communicate?  If you have no IVR zones created and no IVR zoneset than IVR communication will not occur.  Perhaps your IVR is doing nothing?  Do you have specific devices in different VSAN's that are communicating?  which ones?

i have host "sanutil4" in vsan 12 and array "s2186" in vsan 14.  As you can see from output of "show ivr zoneset" they are IVR zoned to each other and have connectivity.

@dynamoxxx

Neither device is seen in that active zoneset, there is no * next to the members indicating there is an issue.  Perhaps check the output of

sh ivr internal debug-log-buffer1

For some clues

switch9222i-1# show ivr zoneset

zoneset name ivr-active

  zone name sanutil4-vsan12-s2186_7e0-vsan14
      pwwn 10:00:00:00:c9:42:39:2c            vsan   12 autonomous-fabric-id  1 <<< - This is the host
      pwwn 50:00:09:72:08:22:29:18            vsan   14 autonomous-fabric-id  1 <<< - This is the array

the host is connected to this array and using its storage so i know it's working.

@dynamoxxx

Make sure you are checking commands on sWWN 20:00:00:0d:ec:71:f0:80.  This switch is in both 12 and 14, so technically IVR only needs to be enabled on that switch, since VSAN 14 is spanned, that switch can facilitate the communications.  This is as opposed to using a transit VSAN where you would have say 12 on one side, 14 on the other and some transit VSAN that exists on both ends to join them.

So when checking the show commands look on that sWWN to be sure we are looking at accurate information.

Brian

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: