HDTenEightyP/NetNews huggingface dataset:
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Still a little confused
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 5 Oct 92 21:46:41 GMT

I am still a little confused about concentrators and rings.
Is the general usage for FDDI to use a concentrator? Or do
users generally build physical rings?

And of course the follow up:  If they use a concentrators, then why
pass tokens out to the stations, when the token can be passed about
inside the hub?
Newsgroups: comp.dcom.lans.fddi,comp.protocols.nfs
From: iscyeoak@nuscc.nus.sg (YEO ANN KIAN)
Subject: Re: Can NFS over FDDI work properly?
Organization: National University of Singapore
Date: Thu, 1 Oct 1992 02:04:39 GMT


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

Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 5 Oct 1992 20:01:39 GMT

In article <mbt.718307170@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> 
> >> IP aside how does SGI deal with ether to FDDI translation bridging
> >> of protocols that don't use byte level acks? Just courious...
> 
> >I don't know what is meant by "byte level acks".  Protocols such as TP4
> >or XNS with records?  What problems special do they have?
> 
> A bridge can't fragment a 4K XNS/IPX datagram the way it can a IP
> datagram. The only reason you can frag an IP packet is because the
> seq numbers are at the byte level. With XNS et. al. since the seq
> numbers correlate to packet number a bridge can't really fragment
> packet number 2 into packet number 2 and packet 2.5. The end node
> is going to send out packet seq number 3 after 2. So how can the
> bridge fragment?



I don't know about XNS or IPX, and I can't find any equivalent to the
IP offset or MF bits in the "Internet Protocol" described in my old
Xerox XNS documents.

The TCP sequence numbers have absolutely nothing to do with fragmenting
TCP/IP, UDP/IP, or any other current IP protocol.  IP fragmenting is
done entirely within the IP datagram, and is based on the 8-byte
"offset" and the "more fragments" flag.

The only IP fragmenting that an FDDI-ether bridge will usually need to
do is of UDP packets.  UDP packets are datagrams, and have no sequence
numbers of any kind.  If you don't have FDDI-ether-FDDI networks, the
initial MSS negotiation in TCP will pick 1500.  This is consistent with
the TCP/IP lore (and RFC) that considers fragmenting harmful.


Vernon Schryver,  vjs@sgi.com
From: rmwise@mcigate.apdev.mci.com (Bob_Wise)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 6 Oct 92 17:19:41 GMT
Organization: MCI

In article <mbt.717889082@Able.MKT.3Com.Com> mbt@ESD.3Com.COM (Brad Turner) writes:
>rmwise@mcigate.apdev.mci.com (Bob_Wise) writes:
>>
>>I've been following this packet-fragmentation-when-using-NFS-over-FDDI
>>thread with some interest.

   ... blah blah blah...

>Bob, et.al.,
>   If you have the opportunity to to design a net from the ground up
>I'd suggest you look at using routing *IF* you will be spanning
>multiple media (fddi, ethernet, tokenring). When you start trying


I appreciate these words of advice, but I was really curious what the
issues were when NOT spanning several media types.

For example, two machines, FDDI only, doing NFS mounts from each other.

Are there packet sizing issues given this scenario?

-Bob
-- 
---------------------------------------------------------------------------
| Bob Wise          | INET:622-1322 | MCIMail:rmwise | Pager:719-577-1928 |
| Unix Consultant   |-----------------------------------------------------|
| Consultant to MCI | Phone:719-592-1322 | Internet:rmwise@apdev.mci.com  |
From: bob (Bob Grow)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: 10 byte fragments on fddi - a sign of trouble?
Date: 5 Oct 92 15:40:47 GMT
Organization: xdi

In article <ON7T+38+F@linac.fnal.gov> crawdad@fncent (Matt Crawford) writes:
>While looking at one of our fddi rings I saw a fair number of 10 byte
>fragment frames which had just the initial frame code byte, a valid
>local destination address, and half of a source address.  Is this
>"normal"?  My analyzer was set to select only LLC frames to or from a
>certain address, and the ring has 2 concentrators (cascaded), 2 fddi-
>to-ether bridges, 2 big vaxes and an sgi machine.  I was selecting on
>the sgi's address.
>_________________________________________________________
>Matt Crawford       crawdad@fncent.fnal.gov      Fermilab
>
This is normal. FDDI strips frames using the source address (e.g., if the SA
equals my address then strip the frame). Some of the FDDI MAC chips strip the
last byte of SA and the rest of the frame, others begin stripping following the
SA field. This produces 13 or 14 bytes fragments of JK FC DA SA (your analyzer
may not count the JK).

