6.2 mtu now limits size of incomming packet

[Stephen Clark]

Eli Dart wrote:

>see below...
>
>Julian Elischer wrote:
>  
>
>>Eli Dart wrote:
>>    
>>
>>>Stephen Clark wrote:
>>>
>>>      
>>>
>>>>So was any decision reached on this issue - will FreeBSD changed
>>>>to accept a packet on an interface that is larger than the mtu on
>>>>that interface?
>>>>        
>>>>
>>>If possible, I'd like to see the ability to enforce interface MTU
>>>for received packets preserved in a sysctl if it is removed for the
>>> default config...  In other words, something like:
>>>
>>>net.link.mtu_limits_received_pktsize = 0|1
>>>
>>>Then, default it to 0 to preserve 4.x behavior.
>>>      
>>>
>>what would this achieve?
>>
>>Answering himself.. it MAY allow a driver to optimise a bit by not 
>>needing to cope with the posibility of receiving jubo packets? I can
>>not think of any other reason.. (except to break networks that are 
>>apparently working fine).
>>    
>>
>
>The networks that are apparently working fine are most likely 
>misconfigured, IMHO.
>
>Others have made a case for permitting an interface to accept as large a 
>packet as it can, regardless of configured MTU.  That's fine for theory.
>
>My operational experience leads me to a different place.  If an 
>interface receives a packet that is larger than its configured MTU, I 
>would prefer that the packet be dropped as a giant and a giants counter 
>  incremented, regardless of whether the hardware can theoretically 
>receive the packet.  In modern networks, an MTU mismatch within a 
>broadcast domain indicates a broken network, IMHO.  If the devices in 
>the network are configured to enforce MTU for both tx and rx, more 
>problems get spotted during turnup, rather than surfacing later on as 
>difficult-to-diagnose problems that users only call about after they are 
>truly frustrated.  And, if you have a giants counter (or input error 
>counter) you can look at, it makes it straightforward to spot the problem.
>
>(one could also stretch a bit and say that enforcing MTU on rx might 
>provide less surprise to code that consumes packets and has knowledge of 
>the MTU setting of an interface.....unfortunately I don't know enough 
>about the details of the network stack to know if this is a real concern)
>
>Many thanks,
>
>		--eli
>
>
>  
>
Hi Eli,

You make some good points, however it is a change from previous FreeBSD 
behavior
and is not required by any RFC's, plus it causes problems for some users.

My $.02
Steve

-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)