
-------------------------------------------------------------------
NOVFRAME.DOC -- 19980320 -- Email thread on Novell Ethernet framing
-------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Fri, 15 Dec 1995 13:54:54 -0500
From: "A. Grant" <ag129@UCS.CAM.AC.UK>
Subject: Re: Novell's angle on frame types?

Joe Doupnik <JRD@CC.USU.EDU> writes:
>	Ethernet_802.3 is specific to Novell, it's not a formal
>standard beyond that usage.

IEEE 802.3 is a standard.  Novell are just using it for something
other than what it was designed for.

>Ethernet_II is the defacto standard
>for the world's Ethernets, and that counts for something.

It is the de facto standard for IP.  It isn't the de facto standard
for protocols in general on a CSMA/CD LAN, not any more anyway.

>	Did you ask where that SNAP item came from? As I understand it,
>it is an industry response to the failure of the IEEE 802.3 committee
>to allocate protocol descriminators/identifiers sufficient for today's
>networks.

That is part of it.  Another part of it is that industry wants to get
away from Ethernet_II and wants a clear migration path to IEEE 802.2
(so they can make their Ethernet products run on token ring etc.),
hence the use of SNAP with the Ethertype code.  Yet another is
that SNAP results in an alignment of payload within frames which
some people consider preferable to standard 802.2 UI frames.

But IPX and RIPL have 802.2 SAPs so there is no problem there.

>>>Ethernet_II is the answer.
>>
>>Rubbish.  What is this extra load of which you speak?

>	Tis not rubbish. Try writing a packet handler and discover the
>extra steps needed to take apart the "one bridge fits all" LLC interior.

If the first three bytes of the LLC header are E0E003, it's an IPX
packet.  If they aren't, it isn't.  That's as much decoding as you
need to do.  IPX only uses the bare minimum LLC functionality.
Real packet handlers don't necessarily work in the same bottom-up
order as by-hand packet analysis, they do the minimum number of
checks to discriminate the high-volume packets.  There could even
be header prediction extending inside the IPX frame.

The other thing is filtering in bridges and routers.  It may be
easier to filter with Ethernet_II, if the bridge knows nothing about
higher-layer protocols and can only do comparisons on a small number
of header bytes.

>I won't make a point of the LEN field being redundant on Ethernet frames.

It is not redundant, as you well know CSMA/CD imposes a minumum packet
length and if the payload has to be padded out, the length field
indicates how long the payload really is.  It is only redundant for
protocols which use a single PDU per frame incorporating its own length
field - of which IPX is one.

>Or the refusal of the committee to allocate a protocol ident to ARP.

They were quite happy to give them a SAP for IP (it is X'06').
They balked at handing out two SAPs for no technical reason, and there
is no technical reason why ARP shouldn't use the same SAP as IP,
just like RARP and BOOTP do.

>Seems to me that the IEEE 802.3 committee tried to create a bridge which
>was a router, and other camels.

Quite the reverse, it was about separation of function, media-dependent
from media-independent.  802.2 is not a routed protocol but it is
media-independent.

>	So is DECnet on Ethernet_II, with a whole bunch of other protocols.

Phase 4 used Ethernet_II.  Phase 5 uses 802.2/SNAP.  Times change.

>	Remote booting uses a variety of frames, depending on the flavor
>of boot ROM.

RIPL uses 802.2 frames with SAP X'FC'.  It's an IBM standard.
IPX remote booting is something entirely different.

The advice remains: network load, technical superiority and expert
opinion should be last on the list when choosing a frame type.
Look at your network drivers, your applications, your routers and
bridges, your boot ROMs and then use whatever works and is easiest
to manage.

------------------------------

Date: Fri, 15 Dec 1995 12:36:03 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell's angle on frame types?

	I'll try to be brief and avoid a slugging match on the topic.

>Joe Doupnik <JRD@CC.USU.EDU> writes:
>>	Ethernet_802.3 is specific to Novell, it's not a formal
>>standard beyond that usage.
>
>IEEE 802.3 is a standard.  Novell are just using it for something
>other than what it was designed for.

	Novell did NOT use IEEE 802.3 because the latter includes
the link info fields. The history on this is covered in Don Provan's
note on Ethernet frames.

>>Ethernet_II is the defacto standard
>>for the world's Ethernets, and that counts for something.
>
>It is the de facto standard for IP.  It isn't the de facto standard
>for protocols in general on a CSMA/CD LAN, not any more anyway.

	In general, quotes, it is the standard. It is not used in every
case, but count the situations of importance and there we are.

>>	Did you ask where that SNAP item came from? As I understand it,
>>it is an industry response to the failure of the IEEE 802.3 committee
>>to allocate protocol descriminators/identifiers sufficient for today's
>>networks.
>
>That is part of it.  Another part of it is that industry wants to get
>away from Ethernet_II and wants a clear migration path to IEEE 802.2

	That's news to me, and I think I keep in touch.

>(so they can make their Ethernet products run on token ring etc.),

	Actually TRN has a difficult time being accepted into new
sites. Ethernet has the mass of acceptance and the pricing. Handlers
cover the difference in media, if done right as say ODI tries to
accomplish. While on that topic, folks may want to read about the
difficulties dealing with 802.2 interiors as presented in the ODI
technical documentation (directory ODI/LAN_DRV on netlab2.usu.edu);
not pretty.

>hence the use of SNAP with the Ethertype code.  Yet another is
>that SNAP results in an alignment of payload within frames which
>some people consider preferable to standard 802.2 UI frames.

	And both are less desirable than no interior and hence
no work to do.

>But IPX and RIPL have 802.2 SAPs so there is no problem there.

	Only one of three kinds of remote program loading does this,
not all by any means.

>>>>Ethernet_II is the answer.
>>>
>>>Rubbish.  What is this extra load of which you speak?
>
>>	Tis not rubbish. Try writing a packet handler and discover the
>>extra steps needed to take apart the "one bridge fits all" LLC interior.
>
>If the first three bytes of the LLC header are E0E003, it's an IPX
>packet.  If they aren't, it isn't.  That's as much decoding as you
>need to do.  IPX only uses the bare minimum LLC functionality.
>Real packet handlers don't necessarily work in the same bottom-up
>order as by-hand packet analysis, they do the minimum number of
>checks to discriminate the high-volume packets.  There could even
>be header prediction extending inside the IPX frame.

	I'll comment here as a person who writes such code that the LLC
material is expensive and awkward.

>The other thing is filtering in bridges and routers.  It may be
>easier to filter with Ethernet_II, if the bridge knows nothing about
>higher-layer protocols and can only do comparisons on a small number
>of header bytes.

	MAC level bridges are protocol independent. Routers are the
term I apply to devices which are protocol dependent, and LLC counts as
protocol dependent in my book because of all the variations in the LLC
material. The committee tried to make all media look alike at the LLC
level and above; they don't and ought not have been contorted to behave
this way. See TRN compromise comment below.

>>I won't make a point of the LEN field being redundant on Ethernet frames.
>
>It is not redundant, as you well know CSMA/CD imposes a minumum packet
>length and if the payload has to be padded out, the length field
>indicates how long the payload really is.  It is only redundant for
>protocols which use a single PDU per frame incorporating its own length
>field - of which IPX is one.

	Sorry, but that's not what I think at all. The LEN field is worthless.
The board supplies frame length in silicon. All protocols of any merit have
internal length indicators. The most obvious "proof" of this is using
Ethernet_II frames with those protocols. The LEN field is there to quiet IBM
Inc and other Token Ring folks about what to do with non-routable fields they
stick in frames (source routing, for example). It's the committee camel here.

>>Or the refusal of the committee to allocate a protocol ident to ARP.
>
>They were quite happy to give them a SAP for IP (it is X'06').
>They balked at handing out two SAPs for no technical reason, and there
>is no technical reason why ARP shouldn't use the same SAP as IP,
>just like RARP and BOOTP do.

	I won't comment further than say this is a backhanded way of saying
the committee flunked a major requirement: satisfy the community using a
very widely accepted method of doing business. Thanks for validating it for
me.
	Joe D.

------------------------------

Date: Mon, 18 Dec 1995 11:17:33 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell's angle on frame types?

>>	I'm going to cut off my participation in this particular thread
>>so that the thread does not continue as a shouting match. Progress seems
>>to be difficult at best, so I will let matters rest as they are. Readers
>>can form their own opinions of the information offered to date.
>>	I'm not backing away; I am simply too busy to engage in rebutting
>>someone else's strongly held opinions if no significant progress can be
>>achieved.
>
>The trace file I offered to send you to prove you wrong is not a
>matter of opinion.  It's still there if you want it.
>
>Anyway I've always said people should make their own decision and
>that no one frame type is an outright winner, they each have their
>pros and cons, and I hope some of them have come out in this thread.
>
>Now will you stop continually telling people to use Ethernet_II,
>if you're not prepared to back this up?
--------
	Brother, what is this problem you have?
	Ethernet_II is the frame of choice. This is a Novell list, and
the protocols of interest are IPX, IP, some EtherTalk, scatterings of
remote boot ROMs, etc. Appletalk Phase II wants to run over Ethernet_SNAP,
so let it. IP and IPX run very nicely over Ethernet_II. Aside from Novell's
NIH syndrome and a remote boot rom situation there is no reason to use
Ethernet_802.2. There is no reason to use Ethernet_802.3 aside from a
remote boot rom case.
	So far as I can ascertain you haven't made a case for not using
Ethernet_II.
	I'm not interested in isolated mainframe situations (SNA), nor in
X.25 over (essentially none of that near me), nor in things which can be
dredged up from goodness knows where but don't relate to the environment
we are interested in here. OSI died from self-inflicted wounds; let it
rest in peace. There is nothing stopping people from creating protocols
which are dependent on physical framing details; whether we should pay
attention to them and their protocols is another matter.
	I'll talk with you privately about trace files.
	My recommendation stands: Ethernet_II is the frame of choice.
It is the defacto standard, it is the fastest to manipulate, it carries
the largest payload, it simplifies setups in servers and clients, it works
with Packet Drivers, ODI and NDIS, it works well with real routers. I cannot
say these things about Ethernet_802.3 nor Ethernet_802.2 nor Ethernet_SNAP.
	Joe D.

------------------------------