Some FDDI PHY chips will nibble away at these fragments, converting the last
byte to Idle symbols. This is done by any PHY so source and destination address
are irrelevant. This nibbling will produce the "fair number" of 10 byte
fragments you saw. The number of bytes in the fragment will vary based on 
number of and the physical ordering of these nibbling PHY chips and the frame
source. If network load is light, the fragments can circulate around the ring
many times (unless you have a purger on the ring), with nibbling on the
fragment continuing. The location of the analyzer will also effect the observed
length.
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 2 Oct 92 06:04:28 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA


In article <mbt.717984230@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> ...
> If after telling somebody they might shoot themselves in the foot I
> firmly believe they still have the right to. The whole issue boils
> down to customer choice and education.


I can imagine situations where an FDDI-ether bridge that doesn't handle
4K UDP/IP packets is the best choice.  Maybe the customer does not and
never will care about NFS servers on the fiber.  If the customer gives
informed consent, so be it.

How you find salescreatures that both can "make plan" and won't shave
that informed consent until it is tenuous, I don't know.  Finding
customers who will admit they don't know everything and so can be
informed enough to give meaningful consent to an unusual solution is
another difficulty.

What went wrong with the customer who started this thread?


> IP aside how does SGI deal with ether to FDDI translation bridging
> of protocols that don't use byte level acks? Just courious...

I don't know what is meant by "byte level acks".  Protocols such as TP4
or XNS with records?  What problems special do they have?

We tend to encapsulate protocols like SNA in TCP/IP.

Silicon Graphics makes UNIX boxes.  None of our standard products
bridge.  We are perforce of the routing faith.

If you mean, how do we as users handle FDDI-ether bridging problems,
answer is that all of the production FDDI rings I know about inside the
company are run by and for the developers, who do not use MACs, PCs,
VAXEN, etc, and so have only IP FDDI frames (and, of course, ARP and
lots of SMT), and we use our own boxes to route, not bridge, IP to and
from FDDI.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.lans.fddi
From: thomas@lkg.dec.com (Matt Thomas)
Subject: Re: Booting diskless DECstation over FDDI?
Reply-To: thomas@lkg.dec.com
Organization: Digital Equipment Corporation
Date: Mon, 28 Sep 1992 19:44:43 GMT


In article <chicken.717694203@npac.syr.edu>, chicken@npac.syr.edu (Mark R. Levinson) writes:
|>	Could anyone tell me if it's possible to boot a diskless DECstation
|>5000 (running Ultrix 4.2a) over FDDI rather than ethernet? If so, how is it
|>done? I've tried using the command "boot #/mop" from the monitor where # is
|>the slot of the FDDI card (which seemed like an obvious solution), but the
|>machine just hangs and syslog on the boot server shows no record of a dumpload
|>request from the client's FDDI address.

Sure can.  Just make to register the FDDI board's address with ris instead of
the Ethernet address.  It's either one or the other.  My workstations loads
over FDDI.
--
Matt Thomas                     Internet:   thomas@lkg.dec.com
DECnet-ULTRIX Development       UUCP:       ...!decwrl!thomas
Digital Equipment Corporation   Disclaimer: This message reflects my own
Littleton, MA                               warped views, etc.
Newsgroups: comp.dcom.lans.fddi
From: mbt@ESD.3Com.COM (Brad Turner)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 5 Oct 92 17:46:10 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <mbt.717984230@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
>> ...
>> If after telling somebody they might shoot themselves in the foot I
>> firmly believe they still have the right to. The whole issue boils
>> down to customer choice and education.


>What went wrong with the customer who started this thread?

I'm following up via email and don't know yet. I was out of the office
Friday.


>> IP aside how does SGI deal with ether to FDDI translation bridging
>> of protocols that don't use byte level acks? Just courious...

>I don't know what is meant by "byte level acks".  Protocols such as TP4
>or XNS with records?  What problems special do they have?

A bridge can't fragment a 4K XNS/IPX datagram the way it can a IP
datagram. The only reason you can frag an IP packet is because the
seq numbers are at the byte level. With XNS et. al. since the seq
numbers correlate to packet number a bridge can't really fragment
packet number 2 into packet number 2 and packet 2.5. The end node
is going to send out packet seq number 3 after 2. So how can the
bridge fragment?


>We tend to encapsulate protocols like SNA in TCP/IP.

>Silicon Graphics makes UNIX boxes.  None of our standard products
>bridge.  We are perforce of the routing faith.

> [SGI site info re: routing only deleted]

