Menu déroulant pour mobile

Monthly Archives: February 2015

Cisco ISLB Issue

Usually people are blogging on a certain topic because they want to share they knowledge with a certain protocol or product.

Today I ll take another approach with that fact and I will actually do the exact opposite. I have an issue with ISLB which allows load balancing for my iSCSI sessions. Today I will elaborate each steps needed to make it work. I have failed this configuration a LOT of time and I have followed the same steps over and over. I decided to make a blogpost about it to keep track of what I should do next time I want to configure it.

I did not play with VRRP yet but this can be an idea for a following blogpost.

The topology is the same as in my previous blog posts related to the MDS.



The difference here is that both MDS will have an iSCSI interface bound to their gigabit interface. (iscsi 1/1 mapped to gig 1/1).

ISLB on Cisco MDS

I will start from scratch and setup the infrastructure:

The outpout above prove us that the JBOD has registered to the fabric and that VSAN 10 is running on the E port between MDS01 and MDS02. Another proof is that the FCNS commands on MDS02 has the JBOD PWWN in its database.

Now we will setup Device-alias, we will activate a test zoneset on vsan 10 because ISLB requires an already active zoneset if you want to use the auto zone feature. If you do NOT have an active zone, you will have to manually perform the zoning configuration.


Now we can start our ISLB configuration. Again we will first configure the infrastructure and check that both iSCSI interfaces are reachable from the L2 domain.


ISLB configuration can now start and you will see it is very brief:

We first need to check the IQN of our servers.

\IQN Win 2008 IQN Win 2012


The configuration has been commited and MDS02 should have the ISLB configuration and the zoning configured on it:

All is all right here and none of the iSCSI initiator have yet logged in the fabric:

Let’s now activate debugs on both switches and try to initiate a Fabric Login from the iSCSI initiators (Server 01 first then Server 02)


MDS01 has performed a FLOGI onto itself on the VSAN10 and it has been mapped to interface iSCSI 1/1.

We can also see that the initiator has been correctly mapped to the JBOD

Let’s now try with server 02


Note that the MDS02 will only see 1 FLOGI and that MDS01 will see both FLOGI from its local FC Disk and from its iSCSI Initiator.

Both servers are able to map the drive and everybody is happy 🙂


As I mentionned at the beginning of the post, I did not played with VRRP on purpose and I will relate about that in a following blogpost 🙂

Cisco MDS Port-Security with Auto-Learning

I have been learning about Cisco MDS port-security recently and I have been struggling with this feature because it was different from what I expected. What I was expecting was something very similar (and easy) like the good old Ethernet Port-Security feature.

This is clearly not the case and I will show you how to configure a basic port-security using auto learning. You still can manually configure entries on the MDS but I wanted to check how to feature was interacting with CFS and how it was implemented.

We will use the same topology as the one we used previously:


VSAN 10 is the only VSAN created in the topology for clarity’s sake.

As every feature in NX-OS, there is a need to activate the feature on both MDS:

Since we want to play with the feature auto learning and CFS distribution , we need to enable it since it is not enabled by default.

As we can see above, if you enable the distribution of the port-security feature, this will not replicate to other switches in the fabric. Here the behavior is different than what we can experience when activating enhanced zoning within a storage fabric.

We do have to activate it on the other switches as well.

As soon as it is done we now need to learn some WWN into the fabric. As soon as you activate port-security for a particular VSAN, auto-learning is automagically (type made on purpose and copyrighted by Vik Malhi 🙂 ) started as well.

The output above shows us that the fabric has been locked for this particular VSAN and application.

In order to remove the lock and spread the configuration into the fabric, we need to commit the changes we’ve done here:

So, learning is enabled and a database has been activated as well. Same analogy as zoning here, there is a config database and active database. The active database has been replicated to the other switches but not the config database … Sounds like basic zoning right ? but the problem here is that the config database has NOT been replicated on MDS01 where we typed the configuration. So we need to replicate that active database to the config database on both MDS.

Let’s check what’s in the database first and :

On MDS01, we can see 3 WWN :

  • 21:00:00:18:62:8d:e8:b7(pwwn) is the pwwn owned by my JBOD and attached to the logging point 20:05:00:0d:ec:71:f1:40 on int fc1/5
  • 20:00:00:0d:ec:94:3c:c0(swwn) is the swwn owned by MDS02 and attached to the logging point 20:01:00:0d:ec:71:f1:40 on int fc1/1
  • 20:00:00:0d:ec:94:3c:c0(swwn) is the swwn owned by MDS02 and attached to the logging point 20:01:00:0d:ec:71:f1:40 on int fc1/2

The logging point here is just the switch wwn (swwn) where we type the commands, we can verify it

We will have the same kind of output on MDS02 :

The tricky part here is that you cannot copy the active database to the config database if auto-learn is running on the VSAN:

So we need to de-activate that feature:

After a copy run start we should be good to go !

But we have to bear in mind that since auto learning is now DISABLED, if any array tries to login within the fabric,it will be blocked 🙂

Feel free to comment or correct me by posting a comment below 🙂



If you now try to connect an Array to the fabric here is what you will have 🙂