------------------------------------------------------------------- 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" Subject: Re: Novell's angle on frame types? Joe Doupnik 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 Subject: Re: Novell's angle on frame types? I'll try to be brief and avoid a slugging match on the topic. >Joe Doupnik 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 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" Subject: Re: Novell's angle on frame types? Joe Doupnik 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 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 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 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" Subject: Re: Novell's angle on frame types? Joe Doupnik 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 Subject: Re: Novell's angle on frame types? >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 Subject: Re: 802.2 and 802.3 necessary for RPL >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. -------------- 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" Subject: Re: 802.2 and 802.3 necessary for RPL On 30 Dec 95 at 9:41, Teo Kirkinen 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 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 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 >> FRAME ETHERNET_II >> FRAME > >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" 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 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\\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 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 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 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 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 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 Subject: Re: Adding a 2nd frame type to a 3.12 server -Reply >On 22 May 96 at 11:06, Joe Doupnik wrote: >> >>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 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 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 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 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 To: "NetWare 4 list" 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 To: "NetWare 4 list" 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 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 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 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 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 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 To: 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 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." 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 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 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" 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" 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 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. -------- 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 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 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 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 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 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 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 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. ------------------------------