Header image

Das Blinken Lichten

Networking, Virtualization, Docker, Kubernetes, DevOps, Automation, etc, etc,
etc
HomeAboutContact MeTech Field Day Disclosure
Subscribe to feed
Search Results
Your search for cisco mds returned the following results.

Basic Cisco MDS configuration

January 19, 2011 3:29 am in Cisco (Networking) | 8 comments
As I laid out in my last post, these are the basic steps for the SAN
configuration of a Cisco MDS series switch. They are.

1. Create the VSAN number you wish to use (1 is the default, not
recommended to use the default for production SAN traffic)
2. Add interfaces to your VSAN (just like you do with a VLAN)
3. Do any interface configuration needed on the FC interfaces (Just turn them
on in most cases)
4. Verify the cabling and ensure that you have SAN connectivity
5. Create Aliases for WWNs (makes life easier)
6. Create required zones
7. Add members to your zones (I recommend using PWWNs)
8. Create a zoneset (I think Brocade calls this a config)
9. Add your zones to your zoneset
10. Activate the zoneset on the fabric

So lets walk through them one at a time and show the associated

configuration. Ill use my same old color coding conventions.

-Insert your relevant information between <>
-Console prompts are shown in green

1.Create the VSAN number you wish to use (1 is the default, not
recommended to use the default for production SAN traffic)
MDS(config)# vsan database
MDS(config-vsan-db)# vsan <new VSAN number>
MDS(config-vsan-db)# vsan <new VSAN number> name <VSAN name>
MDS(config-vsan-db)# exit

-Add interfaces to your VSAN (just like you do with a VLAN)

MDS(config)# vsan database
MDS(config-vsan-db)# vsan <VSAN number>
MDS(config-vsan-db)# vsan <VSAN number> interface <FC Interface>
MDS(config-vsan-db)# exit

-Do any interface configuration needed on the FC interfaces

MDS(config)# interface <FC Interface>
MDS(config-if)# no shutdown
MDS(config-if)# switchport mode <Either Auto, or a set type (E,F, etc.)>
MDS(config-if)# exit

-Verify the cabling and ensure that you have SAN connectivity
Your on your own here. As with anything fiber, if you dont have link, make
sure you have the pair flipped correctly from SFP to SFP.

-Create Aliases for WWNs (makes life easier)

MDS(config)# fcalias name <name of the Alias> vsan <VSAN number>
MDS(config-fcalias)# member pwwn <WWN>
MDS(config-fcalias)# exit

-Create required zones and add members

MDS(config)# zone name <name of zone> vsan <VSAN number>
MDS(config-zone)# member fcalias <alias name 1>
MDS(config-zone)# member fcalias <alias name 2>
MDS(config-zone)# exit
(note: if you didnt want to make aliases, you could use the keyword pwwn
rather than fcalias and directly input the WWN)

-Create a zoneset (I think Brocade calls this a config) and add the zones to
the zoneset.
MDS(config)# zoneset name <name of zoneset> vsan <VSAN number>
MDS(config-zoneset)# member <zone 1>
MDS(config-zoneset)# member <zone 2>
MDS(config-zoneset)# member <zone 3>
MDS(config-zoneset)# exit

-Activate the zoneset on the fabric

MDS(config)# zoneset activate name <zoneset name> vsan <VSAN
number>

Conclusion
And thats it. It goes without saying, but save your config when you are
done.

SHARE THIS:
TwitterEmailPrintLinkedIn
Tags: MDS, SAN

FCIDs, WWNs, Zoning, and VSANs

January 18, 2011 5:54 am in Cisco (Networking) | 23 comments
It occurred to me while writing the NPV and NPIV article (coming up shortly)
that there was a lot of the fiber channel protocol which I hadnt covered. That
being said, Im going to talk a little bit more about it here. Specifically well
discuss FCID, WWNs, zoning, and VSANs

So if you look at the terms we listed in the last post. You might be scratching
your head and wondering what the difference is between WWNs and
FCID/NPIDs. This was something I had trouble understanding initially as well.
For starters, lets agree that well simplify and call NPIDS/FCIDS just FCIDs
going forward. The terms are used interchangeably, but for the sake of
clarity, Ill just call them FCIDs going forward.

That being said, lets talk about about the FCID. The FCID is a 24 bit (3 byte)
field used to route frames through a FC network. Lets walk through each
byte of the FCID.

1st byte Domain ID. The Domain ID is given to each FC switch in a fabric
and must be unique for each switch.

2nd byte Area ID. The Area ID is very similar to the 3rd byte. In fact, in
Cisco documentation, youll find it called the exact same thing as the 3rd
byte. The Area ID is used to identify an N type port that is connected to a
switch.

