Virtualization ESX Server Switch Storage Configure MTU 9000

ESX Server, IP Storage, and Jumbo Frames

With the release of VMware Infrastructure version 3.5, VMware added support for jumbo frames. Although the documentation states that jumbo frames “are not supported for NAS and iSCSI traffic”, jumbo frames for NFS and iSCSI does actually work. Here’s some information on getting it working.

How I Tested

Keep in mind that this is not an “officially supported” configuration (see the section on the “Official” Support Statement below), so use at your own risk. I will not be held responsible if you blow up your production environment trying to make jumbo frames work.

Here’s how I tested the use of jumbo frames for software iSCSI and NFS datastores:

  • For the physical switch infrastructure, I used a Cisco Catalyst 3560G running Cisco IOS version 12.2(25)SEB4.
  • For the physical server hardware, I used a group of HP ProLiant DL385 G2 servers with dual-core AMD Opteron processors and a quad-port PCIe Intel Gigabit Ethernet NIC.
  • For the storage system, I used a NetApp FAS940 running Data ONTAP 7.2.4.

The exact commands and/or procedures may be different for you depending upon the hardware and/or software versions that you’re running in your environment. Keep that in mind.

Configuring the Physical Switch

Fortunately for me, the Cisco Catalyst 3560G does indeed support jumbo frames. (Naturally, you’ll want to ensure that your switch supports jumbo frames.) Jumbo frames are not, however, enabled by default; they must be enabled using the following command in global configuration mode:

system mtu jumbo 9000

Note that 9000 bytes seems to be the generally accepted size for jumbo frames, so that’s what I used.

After running this command, you must reboot the switch. The change doesn’t take effect until a reload. Fortunately, IOS reminds you of this after you enter the command. Once the switch has rebooted, you can verify the MTU setting with this command:

show system mtu

This should report that the system jumbo MTU size is 9000 bytes, confirming that the switch is ready for jumbo frames. Now we’re prepared to configure the storage system.

Configuring the Storage System

Using FilerView, increasing the MTU on the appropriate network interfaces to 9000 bytes is as simple as going to Network > Manage Interfaces and then clicking the Modify link for the interface to be changed. Set the “MTU size” to 9000 (from the default of 1500), click Apply, and you’re ready to roll.

You can verify the settings in FilerView using Network > Manage Interfaces > Show All Interface Details, or by using the “ifconfig -a” command from a Data ONTAP command prompt.

Configuring ESX Server

There is no GUI in VirtualCenter for configuring jumbo frames; all of the configuration must be done from a command line on the ESX server itself. There are two basic steps:

  1. Configure the MTU on the vSwitch.
  2. Create a VMkernel interface with the correct MTU.

First, we need to set the MTU for the vSwitch. This is pretty easily accomplished using esxcfg-vswitch:

esxcfg-vswitch -m 9000 vSwitch1

A quick run of “esxcfg-vswitch -l” (that’s a lowercase L) will show the vSwitch’s MTU is now 9000; in addition, “esxcfg-nics -l” (again, a lowercase L) will show the MTU for the NICs linked to that vSwitch are now set to 9000 as well.

Second, we need to create a VMkernel interface. This step is a bit more complicated, because we need to have a port group in place already, and that port group needs to be on the vSwitch whose MTU we set previously:

esxcfg-vmknic -a -i 172.16.1.1 -n 255.255.0.0 -m 9000 IPStorage

This creates a port group called IPStorage on vSwitch1—the vSwitch whose MTU was previously set to 9000—and then creates a VMkernel port with an MTU of 9000 on that port group. Be sure to use an IP address that is appropriate for your network when creating the VMkernel interface.

To test that everything is working so far, use the vmkping command:

vmkping -s 9000 172.16.1.200

Clearly, you’ll want to substitute the IP address of your storage system in that command.

That’s it! From here you should be able to easily add an NFS datastore or connect to an iSCSI LUN using jumbo frames from the ESX server.

“Official” Support Statement

Officially, jumbo frames are only supported by VMware for use by virtual machines. Technically, VMware does not support the use of jumbo frames for the software iSCSI initiator or for use with NFS datastores. At least, that’s my understanding.

So, feel free to tinker around with jumbo frames for IP-based storage, and when VMware adds official support for it in the future—I can’t imagine why they wouldn’t—then you’ll be able to hit the ground running with the configuration steps necessary to make it work.


Data link from : http://blog.scottlowe.org/2008/04/22/esx-server-ip-storage-and-jumbo-frames/

Posted in 標籤: | 0 意見

Sendmail Server IP In RBL List 會造成 Sendmail Server 誤判

對方主機給的訊息:RBL matched Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=210.68.43.7
Sendmail主機Log卻產生誤判為:dsn=5.1.1, stat=User unknown,
造成管理者判斷錯誤,無法發現自已主機被列入RBL Blocklist,無法即時處理。

對方主機 Log
2008-08-20 14:43:49 H=(mailserver) [210.68.43.7]:49842 I=[210.68.43.8]:25 F= rejected RCPT : RBL matched Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=210.68.43.7

Sendmail Log
Aug 18 14:43:49 mailserver sendmail[3463]: m7I6hnH2003461: to=, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=134598, relay=domain.com.tw. [210.68.43.7], dsn=5.1.1, stat=User unknown

Aug 18 17:05:06 mailserver sendmail[32762]: m7I9566c032758: to=, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=124478, relay=domain.com.tw. [210.68.43.7], dsn=5.1.1, stat=User unknown

Posted in 標籤: | 0 意見

Freebsd add new SCSI Disk

#camcontrol all

#disklabel -r -w da1s1 auto

# disklabel -e da1s1
# /dev/da1s1c:
type: SCSI
disk: IBM
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 1114
sectors/unit: 17912412
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0

8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 17912412 0 unused 0 0 # (Cyl. 0 - 1114*)
~

# newfs /dev/da1s1c
Warning: Block size and bytes per inode restrict cylinders per group to 89.
Warning: 3492 sector(s) in last cylinder unallocated
/dev/da1s1c: 17912412 sectors in 4374 cylinders of 1 tracks, 4096 sectors
8746.3MB in 50 cyl groups (89 c/g, 178.00MB/g, 22144 i/g)
super-block backups (for fsck -b #) at:
32, 364576, 729120, 1093664, 1458208, 1822752, 2187296, 2551840, 2916384,
3280928, 3645472, 4010016, 4374560, 4739104, 5103648, 5468192, 5832736,
6197280, 6561824, 6926368, 7290912, 7655456, 8020000, 8384544, 8749088,
9113632, 9478176, 9842720, 10207264, 10571808, 10936352, 11300896, 11665440,
12029984, 12394528, 12759072, 13123616, 13488160, 13852704, 14217248,
14581792, 14946336, 15310880, 15675424, 16039968, 16404512, 16769056,
17133600, 17498144, 17862688


#mount /dev/da1s1c /data1

#df -h

可參考freebsd handbook作法:
http://www.freebsd.org/doc/zh_TW/books/handbook/disks-adding.html

Posted in 標籤: | 0 意見