Date: Wed, 20 Dec 1995 22:33:46 -0500
From: "A. Grant" <ag129@UCS.CAM.AC.UK>
Subject: Re: Novell's angle on frame types?

Joe Doupnik <JRD@CC.USU.EDU> writes:
>	Brother, what is this problem you have?

My problem is that you're saying everyone who installs NetWare using
the default frame type is inexpert and their networks are substandard.
That's a pretty strong claim.

>	Ethernet_II is the frame of choice. This is a Novell list, and
>the protocols of interest are IPX, IP, some EtherTalk,

IP and EtherTalk have nothing do with IPX.  There is no purpose served
by trying to make all protocols use the same frame type.  You don't
have to get a very complex network before you are forced to use more
than one frame type.  Our servers use all four types on Ethernet.

>Aside from Novell's
>NIH syndrome and a remote boot rom situation there is no reason to use
>Ethernet_802.2. There is no reason to use Ethernet_802.3 aside from a
>remote boot rom case.

In both cases you might have other people in the organisation which
use those IPX frame types.  After all they have been the default at
various times.  The same goes for Ethernet_II (except it's never been
the default) - local consensus may be to use it, but there's no
overriding technical reason to.

>	So far as I can ascertain you haven't made a case for not using
>Ethernet_II.

I'm not trying to.  If I was, I'd probably say something about the
management cost associated with not using defaults, especially global
defaults affecting the whole network plan.  The cost may or may not
be outweighed by benefits, depending on the environment...

>	I'm not interested in isolated mainframe situations (SNA), nor in
>X.25 over (essentially none of that near me)

... which may be very different from Utah State University, USA.

>There is nothing stopping people from creating protocols
>which are dependent on physical framing details; whether we should pay
>attention to them and their protocols is another matter.

>From previous discussion this appears to be a reference to X.25
(and others).  You're way out of your depth here.  Last time I wrote
code for X.25, it was carried inside SNA.

Original Ethernet had the peculiar property that it would add pad
bytes to the data without giving you any way to find out what was
data and what was padding, other than by trying to decode the various
protocol headers inside (of course, you had no way of knowing whether
the header itself was all there...).  IEEE 802.3 simply rectifies this
situation, bringing CSMA/CD into line with other media that do not
have this padding requirement.

This has nothing to do with IPX.

>	My recommendation stands: Ethernet_II is the frame of choice.
>It is the defacto standard

You haven't a shred of evidence for this.  Frame of choice for who?
CNEs?  Dealers pre-installing NetWare on servers?  Turnkey packages?
Don't most people who install red box NetWare use the default?

>, it is the fastest to manipulate

according to your code.  But we don't use your code, we use code from
Novell, Cisco, 3Com etc.  Perhaps you could give some figures showing
a significant performance difference in a real-world situation.

>, it carries the largest payload

Same as 802.3.  3 bytes more than 802.2, but only affects maximum-length
IPX packets - large packet burst transfers, NDS, custom uses of SPX and
IPX.  Again, simply not an issue.  If 3 bytes is critical, use token ring
and get hundreds more.  If it isn't, then forget about it.

>, it simplifies setups in servers and clients

What, even more simple than using the defaults?

>, it works with Packet Drivers, ODI and NDIS, it works well with
>real routers.

Please give more details.  ODI, NDIS and "real routers" (whatever
that means) work with all four frame types.  Not sure what you mean
about packet drivers.  If you need a packet driver interface for
compatibility with really old stuff, use ODIPKT.

------------------------------

Date: Thu, 21 Dec 1995 11:16:15 +0100
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: Novell's angle on frame types?

Arthur,

>...you're saying everyone who installs NetWare using
>the default frame type is inexpert and their networks are substandard.
>That's a pretty strong claim.

Everyone is entitled to make a standard & call it just that. It is
not a law. Joe's (and mine) suggestion/advice based on:
-   Eliminating as much as frames in a IPX/IP environment
-   Using one single, simple and well designed frame for most traffic
    on the wire.

>>        Ethernet_II is the frame of choice. This is a Novell list,
>>and the protocols of interest are IPX, IP, some EtherTalk,
>
>IP and EtherTalk have nothing do with IPX.  There is no purpose served
>by trying to make all protocols use the same frame type.  You don't
>have to get a very complex network before you are forced to use more
>than one frame type.  Our servers use all four types on Ethernet.

There is a purpose. It makes a cleaner/neater network. Routers have an
easier job. Instalations are more uniform.
Traffic can be less (remember each IPX network number per frame &
thus on every frame the same RIP/SAP traffic ?)

>>Aside from Novell's
>>NIH syndrome and a remote boot rom situation there is no reason to use
>>Ethernet_802.2. There is no reason to use Ethernet_802.3 aside from a
>>remote boot rom case.
>
>In both cases you might have other people in the organisation which
>use those IPX frame types.  After all they have been the default at
>various times.  The same goes for Ethernet_II (except it's never been
>the default) - local consensus may be to use it, but there's no
>overriding technical reason to.

Correct. It is an implementation choice. Every network admin is
entitled to make a mess out of his/her network that he or she is
responsible for.

>>So far as I can ascertain you haven't made a case for not using
>>Ethernet_II.
>
>I'm not trying to.  If I was, I'd probably say something about the
>management cost associated with not using defaults, especially global
>defaults affecting the whole network plan.  The cost may or may not
>be outweighed by benefits, depending on the environment...

Defaults may change in the future, without notice. One should set a
standard for himself to make a uniform environment. That does noet
say that one does not change a network plan ...

>>I'm not interested in isolated mainframe situations (SNA), nor in
>>X.25 over (essentially none of that near me)
>
>... which may be very different from Utah State University, USA.
>
>>There is nothing stopping people from creating protocols
>>which are dependent on physical framing details; whether we should pay
>>attention to them and their protocols is another matter.
>
>From previous discussion this appears to be a reference to X.25
>(and others).  You're way out of your depth here.  Last time I wrote
>code for X.25, it was carried inside SNA.
>
>Original Ethernet had the peculiar property that it would add pad
>bytes to the data without giving you any way to find out what was
>data and what was padding, other than by trying to decode the various
>protocol headers inside (of course, you had no way of knowing whether
>the header itself was all there...).  IEEE 802.3 simply rectifies this
>situation, bringing CSMA/CD into line with other media that do not
>have this padding requirement.
>
>This has nothing to do with IPX.
>
>>My recommendation stands: Ethernet_II is the frame of choice.
>>It is the defacto standard
>
>You haven't a shred of evidence for this.  Frame of choice for who?
>CNEs?  Dealers pre-installing NetWare on servers?  Turnkey packages?
>Don't most people who install red box NetWare use the default?

For those who run a environment/network on which most systems _can_
use Ethernet_II; IPX and IP.

Most people don't even know the difference between the frames or its
technical implications, evidence are the messages on the list this
week about people wanting to run IP over raw _802.3 or _802.2, and
people recommending to load just another frame on the server ...

>>, it is the fastest to manipulate
>
>according to your code.  But we don't use your code, we use code from
>Novell, Cisco, 3Com etc.  Perhaps you could give some figures showing
>a significant performance difference in a real-world situation.

Ask people from Cisco & 3Com, they'll tell you that _II rquires less
CPU cycles & lines of code on their routers. The difference ?
Probably some micro-seconds to a some milliseconds, you may not
notice it, but when your router gets cramped with 4 ethernet frames
running the same RIP/SAP and IP routing info then you see performance
going down and you keep plugging RAM in your routers just to keep all
these router tables.

>>, it carries the largest payload
>
>Same as 802.3.  3 bytes more than 802.2, but only affects maximum-length
>IPX packets - large packet burst transfers, NDS, custom uses of SPX and
>IPX.  Again, simply not an issue.  If 3 bytes is critical, use token ring
>and get hundreds more.  If it isn't, then forget about it.
>
>>, it simplifies setups in servers and clients
>
>What, even more simple than using the defaults?

Yes. Defaults change when some manufacturer or supplier decides it
for you.

>>, it works with Packet Drivers, ODI and NDIS, it works well with
>>real routers.
>
>Please give more details.  ODI, NDIS and "real routers" (whatever
>that means)

Cisco, 3Com, Wellfleet.

>work with all four frame types.  Not sure what you mean
>about packet drivers.  If you need a packet driver interface for
>compatibility with really old stuff, use ODIPKT.

Packet drivers use Ethernet_II since they provide an interface to
upper protocol stacks that want _II, for example IP.

------------------------------

Date: Thu, 21 Dec 1995 10:48:42 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell's angle on frame types?

>Original Ethernet had the peculiar property that it would add pad
>bytes to the data without giving you any way to find out what was
>data and what was padding, other than by trying to decode the various
>protocol headers inside (of course, you had no way of knowing whether
>the header itself was all there...).  IEEE 802.3 simply rectifies this
>situation, bringing CSMA/CD into line with other media that do not
>have this padding requirement.
>
>This has nothing to do with IPX.

	Has it occured to anyone else that a protocol which is dependent
on a MAC layer LEN field in a frame has become a non-routable protocol?
Just think about it for a minute. Said frame arrives at a router, the
media on the other side does not support the notion of 802.3 LEN field,
and the frame can't progress. Nor will said protocol survive the ordinary
"even-izing" that occurs as buffer lengths are rounded up to the nearest
word or double word in software. Deduction: IEEE 802.3 LEN field is without
practical value, at least as far as us routable protocol folks are concerned.
	Joe D.

------------------------------

Date: Thu, 21 Dec 1995 17:49:54 EST5EDT
From: Tom Tipsword <TOM@WILBUR.DB.ERAU.EDU>
Subject: Re: Novell's angle on frame types?

