🚀 go-pugleaf

With Brad's consent, I forward his reply to the net:


>In article <mbt.717710343@Able.MKT.3Com.Com> you write:
>: 
>: You are correct in that you need to lower the MTU on the DEC5000. The
>: NETBuilder II will drop packets that are to be **BRIDGED** from FDDI
>: to Etherenet if that packet exceeds the ethernet 1500 byte MTU.
>: 
>: The NETBuilder II has ample capacity to perform fragmentation when
>: it is routing (FYI: see Scott Bradners FDDI-ethernet-FDDI router test for
>: exact performance numbers), however in a bridging mode the NETBuilder II
>: does not currently support fragmentation.
>: 
>: -brad-
>: 
>
>The software release we are using is SW/NBII-BR-5.0.
>It is capable of doing "translating bridging" according to the release notes.
>
>Does that mean the "traslating bridging" function does not do 
>fragmentation at this software release?
>
>--
>Ann-Kian Yeo
>yeoak@iscs.nus.sg
>


   Translation bridging only deals with header conversion between various
media types it does not address the issue of mis-matched MTU's between
media. The problem of differing MTU sizes is really nasty and the best
answer is to use routing instead of bridging. Of course I understand it
might not be practical for you, but none the less it is the answer.

   Given that you probably don't want to go to routing then the next course
of action is to lower the MTU's on your end stations so that they don't
generate frames that exceed the 1500 byte limit.

   It is a very large myth within the industry that multi-media bridging
is a trivial issue. It is not as you have discovered. In the specific case
of the IP protocol it is possible to make the bridge act like a router and
do layer 3 fragmentation the same as a router does. For other protocols
that simply won't work. For example IPX can not be fragmented by a bridge.
So what do you do with IPX packets in a FDDI-Ethernet bridged environment
that exceed the 1500 byte limit? The answer is to go to routing. The only
protocols that a bridge could possibly fragment are IP and OSI. Most other
protocols cannot be treated in this fashion since they do not use byte level
acknowledgements. For a vendor that provides support for multiple protocols
I'm sure you can see how this is a difficult issue.

-brad-

-- 
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner | 5400 Bayfront Plaza  | Marketing Engineer   | (408) 764-5261
3Com Corp.  | Santa Clara CA, 95052| mbt@NSD.3Com.Com     | (408) 764-5002 fax