3rd byte Port ID. The Port ID is used to identify a single FC object on the FC

fabric.

In a SAN each device that is going to talk on the fabric has a WWN and a
FCID. The WWN is very much like a MAC address in Ethernet speak. Each
WWN is globally unique with some exceptions. There are instances where
devices allow an administrator to manually configure a WWN but we wont be
discussing those instances. For basic understanding, lets say that each
WWN is globally unique. So an HBA that had multiple ports would have a
WWN for itself, and then PWWN (port WWNs) for each one of its ports.
Additionally, each port on a fabric switch has a FWWN (fabric WWNs) which
are sometimes also called FPWNNs (fabric port WWNs).

So, a device talking on the fabric has multiple identifiers. Still with me?

The FCID is used in routing through the fabric. So in a FC frame there is S_ID
(Source ID) and a D_ID (Destination ID) field. These are populated with the
appropriate FCID to facilitate traffic through the fabric and to the correct
node.

So what is the WWN used for? Enter zones Put basically, for two devices to
communicate, they MUST be in the same FC zone. Zones are primarily a
security practice. In reality, if everything was in the same zone, and in the
same fabric, everything could talk to everything. That isnt to say that all the
LUNs would show up on all the servers, its just implying that it would be
possible. Zoning is a fabric configuration, not a disk array to host mapping
configuration. So lets go over a quick example so that we are all on the
same page. Take the diagram below as an example. (Side note: Ive had this
wonderfully large whiteboard in my home office for almost a year and have
hardly ever used it. I will waste resources no longer, look forward to more
whiteboard pictures with my hard to read hand writing.)

photo

So as we can see here (in my glorious white board depiction) we have two
servers. A backup server that needs access to the disk array for its local disk,
and access to the tape library to run backups. We also have a file server that

just has access to the disk array. It doesnt need access to the tape library
since the backup server is accessing the file servers files over the network,
and then putting them to tape itself. Thats a pretty simple example of
zoning.

To be clear, you dont always have to use WWNs to create zones. You can
also create zones based on
-PWWN or FWWN
-FC Alias (Basically, a name associated with a WWN)
-FCID
-Physical interface

Cisco recommends using a PWWN to do zoning. This ties an HBA to a zone

rather than a physical port to a zone.

Another concept of logical SAN separation is VSANs. While its usually viewed
as a Cisco fabric feature I believe its recently been approved as a global
standard. VSANs are much like, you guessed it, VLANs. A VSAN allows you to
have logically separate fabrics without actually having to have different
physical fabrics.

photo5

(Additional side note: Im going to get colored markers to make this more
straight forward)
As you can see in the drawing above, all four devices hang off of the same
physical fabric, but since they are in separate VSANs, they are unable to
communicate.

So lets take a step back and talk about the entire Cisco SAN configuration.
We spoke about zones and VSANs, now lets talk about how to configure
them. This is the basic list I use when talking about SAN config on an MDS.

1. Create the VSAN number you wish to use (1 is the default, not
recommended to use the default for production SAN traffic)
2. Add interfaces to your VSAN (just like you do with a VLAN)
3. Do any interface configuration needed on the FC interfaces (Just turn them
on in most cases)
4. Verify the cabling and ensure that you have SAN connectivity
5. Create Aliases for WWNs (makes life easier)
6. Create required zones
7. Add members to your zones (I recommend using PWWNs)
8. Create a zoneset (I think Brocade calls this a config)
9. Add your zones to your zoneset
10. Activate the zoneset on the fabric
(Dont worry Ill show you how to do each one of these steps in the next
article)

Youll notice that we introduced the term zoneset in the steps. We havent
talked about them yet, so lets take a brief moment to discuss them. There
are some basic rules I like to think of when talking about zones/zonesets that
do a pretty decent job defining the term. They are..

-Zonesets are a container for one or more zones in the fabric

-Zones need to be a member of a zoneset in order to be used. That is to say,
zones once configured arent actually on until they are applied to a zoneset
and the zoneset is activated in a particular VSAN.
-Zones can be in more than one zoneset container. That is, a zone can
belong to multiple zonesets.
-Devices (WWNs) can be members of multiple zones
-Only one zoneset can be active at one time in any given VSAN
-If an alias or WWN is not assigned to a particular zone, it is a member of the
default zone (1).

-If zoning isnt active at all, then all devices are default to being a member of
the default VSAN.

So if we looked at the big picture, the layout would look like this.

photo7

I probably shouldnt have used VSAN 1 in the diagram since thats the default,
but you get the idea.

Please keep in mind that we are talking about a very basic configuration here.
There are far more advanced topics/concepts in regards to all of these
functional items. As you get more comfortable with the configuration, you
can start playing with the additional functionality.