Enough already!  Or as your countryman, Will S., might have said:
"Avaunt Troubled Spirit and Cease Thy Endless Tendentious Frettings
and Struttings Lest Thou be Taken for a Witling!"  This thread has
gone on far too long to far too little purpose already.  While many
of us would find an informed, well reasoned technical discussion of
this subject educational and interesting (as indeed I personally find
all of Joe's postings to be), this ill-humored belaboring of a long
dead horse has become a waste of bandwidth and more than a little
tiresome.  Please do us all a favor and let this thread die.

I would also take the liberty of suggesting that before posting again
you might profit from taking a look at the FAQ for this list (which
is available from numerous sites including one of my boxes -- see
this URL: http://amelia.db.erau.edu/novell/faq/) and taking particular
note of the Hall of Fame section.  Many of us in the networking game
treat any post from those whose names are near the top of the list
much like that old E.F. Hutton commercial -- when Joe, or Stephen, or
Henno, or Richard (my apologies to our other esteemed colleagues
whose names I have omitted in the interests of saving bandwidth) talk
people listen.

------------------------------

Date: Thu, 21 Dec 1995 18:10:51 -0500
From: "A. Grant" <ag129@UCS.CAM.AC.UK>
Subject: Re: Novell's angle on frame types?

Joe Doupnik <JRD@CC.USU.EDU> writes:
>	Has it occured to anyone else that a protocol which is dependent
>on a MAC layer LEN field in a frame has become a non-routable protocol?
>Just think about it for a minute. Said frame arrives at a router, the
>media on the other side does not support the notion of 802.3 LEN field,
>and the frame can't progress. Nor will said protocol survive the ordinary
>"even-izing" that occurs as buffer lengths are rounded up to the nearest
>word or double word in software. Deduction: IEEE 802.3 LEN field is without
>practical value, at least as far as us routable protocol folks are
>concerned.

This is an interesting claim and one that deserves a reasoned rebuttal.

In most data links the payload size can be deduced from frame size
without the need for a length field.  This includes cases where the
protocol is encapsulated in some other protocol's payload; it also
includes non-CSMA/CD IEEE 802.x media, point-to-point links and so on.
So, in most cases an explicit length field would carry no information.

CSMA/CD is unusual in that short frames must be padded so that the
collision detection works.  Hence in this case, if there is to be a
general indication of PDU length that is independent of protocol,
it has to be via an explicit length field.

I can't, off-hand, think of anything besides old-style Ethernet framing
(or, as you say, if someone gives you data in a buffer with no
indication of data length) that has this property of not indicating
in a content-independent way, either implicitly or explicity, the
true size of the data that it is carrying.

So yes, if for some reason you have to use old-style Ethernet framing
on a cable, there are some protocols you can't route to that cable
directly as frame payload or put in a buffer without indication of
length.  That doesn't make them non-routable protocols.

Incidentally, ATM is another example of a media which requires
payload padding (to multiples of 48 bytes, in this case).  Do you
consider that the AAL5 length field is "without practical value"?

------------------------------

Date: Thu, 21 Dec 1995 16:30:29 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell's angle on frame types?

	<omitting much, again>
>Incidentally, ATM is another example of a media which requires
>payload padding (to multiples of 48 bytes, in this case).  Do you
>consider that the AAL5 length field is "without practical value"?

	Sticking to one topic: Ethernet_802.3 frame LEN field:
	To prove its lack of worth we do a simple experiment. Route the
frame to an Ethernet_II wire. If the protocol is routable then it survives
the hop just fine, else it doesn't. Since LEN does not exist on the Ethernet_II
side and the protocol works just dandy anyway then LEN is not necessary for
proper operation of the protocol. IP, IPX, and many other protocols are so
routable (or, putting it another way "media independent").
	QED (I'll have to fall back on Latin since my Shakespeare is rusty
and yet this is a high class list).
	Joe D.

------------------------------

Date: Fri, 29 Dec 1995 09:56:02 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: 802.2 and 802.3 necessary for RPL

<snip>
>However, for RPL (Remote Program Load for diskless stations with
>ethernet cards equipped with a boot ROM) I have found that it's
>necessary to use both 802.2 _and_ 802.3, despite the fact that
>RPL itself is only bound to 802.2.
<snip>
--------------
	Yes, indeed. A couple of months ago I presented a section of
autoexec.ncf dealing with a) IP subnetting and b) dual IPX frame kinds
to handle remote booting on one of my systems. It's file subnet.txt in
directory misc on netlab2.usu.edu, in case anyone is interested.
	There appear to be about three basic remote boot protocols floating
around, with the oldest using Ethernet_802.3 for IPX only (natch), IBM's
flavor using Ethernet_802.2, and a "new IPX" (or somesuch expression) which
can use Ethernet_II. I ended up with roms for the oldest flavor, because
they were at a price I could afford. There is an outfit in Canada which
makes super boot roms (BootWorks, ??) at a hefty price, and those
apparently can do whatever the system manager wishes. In any case, we can
be stuck with dual frames for IPX.
	So in the case at my place I bind IPX to two frames within the
student lab and one on the wire going to the backbone. Ethernet_802.3
is used only during the boot process by the boot rom itself; the ODI board
driver uses Ethernet_II. That means the bootrom code finds a server with
the 802.3 frame, loads the boot disk image file with it, then turns off.
Everything from that point forward uses Ethernet_II frames, and IPX
checksumming is turned on. Ethernet_802.3 frames on backbone wiring is
strongly discouraged (this lab obeys the rule) and our Ciscos are
configured to route IPX only if Ethernet_II frames are used.
	As a matter of historical interest, my place lived through the days
of machine crashes (NW servers & non-NW machines) when Ethernet_802.3 frames
hit the backbone. I went to some trouble to patch our board handlers (the
monolithic ipx.com programs) to convert to Ethernet_II frames with the aid
of BYU's patch code plus some binary editing by hand; that was not much fun.
Back then Novell had hundreds of servers on their company net, all using
Ethernet_802.3 and not one connection to the outside world nor other kinds
of networking. The experience of my University, amongst others, came as a
surprize to them. Thankfully matters as a whole have improved over time.
	Joe D.

------------------------------

Date: Sat, 30 Dec 1995 14:14:38 -0500
From: "Philip R. Reznek" <preznek@SUNBELT.NET>
Subject: Re: 802.2 and 802.3 necessary for RPL

On 30 Dec 95 at 9:41, Teo Kirkinen <NOVELL@LISTSERV.SYR.EDU> wrote:
> Theodore Hope (hope@CHANCHAN.PNIC.PNUD.ORG.PE) wrote:
>>We run lots of Netware 3.12 networks with diskless stations for our
>>projects, and aside from loading the standard RPL on the server and
>>binding it to an 802.2-frame board, I _also_ have to bind IPX to
>>an 802.3-frame board (same board, different LOAD *.LAN).  I have not
>>been able to get RPL working with only 802.2 and Ethernet_II.
>
>Have you tried Lanwork Inc's Bootware bootrom? We are moving
>from bridged 802.3 to switched/routed 802.2 network and have
>just tested the current version of Lanwork's roms (in fact the
>OEM version made by SMC) and they seem to boot fine with 802.2
>frames. Two years old bootroms didn't. One part of the solution
>is to switch from Novell's RPL.NLM to Lanwork's Bootware/MSD
>-server but it's not expensive and it's much better.

A caution:  I think there are three flavors of BootWare extant, and
not all of them support multiple frame types.  BootWare Plus as I
recall handles 802.2 & 802.3.  Some may support Ethernet_II.

Some of our suppliers have had stale versions of the product.

BootWae/MSD is way cool.

------------------------------

Date: Fri, 16 Feb 1996 12:26:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: IPtunneling

>>Daniel Tran writes:
>>>Can you get a NetWare client to 'see' servers running ethernet 802.3 and
>>>servers running an IPTunnel only?
>
>>Solution: get rid of 802.3 and use ethernet_II
>
>Then Alastair Grant responds:
>At risk of bringing up frame type wars again, this is completely
>irrelevant.  IPTUNNEL is a logically distinct frame type.  The IP
>tunnel appears as a logical LAN.  (Indeed one can apply LAN emulation
>tricks to scale large IP tunnel networks efficiently... but that is
>another story.)
>
>On the server, you can bind IPX to any or all combinations of
>frame types including the four Ethernet_... types and IPTUNNEL.
>Choice of IPX Ethernet frame type might save you loading an extra
>logical NIC, that's all.
>
>On the client you can only bind IPX to one frame type.  It doesn't
>help if you are running IPTUNNEL-over-TCP/IP-over-Ethernet_II, you
>still won't be able to bind IPX to IPTUNNEL and Ethernet_II.

	Maybe the words are still a little confused here. IPTUNNEL
is not a frame type. What is really happening is LSL is offering up
logical boards to IPXODI and IPXODI chooses one it wants. Unless
instructed otherwise it grabs the first logical board it can deal
with. First, second, etc logical board numbers are created by the
order in which MLID (board drivers) are loaded at the DOS prompt,
and within each the order in which virtual boards are created by
frame statements (for IPX) and more correctly by protocol statements
for everything else.
	IPTUNNEL works by creating a fake MLID to the LSL, and below
that IPTUNNEL grabs ahold of the TCPIP stack as its transportation.
It's a dual pass through the LSL:

		applications
		   .
		   .
		IPXODI      ........> TCPIP
		   .        .           .
		---.--------.-----------.-----
	       |   .    LSL .           .    |
		---.--------.-----------.-----
  fake ->       iptunnel    .          real             <- real
  MLID             .        .          board              MLID
		   ..........           .
				       wire

	In cases of multiple choices being available and we don't want
the first then a BIND clause is needed to steer the item to the proper
selection; that is the entire and only purpose of a BIND clause. For
IPTUNNELing we do not want the default/first choice, which is direct
to the real MLID.
	IPTUNNEL uses UDP/IP material on the wire.
	Joe D.

----------

	Following up one's own post is regarded as silly or worse. Ok,
pin the label and I'll wear it for today.
	What I think I need to do is clarify the logical boards business
just a little.
	MLIDs (board drivers) register themselves with the LSL. Each MLID
can offer frame types, and each frame type constitutes a virtual board.
The order of virtual boards is thus the order in which the MLIDs load at
the DOS prompt (or equivalent) and with each the order of appearance of
the frame subclauses.
	Novell has arranged matters such that IPX is a protocol name tied
to each virtual board, automatically. Other protocol names can be tied
explictly via protocol subclauses, or implictly through the actions of
an application (aka "protocol stack"). MS-DOS Kermit and others use the
explicit manner, LWP/DOS uses the implicit one.
	Given that IPX is tied to each logical board there are a bunch to
select from in the IPTunnel case. IPXODI chooses the first unless directed
otherwise by a BIND statement for IPXODI. Kermit has its own section of
net.cfg and hence its own BIND statement, etc.
	BIND subclauses direct the protocol stack to seek the stated target