Actually what I was getting at was that it is merely a happy coincidence
that IP can be hacked by a bridge to work. Other real world protocols
still pose problems. More than likely since you are in such an IP-centric
shop you don't see these other protocol problems.


>Vernon Schryver,  vjs@sgi.com
--
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
Xref: sparky comp.dcom.lans.fddi:659 comp.protocols.nfs:2439
From: mbt@ESD.3Com.COM (Brad Turner)
Newsgroups: comp.dcom.lans.fddi,comp.protocols.nfs
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 30 Sep 92 21:38:02 GMT
Followup-To: comp.dcom.lans.fddi

rmwise@mcigate.apdev.mci.com (Bob_Wise) writes:
>
>I've been following this packet-fragmentation-when-using-NFS-over-FDDI
>thread with some interest.
>
>I've got two IBM RS/6000 950's which are shortly to become 970's, plus
>I've got another 2 970's coming.  We do a lot of NFS over ethernet,
>and I am about to move that NFS traffic over to a small FDDI ring that
>only has the 970 servers on it.
>
>Is the fragmentation problem present with this scenario, or is
>fragmentation only a problem with bridges and routers?
>
>Do I need to consider adjusting packet sizes?
>
>Thanks,
>
>-Bob
>
>
>
>-- 
>---------------------------------------------------------------------------
>| Bob Wise          | INET:622-1322 | MCIMail:rmwise | Pager:719-577-1928 |
>| Unix Consultant   |-----------------------------------------------------|
>| Consultant to MCI | Phone:719-592-1322 | Internet:rmwise@apdev.mci.com  |

Bob, et.al.,
   If you have the opportunity to to design a net from the ground up
I'd suggest you look at using routing *IF* you will be spanning
multiple media (fddi, ethernet, tokenring). When you start trying
to do bridging between different types of media all kinds of nasty
issues raise their head. These issues are effectively dealt with
by routing. In case you are wondering what types of "nasty issues"
I'm refering to here is a short list off the top of my head I'm sure
others can add to it.

 o MTU mismatches (fddi vs eth)
 o Some ARP implementations use canonical address within the data
   others use non-canonical address representation within the data field.
 o Source Route to non SR media (token ring to ethernet or fddi)

-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
From: mbt@ESD.3Com.COM (Brad Turner)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 2 Oct 92 00:03:50 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <mbt.717961736@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
>> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>> ...
>> >That's a reasonable statement.  Why does 3Com allow their boxes
>> >to do FDDI-ethernet bridging?  When they drop 4K IP FDDI packets?
>> 
>> Because in some instances it solves real customer problems. As a vendor
>> it is our challenge to educate/advise customers as to the pros and cons
>> of various methods of interconnecting networks and help them design
>> the best solution to fit their specific needs. In some instances
>> translation bridging is a valid solution.


>I understand that kind of pressure.  There are always salescreatures
>who find multi-million dollar deals that the system (yours or mine)
>does not quiet fit.  The salescritters I deal with never, and even some
>management often does not understand my concern that while doing the
>deal is good for this quarter's revenue numbers and this month's
>commission check, selling a bad solution now can prevent ever selling
>anything to that account again.  Or even selling anything other
>accounts which have in future years hired someone who worked at the
>first account.  I don't even try to convey my fear and loathing for the
>support hassles, arguments, and verbal abuse generated by such a bad
>fit.

That's where the education I mentioned above comes in. If you take the time
to advise your sales folk and their customers as to the issues at hand you
are doing the best you can.

> [...example deleted...]

>There are several companies selling FDDI-ether bridges that do not work
>in the presense of real FDDI hosts using UDP.  I continue to wonder
>what their customers think after they discover they have purchased
>bridges that work "some of the time for some traffic."  No matter how
>great the bridge may be otherwise, do they ever deal with that vendor
>again?

Again I harp on the education issue. You must be up front and honest
with the customer during the first sale and let them up front they
might be bitten in the future.

>I know that I would be skeptical of any company that tried to sell me
>an FDDI-ether bridge that just dropped 4K UDP/IP/FDDI packets, because
>if the bridge vendor does not understand the importance of 4K FDDI
>packets and just tells me to "change the MTU", then the bridge vendor
>may not understand other, more important issues.

If after telling somebody they might shoot themselves in the foot I
firmly believe they still have the right to. The whole issue boils
down to customer choice and education.

IP aside how does SGI deal with ether to FDDI translation bridging
of protocols that don't use byte level acks? Just courious...


-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
Newsgroups: comp.dcom.lans.fddi
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Hubs
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 5 Oct 92 18:22:40 GMT