As I reread these posts, Im starting to see they are a bit scatterbrained in

regards to flow. I apologize for that; Ill do my best to keep these flowing as
Im sure that makes them easier to read. Once we get all the basic FC
understanding out of the way, I think the actual config posts will flow
together nicely.

This is my outline for the next few posts

-CLI config of an MDS (how to do what weve been talking about)
-NPV and NPIV
-Nexus 5k/2k config (just the base config)
-Nexus 5k/2k config (Connecting to the MDS and the IP network)
-Nexus 5k/2k config (Connecting to the hosts (CNAs))
-Follow up posts to answer any questions I see coming through in the
comments.

SHARE THIS:
TwitterEmailPrintLinkedIn1
Tags: MDS, SAN

SAN Terminology FCOE Nexus 5k/2k

January 16, 2011 7:03 am in Cisco (Networking) | No comments
So if youre working Cisco at all these days, youve probably heard of the
Nexus platform. Ive had some exposure to the 7ks, but more recently weve
been doing some testing with the 5k/2k platforms. The 5k is a layer 2 switch,
that allows FEX (Fabric Extender) modules to connect to them. The FEX in
this case, would be the Nexus 2k. I like to think of the 2k as a line card in a
6500 chassis. It has ASICs and is very much a layer 2 switch, but the brains
of the operation are the 5k to which the 2ks connect. To be clear, there is NO
configuration done on the 2ks. When the 2ks are connected to the 5ks, and
the 5ks are configured for the FEXs, the ports from the FEX show up in the 5k
configuration. The idea is that the 5k could be a middle of row data center
solution with multiple 2ks hung off of it in adjoining racks. This reduces the
complexity of access layer switches since the only real configuration is on the
5k.

The other benefit of the 5k/2k solution is that they support 10 gig FCOE. That
is, with a fiber module in the 5k, I can connect the 5k to a SAN switch (MDS in
most cases) and then extend a VSAN to the 5k. The 5k can then associate
the VSAN to a VLAN. The access ports on the 2k are then configured as
trunks, and allow traffic from both the SAN VLAN and the data VLAN (which is
also connected to the 5k) to traverse a single link to the server. The server
then uses what are called CNAs (Converged Network Adapter) to split the FC
and IP traffic out and deliver it to the host. So rather than having dual NICs
(or more), and dual HBAs, we now have dual CNAs that deliver redundant
paths to both the IP network as well as the SAN fabric.

It had been awhile since I worked with fiber channel, so to wrap up this post
Im going to define some of the basic terms/acronyms you should know about
when working with this sort of technology. Some will be obvious to many of
you, but Im going to cover all of the basics. In following posts I plan on
discussing NPV and NPIV, 5k/2k configuration, and troubleshooting steps for
FCOE pertaining to the Nexus platform.

SAN/FC Terms and Acronyms

SAN Storage Area Network
FC Fiber Channel
N(ode) Ports End node port, either an HBA on a server, or a target on a
storage array
F(abric) Ports A port on a FC switch that is connected to the N port
E(xpansion) Port A port on a FC switch that is connected to another FC
switch
ISL Inter Switch Link. The connection between two E ports
WWN World Wide Number. A globally unique 64 bit number used to identify
nodes on a SAN fabric
FLOGI The fabric logon process
N Port address Also called, N Port ID. A 24 bit address that is automatically
assigned to a WWN during the fabric login process. The N port address is
also commonly referred to as the Fiber Channel ID.

SHARE THIS:
TwitterEmailPrintLinkedIn
Tags: FCOE, Nexus, SAN

CONNECT W/ JON LANGEMAK

LinkedInTwitterEmailRSS

cisco mds
Search
FOLLOW ME ON TWITTER

My Tweets
CATEGORIES

Automation (2)
Cisco (Networking) (171)
Compute (1)
DevOps (29)
DNS (1)
docker (4)
F5 (16)
golang (1)
Google (4)
Kubernetes (2)
Links (1)
Linux (15)
Microsoft (5)
OpenStack (3)
Opinion (1)
Python (3)
Rants (1)
SDN (9)
Storage (8)
Tech field day (3)
Uncategorized (38)
Virtualization (6)

VMWare (23)
VOIP (6)
TAGS

AnyConnect ASA BGP CCIE CentOS CME CoreOS CSD docker Easy VPN EIGRP
FCOE FHRP IAS IGP ISCSI kubernetes LeftHand LISP LTM MDS MPLS Multicast
NAT Nexus NFD10 NSX OpenFlow OpenStack OSPF QOS RADIUS RedHat
Routing saltstack SAN Spanning-tree Storage Subnetting Switching TISHK VCP
VMWare WAAS WebVPN
Subscribe to feed

Powered by WordPress and Tarski

:)