while asking the LSL about available logical boards. A stack can ask all
kinds of questions about boards and make its own choices as it sees fit,
but it's supposed to obey BIND directives if at all possible.
	The LSL is ODI's management team, the arbitor of all things ODI,
and hence it is loaded first so the other components can check in and
register for work.
	To point IPXODI at the fake MLID IPTunnel, rather than at the real
MLID, we need to BIND appropriately. ODIPKT, unfortunately, numbers board
from 0, despite the rules, but everything else starts at board 1.
	Ok, where's that conical hat?
	Joe D.

------------------------------

Date: Tue, 27 Feb 1996 08:38:49 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Client frames

>> I continually had problems with ODIPKT, and WINPKT until I moved Ethernet_II
>> to be the first defined frame type in the workstations NET.CFG.
>>
>> Link Driver <driver Name>
>>    FRAME ETHERNET_II
>>    FRAME <next frame name>
>
>Can you have more than one frame type in the NET.CFG?  I tried this and it
>seemed to me that only the first frame type was used and the others did not
>run.
----------
	Two birds in one message.
	First, NW clients do not route IPX traffic. Therefore IPX can be
bound to one logical board only, period.
	Second, logical boards are created with every frame statement. IPX
binds to the first it finds (in the order listed in net.cfg) UNLESS you
instruct otherwise. That instruction is the BIND subclause under major
heading PROTOCOL IPX. If you have multiple MLIDS (board drivers) loaded
for some reason then logical boards are numbered from 1 on up starting with
the DOS load order of MLIDS (not their order of appearance in net.cfg) and
for each board each frame creates a new logical (in their order of appearance
in net.cfg).
	BIND is a subclause. It never appears without indentation. It is
related to the major clause (never indented) for a protocol. Its only purpose
is to select among alternatives. Like this:

Protocol KERMIT
	bind ne2000
;       bind telebit
;       MYIP   129.123.247.1

Protocol LATDRVR
	bind #1

Protocol IPX
	bind #1

	These days IPXODI understands only logical board number, not the
shorthand MLID name. Kermit understands both forms of BIND.
	Dan Lanciani's ODIPKT shim still numbers logical boards from 0
rather than from 1.
	Joe D.

------------------------------

Date: Sat, 2 Mar 1996 21:24:55 GMT
From: "Stephen M. Dunn" <stephen@BOKONON.USSINC.COM>
Subject: Re: Multiple Frame Types

>	I am in the middle of a project which will convert all of my 3.12
>servers from using 802.3 to 802.2.  I have noticed by default on my work
>stations ipxodi binds to the first frame type automatically. How do I get
>it to bind to a second frame type.  My goal is to have the workstations
>use both 802.2 and 802.3 untils I convert all the servers.  What do I
>need to put in my net.cfg.

  IPX on workstations only binds to one logical card.  That means
one card, one frame type.  You can pick which one, but you can't pick
_more_ than one.

>LINK DRIVER 3c5x9
>   FRAME ETHERNET_802.3
>   FRAME ETHERNET_802.2
>   Protocol IPX 0 Ethernet_802.3

will make it bind to the 802.3 frame type, and

    Protocol IPX E0 Ethernet_802.2

will cause IPX to bind to 802.2 instead.

------------------------------

Date: Tue, 5 Mar 1996 09:17:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Frame types again, sorry

>	I have one last question about diffrent frame type.  I have about
>500 workstations running 802.3 and 10 servers doing the same.  What is
>the best way to convert my workstations and servers to 802.2 or
>ethernet_ii.  I have been told you can not bind more than one protocol to
>multiple frame types on a workstation.  Is this true?  Another option is
>to load both frames type old and new on  the servers.  I tried this.  The
>servers gave me some kinda routing error.  I think it has to do with the
>fact that I had to give the BIND command a diffrent network number from
>the first bind command.  Is there some kinda NLM I need to load to manage
>multiple frame types on the server?  Any input would be helpfull.
------
	Each frame constitutes a different IPX network number. Migrate by:
	a) Loading Ethernet_802.3 (old) and Ethernet_II (new) on the
servers.
	b) Move workstations to the new frame. They learn network numbers
from servers so just change the frame material. See the list's FAQ for
examples.
	c) Look at utahstd.txt (utahstd.doc in the FAQ) on how to number
your IPX networks. See also subnets.txt in directory misc on netlab2.usu.edu
for dealing with numbers while having multiple frames on a wire.
	d) Consider running NLSP to reduce RIP/SAP traffic between servers.
That's updates\nwos\<your server version>\ipxrt3.exe or similar from
ftp.novell.com and official mirrors.
	Joe D.

------------------------------

Date: Sat, 20 Apr 1996 07:41:43 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Which Ethernet Frame type and why?

>I've seen recommendations from various sources (like the venerable
>Joe D.!) for the Ethernet_II frame type. I have a few questions....

	Our first pointer for information on this topic is Don Provan's
note in the list's FAQ (it's also file ethernet.txt in directory misc
on netlab2.usu.edu).

>1) Why does II come so highly recommended? What performance advantages
>   will Ethernet_II provide over, say, Ethernet_802.3?
>   (faster? more reliable?)

No, none of those vital protocol-related things, alas. It's just
a way of packaging bits for transmission on the wire.
We start by noting that Ethernet_802.3 is a mistake, something which
ought never have happened and is in violation of the rules, but which
has been worked around in modern software. Because of the mistake only
IPX traffic can use it, and only ancient installations with a big
conversion problem should be using it, and only certain remote boot
situations still require it.
	The world's Ethernet networks use Ethernet_II because it
is the accepted standard, it is the most efficient frame. The
competing formats don't have either attribute, nor the carrying
capacity, nor the encode/decode efficiency (cpu cycles where they
really count), nor anything else to recommend them.

>2)  In what situations would Ethernet II NOT be advantageous?

When running Appletalk which requires Ethernet_SNAP. When you are
stuck with old Ethernet bootroms which use only Ethernet_802.3,
yet that frame is needed ONLY during loading the remote boot image.
I have those roms here and that frame is used only for the few seconds
of remote boot image loading. An example autoexec.ncf for this
situation is shown in file subnet.txt in directory misc on netlab2.

>3) Lastly, are there any specific requirements needed to implement
>Ethernet II on our network?

Just convert. Changing client NET.CFG files is straight forward if
tedious, but do it. To solve the time-to-finish problem configure
your servers with proper IPX network numbers for Ethernet_II frames
and then a temp set of IPX network numbers for Ethernet_802.3. Bind
IPX to both during the transition; remove Ethernet_802.3 when done.
To help with IPX network numbers please have a look at document
utahstd.txt in directory misc on netlab2; it is a widely accepted
naming and numbering method (it works well).
	Joe D.

------------------------------

Date: Wed, 22 May 1996 11:06:41 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Adding a 2nd frame type to a 3.12 server -Reply

>>I have been following the Ethernet_II and Ethernet_802.2 debate for some
>>time.  The reason I am leaning towards Ethernet_802.2 frame is because
>>several other 4.1 servers already have that frame installed.  Another
>>reason is that 802.2 is the Default frame of choice for Novell NetWare.
>>I guess I don't see any major advantages of Ethernet_II over
>>Ethernet_802.2 and there are down sides to Ethernet_II as you mentioned.
>
>Have you met Professor Doupnik? I suspect you may receive some gently worded
>correspondence from him in the near future given that last sentence...
--------
	Enter, stage left:
	There are situations where non-Ethernet_II frames are needed. One
is Appletalk (Ethernet_SNAP) for reasons known only to Apple. Another is
lan adapter remote boot proms of old vintage (Ethernet_802.3), which afflicts
a couple of my labs. Some newer proms require Ethernet_802.2. These remote
boot cases use such frames only during remote booting the floppy disk image,
and thereafter we can go to Ethernet_II frames (as I do). Old printer boxes
using Ethernet_802.3 only must be extremely old indeed and well overdue for
retirement.
	The advice is use Ethernet_II and end your troubles. The network
will continue to grow, so design it correctly now.
	Let me add another aspect to the too-many-frame-types discussion.
The LSL and medium support worker (MSM) have to decode frame kinds upon
packet reception. The more kinds the longer this process takes, for every
packet. There are strong indications this is already a problem with fast
Ethernet. Ethernet_802.2 frames are so bungled that the overhead on them is
largest of any frame, and that isn't helping anyone. Hint to Novell: let's
stop loading all four Ethernet frame kinds on clients, please.
	Joe D.

------------------------------

Date: Wed, 22 May 1996 13:01:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: IPX across the WAN

>I have two ethernet LANs, attached to each other using a Megastream
>(2Mbps), and two identical Ciscos. The Ciscos are configured to a bare
>minimum, i.e. no filters, or anything in addition to the required network
>configuration.
>
>I have Netware servers on both LANs.
>
>From one end of the MStream, I have a problem whereby I can only log onto
>the servers at the other site if I have 802.2 frame type set in my
>net.cfg, either as the only frame type or if it's the first in the Link
>Driver section.
>
>The servers on both LANs have all frame types (that's to say 802.2, 802.3
>and _II types) loaded, and LAN workstations on both sites can all log
>into their own local servers without problem.
-----------
	Don't use multiple frame kinds. Please do pick up your Cisco manual
and read about how Cisco decides what's a NetWare frame (singular, not
multiple). See earlier traffic today on frame kinds. Please contact Cisco
for help on their routers.
	Joe D.

------------------------------

Date: Wed, 22 May 1996 21:01:59 +0100
From: Eric Hall <ehall@NWC.COM>
Subject: Re: IPX across the WAN

>The servers on both LANs have all frame types (that's to say 802.2, 802.3
>and _II types) loaded, and LAN workstations on both sites can all log
>into their own local servers without problem.

If memory serves correct, Ciscos only support one frame type for IPX. Make
sure that the LAN interfaces on BOTH routers are set to the same interface
type.

Also, unless your local server is routing IPX between the different frame
types, you won't see the remote server UNLESS you use the frame type in
use on the router's LAN port.

------------------------------

Date: Wed, 22 May 1996 14:44:43 -0800
From: Kevin Kelly <KELLY@WPOFFICE.WHITMAN.EDU>
Subject: Re: Adding a 2nd frame type to a 3.12 server -Reply -Reply

Thanks for the information Joe.  My current understanding of frames, this
may change -)

