×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Another question about IVR

Answered Question
Sep 4th, 2010
User Badges:
  • Silver, 250 points or more

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

Attachment: 
Correct Answer by bfeeny about 6 years 11 months ago

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.

Correct Answer by bfeeny about 6 years 11 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
bfeeny Sat, 09/04/2010 - 22:32
User Badges:

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.

dynamoxxx Sun, 09/05/2010 - 06:50
User Badges:
  • Silver, 250 points or more

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

Correct Answer
bfeeny Sun, 09/05/2010 - 09:54
User Badges:

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.

dynamoxxx Sun, 09/05/2010 - 12:34
User Badges:
  • Silver, 250 points or more

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.

bfeeny Sun, 09/05/2010 - 12:53
User Badges:

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
bfeeny Sun, 09/05/2010 - 12:54
User Badges:

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



dynamoxxx Sun, 09/05/2010 - 16:21
User Badges:
  • Silver, 250 points or more

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

bfeeny Sun, 09/05/2010 - 16:24
User Badges:

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.

dynamoxxx Sun, 09/05/2010 - 16:42
User Badges:
  • Silver, 250 points or more

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.

bfeeny Sun, 09/05/2010 - 16:46
User Badges:

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?

dynamoxxx Sun, 09/05/2010 - 16:53
User Badges:
  • Silver, 250 points or more

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.

bfeeny Sun, 09/05/2010 - 16:58
User Badges:

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

dynamoxxx Sun, 09/05/2010 - 17:04
User Badges:
  • Silver, 250 points or more
switch9222i-1# show ivr zoneset<br/><br/>zoneset name ivr-active<br/><br/>  zone name sanutil4-vsan12-s2186_7e0-vsan14<br/>      pwwn 10:00:00:00:c9:42:39:2c            vsan   12 autonomous-fabric-id  1 <<< - This is the host<br/>      pwwn 50:00:09:72:08:22:29:18            vsan   14 autonomous-fabric-id  1 <<< - This is the array<br/>


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

bfeeny Sun, 09/05/2010 - 17:16
User Badges:

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

dynamoxxx Sun, 09/05/2010 - 18:48
User Badges:
  • Silver, 250 points or more

yep, i am looking on the switch that ends with f0:80.  You are right, VSAN 12 and 14 are on the same physical switch so no need for transit vsan.  I am still youcurious why you are seeing IVRZ zones and i am not. Do you think that only happens when you configure between two physical switches ?

bfeeny Sun, 09/05/2010 - 18:52
User Badges:

You always have to have IVR zones and IVR Zonesets in IVR.  I am not sure why you would not have them, or how it would be working without showing them.  Obviously there is some explaination.  If you view either of those zonesets 12 and 14 "show zoneset active vsan 12", "show zoneset active vsan 14", it would have to show the membership of those two devices, does it not? And they should have * next to them to show they are seen.

dynamoxxx Mon, 09/06/2010 - 05:38
User Badges:
  • Silver, 250 points or more

Aha, i see what i am doing wrong. I ran "show zonetset vsan 12" - this does not show IVRZ zones, but then i tried you example "show zoneset active vsan 12" and i do see IVRZ zones.  Ok so Brian help me understand why i am seeing IVRZ when i look at active zoneset for VSAN 12 versus  regular zoneset command.


Thank you for your help.

bfeeny Mon, 09/06/2010 - 09:34
User Badges:

This is normal behavior.  The "full zoneset" is the zones/zonesets you configure.  There can be many zones, many zonesets.  But only one zoneset per VSAN can be active at a time.  The MDS takes the IVR Zoneset you created "sh ivr zoneset" and it merges it with the zoneset you activate, to create the active zoneset.  It also adds in things like any iSLB auto-zones you may have as well.


So if you want to make any changes to your IVR you only edit the IVR zones/zoneset.  The MDS takes care of the merge, its smart enough to add these to the appropriate zones as needed with the IVZ prefix.


In your situation, you are in fact spanning the one VSAN and then doing IVR on a single border router.  It would be good to introduce a true transit VSAN.  Although you have to deal with the fact you are partitioning one of your VSAN's you can either renumber it at one end or deal with it via IVR NAT.

bfeeny Mon, 09/06/2010 - 09:52
User Badges:

so just to be clear, if you edit a regular zone/zoneset, say  you make a change, you then activate that zoneset.

