Ontap Vif miscellany

A few things about networking on a FAS2050.

The FAS2050 has two ports per controller: e0a and e0b. There is a management port (with a wrench symbol) but I can find no trace of this from the software side of things.

From controller 1 I deleted all the vifs so that I would have to learn to recreate them via SSH. On the switch each port that the Netapp is plugged into is configured as follows:

interface FastEthernet0/2
 switchport trunk allowed vlan 100,302,303
 switchport mode trunk
 spanning-tree portfast

I decided that I ought to aggregate the two ports so I ran this command:

vif create multi dennis e0a e0b

The multi could have also been "single" or "lacp". Multi and LACP are forms of aggregation whereas single is an active / passive arrangement. I could have also added a "-b" switch to specify the type of balancing (IP, port, MAC or round robin - I think IP is default).

I then created the VLANs to correspond with the switch port settings:

vlan create dennis 100 302 303

I then decided I didn't need VLAN 302 and 303 for this test:

vlan delete dennis 302 303

Finally, I had to assign an IP address to the new interface. Hence:

ifconfig dennis-100 10.10.10.54 netmask 255.255.0.0

Cisco + NetApp + VMware p1

I have a free NetApp FAS2050, a very old Cisco 2950 100mb switch and a HP DL380 server. Can I make them work together?

My objective is to run ESXi 5.1 on the HP server with two guests (an Exchange 2010 server and a domain controller). The server only has 2 NICs unfortunately: one of them will be used for iSCSI and the other management. The NetApp must be configured in one big RAID 10 volume. They must communicate through the 2950.


The Cisco 2950

Log in as a super user:

en ↵
[password] ↵

The "show" command followed by "?" will display all the informational commands. To start off, good informational commands:

show running-config ↵
show interface status ↵ 

The switch that I picked up has most of its ports set to VLan 100, but I want VLan 302 because that is what the NetApp is set to. To create a VLan:

conf t ↵
vlan 302 ↵
name iSCSi ↵
Ctrl Z

Now to assign a port (or two) to the previously created VLan:

conf t ↵
int fa0/1 ↵
switchport mode access ↵
switchport access vlan 302 ↵
Ctrl Z

If you wanted to make that port a trunk you would have entered:

switchport mode trunk ↵

A trunk can accept multiple VLan traffic:

switchport trunk allowed vlan 100,302,303
 
I cheated a bit in the end. I had the config from the switch the NetApp used to be plugged into. From that I determined how the ports should be configured. This is the port configuration that I copied:

interface GigabitEthernet0/7
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,302,303
switchport mode trunk
spanning-tree portfast

After this the NetApp could be pinged and I could connect to it via putty.

DR Server Migration

The great virtualisation project mentioned in the last post hasn't really kicked off as I had envisioned and no hardware has made an appearance yet! From the outset this blog has been a roller coaster ride of exciting facts so apologies to my avid readers for the delay here.

Had a simple server move to do yesterday. We moved a switch, a storage server and its associated SAS-attached storage and an ESXi server from one data center to another. A NetApp FAS2050 was decommissioned and lies unused on our server room floor.

The decommisioned 2050 was the snapmirror target but was replaced by a hosted "vFiler". I intend on powering up the old one soon, but what do I have to do to it beforehand? Delete snapshots, that's what:

Show all snapshots on the current controller:
 
snap list

Show the status of the various snapmirrors:

snapmirror status

Delete a particular snapshot:

snap delete [volume_name] [snapshot name]

One of the snapmirrors to the decommisioned SAN was "busy" and so the snapshot could not be deleted. I used

snapmirror abort [source_filer]:[volume_name] [destination_filer:volume_name]

But it told me that it was already idle. So how could I delete a snapshot that was supposedly busy (but was not apparently involved in a snapmirror)?

Well it turns out that that volume was being snapmirrored to the new hosted vFiler and this was causing a lock. I'm not sure, since there are two snapshots for that volume, one for the old destination and one for the new destination, why this would happen but there you go.