Ethernet_SNAP - Needed for MACs, unless you start using the new Novell MAC
IPX client.

802.3 - Junk, get rid of it...  No IPX checksums, no packet signatures...
May be needed for some printers and boot roms...

802.2 - Novell Netware default, but takes more processing by the client and
routers to process...  May be needed for some boot roms...  Has IPX
Checksums and packet signatures.

Ethernet_II - Needed for TCP/IP anyway.  Best choice for IPX as well.  Has
IPX Checksums and packet signatures.

------------------------------

Date: Fri, 24 May 1996 09:41:30 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Adding a 2nd frame type to a 3.12 server -Reply

>On 22 May 96 at 11:06, Joe Doupnik wrote:
>><SNIP>
>>Let me add another aspect to the too-many-frame-types
>>discussion. The LSL and medium support worker (MSM) have
>>to decode frame kinds upon packet reception. The more
>>kinds the longer this process takes, for every packet.
>>There are strong indications this is already a problem
>>with fast Ethernet. Ethernet_802.2 frames are so bungled
>>that the overhead on them is largest of any frame, and
>>that isn't helping anyone. Hint to Novell: let's stop
>>loading all four Ethernet frame kinds on clients, please.
>>Joe D.
>
>On 23 May 96 at 11:17, Joe Doupnik wrote:
>>>Just out of curiosity, how do I load multiple frame types on a client?
>>>I know how to do it on the server.
>>
>>	a) install recent NW shells
>>	b) see this example from my net.cfg
>>
>>Link Driver NE3200
>>	SLOT 1
>>	INT 5
>>	Frame Ethernet_II
>>	Frame Ethernet_SNAP
>>	Frame Ethernet_802.3
>>	Frame Ethernet_802.2
>>	Protocol   IPX 8137 Ethernet_II
>>	Protocol   IP 0800 Ethernet_II
>>	Protocol   ARP 0806 Ethernet_II
>>	Protocol   RARP 8035 Ethernet_II
>>	Protocol   LAT 6004 ETHERNET_II
>>
>>	Please note: NW clients can use IPX on only ONE (1) frame; clients
>>do NOT route between IPX networks.
>>	Joe D.
>
>OK, using the example above, I see four frame types being
>loaded, but all of the "Protocol"s are using Ethernet_II.
>Assuming that there were no other entries in the NET.CFG
>file referring to the three unused frame types, does
>having them listed in the NET.CFG file cause unnecessary
>work for the NW client?  (i.e. because Frame Ethernet_SNAP is
>defined in the Link Driver section, will the NW Client try
>to decode an incoming packet into this frame type if it
>hasn't already been matched to the Ethernet_II frame type?)
>
>Put another way: The only frame type listed in my NET.CFG
>is Ethernet_II. If a non-Ethernet_II framed packet arrives,
>I assumed that the NW client would recognize that it is not
>an Ethernet_II framed packet, and discard it.  If I had
>more than one frame type in my Link Driver section, after
>recognizing that the packet was not Ethernet_II framed,
>would the NW Client go on to try and decode it as the next
>frame type in my NET.CFG, even though all the "Protocol"s
>point to Ethernet_II?
>
>I guess I always thought (usually my first mistake) that a
>FRAME in NET.CFG without some PROTOCOL using it, was about
>as useful (or as harmful) as a blank line or comment line.
>
>Based upon what Joe D. sayed in the quoted text above
>from 22 May 96, I believe the answer to my question is
>"Yes, it does more work", but I can't fully mesh Joe's
>comment into my question without making more assumptions,
>which I've reached my limit on for today.
------------
	Each FRAME line creates a separate virtual board within ODI.
Each PROTOCOL line defines an association between the name that follows
(which is the name of a protocol) and the frame kind associated with it,
plus the decode identifier within that kind. PROTOCOL lines are not tied
to that particular lan adapter, alas, and are thus global to net.cfg.
	The LSL keeps track of these items. It's the manager of ODI.
	Each usual ODI lan driver (MLID) normally offers built-in support
for protocol IPX, which is why some folks get by with skimpy net.cfg files.
	A protocol stack can make ODI calls to register a protocol name
with the LSL with the same result as having a PROTOCOL line in net.cfg.
Lan WorkPlace for DOS does this. Alas, such a tactic means knowing the
decode ident for every possible frame kind. Too cute.
	Some apps/protocol stacks can take whatever comes in rather than
just a particular protocol ident on a particular frame kind. ODI is very
flexible about that. NDIS, the 3Com/Microsoft thingy, works by receiving
a frame, any frame, and offering it in turn to every registered protocol
stack. It is a polling approach. PROTOCOL lines lets ODI decode the ident
and direct the frame to the specific protocol stack without the busywork.
	Novell's ODI to NDIS converter ODINSUP requires all four Ethernet
frame kinds to be supported. Client32 prefers to as well. Neither "must be"
that way except by choice of the guys writing code in that style.
	IPXODI is an aggressive protocol stack. It grabs the first logical
board offering IPX support, unless you direct otherwise with a) a PROTOCOL
line, and/or b) a BIND clause when there are multiple physical boards.
Kermit's TCP/IP stack is a considerate ODI protocol stack: it neither forces
in an effective PROTOCOL line nor does it grab the first thing seen willy
nilly. And it uses full net.cfg syntax capabilities for BIND clauses, etc.
It's about the only place where one sees source code to deal with ODI in
detail. ODI tech docs are found on netlab2.usu.edu in the ODI directory.
	The only reason to have all four frame kinds listed is to placate
Novell's shells, which may in turn try to support the NDIS stuff. If you
can get away with less please do so.
	Each FRAME line adds one more item to test for every incoming frame.
	I'm a developer, and as such I often run rather unusual combinations
of things (sigh) and change the setup just as often. So my poor net.cfg file
is just filled to the brim with boards and other things. I have two Ethernet
boards in my desktop PC to cope with some combinations, and ODI is just
great for handling both boards and several protocol stacks over those boards.
	Joe D.

------------------------------

Date: Fri, 24 May 1996 10:08:28 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: 802.2 and 802.3

>I have a client that needs to see two servers, one with the
>802.2 frame time and the other with the 802.3 frame type.
>Do to restrictions I can not change either of the servers
>frame types and can not bind a second frame type to one
>of the servers. Interesting ?
>I though that if I put the following into the NET.CFG the
>client would see both servers but it only sees the server
>which is the first on in the list.
>	FRAME Ethernet 802.3
>	FRAME Ethernet 802.2
----------
	Your client has dug a deep hole. We just went through this
yesterday on the list. NW clients do NOT route, they use only one frame
for IPX and hence one IPX network, period.
	Tell your client to get their act together, purge both above
frame kinds, use Ethernet_II, and get a networking consultant in to solve
their topology and security-worry problems.
	Joe D.

------------------------------

Date: Tue, 28 May 1996 10:18:26 +0200
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: Switch from 802.3 to ethernet_ii

>We're planning to switch from ethernet_802.3 frames (a leftover from
>Netware 3.11; and we were wondering why NCP security didn't work :-)
>) to either 802.2 of ethernet_ii (depends on the bootproms we're
>using all over the place). We've planned to switch one small segment
>over coming tuesday (an education-free day), to find out if the
>complete switch is going to present any possible problems. Are there
>any points we should pay extra attention to? Most of the workstations
>are already running VLM, and this is how the driver section of
>some of the net.cfg's looks like:
>
>LINK DRIVER 3C5X9
>	FRAME ETHERNET_802.3
>	FRAME ETHERNET_II
>	FRAME ETHERNET_SNAP
>	protocol IP 0800 Ethernet_II
>	protocol ARP 0806 Ethernet_II
>	protocol RARP 8035 Ethernet_II
>
>I suppose the PROTOCOL IPX line has to be changed so something else,
>could someone indicate what this should be? Is a line like that
>really needed, or will it work correctly without?

I would not recommend using the Protocol IPXODI line for changing
frames, it is confusing. Let IPXODI have the first frame, change your
net.cfg to:

LINK DRIVER 3C5X9
	Int ??
	Port ???
	FRAME ETHERNET_II
	Protocol IPX  8137 Ethernet_II
	Protocol IP   0800 Ethernet_II
	Protocol ARP  0806 Ethernet_II
	Protocol RARP 8035 Ethernet_II


>Is there anything that can be said in advance about the supported
>frametype by bootproms? We're running mainly with D-LINK DE-220, SMC
>8000 or NE-1000 NIC's, with a complete new lab coming up on HP 100VG-
>Anylan.

A lot of people just run _802.2 just for rpl, and have the frame
changed to _II in the net.cfg, shouldn't be a problem.

>What if the bootproms don't support Ethernet_II. Will we then need to
>bind IPX to 802.2 on the server? I suppose so, but this will require
>a change to all net.cfg's. Is it possible (and efficient) to bind IPX
>to Ethernet_II too?

No & yes. The boot prom's require _802.2 on the server, not in the
net.cfg, which sits inside the boot-image. Just use the net.cfg part
above & you will see that your systems boot via _802.2, load the
image & connect to the net via _II.

>Anything else you would like to share with me on this subject? :-)

Keep the _802.2 stuff local by reconfiguring your routers to _II and
blocking anything else.

------------------------------

Date: Wed, 3 Jul 1996 12:06:47 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Multiple Protocol in NET.CFG file

>Does anyone know how (or whether it is possible) to bind IPX to
>mulitple protocols?  We are changing IPX protocol bindings soon (due

	Well, picking nits, the term is frames rather than protocols, even
	if Novell has overburdened the word "protocol" in net.cfg.

	The answer is no. IPX attaches to one and only one frame and hence
	one IPX network number because clients are unable to route IPX
	(routing is needed when comms pathway alternatives are present).

	The suggestion is just change client net.cfg files, reboot them,
	and in two minutes the switch is completed. Then unbind the
	[old] frame kind on the server.

------------------------------

Date: Mon, 8 Jul 1996 20:31:44 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Multiple Protocol in NET.CFG file

>In the workstation, one protocol and one frame type for the VLMs.
>
>In the server it is different.  You can use multiple frame types per
>protocol.
>
>I have not done tested the 32 bit client which is based on the server NLMs.
>Has anyone else?
---------
	It's not the lan adapters, nor ODI, but rather the IPX software
above them that determines whether or not a machine can maintain multiple
connections and possibly route too. Each frame kind counts as a different
logical path between systems. Certainly such software could be written,
but one thinks the benefits would be small overall, not to mention the
increased size and complexity. Reducing the frame farm to one animal
solves the problem much more easily.

	On the subject of multiple frames, here's a hillarious (I thought
so, user's didn't) mini-story of a situation at my place last week. We
turned on NLSP in our Ciscos and lost all that nice RIP/SAP filtering.
One server had two frames attached, Ethernet_II for normal use and
Ethernet_802.3 for a handful of old boot rom stations. Fine, I do the same
on two servers. But both frames attached to the local backbone, and that
in turn had a Cisco connection to the campus as a whole. So what, you say.
	Well, without filtering the Cisco could hear material on both