Can someone tell me by post, what percentage of FDDI installations have
a hub?  I know the system is a logical ring, but how often is it deployed
as a physical ring and how often as a start, with a center hub?

         Thank You
Newsgroups: comp.dcom.lans.fddi
From: kjell@Xenon.Stanford.EDU (Kjell Saeten)
Subject: Concentrator(?)
Originator: kjell@Xenon.Stanford.EDU
Organization: Computer Science Department, Stanford University.
Distribution: usa
Date: Mon, 5 Oct 1992 08:24:23 GMT

Hello!!!

This is probably a stupid question, but can I connect SAS's FDDI adapter
cards in a single ring without a concentrator/hub???
I want to test a FDDI ring, but I have only SAS cards, and I don't
want to buy a concentrator. Can I do this?, and how ?

Kjell@neon.stanford.edu
Newsgroups: comp.dcom.lans.fddi
From: iscjcm@nuscc.nus.sg (John Charles Mccallum (Dr))
Subject: Re: Can NFS over FDDI work properly?
Organization: National University of Singapore
Date: Fri, 2 Oct 1992 02:42:20 GMT

mbt@ESD.3Com.COM (Brad Turner) writes:
: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
: >In article <mbt.717961736@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
: >> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
: >> >That's a reasonable statement.  Why does 3Com allow their boxes
: >> >to do FDDI-ethernet bridging?  When they drop 4K IP FDDI packets?
: >> 
: >> Because in some instances it solves real customer problems. As a vendor
: >> it is our challenge to educate/advise customers as to the pros and cons
: >> of various methods of interconnecting networks and help them design
: >> the best solution to fit their specific needs. In some instances
: >> translation bridging is a valid solution.
: 
: >There are several companies selling FDDI-ether bridges that do not work
: >in the presense of real FDDI hosts using UDP.  I continue to wonder
: >what their customers think after they discover they have purchased
: >bridges that work "some of the time for some traffic."  No matter how

	As the customer of the bridge that started this thread, let me say we
expected to have some difficulty with FDDI interoperability. But, not
the problem we see with the dropped packets. The 3Com Netbuilder II
manuals certainly do not indicate that any problems will occur. In fact, the
new manuals are particularly short on references to FDDI difficulties. I
think that they should at least include notes about the likely problems
with running NFS through their boxes. The fixes necessary to make the
boxes work in our environment are not trivial - because the workstation
vendors often do not allow the setting of the MTU - to limit the
packet sizes to prevent the fragmentation. Our RS/6000 was okay. But, DEC
5000/240 doesn't look easy (DEC is looking into it for us). A month ago,
I didn't know what an MTU was. We don't want to use routing due the
extra work in setting it up, and the lack of flexibility of moving
equipment about. We have a work-around solution now, but I think that
it is still very fragile. We are obviously a little disappointed in 
the 3Com product not doing what we expected it to do. But, I am much
more disappointed that we had to go to so much work to find out that
there would be a problem, when 3Com knows that a problem exists, and that
they don't tell you until you complain.

John McCallum	johnm@iscs.nus.sg	DISCS, National Univ of Singapore
From: syj@ecmwf.co.uk (Jean-Philippe Martin-Flatin)
Newsgroups: comp.dcom.lans.fddi
Subject: Modify FDDI MTU on an EP/IX machine
Date: 5 Oct 92 17:51:58 GMT
Organization: ECMWF

We have a CD 4680 file server running EP/IX connected to an FDDI ring. All
workstations are connected to an Ethernet (let's say there is just one).
An NSC/DX router routes between FDDI and Ethernet.

We have just setup this config, and are experiencing long delays that we
suspect to be due to fragmentation of NFS packets on the NSC/DX. In order
to prevent this fragmentation, we are considering 2 scenarios:

1) Tell the CD 4680 to use an MTU of 1500 rather than 4352 when it uses
   its FDDI interface for outgoing traffic.

2) Tell the CD 4680 to use an MTU of 1500 when it uses its FDDI interface
   for outgoing traffic to our Ethernet subnet, and an MTU of 4352 when
   traffic is directed to any other subnets.

Is any of these scenarios possible ? I RTFM'ed but didn't find a way to
change the FDDI MTU. Any idea ?

Thanks in advance

/----------------------------------------------------\
| Jean-Philippe Martin-Flatin                        |
| European Centre for Medium-Range Weather Forecasts |
| Shinfield Park                                     |
| Reading RG2 9AX                                    |
| England                                            |
|----------------------------------------------------|
|  Disclaimer: I speak for myself, not my employer   |
\----------------------------------------------------/