> FDDI has a max frame size of ~4500 byte, whereas ethernet has ~1500 byte.
> An FDDI host will try to use the biggest frame size to transfer big files.
> However, 4500 bytes do not match into 1500 byte ;-) if the destination is
> on an ethernet. There is a flag (may fragment, between identifier field and
> TTL field) in the IP header which allows to fragment large data into smaller
> IP chunks. However, I assume that this flag is primarly used by the next
> layer (eg. TCP).

The DF flag is for IP, not really TCP or UDP.

> Some FDDI-to-ethernet bridges are capable to fragment a 4500 byte FDDI 
packet 
> into smaller 1500 byte ethernet packets, but how is this made?
> Does this depend on this "may fragment" flag I mentioned above?

No, except that if you turn it on, things are even less likely to
work.  If the bridge can generate the ICMP error packets used by "MTU
discovery" and if the hosts do MTU discovery on UDP, the right thing
might happen.  A bridge than can generate ICMP packets can probably do
the IP fragmentation correctly, so turning on the DF bit is unlikely to
help.

> As I understand IP, the "bridge" has to maintain the identifier field, the
> flag field, the fragment offset field and probably the total length field
> in the IP header of each IP frame. And I guess the sequence number is
> involved as well..

No, a "bridge" is supposed between transform the 13-byte FDDI MAC
header (FC, DA, SA) and the 12-byte Ethernet (DA, SA).  Since a lot of
stuff on FDDI rings uses SNAP encapsulation, a bridge generally
transforms the SNAP header with an ethertype, (FC, DA, SA, 0xaa, 0xaa,
0x03, 0x00, 0x00, 0x00, XXYY) and (DA, SA, XXYY), with the SA and DA
bitswapped.  When simply bridging, the IP and subsequent headers are
not touched.

Unfortunately for the bridge guys, you simply cannot just transform
the MAC and SNAP haeders to put a 4K FDDI packet on an ethernet.
You must make your bridge do the hardest part of routing, which
is to IP-fragment.  IP fragmentation involves creating new IP headers
with the same sequence number, the MF bit set sometimes, new fragment
offset, and so on.


> If the bridge does fragment the FDDI IP packets, will the destination host
> on the ethernet still be able to reassemble the packets correctly (since the
> sequence numbers, identifier etc.. have changed..)? 

Yes, although there are good reasons to avoid fragments, as documented in 
a classic RFC.

>All doc I found to this topic only mention source hosts and destination hosts. 
> No doc considers a frame size change between the hosts...

That's right, because 
    (1) bridges are outside the IP universe described in the RFC's.

    (2) some people who like bridges in general (not me) are offended
	by the idea of making them do the hardest part of the work
	done by an IP router.


> The problem I'm facing at the moment is that we have a lot of FDDI LAN
> cards, but I cannot get them to talk RELIABLE with ethernet
> based hosts.... (NFS, FTP, rcp problems....). No problems with interactive
> services like telnet..

Not all bridge vendors are what I call "honest."  Some sell FDDI-ether
bridges that do not do IP fragmentation.  Others (e.g. at least one of
the largest vendors) do fragmentation, but at 0.1 or 0.01 of their
advertised performance.

NFS is a different problem than FTP and rcp.  FTP and rcp use TCP/IP,
while NFS generally uses UDP/IP.  Any pair of good TCP machines will
exchange MSS options at the start of the connection and discover that
one of them has a smaller MTU (really MSS) and use that instead.  As
long as you have not done something to override the MSS computed from
the MTU such as use the 4.3BSD-reno route MTU setting, FTP and rcp
should work fine.

There is no MSS option for UDP/IP, so NFS is problematic for FDDI-ether
bridges.  It is the protocol that usually (in my experience) makes
people stick pins into dolls representing bridge salescritters.

Of course, since I am of the routing instead of the bridging religion,
I think the best answer is to not bridge IP packets between FDDI but to
route them.


One thing to check is that your ethernets are not being saturated.
Another difference between FDDI and ethernet is speed.