frame kinds. In comes an NLSP message on Frame_II, into the server it
goes, one hop is added to the routing database, and out it comes onto
the other Frame_802.3 to ensure that area of the world gets the word (one
hop later). Back to the Cisco it goes, an update is triggered from
the new hop count, broadcasts are sent everywhere. Further input from
abroad corrects the Cisco, down Frame_II goes the new new material,
round the bend it goes in that server emerging one hop later, ... as fast
as the network could go.
	It led to a minor broadcast storm which brought down some machines
and bothered the rest, on the whole campus. It took only a short time (a
day) to figure out that was the situation, and we did some logical wire
yanking to stop it. As of today NLSP is turned off in the Cisco routers
and we are back to normal RIP/SAP filtering operations.
	Given that state of affairs, only very brave system managers would
give multiple frame and routing capabilities to every client desktop.
	Joe D.

------------------------------

Date: Wed, 16 Oct 96 10:47:22 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Re[2]: Macintosh client...

>Thanks a lot. I was a bit confused because I was able to select Ethernet
>_SNAP, II, 802.2 or 802.3 from the Macintosh client. I always thought
>that I what not necessary to load AFP if I only wanted a simple access
>to the NW server. I'll try again.

A bit of confusion here. If you're using Appletalk you need Ethernet_SNAP
at the server. The Mac IPX client does NOT need snap; set it to whatever
frame type you have bound to IPX at the server. This is the SAME as the
more traditional PC clients. How do I know? I'm using 802.2 on the Mac
I'm writing this on!

------------------------------

Date: Wed, 16 Oct 96 10:47:19 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Fundamental 802.2 & 802.3 question.

>I am studying for my CNE and have become a bit confused on one issue...802.2
>vs 802.3.  I know that NetWare 4.x and 3.12 use 802.2 for default and older
>versions use 802.3.  However, it seems that according to the protocol stack
>that both would be necessary...802.3 providing physical and MAC
>specifications and 802.2 providing LLC needs.  Where have I lost my way?

In bad naming, not your fault. See, what Novell calls 802.3 is more
accurately termed 802.3 RAW. the 802.2 LLC should be in there, but they
didn't implement it properly, hence the distinction. 802.2 really does
sit inside a proper 802.3 packet. Any of your materials dealing with
frame types should be able to explain this properly, just remember when
talking about IPX packets, think 802.3 RAW when you read 802.3.

------------------------------

Date: Mon, 21 Oct 1996 19:21:53 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Ethernet_II vs 802.3 -Reply

Look, will you lot stop talking about what you don't know! if I see another
post which starts "I can't comment on... " and then does I'll spit nails.

The difference in speed types between ethernet_ii and 802.3 will be minimal
ethernet_II might be slightly faster, but we're talking microseconds in
milliseconds here folks. if you can measure the difference then you have more
problems than just frame type.
[the LSL packet de-multiplexer can use the frame-type field rather than then
having to check the data portion of the frame to ensure it really is an IPX
packet before passing it to the IPX protocol stack for further decode]

OLDER boot-roms have supported both 802.3 and ethernet_II frame types since
before I installed my first netware 2.12a fileserver. check the configuration
guide for NE2000 [original] cards and you'll see the settings for 'ECONFIG'
booting.

NEWER boot-roms generally only support ethernet_802.2 and Ethernet_802.3
frames. There is NOTHING stopping you using either of these for remote boot
and THEN switching to ethernet_II after the boot process has finished (which
is what we do here on some networks). the advantage of ethernet_802.2 (or RPL)
style booting is you can have wild-cards in the bootconf.sys (and that is it
as far as speed/performance.ease of use/ anything else goes).
If you are running Netware 4.1, then use INETCFG.NLM and switch off forwarding
from the frame type you use for remote-booting and SAP/RIP general service
broadcasts)

If it aint BROKE: if you are happy using your current framing then switching
to something else only make sense if you're going to gain something out of it.
802.3 is a LOOSER. you gain NO functionality or speed by moving to it.
802.2 is weak, if only becuase if you have TCPIP loaded, then it is another
frame type LSL has to deal with (okay, a couple of dozen bytes if you have LSL
trimmed down on the max boards) ethernet_II is better as you'll probably have
that loaded anyway if you've any Internet Access requirements.

Ethernet_802.2 and ethernet_II CAN (if you CHOOSE to use it) give you packet
checksumming which is important to poeple running database applications where
packet corruption might be a problem. (IPXODI is alas not that good at
spotting bad IPX packets and they occasionaly make it up to the next layer
(OOPS!))

>Not your CNE Dude, the only reason to run 802.3 is if you have older
>boot rom's or something that can't use Ethernet_II. Since you say you
>are already running Ethernet_II I see no reason to switch back to
>802.3.

I agree with Ian.

------------------------------

Date: Wed, 13 Nov 1996 18:24:57 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: IP Configured on Print Servers

>>erm, If you use FDDI_SNAP for IPX on the FDDI network it will come out of the
>>LanPlex 2500 as ETHERNET_II and hence is a Good Thing
>>
>>FDDI_802.2 is useful if you have RPL boot roms, but I'd not reccomend it if
>>you've a mixed ethernet/fddi environment.
>
>	That's interesting. We use the Cabletron Smartswtich here and the
>Bay 5000 at another site. We use FDDI_80.2 on the servers and when the box
>switches it, it comes out as ethernet_80.2. I have never tried a3COM
>Lanplex 2500.

This is correct, see the table below (copied to the Novell List)

	FDDI    --------> Bridge -----> Ethernet
	FDDI_SNAP                       ETHERNET_II
	FDDI_802.2                      ETHERNET_802.2
	FDDI_SNAP       possibly        ETHERNET_SNAP
	FDDI_802.3 ??? non-standard     ETHERNET_802.3

The last one may be fddi_raw, but I'd not reccomend using that as other FDDI
connected devices (routers) may get upset. FDDI has never had the ethernet_II
format type frames allowed.

I've never come across a transparent/translating bridge that does a
FDDI_SNAP/Ethernet_SNAP conversion, all I've encountered do a SNAP<>II
conversion.

I quite like the LanPlex2500, it's got a bash-like interface which asks you
if you mistype things...

------------------------------

Date: Tue, 19 Nov 1996 10:20:31 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell HTTPD and token ring

>We recently moved a Netware 4.11 server running the Groupwise WebAccess
>Gateway v4.1 on top of HTTPD version 2.00a from a test environment on
>Ethernet to our production token ring server backbone.  Before the move,
>both Ethernet and token ring clients could access the gateway with
>relatively speedy (and similar) response times. Since the move, Ethernet
>clients continue to enjoy snappy response times, but response times for
>token ring clients have increased to the point of non usability.
>
>Although maximum physical receive packet size is set to 4202, and the
>token ring interface is the only board driver loaded, the server will
>respond to a maximimum ICMP PING packet size of 2042 bytes. Interestingly,
>pinging a Netware 3.11 server reveals that 2042 is also the upper limit
>recognized by its IP stack, as well.  Currently the server is plugged into
>a dedicated port on a Centillion 1500 switch which is also connected to
>our four Bay BCN backbone routers.
>
>Has anyone else seen this problem and devised a workable solution?
-------------
	Ethernet frames are limited to 1500 bytes of data. Token Ring frames
are limited to the 4KB value.
	Ping uses ICMP over IP packets. IP packets which are longer than
the frame size on the media need to be fragmented or dropped. IP fragment
reassembly buffers are limited in size (64KB max) determined by the program
author. Reassembly can involve many original packets simultaneously and
thus buffer size becomes important. A 2KB buffer is a generous value so
don't complain.
	Generally speaking, set the system to use frames no longer than
that on the network with the shortest length. This will avoid
fragmentation, and avoidance is a good thing.
	Joe D.

------------------------------

Date: Wed, 1 Jan 1997 12:57:31 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: 'Get Nearest Server' and Frame types

>A simple LAN consists of a PC and 2 NetWare servers.
>
>The workstation using Ethernet_II frame type needs to login to the
>server supporting Ethernet_802.3, it issues a Get Nearest Server
>request, the first server supporting EnetII will respond, and if it
>has a MAC address for the Preferred Server, does it then act as a
>router b/t the W/S and PS?
>Am I correct in supposing that the Nearest Server must support 802.3
>in order to even know about the Preferred Server? Since the PS
>broadcasts SAP using Enet_II , how could it be otherwise .... ??
>Once a route has been discovered, all IPX traffic b/t the WS and PS
>must then go thru the Nearest Server?
---------
	As I finish grading the last of the exams (computer networks), among
which was a sub project to find out how an IPX client gets its network
number, I can answer your question briefly.
	Each frame must be a separate IPX network number. They can share
the same wire or be in a relay configuration.
	The client can talk directly to only one server, because of the
frame kind constraint. If that server does not support the other frame
kind, and there is no other agent on the net acting as a router between
those two frame kinds/IPX networks, then the router does not know about
the other and there is no path from client to second server.
	If there is an agent between the frame kinds, perhaps the first
router, then the client goes through the only router it can talk to: the
Ethernet_II flavor.
	Each frame is a different IPX network, routers join one network
with another, clients are on only one network. Those are the key points.
	It is considered unwise to have multiple frames carrying IPX traffic
on the same wire or even on different wires. It's wasteful and confusing.
The exceptions are a) remote boot roms which speak only non-Ethernet_II
(use that frame only during booting), and b) Ethertalk (uses Ethernet_SNAP),
and c) you have non-Ethernet on another network segment. For pure Ethernet
use Ethernet_II frames throughout. There is no reason other than a) to ever
use Ethernet_802.3, but lots of folks have trouble with things technical
and make the mistake even on new installations.
	Joe D.

