Jumbo frame stuck at 8165 bytes or larger

Model: Macbook Pro Retina 15" Mid 2012, OS X 10.9
NIC: thunderbolt Ethernet
Issue:
I enabled Jumbo frame in Network > Advance > Hardware > Manaually > MTU 9000,
and then i tried the ping command in Terminal to verify the functionality.
The following 192.168.16.13 is another LAN client.
1.
XXX$ ping -D -s 8100 192.168.16.13
PING 192.168.16.13 (192.168.16.13): 8100 data bytes
8108 bytes from 192.168.16.13: icmp_seq=0 ttl=128 time=1.255 ms
8108 bytes from 192.168.16.13: icmp_seq=1 ttl=128 time=1.014 ms
8108 bytes from 192.168.16.13: icmp_seq=2 ttl=128 time=0.953 ms
^C
works fine
2.
XXX$ ping -D -s 8200 192.168.16.13
PING 192.168.16.13 (192.168.16.13): 8200 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
Request timeout for icmp_seq 0
^C
doesn't work!
So i tried some more ping to find out the critical size on my Mac, and turned out that when the ping size is 8165 bytes or larger, the ping fails:
1.
XXX$ ping -D -s 8164 192.168.16.13
PING 192.168.16.13 (192.168.16.13): 8164 data bytes
8172 bytes from 192.168.16.13: icmp_seq=0 ttl=128 time=0.901 ms
8172 bytes from 192.168.16.13: icmp_seq=1 ttl=128 time=0.974 ms
^C
--- 192.168.16.13 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.901/0.938/0.974/0.036 ms
XXX$ ping -D -s 8165 192.168.16.13
PING 192.168.16.13 (192.168.16.13): 8165 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
Request timeout for icmp_seq 0
^C
Just to figure out is this issue caused by my Mac or the responder (another LAN client), i launched my wireshark to sniff packets.
And the wireshark told me when the ping size is 8165 or larger, my Mac actually did NOT send out the icmp packets.
So now it seems the issue is cuased by my Mac since it didn't send out the packets...
Is there anyone have any related experience?
Thanks for any kind of feedbacks in advance!

Hi rack0 tack0,
Thanks! and yes i did read this article before.
As this article suggested, that the max icmp size supported by Mac OS X is 8184, and i got stuck at 8164.
20 bytes is not a big issue, but i just want to figure out what's making it wrong.
Thanks again!
any other suggestion?

Similar Messages

SG 300-28 Switch - Jumbo Frames Problem.

I just got the SG 300-28 28 port switch tonight and got it up and running however, i've encountered a problem regarding jumbo frames. In the documentation and product brochures, it states the SG 300 switches supports jumbo frames up to 10k. When I first setup the switch and enabled jumbo frames, i was getting very slow speeds in my network transfers (800kb/s !!!). All the workstations are running Intel PCIE nic cards with jumbo frames enabled at 9014 bytes. After some troubleshooting, i lowered the frame size to 4088 bytes and everything returned to normal with fast speeds.
I had a suspicion that it might be the switch that is causing the network slowdown with 9k frames; I went ahead and enabled the 9k jumbo frame settings on my NICs again and started to ping other workstations on the network using the "don't fragment" flag. It turns out, the largest packet that i can send out is 8972 bytes. This is a little far from 10k frames that is stated in the documentation and brochures. Please correct me if i'm wrong, but it seems that i've stumbled into a bug in switch.
Time for a firmware update?

Hi Dickson C,
Interesting query.. TCP, UDP and ICMP packet overhead are fairly negligible according to the information below i would think about 94 bytes for ethernet plus tcp overhead.
The switch would internally label the ethernet frame to identify what VLAN the frame is in (even Vlan 1), so an extra 4 bytes would be used within the switch for that.
Ethernet frame format:
6 byte dest MAC addr
6 byte src MAC addr
[4 byte optional 802.1q VLAN Tag]
2 byte length/type
46-9014 byte data (payload)
4 byte CRC
Ethernet overhead bytes:
12 byte intergap + 8 preamble + 14 header + 4 trailer = 18 bytes/packet w/o 802.1q
12 byte intergap + 8 preamble + 18 header + 4 trailer = 22 bytes/packet with 802.1q
TCP encapsulated in Ethernet:
Assuming no header compression (e.g. not PPP)
Add 20 IPv4 header or 40 IPv6 header (no options)
Add 20 TCP header
Add 12 bytes optional TCP timestamps
TCP overhead can be 52 bytes
Ethernet + TCP overhead around 52+22 bytes = 74 bytes
Your Intel ethernet NIC supports around 9500-byte, so the datasheets from intel suggest for a jumbo frame , but you have it enabled at 9014 bytes.
So your NIC enabled at 9014 bytes - 74 bytes for Ethernet and TCP packet overhead= approximately 8940 bytes of data.
You say you are getting packet data throughput around 8972 bytes.
Check my maths, I have made a few assumptions. What you reckon, worth a call to the Small Business Support center to double check, please open a case and report back with the results. I really may be way off in some of my assumptions.
regards Dave
http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