If you edit any of the IVR zones/zoneset, you then activate the ivr zoneset.


you only have to activate the one you just made changes to, the system will ensure the complete active zoneset has both regular zoneset and ivr zoneset information.

dynamoxxx Mon, 09/06/2010 - 18:20
User Badges:
  • Silver, 250 points or more

So if you want to make any changes to your IVR you only edit the IVR zones/zoneset.  The MDS takes care of the merge, its smart enough to add these to the appropriate zones as needed with the IVZ prefix.



yeah, this is what's odd to me. I thought that everything IVR related resides in that IVR zoneset with its  zones. Still don't quite understand why IVRZ zones need to be added to the other VSANs


In your situation, you are in fact spanning the one VSAN and then doing IVR on a single border router.  It would be good to introduce a true transit VSAN.  Although you have to deal with the fact you are partitioning one of your VSAN's you can either renumber it at one end or deal with it via IVR NAT.


i am trying to understand what you are saying here. So i have this one switch that has two VSANs: 12 and 14.  Since these two VSANs reside on the same physical switch why would i need a transit VSANs.  From Cisco documentation i understand that "adjacent" VSANs don't require transit VSANs.

If VSAN 12 and VSAN 14 have unique domain id why would i need to re-number them or use IVR NAT.


Thank you for these discussions, hopefully they will assist other IVR noobies like me

bfeeny Mon, 09/06/2010 - 18:28
User Badges:

I don't have a diagram of your current network, but I guess I was assuming that one of those VSAN's, 12, 14, or whatever, was extended over an FCIP/DWDM link.  If you do that, without using a transit VSAN, then any disruption in the WAN, can cause disruption to the SAN which would not be good.  By making the WAN link its own VSAN, it isolates the non-transit VSAN's from these disruptions.


IVR is a cisco thing, and all switches do not understand it.  What switches do understand is regular zones and zone changes.  So IVR is sort of a middleware mechanism that is really just manipulating regular type zones.  There is more to it than that of course, but my point is, there is a reason why you maintain IVR in a set of IVR zones/zonesets, but it adds this information to "regular" zones.


Also any changes you make to zoning you will want to do on one of your IVR enabled switches, your border switches, you will want to avoid making zoning changes directly on the switches that are not running IVR, as this can cause some unpredictable results and disruption.


You don't need a transit VSAN for VSAN's that reside on a single switch or even a single localized fabric.  Its encouraged if you are using a WAN link.  Spanning VSAN's over the WAN is not a good idea (unless its a Transit VSAN your spanning).


Brian

dynamoxxx Mon, 09/06/2010 - 19:41
User Badges:
  • Silver, 250 points or more

my fault Brian, i started talking about my "proposed" design with DWDM link in the middle but then got into other areas.


So if you look at my original diagram (attached to my first post). Somebody on other forum told me that i don't need to put my long-way ports into transit VSAN 30, they can be in VSAN 1 or any other VSAN. What do you think about that ?

bfeeny Mon, 09/06/2010 - 19:54
User Badges:

By long-way ports do you mean your DWDM ports?  You should put those in a transit VSAN, it can be whatever number you want, 1, 30 etc.  But it should be a VSAN that you are only using for this purpose.  If you have other stuff in it, then it defeats the purpose of having a transit VSAN. 


You don't have to use a transit VSAN, but its best practice to do so.

dynamoxxx Tue, 09/07/2010 - 02:54
User Badges:
  • Silver, 250 points or more

yes, by long-way ports i mean my DWDM ports. Is there a specific reason they need to be part of my transit vsan ? Could they be in VSAN 1 as long as i "trunk allow" VSAN 30 only (my transit VSAN) ?


i was looking at this document and trying to understand why they say that "The default zone in the transit VSAN should be set to deny"


http://www.ciscosystems.com/en/US/docs/storage/san_switches/mds9000/sw/svc/configuration/guide/Dual.html


Thank  you

Correct Answer
bfeeny Tue, 09/07/2010 - 05:48
User Badges:

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.

bfeeny Sun, 09/05/2010 - 17:02
User Badges:

Notice how in your output for show ivr vsan-topology even though its Active "yes", under Cfg. it says "No".

dynamoxxx Wed, 09/08/2010 - 18:43
User Badges:
  • Silver, 250 points or more

Thank you Brian so MUCH !!!

Actions

This Discussion

Related Content

 

 

Trending Topics: Storage Networking