------------------------------

Date: Fri, 21 Feb 1997 11:21:21 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Ethernet_802.2 vs. Ethernet_II

>I've heard on this forum, talk about the benefits of Ethernet_II over
>that of Ethernet_802.2.  Even mentioned as the protocol of choice.
>Can someone brief me on the story here, if there is one.

This was discused at great length in the sign-off message from Don Provan
of Novell [covered in the FAQ]. Basically IP runs over ethernet_II, so why
have two frame types when you can have one. 802.3 is kludgy and yuck
(it only works because the checksum field is unused, and set to FF FF !)

------------------------------

Date: Wed, 5 Mar 97 08:00:41 -0800
From: Randy Grein <rgrein@halcyon.com>
To: <netw4-l@ecnet.net>
Subject: Re: Speed

>How do they get the ability to do voice and video?  There's the real need
>for a 1Gbps Ethernet and why some people are wanting ATM to the desktop.
>Besides, OC-48 is up to 6.5Gbps.

Sorry, but there doesn't seem to be much "need" to do video. Of course,
if this IS an issue, you can either live with video on ethernet (yes, it
HAS been done, check out Netware Video) or go to ATM as you suggest.

>Some hardware manufacturers say it's no longer true Ethernet if you have
>any collision detection.  After all, we are talking about CSMA/CD (sp?).
>So do you build a NIC that listens to the wire or build an intelligent hub?

Uh, Kev, check out your specs on ethernet -the NICs listen to the wire by
definition. Your spelling is right, it stands for Carrier Sense Multiple
Access/Collision Detection. And what I was getting at is that in a
switched full duplex environment there can be no collisions, because the
media is no longer truely shared - not that there had been any
fundemental change in the ethernet spec. (The reason there are no
collisions is that each NIC communicates with the switch directly with
transmit and receive on separate pairs.)

Of course, all of this begs the question of what to use for WAN
protocols. Ethernet simply doesn't work well there, which does argue for
ATM, on the WAN at least.

------------------------------

Date: Fri, 21 Mar 1997 14:21:38 +0800
From: Brett Looney <BLooney@COMTECH.COM.AU>
Subject: Re: can't login...

>We have 2 servers on one backbone but in different segments, one is a
>NW311 and one a NW312 server. About 50 machines login to the NW311
>server by default (net.cfg setting), the rest login to the NW312
>server by default (again via net.cfg setting). When the 312 server is
>down, it is not possible for *most* (but not all!) machines who
>connect by default to the NW311 machine to login at all. two or three
>of these machines can login.

Large guess: frame type problem.

Your 3.12 server is probably running both 802.3 and 802.2 frame types and
your 3.11 server is only running 802.3. Some workstations have old ODI (or
older IPX.COM) drivers that run 802.3 by default and the rest are running
newer drivers that default to 802.2.

So, when the newer drivers try to connect to the 3.11 server, they actually
route via the 3.12 server - increasing network load, and also giving you
your problem - when the 3.12 server is down, no route to the 3.11 server
can be found. In short, the two or three machines that work are running
older drivers...

Short term solution: Use both 802.3 and 802.2 on the 3.11 server.
Longer term solution: Upgrade all the drivers and make the 3.11 server
speak only 802.2.
Alternate solution: Use both 802.3 and 802.2 AND upgrade all the drivers.

What I don't understand is your first sentence "...one backbone but in
different segments". If the above explanation is incorrect (good chance of
this...) how are the segments connected? A network diagram would be handy.

---------

Date: Fri, 21 Mar 1997 15:19:52 +0530
From: "Information Systems Mgr." <ISM@KIS.ERNET.IN>
Subject: Re: can't login...

>Your 3.12 server is probably running both 802.3 and 802.2 frame types and
>your 3.11 server is only running 802.3. Some workstations have old ODI (or
>older IPX.COM) drivers that run 802.3 by default and the rest are running
>newer drivers that default to 802.2.

That must be it! Thanks for the input! I'll get the proper driver
loaded on the 3.11 server. Yes, it is running only 802.3.

>Short term solution: Use both 802.3 and 802.2 on the 3.11 server.
>Longer term solution: Upgrade all the drivers and make the 3.11 server
>speak only 802.2.

Is there some place where I can find more information about the
advantages and disadvantages of the various frames, their purposes
etc., and the drivers? I didn't go yet so deeply into the technical
details. If you want to tell me more on the personal line, I would
appreciate it!

>What I don't understand is your first sentence "...one backbone but in
>different segments". If the above explanation is incorrect (good chance of
>this...) how are the segments connected? A network diagram would be handy.

Two segments on one backbone - actually we have 6 segments, two
segments have one server each. I would draw a diagram, but resources
on email are limited, and attaching a graphical file seems a bit too
big... :-) Your response was perfectly matching our problem, I am sure!

------------------------------

Date: Thu, 27 Mar 1997 10:08:49 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Need help with odipkt and winsock

>ODIPKT 3.1
>Using 802.3 framing, Class 11
<99% omitted>
---------
	So you chose the wrong virtual board. TCP/IP runs over Ethernet_II
frames, please. Only IPX can run over Ethernet_802.3, and you should have
abandoned that years and years ago. Dan Lanciani at Harvard Univ is the
person responsible for odipkt and you should contact him for tech support.
	Joe D.

------------------------------

Date: Wed, 21 May 1997 08:29:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Ethernet Frame Type

>I've gotten a little fed up with the responses that people get on
>Compuserve concerning what frame type to use. The other day, I ended up
>posting the complete section on Ethernet frames from the Novell FAQ to the
>Compuserve Netware 4 forum.
------
	Frame kind Ethernet_802.2 is poor indeed. Not only is it very
limited (no TCP/IP) but the payload is reduced compared to Ethernet_II
and the code involved to support such frames is a great deal more complex
than for Ethernet_II. There is not a thing to recommend it.
	As has been said many times, Novell's default frame choice is
political, not technical, and thus you are entitled to laugh in their face.
	If people wish to debate the matter it helps to pick the grounds:
political/emotional or technical.
	Joe D.

---------

Date: Wed, 21 May 1997 11:48:02 -0700
From: "Rappaport, Shawn" <shawn.rappaport@SPECASTRO.COM>
Subject: Frame Types (was: RE: DHCP2B)

>	Goodness. Use only Ethernet_II for TCP/IP. Don't dream of any other
>Ethernet frame kind with TCP/IP, or with IPX if you can help it. Put
>Ethernet_802.3 in the dust bin, and join it with Ethernet_802.2 as nearly
>as useless. Surely these things are taught to all CNEs.
>
As a side note on how much misinformation there is on the topic of frame
types: I recently attended a Novell TechWise video seminar on TCP/IP.
The speaker (considered the TCP/IP guru at Novell tech support) on the
video kept making statements that Ethernet_SNAP is the only frame type
you can use for TCP/IP. He also made a bunch of other incorrect
statements. Needless to say, that is the last TechWise video seminar
I'll attend.

---------

Date: Wed, 21 May 1997 20:52:29 -0400
From: "MICHAEL D. SETZER II" <MICHAEL@GCCCC.GUAM.NET>
Subject: CIS REPLY - Re: Ethernet Frame Type

Below is the reply that I got from the CIS Sysop concerning
Frame types, it seems to be a because the committe said so.
As Joe D. said, looks political, but it is beyond my expertise,
and the equipment that I have. By the way, I do have 4 Novell 2.x
servers still running great.

(Message on Novell Netware 4X Forum)

#: 289190 S8/Install/Upgrade  (CIS:NETW4X)
    21-May-97  12:26:08
Sb: Frame types
Fm: Marcel Cox [SysOp] 100041,110
To: Michael D. Setzer II 70143,3166
Replies: 1    TID: 67145     Par: 289028    Chd: 289271    Sib: 0

802.2 is standardized by the IEEE (IEEE 802.3 & 802.2) and by the ISO (ISO
8802.2 & 8802.3), Ethernet_II isn't. Ethernet_II is based on older
standards which almost aren't used anymore. Beside TCP/IP, all other
COMMON lan protocols are based on IEEE 802.2. This includes:
- Appletalk (when going from phase I to phase II, they switched from
Ethernet II to 802.2 snap headers)
- NETBEUI
- SNA over LANs
- OSI protocols

IPX and TCPIP can be used both with Ethernet II and IEEE frames, although
TCPIP is normaly only used with Ethernet II.

When doing bridging between different LAN topologies, 802.2 is the most
seamless frame type to bridge as all common LAN topologies use 802.2
headers (Ethernet, Token-Ring, FDDI), while Ethernet II is Ethernet only
and needs translation when being bridged to other LAN topologies.

As for the SAP (service access point?) address E0 used by IPX, I don't
know if these addresses are officially assigned at all. I think it is
rather up to the user to decide which number to use for which
applications. Commonly used values are:
E0 for IPX
F0 & F1 for NETBEUI
AA for SNAP headers

As for the "BEEF", a close examination of the pro Ethernet_II arguments
shows that most of them viewed under today's situations don't have that
much "BEEF".

- Argument: NW 2.x does not support Ethernet_802.2.
  This is a good argument, but do you have any NW 2.x servers? If you
don't have any, this argument does not count.

- Argument: standardization of Ethernet_II protocol / IPX protocol ID
  A close examination shows in fact that this argument is rather in favor
of 802.2. In fact Ethernet II is an old standard which has been REPLACED
by the IEEE 802.2/802.3 standards. Ethernet II isn't standardized neither
by the IEEE nor by the ISO. It is only because the popular TCPIP protocol
uses it that it still exists.

- Argument: performance loss because of extra packet length and odd
alignment:
The author himself admits that the difference is not measurable.

As for the FAQ, it is not written or maintained by Novell or any of the
sysops here, so we have no influence of its contents.

Marcel Cox, [Novell Support Connection]

---------

Date: Wed, 21 May 1997 19:22:12 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Ethernet Frame Type

>Below is the reply that I got from the CIS Sysop concerning
>Frame types, it seems to be a because the committe said so.
>As Joe D. said, looks political, but it is beyond my expertise,
>and the equipment that I have. By the way, I do have 4 Novell 2.x
>servers still running great.
>
>Also commented on the fact that the FAQ is open, and I'm sure they
>would happy to add stuff.
>
>Thanks again.
	<inclusion excluded>
