Hopefully second last storage topic I am going to cover for CCIE DC. Then from there it will turn to the other area's that make up this behemoth of a blueprint.
So let's talk about iSCSI a bit, so the MDS allows you to present your FC targets as iSCSI, so that iSCSI initiators can talk to your FC devices, pretty funky, I have already done a few blog posts on iSCSI:
http://www.ccierants.com/2012/05/iscsi-qualified-name-iqn-naming-format.html
http://www.ccierants.com/2012/06/iscsi-discovery-mechanisms.html
OK assuming you already know most of the stuff in there, let's carry on :)
So, first of all you have to understand the model that Cisco have here, the following documentation is where I got most of my info from:
http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/sw/6_2/configuration/guides/ip_services/nx-os/ciscsi.html
The way that document is laid out makes it a little confusing to follow, I will try and demystify a little here, these are my golden rules for iSCSI Configuration that have served me well
1. The enabling of iSCSI is easy enough, and you enable it per module, in the CCIE DC this is probably only going to be one module, so should not be a big stress for you.
2. There are always two aspects to this iSCSI gateway, you have the initiator, and the target, the complication comes in how your gateway marries the two together, do we have dynamic initiators, static targets? maybe we need to configure our initiators because we plan to authenticate some initiators, do we want to provide authentication? etc?
3. The access control, there are always TWO access control methods involved in this iSCSI gateway config which you would not normally have in a pure FC or pure iSCSI enviroment, you have the FC access control, and the iSCSI access control and we will get into each of those later.
Let's start at the basics and just get a very simple config done where we have a target we want to present dynamically, our initiator is going to be dynamic too, and we will be doing as little access control as possible.
Here is the basic config we need
Switch1(config)# feature iscsi
Switch1(config)# iscsi enable module 1
All fairly self explanatory so far, to configure the actual iSCSI interface, it maps to our available gigabit interfaces (unlike FCIP where we actually specify the interface ourselves)
Switch1(config)# show iscsi stats
iscsi1/1
5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
iSCSI statistics
0 packets input, 0 bytes
Command 0 pdus, Data-out 0 pdus, 0 bytes, unsolicited 0 bytes
output 0 packets, 0 bytes
Response 0 pdus (with sense 0), R2T 0 pdus
Data-in 0 pdus, 0 bytes
iscsi1/2
5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
iSCSI statistics
0 packets input, 0 bytes
Command 0 pdus, Data-out 0 pdus, 0 bytes, unsolicited 0 bytes
output 0 packets, 0 bytes
Response 0 pdus (with sense 0), R2T 0 pdus
Data-in 0 pdus, 0 bytes
As you can see it maps up to what interfaces we have available.
The show iscsi global is a ridicolously useful command we can use to check what is going on in our iscsi Enviroment:
Switch1(config)# show iscsi global
iSCSI/iSLB Global information (fabric-wide)
Authentication: CHAP, NONE
Initiator idle timeout: 300 seconds
Dynamic Initiator: iSCSI
iSLB Distribute: Disabled
iSLB CFS Session: Does not exist
Number of load balanced VRRP groups: 0
Number of load-balanced initiators: 0
iSCSI/iSLB Global information (local to this switch)
Import FC Target: Disabled Initiator Plogi timeout: 2 seconds
Number of target node: 0
Number of portals: 3
Number of session: 0
Failed session: 0, Last failed initiator name:
We can see with the default config that we have dynamic initiators, and we also have import FC target disabled, the iscsi import target FC command will import all of the available FC Targets straight into iSCSI to be available as iSCSI targets
Switch1(config)# iscsi import ?
target Configure import of targets to iSCSI domain
Switch1(config)# iscsi import target ?
fc Configure import of FC targets
Switch1(config)# iscsi import target fc ?
Switch1(config)# iscsi import target fc
Let's try and connect an initiator now and see what happens, amazingly the iscsi debugging is actually extremely useful:
Switch1# debug ips iscsi ?
config Debug iSCSI config
config-detail Debug iSCSI config detail
flow Debug iSCSI flow
flow-detail Debug iSCSI flow detail
msgs Debug iSCSI msgs received responded
Switch1# debug ips iscsi msgs ?
Switch1# debug ips iscsi msgs
We still have to no shut our iscsi interface:
int iscsi1/1
no shut
!
Switch1# show int iscsi1/1
iscsi1/1 is up Hardware is GigabitEthernet
Port WWN is 20:0f:00:0d:ec:2d:4f:40
Admin port mode is ISCSI
snmp link state traps are enabled
Port mode is ISCSI
After connecting, here is what iSCSI Initiator on windows shows us:
So let's see what has happened so far,
First of all, because we tried to connect, an iscsi Initiator has been automatically setup for us:
Switch1# show iscsi initiator
iSCSI Node name is iqn.1991-05.com.microsoft:nervmainpc
Initiator ip addr (s): 10.0.0.83
iSCSI alias name:
Auto-created node (iSCSI)
Node WWN is 21:01:00:0d:ec:2d:4f:42 (dynamic) Member of vsans: 1
Number of Virtual n_ports: 1
Virtual Port WWN is 21:02:00:0d:ec:2d:4f:42 (dynamic) Interface iSCSI 1/1, Portal group tag: 0x3000
VSAN ID 1, FCID 0x010003
The Node WWN and Port WWN have been selected for us and assigned dynamically, and has even been inserted into the FC Database:
Switch1# show fcns database
VSAN 1:
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0x010001 N 50:01:10:a0:00:18:31:e4 scsi-fcp:init
0x010002 N 50:01:10:a0:00:18:31:e6 scsi-fcp:init
0x010003 N 21:02:00:0d:ec:2d:4f:42 (Cisco) scsi-fcp:init isc..w 0x020000 N 50:01:10:a0:00:18:31:80 scsi-fcp:target
yet we haven't seen any targets yet.. we can't see any targets that our iSCSI initiator can talk to, even though we have imported the target, which allows all targets, and we can see the initiator, why?
Because we haven't done our access-control for FC yet. Just because it is connecting via iSCSI, doesn't mean this host is immune from our requirements from FC Zoning.
Looking at the active database:
Switch1# show zone active
zone name switch1 vsan 1
* fcid 0x020000 [pwwn 50:01:10:a0:00:18:31:80]
pwwn 50:01:10:a0:00:18:31:e6
We can clearly see the FCID we want to allow access is not listed. so we are going to need to zone to allow this device.
We can do our zoning based on a variety of settings, including the iSCSI node name (IQN)
Switch1(config)# zone name switch1 vsan 1
Switch1(config-zone)# member symbolic-nodename ?
WORD Enter symbolic node name (Max Size 255)
and even the IP Address we expect the initiator to come from or a subnet range
switch1(config-zone)# member ip-address ?
A.B.C.D Enter ip address
A:B::C:D Enter ip address
A:B::C:D/LEN Enter ip address
Switch1(config-zone)# member ip-address 10.0.0.0 ?
A.B.C.D Enter subnet mask
Switch1(config-zone)# member ip-address 10.0.0.0
Of course we can also zone based on the dynamically assigned pWWN which we will do for now:
Switch1(config-zone)# show iscsi initiator
iSCSI Node name is iqn.1991-05.com.microsoft:nervmainpc
Initiator ip addr (s): 10.0.0.83
iSCSI alias name:
Auto-created node (iSCSI)
Node WWN is 21:01:00:0d:ec:2d:4f:42 (dynamic)
Member of vsans: 1
Number of Virtual n_ports: 1
Virtual Port WWN is 21:02:00:0d:ec:2d:4f:42 (dynamic)
Interface iSCSI 1/1, Portal group tag: 0x3000
VSAN ID 1, FCID 0x010003
Switch1(config-zone)# member pwwn 21:02:00:0d:ec:2d:4f:42
but this has a major drawback: if the switch is reset, the assigned pWWN may be diffirent, meaning our zoning will no longer be accurate.
Switch1(config)# zoneset name switch1 vsan 1
Switch1(config-zoneset)# member switch1
Switch1(config-zoneset)# exit
Switch1(config)# zoneset activate name switch1 vsan 1
Switch1(config)# show zone active
zone name switch1 vsan 1
* fcid 0x010003 [pwwn 21:02:00:0d:ec:2d:4f:42]
* fcid 0x020000 [pwwn 50:01:10:a0:00:18:31:80]
so let's save the config for this initiator:
Switch1(config)# iscsi save-initiator ?
ip-address ISCSI initiator node ip address
name ISCSI initiator node name
Switch1(config)# iscsi save-initiator
Please execute "copy run start" to keep the WWNs persistent across switch reboots
Let's see what it has done to our config:
Switch1(config)# show run | sect iscsi
feature iscsi
iscsi enable module 1
iscsi import target fc
iscsi initiator name iqn.1991-05.com.microsoft:nervmainpc
static nWWN 21:01:00:0d:ec:2d:4f:42
static pWWN 21:02:00:0d:ec:2d:4f:42
It has created a static entry as you can see above, and in the show iscsi initiator output below:
Switch1(config)# show iscsi initiator
iSCSI Node name is iqn.1991-05.com.microsoft:nervmainpc
Initiator ip addr (s): 10.0.0.83
iSCSI alias name:
Configured node (iSCSI)
Node WWN is 21:01:00:0d:ec:2d:4f:42 (configured) Member of vsans: 1
Number of Virtual n_ports: 1
Virtual Port WWN is 21:02:00:0d:ec:2d:4f:42 (configured) Interface iSCSI 1/1, Portal group tag: 0x3000
VSAN ID 1, FCID 0x010003
Can we now see some storage via iSCSI?
We sure can, notice the IQN Name, it has a particular format
Switch1(config)# show iscsi session
Initiator iqn.1991-05.com.microsoft:nervmainpc
Initiator ip addr (s): 10.0.0.83
Session #1
Target iqn.1987-05.com.cisco:05.switch1.01-01.500110a000183180
VSAN 1, ISID 400001370000, Status active, no reservation
The target IQN is the usual cisco prefix, followed by .
If you had multiple targets, this is the format they would show up in.
So now our dynamic has become a static entry, let's look at what options we have for initiators.
if we wanted to configure a static initiator lets say because we knew a particular host was coming online, but we had no idea what IQN etc it is going to receive, but we did know what IP address it was going to come from, this is where we could configure that:
Switch1(config)# iscsi initiator ?
idle-timeout ISCSI initiator idle timeout value in seconds
ip-address ISCSI initiator node ip address
name ISCSI initiator node name plogi-timeout ISCSI initiator idle timeout value in seconds
As you can see you can specify the ip address or IQN that the initiator will use, let's configure our existing one
Switch1(config)# iscsi initiator name iqn.1991-05.com.microsoft:nervmainpc
Switch1(config-iscsi-init)# ?
mutual-chap Assign username for initiator's challenge (mutual chap) no Negate a command or set its defaults
static Create static nWWN or pWWN for the initiator
username Assign username for iSCSI login authentication
vsan Assign VSAN membership for the initiator end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
I have highlighted the entries that might be interesting to us, the first is mutual-chap, iSCSI supports the concept of authentication via CHAP, and an initiator can authenticate against a target, and also a target can authenticate against an initiator! so this is Mutual-CHAP which we will go through shortly.
the static keyword allows us to define static nWWN and pWWN's that we can use for initiator as it joins the FC, we need both an nWWN and a pWWN
Switch1(config-iscsi-init)# static ?
nWWN Configure static nWWN for the initiator
pWWN Configure static pWWN for the initiator
Switch1(config-iscsi-init)# static pwWN ?
system-assign Ask the system to assign static pWWN(s) for this
initiator
Note that we can specify the system-assign method and this is recommended, this will be saved on reboot but just means we don't have to come up with our own pWWN and nWWN but instead the switch will pick some appropriate ones for us, this seems a lot less risky to me ;)
Next we have username which allows us to specify what user is allowed to come from this initiator, we will go through CHAP authentication shortly. the final option is VSAN which allows us to say that this particular initiator is going to belong to this VSAN, you can have membership of VSAN be based on the initiator or just the interface, the VSAN a target will belong to is dependent upon what VSAN that actual target belongs to in the FC Network!
Let's configure iSCSI to require CHAP as this will then conclude our look at initiators!
First, you define the authetication methods for iscsi:
Switch1(config)# iscsi authentication chap
Switch1(config)# username nervmainpc password nervmainpc iscsi
You must also configure an AAA method, iSCSI can be authenticated against a radius server like other login methods:
Switch1(config)# aaa authentication iscsi default local
(Note: this is the default method)
We need to then specify we expect this username to be associated with this iSCSI initiator:
Switch1(config)# iscsi initiator name iqn.1991-05.com.microsoft:nervmainpc
Switch1(config-iscsi-init)# username nervmainpc
Now if we try and login:
Oh dear!
Let's configure a username and password on our iSCSI initiator
This will now connect and we have an authenticated session!
Switch1(config)# 1981 Sep 3 03:32:44.816981 ips: Session Create (init-name:[iqn.1991-05.com.microsoft:nervmainpc] tgt-name:[iqn.1987-05.com.cisco:05.switch1.01-01.500110a000183180] init-alias:[] ISID:[400001370000] indx:[0x02000000] init_ip:[10.0.0.83]
1981 Sep 3 03:32:44.817879 ips: Querying NS for target pwwn 50:01:10:a0:00:18:31:80 vsan 1 filter fcid 00010003
1981 Sep 3 03:32:44.819059 ips: NS target response vsan:[1] fcid:[00020000] for target pwwn 50:01:10:a0:00:18:31:80
1981 Sep 3 03:32:44.820049 ips: Session Create Response: Init: node_name iqn.1991-05.com.microsoft:nervmainpc init_name iqn.1991-05.com.microsoft:nervmainpc init-nwwn 21:01:00:0d:ec:2d:4f:42 init-pwwn 21:01:00:0d:ec:2d:4f:42 init-fcid 10003 isid 400001370000pgt 12288 num_auth method 1 nodeIndex 2target_name iqn.
1981 Sep 3 03:32:44.822181 ips: Received chap authenticate user: nervmainpc chap_i: 4
1981 Sep 3 03:32:44.823285 ips: Chap Verify user-name nervmainpc, chap-id 4 result 0x00000000 authen status 0x00000001
(I told you the debug for iSCSI was good ;)
the show commands are not too shabby either
Switch1(config)# show iscsi session detail
Initiator iqn.1991-05.com.microsoft:nervmainpc
Initiator ip addr (s): 10.0.0.83
Session #1 (index 7)
Target iqn.1987-05.com.cisco:05.switch1.01-01.500110a000183180
VSAN 1, ISID 400001370000, TSIH 12288, Status active, no reservation Type Normal, ExpCmdSN 122, MaxCmdSN 249, Barrier 0
MaxBurstSize 262144, MaxConn 1, DataPDUInOrder Yes
DataSeqInOrder Yes, InitialR2T No, ImmediateData Yes
Registered LUN 0, Mapped LUN 0
Stats:
PDU: Command: 121, Response: 121
Bytes: TX: 1636916, RX: 98304
Number of connection: 1
Connection #1 (index 1)
Local IP address: 10.0.0.32, Peer IP address: 10.0.0.83
CID 1, State: Full-Feature
StatSN 125, ExpStatSN 0
MaxRecvDSLength 65536, our_MaxRecvDSLength 262144
CSG 3, NSG 3, min_pdu_size 48 (w/ data 48)
AuthMethod CHAP, HeaderDigest None (len 0), DataDigest None (len 0) Version Min: 0, Max: 0
FC target: Up, Reorder PDU: No, Marker send: No (int 0)
Received MaxRecvDSLen key: Yes
Stats:
Bytes: TX: 1636916, RX: 98304
Let's quickly look at mutual authentication
Switch1(config)# iscsi initiator name iqn.1991-05.com.microsoft:nervmainpc
Switch1(config-iscsi-init)# mutual-chap username authTarget password nervmainpc123
As you can see the config is relatively straight forward under the initiator for this
Switch1(config-iscsi-init)# 1981 Sep 3 03:37:54.660248 ips: Session Create (init-name:[iqn.1991-05.com.microsoft:nervmainpc] tgt-name:[iqn.1987-05.com.cisco:05.switch1.01-01.500110a000183180] init-alias:[] ISID:[400001370000] indx:[0x02000000] init_ip:[10.0.0.83]
1981 Sep 3 03:37:54.661143 ips: Querying NS for target pwwn 50:01:10:a0:00:18:31:80 vsan 1 filter fcid 00010003
1981 Sep 3 03:37:54.662339 ips: NS target response vsan:[1] fcid:[00020000] for target pwwn 50:01:10:a0:00:18:31:80
1981 Sep 3 03:37:54.663265 ips: Session Create Response: Init: node_name iqn.1991-05.com.microsoft:nervmainpc init_name iqn.1991-05.com.microsoft:nervmainpc init-nwwn 21:01:00:0d:ec:2d:4f:42 init-pwwn 21:01:00:0d:ec:2d:4f:42 init-fcid 10003 isid 400001370000pgt 12288 num_auth method 1 nodeIndex 2target_name iqn.
1981 Sep 3 03:37:54.667042 ips: Received chap authenticate user: nervmainpc chap_i: 6
1981 Sep 3 03:37:54.668107 ips: Chap Verify user-name nervmainpc, chap-id 6 result 0x00000000 authen status 0x00000001
That pretty much covers all of the settings for iSCSI initiators, let's just have a quick look for any other params that might be interesting:
Switch1(config)# iscsi dynamic initiator ?
deny Configure dynamic initiators to be denied
islb Configure dynamic initiators to be handled as iSLB initiators
This allows us to deny dynamic initiators completely or use them with iSLB which we will cover later.
under the iSCSI interface itself we have some options too:
Switch1(config)# int iscsi1/1
Switch1(config-if)# ?
link-state-trap Enable/disable link state change traps
mode Configure forwarding mode no Negate a command or set its defaults
port Configure listener port
qos Configure qos for interface shutdown Enable/disable an interface
switchport Configure switchport parameters
tcp Configure TCP parameters tmf-queueing Configure TMF Queueing mode
end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
The mode specifies how the switch will forward iSCSI packets in it's data plane, there are three modes available, store and forward, cut through and pass-thru but the actual options presented will depend on your hardware platform, for me i only have store-and-forward so i can't show you any of the config here.
the QOS param just let's you specify a DSCP value to associate with your traffic, the TCP setting lets you specify the usual TCP parameters that you might want to tweak just like with FCIP
Switch1(config-if)# tcp ?
cwm Enable congestion window monitoring
keepalive-timeout Set keep alive timeout in sec
max-bandwidth-kbps Configure maximum available path bandwidth in Kbps
max-bandwidth-mbps Configure maximum bandwidth
max-jitter Configure jitter for iSCSI in micro seconds
max-retransmissions Maximum number of retransmissions
min-retransmit-time Set minimum retransmit time in millisec
pmtu-enable Enable PMTU Discovery
sack-enable Enable SACK option for TCP
send-buffer-size Send buffer size in KBytes
THIS INCLUDES THINGS LIKE MAXIMUM BANDWIDTH ETC!
Switch1(config-if)# show int iscsi1/1
iscsi1/1 is up
Hardware is GigabitEthernet
Port WWN is 20:0f:00:0d:ec:2d:4f:40
Admin port mode is ISCSI
snmp link state traps are enabled
Port mode is ISCSI
Port vsan is 1
Speed is 1 Gbps
Interface last changed at Thu Sep 3 02:45:57 1981
iSCSI initiator is identified by name
Number of iSCSI session: 1 (discovery session: 0)
Number of TCP connection: 1
Configured TCP parameters
Local Port is 3260
PMTU discover is enabled, reset timeout is 3600 sec
Keepalive-timeout is 60 sec
Minimum-retransmit-time is 300 ms
Max-retransmissions 4
Sack is enabled
QOS code point is 0
Maximum allowed bandwidth is 1000000 kbps
Minimum available bandwidth is 70000 kbps
Configured round trip time is 1000 usec
Finally the switchport under this has a few interesting commands:
Switch1(config-if)# switchport ?
description Enter description of maximum 80 characters
initiator Configure iSCSI initiator id mode
proxy-initiator Configure iSCSI proxy initiator mode timestamp-check Enable timestamp check
The switchport initiator command lets us specify if initiators should be identified based on IP address or IQN, with IQN being the default, proxy-initiator is a command that allows us to "proxy" ALL inititators behind a single address, this would be an easy method if you wanted to quickly and effectively integrate your iSCSI and FC network and where not too concerned about what iSCSI devices have access to what.
Alright, let's look at iSCSI virtual-targets now and discuss them in detail.
So in our example above, we where using a dynamic target and at first we used a dynamic initiator, later we switched to a static initiator with CHAP, next we will look at a static target
Here is the MOST IMPORTANT THING, TO Remember about Virtual-Targets:
BY DEFAULT, NO INITIATOR IS ALLOWED ACCESS TO THEM
you must disalbe "iscsi import target fc" to remove the dynamic iSCSI targets
Let's create our iSCSI target:
conf)# iscsi virtual-target name iqn.2007-01.com.ccierants:mainfctarget
Switch1(config-iscsi-tgt)# ?
advertise Advertise virtual-target on interfaces specified
all-initiator-permit Allow all iSCSI initiator access to this target
initiator Allow iSCSI initiator access to this target no Negate a command or set its defaults
pWWN Enter the pWWN of the fc-target revert-primary-port Revert back to primary port when it comes back up
end Go to exec mode
exit Exit from command interpreter
pop Pop mode from stack or restore from name
push Push current mode to stack or save it under name
where Shows the cli context you are in
!
The first option allows us to specify which interfaces this iSCSI target is available on, by default all iSCSI enabled interfaces will allow you access to the target.
The next options are where we specify what initiators are allowed access to our target, we can specify the initiator using the initiator keyword or all-initiator-permit to permit all initiators, the pWWN is where we specify what FC Target we are actually going to advertise with our virtual target.
Switch1(config-iscsi-tgt)# initiator ?
WORD Enter iSCSI initiator name (Max Size 223)
ip Allow iSCSI initiator access to this target by ip address
In this example we can specify the initiator based on IP or it's name, if we choose to use Ip address then the initiator mode in the interface iSCSI config must be based on IP-Address
Switch1(config-iscsi-tgt)# initiator
Next we need to specify the targets pWWN
Switch1(config-iscsi-tgt)# pwWN 50:01:10:a0:00:18:31:80 ?
fc-lun FC lun
secondary-pWWN Enter the secondary pWWN of the fc-target
Notice we can restrict down to a particular LUN id if we wish, and also specify a secondary pWWN incase there are mulitple paths to this target that we want to use.
Our target is now ready:
Switch1# show iscsi virtual-target
target: iqn.2007-01.com.ccierants:mainfctarget
Port WWN 50:01:10:a0:00:18:31:80
Configured node (iSCSI)
No. of initiators permitted: 1
initiator 10.0.0.83/32 is permitted
All initiator permit is disabled
Trespass support is disabled
Revert to primary support is disabled
This is now available as a target:
Important note: the usual FC Zoning rules apply, your target and initiator must have access!
iSCSI Failover
VSAN 1:
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0x010001 N 50:01:10:a0:00:18:31:e4 scsi-fcp:init
0x010002 N 50:01:10:a0:00:18:31:e6 scsi-fcp:init
0x020000 N 50:01:10:a0:00:18:31:80 scsi-fcp:target
0x020002 N 50:01:10:a0:00:18:31:82 scsi-fcp:target
pWWN 50:01:10:a0:00:18:31:80 secondary-pWWN 50:01:10:a0:00:18:31:82
!
-------------------------------------------------------------------------------
-
INTERFACE VSAN FCID PORT NAME NODE NAME
-------------------------------------------------------------------------------
-
fc2/1 1 0x020000 50:01:10:a0:00:18:31:80 50:01:10:a0:00:18:31:81
fc2/3 1 0x020002 50:01:10:a0:00:18:31:82 50:01:10:a0:00:18:31:8
3
Switch2# show flogi database
-------------------------------------------------------------------------------
-
INTERFACE VSAN FCID PORT NAME NODE NAME
-------------------------------------------------------------------------------
-
fc2/3 1 0x020002 50:01:10:a0:00:18:31:82 50:01:10:a0:00:18:31:8
3
ip address 10.0.0.32 255.255.255.0
no shutdown
vrrp 1
address 10.0.0.55
no shutdown
Note that this failover won't be seamless, your host will have to reconnect to the target.
This is by FAR the most comprehensive piece I've read about iSCSI and its variations. I can honestly say that, compared to this, the INE videos and workbooks were rather poor. The iSCSI section of IPexpert's workbook was definitely better that INE's, but still this post explains it all way clearer from the very beginning to a medium complex level. Well done Peter.
ReplyDeleteAlso, like you said, the official Cisco iSCSI config guide is not that well organized and, as usual, repeats itself a lot instead of giving out concrete, useful info like you do here. My respect to you.
The only thing that is still not that clear to me is where do you configure the other side for MUTUAL CHAP? I understand that this is a way for the initiator to actually authenticate the MDS, which is acting as its iSCSI target. Sadly, I don't have any equipment where I can try this myself.
dich vu ke toan thue tron goi tai quan 6
ReplyDeletedich vu ke toan thue tron goi tai quan 7
dich vu ke toan thue tron goi tai quan 8
dich vu ke toan thue tron goi tai quan 9
dich vu ke toan thue tron goi tai quan 10
dich vu ke toan thue tron goi tai quan 11
dich vu ke toan thue tron goi tai quan 12
dich vu ke toan thue tron goi tai hoai duc
dich vu ke toan thue tron goi tai son tay
dich vu ke toan thue tron goi tai thuong tin
dich vu ke toan thue tron goi tai ung hoa
dich vu ke toan thue tron goi tai phu xuyen
dich vu ke toan thue tron goi tai my duc
dich vu ke toan thue tron goi tai thanh oai
dich vu ke toan thue tron goi tai dan phuong
dich vu ke toan thue tron goi tai quoc oai
dich vu ke toan thue tron goi tai phu tho
dich vu ke toan thue tron goi tai soc son
dich vu ke toan thue tron goi tai nha be
dich vu ke toan thue tron goi tai can gio
dich vu ke toan thue tron goi tai hoc mon
dich vu ke toan thue tron goi tai cu chi
dich vu ke toan thue tron goi tai binh chanh
dich vu ke toan thue tron goi tai binh duong
dich vu ke toan thue tron goi tai bien hoa
dich vu ke toan thue tron goi tai hue
dich vu ke toan thue tron goi tai da nang
dịch vụ thay đổi nội dung đăng ký kinh doanh