Airport Extreme with Gigabit Ethernet - Does it have jumbo frame support?

Please, can I get definite answer to this question? I do not need speculations as I read some reviews already. Can we have Apple finally put complete specification of the product rather than "popular one" with attachement of protocol numbers?
I just need simple answer possibly from Apple engineering team to the following questions:
1. Does current Airport Extreme have support for jumbo frames (everything above 1500bytes per frame)? (if one does not know what that is them perhaps understanding acronym "MTU" can help a bit)
2. If there is support then what is the maximum supported size of jumbo frame? (Some products do not go above 6k and I read some statistics that traffic somwhere is usually 66% at about 4k jumbo frames and above that there is not much...)
3. If there is no support then does Apple plan on update for this (firmware or hardware) in the future?
Please, do not tell me that someoene ran something with jumbo frame and it worked as I tried yesterday LaCie Ethernet drive with supposedly setup (I set it myself) of jumbo frame 4k and on soft reboot of the drive it worked when connected to Airp[ort Extreme, but after hard reboot the disk is not visible anymore. I will recover the disk, but I need to understand if I have chance of using jumbo frames that tremendously improve performance with large files (e.g. try movies stored for AppleTV on network drive) when using Airport Extreme with its gigabit Ethernet... or that is just Gigabit Ethernet for product marketing purposes only.
I just need reliable answer by product specification that should be on paper at Apple, but it is not so I hope that one of guys here has access to some engineering team.
Thank you,
Maciek Samsel

The spec. on the chip used by Apple support your conclusion.
BCM5395 Features
Complies with IEEE802.3, IEEE802.3u, IEEE802.3ab standards
5 10/100/1000Mbps Auto-Sense RJ45 ports supporting Auto-MDI/MDIX
All ports Support Full/Half Duplex transfer mode for 10/100Mbps and Full Duplex transfer mode for 1000Mbps
Port-based and MAC-based VLAN
IEEE 802.1Q-based VLAN with 4K entries
Port-based rate control
Port mirroring
Compact field processor (CFP)
512 rules
Filtering, classifications, remarking, and priority actions.
Priority modification on egress
DOS Attack Prevention
Loop detection for unmanaged configurations with Broadcom’s patented LoopDTech™ technology
CableChecker™ with unmanaged mode support
Double tagging
IEEE 802.3x programmable per-port flow control and back pressure, with IEEE 802.1x support for secure user authentication
4K entry MAC address table with automatic learning and aging
128-KB packet buffer
128 multicast group support
Jumbo Frame support up to 9728 byte

Does Airport Extreme (2010) support Jumbo Frames?

I changed my MacBookPro, my iMac27" and my NAS to Jumbo Frames (first try 9000 MTU, then 4074). But there was no faster copy speed. Now I wonder whether my switch "Airport extreme (from 2010)" is able to work with Jumbo Frames. As far as I see, on the Airport extreme there is no possibility to change the MTU.

Yes. The 2010 (actually 2009) Gigabit AirPort Extreme base station incorporates a Broadcom BCM5395 chip that supports Jumbo frames up to 9728 bytes.

Airport Utility on iMac with Jumbo Frames can't read Airport configuration

My 24" iMac is connected to a Netgear switch (GS608 rev2) that supports Ethernet jumbo frames. My GigE Airport Extreme base station is also connected to the Netgear switch and is acting as a gateway for my cable modem connection. Here's the rough wired layout:
iMac--Netgear--Airport--Cable Modem
The iMac has jumbo frames enabled (MTU=9000) and can communicate fine to the Internet and other devices on my local LAN (including a Netgear NAS box also with Jumbo frames enabled).
Airport Utility on the iMac starts and discovers my 3 Airports (1 extreme + 2 express) but if I double click on one of them to configure it, the window says "Reading the AirPort Extreme configuration..." and hangs there never bringing up the setup screen. Printer jobs to the shared USB printer that worked before Jumbo Frames were enabled on the iMac are also failing. The same happens for the 2 Airport Express as well although I can still steam Airtunes music to them.
Any ideas what might be wrong ? Do the airports have problems negotiating with jumbo frame enabled Macs ?
My wireless MBA with std MTU can still communicate fine with the Airports.
Thanks,
E
Message was edited by: Gaijin Kuma

None of Apple's Airports support jumbo frames.
The networking chip that Apple uses in the Airport Extreme has the capability to support jumbo frames, but it isn't an option that Apple has chosen to expose to the user. So you can't reliably use the Airports on a jumbo frame enabled subnet.
The likely reason the Internet is still working is that, unless your uploading, it's unlikely the iMac sent a packet in excess of 1500 bytes to the Airport. The Airport is always sending 1500 byte packets which your iMac wold receive fine regardless of what the MTU was set (well, unless it was set below 1500).
Some people do report success but I would be wary of their results, they may not have down/upped the interface so the MTU may have been listed as changed, but not yet actually changed to the larger MTU. No-one has actually posted a tcpdump -e capture showing an Airport actually sending/receiving packets in excess of 1500 bytes.
Some more links to this discussion topic-
http://discussions.apple.com/thread.jspa?threadID=1085469
http://discussions.apple.com/thread.jspa?threadID=1222397
http://www.smallnetbuilder.com/content/view/30188/96/

LwIP Socket Jumbo Frame

Running a VC707, the HW design is based on the BIST project. I updated the TEMAC to have 32k FIFO buffers. SDK 2014.2.
For my SDK application I have 2 designs.
1. Socket based echo server from XAP1026
2. Default echo server example project
Following XAP1026 for configuring LwIP for jumbo frames I can get my RAW API design to send jumbo frames (8192 length packets).
My socket echo server still only sends 1500 byte packets with the same configuration (only difference is socket vs. RAW mode).
Has anyone overcome this issue before? Or has anyone information on configure jumbo frames for LwIP in socket mode.
Found this older post that seems similar yet different, but it is like 3 years old so I'm not sure if it is still accurate:
http://forums.xilinx.com/t5/Embedded-Development-Tools/Trying-to-send-larger-packets-using-UDP-XAPP1026-UECHO-test/m-p/16237?query.id=22717

Xilkernel Configuration
BEGIN OS
PARAMETER OS_NAME = xilkernel
PARAMETER OS_VER = 6.1
PARAMETER PROC_INSTANCE = microblaze_0
PARAMETER config_named_sema = true
PARAMETER config_pthread_mutex = true
PARAMETER config_sema = true
PARAMETER config_time = true
PARAMETER debug_mon = true
PARAMETER max_bufs = 100
PARAMETER max_pthreads = 100
PARAMETER max_readyq = 100
PARAMETER max_sem = 25
PARAMETER max_sem_waitq = 100
PARAMETER pthread_stack_size = 32768
PARAMETER stdin = axi_uart16550_0
PARAMETER stdout = axi_uart16550_0
PARAMETER sysintc_spec = microblaze_0_axi_intc
PARAMETER systmr_dev = axi_timer_0
PARAMETER systmr_interval = 1
PARAMETER verbose = true
END
LwIP Configuration
BEGIN LIBRARY
PARAMETER LIBRARY_NAME = lwip140
PARAMETER LIBRARY_VER = 2.1
PARAMETER PROC_INSTANCE = microblaze_0
PARAMETER api_mode = SOCKET_API
PARAMETER ip_frag_max_mtu = 9000
PARAMETER mem_size = 524288
PARAMETER pbuf_pool_bufsize = 9700
PARAMETER tcp_mss = 8060
PARAMETER tcp_snd_buf = 32768
PARAMETER temac_use_jumbo_frames = true
END

Linksys SE2800 and jumbo frames

Does the Linksys SE2800 gigabit 8 port switch support jumbo frames? Anyone have this switch? Any issues? Looking to replace a netgear gigabit switch that likes to forget that it has gigabit machines connected to it.

Hi Michael,
Actually had a chat with a colleague at linksys regarding your question, but he referred me to a datasheet, which left me with the question I started with. The technician said yes it suppported Jumbo frames but he could post me nothing in black and white..
Why not look at the Cisco Small Business umnanaged product the SG100D-08. It offers as the datasheet suggets;
Peace of mind:
All Cisco 100 Series switches are protected for the life of the product by the Cisco Limited Lifetime Hardware Warranty
Also, even though an unmanaged product, this series supports such features as;
1. Green Energy—Efficient Technology
The Cisco SG 100D-08 switch supports Green Energy-efficient
Technology. It can enter sleep mode, turn off unused ports, and adjust
power as needed. This increases energy efficiency to help businesses use
less power and save money.
2. Jumbo Frame Support
The Cisco SG 100D-08 switch supports frames up to 9,000 bytes called
jumbo frames. Jumbo Frame support improves network throughput and
reduces CPU utilization during large file transfers, such as multimedia files,
by allowing larger payloads in each packet.
regards Dave

Dual nic NAS and Jumbo Frame

I am posting this on the server area because I doubt I am going to get an answer anywhere else.
I have a linux based NAS running netatalk and avahi (afp server and bonjour) with two nics and I have a brand new Mac Pro with two NICS. What I want to do is run a crossover cable between the NAS and the Mac Pro in addition to both being plugged into the normal network. The normal network would have 1500 byte mtu so my internet performance and all of the various vintages of print servers work ok. The dedicated network would have jumbo frames. As we get more Mac Pros, we would add a switch and more machines to this secondary jumbo frame network.
That in theory should work fine (I have done it with other operating systems). My quandary is how to get the Mac to always connect to the NAS via the Jumbo nic and not through the other nic? The Mac learns of the server via Bonjour, so how do I tell it to prefer the "appearance" of the server on the jumbo NIC vs the appearance on the normal network. I know with WINS or DNS I can override the name resolution with a LMHOSTS or hosts file entry, can I do the same with Bonjour?
Thanks for any help or any pointers in the right direction!

I think you are misguided in your assumption that I am not intimately familiar with TCP and don't know what I am talking about.
TCP does not "negotiate" MSS, it advertises the MSS of each side to the remote in the 3 way handshake. It is perfectly acceptable to have asymetric MSS values. TCP does NOT NEGOTIATE a common MSS size. On a LAN, this will result in a functional communication. UDP however does not have such mechanisms and will fail.
TCP will also not function properly in the scnario of my local workstaion with jumbos enabled communicating with a distant endpoint that also has jumbos enabled across a transit network that does not support the maximum MSS used by one of the end stations. For giggles let's say the far end is FDDI and has 4k frame size. Our transit does not support frame sizes larger than the "natural" frame size of 576 bytes. We will use a 4k frame size from me to the remote and a 9k from the remote to me. If the remote sends to me it can use the full 4k MSS of token ring because its less than my MSS. In the reverse my workstation would send 4k frames back to the token ring station. Successful communication would then depend on path MTU and intermediary routers to send ICMP type 3 code 4 messages to signal back to our end stations to reduce our MSS (assuming the DF bit is set on our traffic or the transit router is incapable of fragmentation).
This is perhaps a bit of a flippant example in that nobody would be running FDDI or Token ring anymore, but random entities on the internet will run jumbo frame and perhaps some other l2 technology we aren't familiar with.
Did you ever deal with someone on a token ring segment trying to hit 3Com's web site when it was fddi or token ring? I have on several occasions. I also see this with VPNs all the time. Cisco's genius recomendation is to reduce your MSS on your server as some of their products don't support PMTU. I have had a Cisco <-> Juniper VPN where transfers worked one way because the Juniper would silently strip the DF bit from the packet and fragment it and the Cisco router (38xx) wouldn't do the same in the reverse direction. I also went through **** with the Nortel Contivity VPN devices while they sorted out what to do with the whole MTU negotiation issue.
I have spent many hours of my life pouring through sniffer captures because of mismatched MTUs. Let's not forget the old days of FDDI backbones with ethernet segments bridged across them and FDDI attached servers... mismatched buffers... no thanks.
I therefore don't want to waste my time troubleshooting some bizzare networking issue when there is a perfectly valid way of solving the issue for absolutely minimal expense. I am moving large files here (certainly large enough to get well out of TCP slow start), we easily saturate the full gig link minutes at a time and a saturated gigabit link at standard frame size is inefficient due to the interpacket gap which is locked at 96 bit times for ethernet and the 40 bytes of TCP/IP header plus whatever application payload is prepended per packet on each link. Cutting the number of TCP/IP headers and (probably more importantly since most decent nics do checksum offload these days) application layer headers also reduces load on both client and server.
On large sequential bulk data transfers jumbo frame effectively increases performance and reduces overhead. Period. I have implemented it from the early days of Alteon hardware in Sun servers through Juniper EX products last week. Every iSCSI implementation I run into is jumbo frame based for those exact reasons.
That being said, I don't need to restrict anything. All I want to do is to override bonjour/mDNS for this particular host such that the Pro always communicates over the jumbo segment. This is easily accomplished in windows with an LMHOST entry or in a unix environment with a HOSTS file entry. Is there some way to override bonjour from the client side? I'm ok even statically defining the services presented by bonjour on this host.
I am also willing to force all bonjour requests through a DNS server, however Apple doesn't have any decent documentation on how this is accomplished in an enterprise environment.

Jumbo Frame support

Hi all
I have a vendor that wants to run an application called mirrorview to do a bandwidth test for a new application; the only requirement is that I support jumbo frames on my uplinks. I do not currently have my ports configured to support jumbo frames, are there any benefits or drawbacks to supporting jumbo frames? If so please post so I can weigh those options before I reconfigure my uplinks.
TIA Rodney.
FYI I am running 6500 hybrid in the core , and 3550-xx at the edge.

If jumbo frames are enabled only on uplinks but not all the way between two systems, then the end systems won't take any advantage of jumbo frames. There is no drawbacks of jumbo frames as such as far as I know, but some pitfalls.
Jumbo frames are any frames bigger than standard Ethernet frames (1518 bytes of user-visible part). And some platforms implement jambo frames as big as 9216 bytes (Cat 6500), while others (e.g. Cat 2950) are limited to baby-jumbo of 1530 bytes. So when you enable jumbo frames you must be sure that the size of jumbo frame is consistent across all your systems including servers and client PC's connected to your network.
Another pitfall is that if you enable jumbo frame on any IP-layer interface this will automatically change IP MTU. If you're running OSPF and jumbo frames are enabled only on some systems connected to a subnet but not on other systems from the same subnet OSPF adjacencies will not form until you specify 'ip mtu 1500' on jumbo-enabled systems. As soon as you do this, effect of jumbo frames for IP traffic will be void (but it might still be necessary for things like MPLS). So be sure that systems on common subnet have same MTU.
Routing problem is easy to detect, more general problem is that travelling across L2-only path there is no way for switches to send 'ICMP Fragmentation required' if packet is large then next interface MTU. This will break PMTU Discovery and since most applications usually sent packets at max MTU and DF-bit set, there will be timeouts. So again, consistent MTU across whole L2 path is important.
By the way, if your servers and PC's are not connected via jumbo-enabled links then you unlikely see any difference by enabling jumbo frames on the uplinks because both 6500 and 3550 catalysts are capable of wirespeed performance. The only time when it makes sense to enable jumbo frames only on the core links is when you need some non-IP headers to encapsulate your max-sized IP packets (MPLS is one such example).
As for benefits - servers running (very) heavy traffic applications (think full-feed USENET server with multiple fast peerings) may benefit from sending large portion of data in each packet, so for the same amount of data they need less number of packets. Destination system will have to handle less interrupts and overall performance may increase.
Hope this helps.

KT6 FISR (5188) - Jumbo frames support

Hi,
I have the KT6 FISR motherboard up and running with a gigabit network (after a dodgy network cable dropped my speed to 100Mbps ) and was wondering if anyone knew whether it supports jumbo frames. Have searched the spec sheets and also broadcom's website without any joy. There are no settings in the 'configure' section of the hardware.
Anyone?
Mike

Taken from the netgear site - http://kbserver.netgear.com/kb_web_files/n101539.asp:
What is the Jumbo Frame Supported by Switches and Adapters?
Ethernet traffic moves in units called frames. The maximum size of frames is called the Maximum Transmission Unit (MTU). When a network device gets a frame larger than its MTU, the data is fragmented (broken into smaller frames) or dropped. Historically, Ethernet has a maximum frame size of 1500 bytes, so most devices use 1500 as their default MTU. An Ethernet packet larger than 1500 bytes is called a Jumbo Frame.
An Ethernet frame uses a fixed-size header. Since the header contains no user data, it's overhead. It is more efficient to transmit a larger frame — the overhead-to-data ratio is better.
The performance problem arises when the MTU of one device is different than another. Indeed, casual changes to MTU to "optimize performance" are likely to have the opposite effect. See MTU, Partial Loss of Internet Connection, and Performance for an explanation of MTU problems — before considering the effects of Jumbo Frames. Also note that Jumbo Frames only help LAN performance, traffic leaving your network to the Internet is limited to packets of 1500 bytes.
With Jumbo Frames, much larger frames than the Ethernet standard of 1500 bytes are supported. If most of your local network devices and applications can be configured for the same Jumbo Frame size, your network may benefit from large packets, little fragmentation, and little overhead. However, if there are many applications and devices on your network that already limit frames to less than 1500 bytes, Jumbo Frames might decrease your performance slightly.
So with a switch and NAS both supporting jumbo frames it would have been good to have used them (or is that being too greedy? )

Why does iMac (Mid 2012) not support Jumbo Frames?

Why is it not possible to change MTU size to more than 1500? Buying such a high quality product, I would expect that it supports jumbo frames!
My NAS supports jumbo frames, the Air Port Extreme does but a brand new iMac doesn't???
Is there any patch or somethin to fix this?
Thanks!!!

Hi Marcus,
I find conflicting info on this...
The Ethernet port supports the configuration of Ethernet frames larger than 1,500 MTU (Maximum Transmission Unit).
http://support.apple.com/kb/HT4619
Can anyone confirm if the new 2011 imacs already support jumbo frames? I heard it now uses a new broadcom ethernet chip that now supports jumbo frames on the 21 inch model. They removed jumbo frames support in the previous i5 and i7 models...
Hmm, I remember that the iFix tear down revealed that the 2011 iMacs had a Broadcom BCM57765B0KMLG Eithernet chip. (just go to the page and if you are using safari/firefox press command + F and type "Broadcom" to jump to that particular)
http://www.ifixit.com/Teardown/iMac-...eardown/5485/2
so I did a little googling and found out that:
http://www.broadcom.com/products/Eth...lient/BCM57765
Integrated 10/100/1000BASE-T transceiver with:
- 10/100/1000BASE-T triple-speed MAC
- Compliant with IEEE standards
- Compliant with IEEE 802.3az draft standard for Energy Efficient Ethernet™ (EEE)
- State-of-the-art physical layer interface that exceeds IEEE requirements
- Jumbo frame support with up to 9.6 KB frame size
- EthernetAV protocols with IEEE 802.1AS, 1588-2008, IEEE P802.1Qat and IEEE P802.1Qav support
So it should support Jumbo Frames.
http://www.philmug.ph/forum/f23/new-imac-early-2011-sandy-bridge-processors-7106 4/index8.html
Originally Posted by mpe
At least mine doesn't
Weird. My 27" 3.1GHz iMac that was delivered yesterday supports jumbo frames fine. I was quite concerned that it wouldn't because I rely on them for good performance with my NAS
I set it using System Preferences -> Ethernet -> Advanced -> Ethernet -> Configure Manually.
I've confirmed the setting by checking the output of ifconfig. It shows an mtu value of 9000.
http://forums.macrumors.com/showthread.php?t=1148176
Some of the 2010 iMacs did not I read.

Adding jumbo frame support into an existing Ethernet network

I have a remote site with 40 users that connect back to our main site via two point to point T-1s. These users connect to an Exchange server (DMZ), Sybase databases on Sun servers (Internal network), and access the Internet via the main site.
I have installed a new WS-2970G-24TS-E switch into the network at this remote site. I have connected all of the designers (total of 10) Apple G5 workstations and two Apple Xserves to this switch. I have also configured the system jumbo MTU to 9000 bytes on the 2970. I have not yet enabled jumbo frames on the Xserves or the G5s since I am unsure of what the effect on the network might be. I imagine it could range from dropped packets to crashing the router.
I would like to enable jumbo frame support on these devices since they transfer hundreds of gigabytes of data on their local network. But if I do this, what will be the affect when they attempt to visit web sites or connect to the Exchange server?
How have you guys worked with this type of scenario?
The address space for this site is a /25 of one of our class Cs.
Please see the attached Visio diagram that outlines the connection points throughout the network.
Thank you

Best practice here is to segment your Jumbo Frame servers on their own VLANs for Jumbo supported systems only.
As a post here has already mentioned, Path MTU discovery will tell the systems on the Jumbo VLANs to keep the frames under 1500 when talking to a non-Jumbo VLAN.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2970/12225see/scg/swint.htm#wp1154596
Please rate all helpful posts.
Brad

How do I maximize LAN speeds using Gigabit Ethernet, jumbo frames?

I move a lot of large files (RAW photos, music and video) around my internal network, and I'm trying to squeeze out the fastest transfer speeds possible. My question has to do both with decisions about hardware and what settings to use once it's all hooked up.
This is what I have so far:
-- imac 3.06GHz, macbook pro 2.53GHz
-- Cisco gigabit smart switch capable of jumbo frames
-- Buffalo Terastation Duo NAS (network attached storage), also capable of Gbit and jumbo frames
-- All wired up with either cat6 or cat53e.
-- The sizes of the files I'm moving would include large #s of files at either 15MB (photos), 7MB (music), 1-2GB (video) and 650MB (also video).
-- jumbo frames have been enabled in the settings of the macs, the switch and the buffalo HD.
-- I've played with various settings of simultaneous connections (more of a help with smaller files), no real difference
-- Network utility shows the ethernet set to Gbit, with no errors or collisions.
-- have tried both ftp and the finder's drap and drop
-- also, whenever I'm doing a major move of data, I kick my family off the network, so there is no other traffic that should be interfering.
Even with all that, I'm still lucky to get transfer speeds at 15-20mbps, but more commonly at around 10. The other odd thing I've encountered while trying to up my speeds, is that I might start out a transfer at maybe 60mbps, it will maintain that for about 30-60sec and then it appears to ramp itself down, sometimes to as low as 1-5mbps. I'm starting to think my network is mocking me
I also have a dual band (2.4/5) wireless n router (not jumbo frame capable), but I'm assuming wired is going to trump wireless? (NOTE: in my tests, I have disabled wireless to force the connection through the ethernet).
Can anyone help with suggestions, and/or suggest a strong networking reference book with emphasis on mac? I'm willing to invest in additional equipment within reason.
Thanks in advance!
juliana

I'm going to pick and choose to answer just a few of the items you have listed. Hopefully others will address other items.
• This setup was getting me speeds as high as 10-15MB/sec, and as low as 5-6MB/sec when I was transferring video files around 1-2 GB in size
I would think a single large file would get the best sustained transfer rates, as you have less create new file overhead on the destination device. It is disturbing that the large files transfer at a slower rate.
• Would a RAID0 config get me faster write speeds than RAID1? I have another NAS that can do other RAID configs, which is fastest as far as write times?
RAID0 (Striped) is generally faster, as the I/O is spread across 2 disks.
RAID1 is mirrored, so you can not free the buffer until the same data is on BOTH disks. The disks are NOT going to be in rotational sync, so at least one of the disks will have to wait longer for the write sectors to move under the write heads.
But RAID1 gives you redundency. RAID0 has not redundency. And you can NOT switch back and forth between the 2 without reformatting your disks, so if you choose RAID0, you do not get redundency unless you provide your own via a backup device for your NAS.
• what is the most efficient transfer protocol? ftp? smb? something else? And am I better off invoking the protocol from the terminal, or is the overhead of an app-based client negligible?
Test the different transfers using a large file (100's of MB or a GB sized file would be good as a test file).
I've had good file transfers with AFP file sharing, but not knowing anything about your NAS, I do not know if it supports AFP, and if it does, whether it is a good implementation.
If your NAS supports ssh, then I would try scp instead of ftp. scp is like using cp only it works over the network.
If your NAS support rsync, that would be even better, as it has the ability to just copy files that are either NOT on the destination or update files which have changed, but leave the matching files alone.
This would help in situations where you cannot copy everything all at once.
But no matter what you choose, you should measure your performance so you choose something that is good enough.
• If a client is fine, does anyone have a suggestion as to best one for speed? Doesn't have to be free -- I don't mind supporting good software.
Again just test what you have.
• Whats a good number to allow for simultaneous connections, given the number of files and their size?
If the bottleneck is the NAS, then adding more I/O that will force the disk heads to move away from the current file being written will just slow things down.
But try 2 connections and measure your performance. If it gets better, then maybe the NAS is not the bottleneck.
• What question am I not asking?
You should try using another system as a test destination device in the network setup to see if it gets better, worse, or the same throughput as the NAS. You need to see about changing things in your setup to isolate where the problem might be.
Also do not rule out bad ethernet cables, so switch them out as well. For example, there was a time I tried to use Gigabit ethernet, but could only get 100BaseT. I even purchased a new gigabit switch, thinking the 1st was just not up to the task. It turned out I had a cheap ethernet cable that only had 4 wires instead of 8 and was not capable of gigabit speeds. An ethernet cable that has a broken wire or connector could exhibit similar performance issues.
So change anything and everything in your setup, one item at a time and use the same test so you have a pear to pear comparision.

How to enable "Jumbo Frame" at RV320 LAN ports?

I'm sorry about my silly question, where is the option to turn on the "Jumbo Frame" or allow to adjust MTU at the RV320 LAN ports?
I can't found that in the Web management interface, will it just take the 9Kb MTU packet and no need to set?
Looks like the MTU settings is only available at those internet ports or USB interface.

Hello,
You won't find any LAN side MTU settings on any of the small business routers. The LAN ports are simply layer 2 switch ports, which means they will either forward or drop the larger packets. They have to be gigabit ports as well, Jumbo Frames do not work with anything less. Unfortunately I cannot find anything specific to this model, and I am unable to test it since I don't have any Jumbo capable NICs.
So your best bet is really to just give it a try. The switch ports on the router will either forward or drop the packets, and anyone going out to the internet will either lower their packet size using MTU discovery, or the router will fragment the packets down to a size appropriate for the WAN link.
I wish I could be more specific, but without being able to test it that is the most info I can give you right now.
Let me know how it goes,
Christopher Ebert

Jumbo frame ethernet

I came across a number of articles relating to jumbo frame gigabit ethernet and integrating into existing networks with fastethernet and 1518 frame size gigabit ethernet devices. Heres a quote i'd like to discuss...
"Today, however, applications optimized for large frame sizes can easily be integrated with existing Ethernet LANs without causing interoperability problems. For example, you can partition a logical network in which systems can exchange Jumbo Frames and mark them with IEEE 802.1Q virtual LAN tags. The extended frames will be transparent to the rest of the network.
Adapters that implement IEEE 802.1Q can support different Ethernet frame sizes for different logical network interfaces. For example, a server could communicate with another server using Jumbo Frames while communicating with clients sitting on another VLAN or IP subnet using standard Ethernet frames - all via the same physical connection."
The use of VLANs to ease interoperability issues is discussed in numerous articles and papers on jumbo ethernet - however, can someone pls explain why cisco have and the implications of the design decision they have taken with the 3750 switches to have no flexibility with configuring jumbo frame support, It can't be assigned on port-by-port basis, nor even on a VLAN basis but is set system wide so on a 24 port 10/100/1000 switch all ports are configured as jumbo regardless of what the connected client devices support.
Are there any plans to upgrade the IOS to support configuring jumbo frames on per VLAN basis. Jumbo frames are an important issue to us as we can benefit from the performance increases and the improved server CPU utilization. Any thoughts ?

Best practice here is to segment your Jumbo Frame servers on their own VLANs for Jumbo supported systems only.
As a post here has already mentioned, Path MTU discovery will tell the systems on the Jumbo VLANs to keep the frames under 1500 when talking to a non-Jumbo VLAN.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2970/12225see/scg/swint.htm#wp1154596
Please rate all helpful posts.
Brad

Jumbo frame stuck at 8165 bytes or larger

Similar Messages

Maybe you are looking for