--------
Michael,
	With all due respect, I'd be happier if you didn't drag in stray
cats just because they are cats or strays. There are many people who don't
understand Ethernet frames, and the history of them, and what really happens
in use. Too bad, they lose.
	For my part, after explaining this issue a great many times, I'm
tired of repeating the whole story each time one of these partial information
or misinformation things occurs (and the CIS item falls into these slots).
	The list has a fine summary doc, by Don Provan, and I warmly recommend
reading it carefully. Don and I agree 100% on it. So do other knowledgable
professionals. That's the easy solution. The harder one is to do your own
homework in detail, really think things through and look at real life and
real code.
	So please let the CIS folks, and "religiously bound" Novell TV
presenters, rest in peace and don't create unnecessary cross talk. The FAQ
is far better off without partially-baked comments from non-list people.
	Joe D.

------------------------------

Date: Wed, 21 May 1997 23:31:34 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: DHCP2B

>Does RPL work with ETHERNET_II?

No.  RPL[.NLM] only works with 802.2 type framing, as supported by modern
boot proms.

Older boot-rpoms will boot off ethernet_ii frames (in the case of
decade-old boot proms only if set to the right base address (see the
installation supplements for details).

RPL is nothing whatsoever to do with DHCP. Most sane people run IP over
ethernet_II and deal with IP and IPX as separate protocols.

------------------------------

Date: Wed, 21 May 1997 17:27:35 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Ethernet Frame Type

>I have continued to use the old IPX for a long time. It doesn't do
>bursting, but that's seldom necessary. It all depends on the application.
>I certainly would not use VLM's. If I needed to go up a step I'd use ODI.
>None of my stations have hard disks and each boots from a floppy. The old
>IPX provides the quickest bootup by far. Each station is given a virtual
>C: drive in case anyone needs it. The old IPX also requires the least
>amount of memory.
---------
	If you will pardon some corrections, it will help to use proper
terminology and by so doing may help your site understand the situation.
	IPX is a protocol, delivering Novell material in datagrams (send
and forget). It's analogous to IP in the TCP/IP protocol suite.
	NCP is NetWare Core Protocol which uses IPX for transport and does
all the server commands etc. It is not transportation, though it also does
Packet Burst accounting. The analogy is roughly TCP in the TCP/IP suite
but NCP does more.
	VLMs are a way of packaging NCP modules in memory. They use IPX
for transportation.
	NETX is an out of date rendition of NCP modules which runs only
below 1MB. It and VLMs do the equivalent job and use the same
transportation.
	ODI is a specification on how to write LAN adapter drivers and
the first level of packet distribution (dealing with frames and such). Its
competition is NDIS (from 3Com and Microsoft) and Packet Drivers (free).
They all do similar tasks, but much differently internally.
	IPXODI is a version of the IPX software which talks to ODI for
board support. An obsolete rendition is "monolithic IPX" which builds in
a particular board driver. NETX, VLMs can run over either. My MS-DOS Kermit
is another user of ODI, in parallel with IPXODI.
	Client32 does the same jobs: splitting LAN driver, IPX transport,
NCP level stuff, but organizes them to run in protected mode. Shims are
provided to use real-mode ODI LAN drivers and to provide an image of ODI
to real mode programs (by adding lsl.com and pdoseth.com, for example).
Rather clever work, if we do say so.

	So far there has been not one word here indicating what frame to
use. And that's proper because the LAN may not be Ethernet (gasp!). ODI
itself handles frame details, and quite cleverly too. In ancient times of
monolithic IPX there could be only one frame kind in the code, patchable
but otherwise fixed. ODI is far more elegant and flexible. NDIS knows
almost nothing about frame kinds and instead shoves the entire raw packet
to the application to figure out. Ditto Packet Drivers.

	Remote booting comes in many flavors, all different. Some ROMs
require using Ethernet_802.3 frames (so call "Old Novell"), some use
Ethernet_802.2 (most often IBM RPL spec), and some use Ethernet_II. It
just so happens that these frame choices are hardwired into the code for
no good reason at all, other than there isn't a way of reading a
configuration file during booting, and if you had remote boot ROM source
code you could change the frames. I happen to have some of that code so
I can see what really happens.
	Remote booting moves an image of a floppy disk to the client and
then causes the machine to reboot from that fake A: image. Once the reboot
starts there is no need to continue using the frame kind employed to move
the image. In fact I use Ethernet_802.3 to move the image because the boot
ROMs were affordable and ancient, and use Ethernet_II to login. Look at
your particular boot ROM situation carefully and make a disk to fit modern
work. Remote booted images need not have any networking material at all!
Try it to understand what I'm trying to indicate. Yes, you can remote boot
Client32 for DOS/Win 3.1 (not for Win95) by very carefully squeezing
components onto the floppy image.
	Joe D.

------------------------------

Date: Thu, 19 Jun 1997 20:19:25 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: TCP/IP Packets > 1500 will not go out

>>>>We just finished an upgrade to Intranetware 4.11 from 3.12 and we our
>>>>having problems with Mercury not being able to send packets out .GT.
>>>>1500 bytes.  I loaded the PING.NLM module on my file server and cannot
>>>>seem to ping any site if the packet size is greater than 1500 bytes.
>>>>It seems the problem is with the Netware and not Mercury.  I have
>>>>tried the lastest Intranetware patch kit 3 and putting the statement
>>>>SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE = 2048 in STARTUP.NCF and
>>>>have had no luck.
>>
>>	If this is Ethernet then 1500 data bytes in Ethernet_II frames is
>>the legal maximum anyway. Using a larger SET MAX etc above just wastes
>>server memory. Frames longer than this (MAC header + 1500 data + CRC)
>>will be in violation of Ethernet rules. Note that Ethernet_802.2/_SNAP
>>use even shorter data lengths because of the LLC + SNAP fields taken
>>from the data part. See Don Provan's Ethernet.txt paper in the FAQ for
>>pictures.
>
>That's not entirely complete. IP does support fragmentation, so you
>can have larger pings legally on ethernet.  I have noticed this
>problem too, but it was always related to the adapter, not the
>version of Netware.  To make sure, I just ran PING on INW411+SP2 and
>it tested out fine with packets over 8K and I know my packet size
>isn't that large.
>
>I missed the original post, but basically, why?  I sometimes do
>pings of 4000 or more to get a better idea of network performance
>with some back-to-back packets.  Still, it isn't normally used by
>mercury, unless on FDDI or something...  If that's the case, it's
>probably something else not fragmenting the FDDI packets correctly or
>the destination site not supporting fragmentation, etc...  (or,
>possibly do you have a different network card in 4.x then in 3.x?)
-----------
	Ok, I think we have a better understanding, and I have a probable
cause or two.
	First the person meant IP packets/datagrams, we presume, and not
Ethernet FRAMES. The SET MAX PACKET command is really frames, the way I
understand it (and it shows just that way in memory consumption). For
the specialists, frames are the objects on the wire, packets are the
objects in software, datagrams are packets, segments are packets seen
at the TCP level rather than at IP level, and similar renaming to keep
the uninitiated intimidated.
	Second, there are many Ethernet <-> FDDI switches which do not
fragment IP datagrams, or can be configured to not do so. Also, a generating
IP stack can set the Do Not Fragment bit in IP datagrams, and that's the
end. MTU discovery relies upon this feature to find the largest surviving
datagram along a given path.
	Third, not every TCP/IP stack reassembles IP fragments, or not
always properly, or does not have enough buffer space to hold many fragments.
Recall that smaller machinery prefers tiny buffers, 4KB or so, and not
blithely malloc(64KB max length IP datagrams * number of datagrams to keep).
Reassembly is cpu time intensive, so the box may fall behind and drop pieces
and thus fall futher behind, until finally reassembly buffers time out and
are discarded. Ping, in particular, is very pushy about sending without
waiting for replies.
	It turns out that IP frag reassembly is a real headscratcher to
implement in code. So some stacks don't have it, particularly older ones.
	Fourth, it is fairly easy to overwhelm many older bridges which
have limited buffering (busy output wire, trying to fit a new frame in
edgewise and failing).
	Busy routers may well decide to discard ping (ICMP ECHO) packets,
and some may discard those which would require fragmentation. Try traceroute
(UDP/IP) to see routers only reluctantly agree to ICMP "TTL exceeded" reply.
	While all this is technically curious, it begs the original question
about Pmail and "packets." I wonder what observation lead to the term
packets rather than say email messages.
	Joe D.

------------------------------

Date: Sat, 20 Dec 1997 06:35:16 GMT
From: Ken Wallewein <wallewek@CADVISION.COM>
Subject: Re: Frame Types

>I was reading about a neat utility program that checks what Frame
>Types are in use on the network and by who.  It also did a lot more
>and COST a lot more.  Therefore ...
>
>Does anyone know of any free/cheap utility that does just this
>function?

Check out ETHLOAD.  For the price, it's pretty good.

------------------------------

Date: Sat, 3 Jan 1998 17:58:45 -0800
From: Brandon Fouts <BrandonF@WSHA.ORG>
Subject: Frame Sizes

Always good to read the current documentation. See page
36 on Installing Border Manger for the following suggestions:

Ethernet 1524
TokenRing 4540
FDDI  4540
ARCnet 618
Local Talk 618

------------------------------

Date: Mon, 12 Jan 1998 22:55:29 +0100
From: Hans Nellissen <dbphilos@UNI-DUESSELDORF.DE>
Subject: Re: PSD.EXE

>Was looking throught past AppNotes and read about a program to show
>frame sizes during a promiscuous sample period. The program was PSD.EXE
>Unfortunately, I cannot locate it.

Last known address:
	ftp://ftp.vse.cz/pub/.sd60c/novell/novuser/01/psd.exe

------------------------------

Date: Fri, 20 Mar 1998 00:55:27 +1100
From: Scott Marshall <esmarshall@USA.NET>
Subject: Re: Novell Front Screen For Win95

I think that it is worth mentioning that I have always distrusted the
Win95 "Auto" frame type option.  Enforcing a particular frame-type (in
my cases Ethernet_II) has always resulted in much more reliable network
connections.

------------------------------

