1468 is due to IP and ICMP header costs. 1468 is the maximum ICMP ECHO
payload. (That's why its different from 1500.)
Additionally, full MTU size support in VLANs require that all the NICs
involved be able to deal with a frame that is 4 bytes larger. The VLAN
tag and related information increases packets by 4 bytes.
This has to be true for both ends of the connection. I'm pretty sure
that the e1000g driver has no problem with full MTU VLAN frames. I
don't know about vnet, though, as I have no experience with it.
-- Garrett
Mike Gerdts wrote:
Today I ran into problems with the following scenario:
- T2000 w/ 6.4.4 firmware
- Control LDOM running Nevada build 60 + LDOM manager 1.0
- e1000g0 - management network
- e1000g49000 - application network
- Resource domain running S10U3 + patches (118833-36)
- vnet0 - management network
address assigned for global zone
- vnet49000 - app network
- Non-global zone in resource domain
- vnet49000:1 used by non-global zone
I can use the resource ldom global zone without problems. I noticed
that the non-global zone was not passing 1500 byte packets, initiall
observed as hangs during login and confirmed by ping -s <other host
ip> 1500.
The largest packet size that would pass from the non-global zone to
the other host was 1468 (I think that was the packet size). Adjusting
the mtu on vnet49000:1 to 1400 resolved all of my problems talking to
remote networks. However, this is not a good general solution because
I kinda need to have a similar MTU for same subnet communication.
Does this start to ring any bells for anyone? Should I be barking up
the nevada tree, the LDOMs tree (Sun Support), or the Solaris 10 tree
(Sun Support)?
Mike
_______________________________________________
networking-discuss mailing list
[email protected]
