802.2 / 802.3 / II Frame types & multiple NIC performance
Roger Foss
-----
Network performance when running multiple NIC's, protocols, frame types.
BACKGROUND
----------
Like so many other network administrators, I started using the
Ethernet 802.3 'raw' frame type on my Novell servers. It's the default, so it
must be the right one, right?
WRONG! Don Provan's FAQ has some very good reasons for choosing either
802.2 or Ethernet II (preferrably the latter).
At any rate, at some point I had to support IPX on Ethernet II. So I simply
loaded the LAN driver twice on the server, and bound IPX to both frame types.
Later, I started thinking I should put another NIC in and dedicate each NIC
to different frame types.
I mean, the internal router function of NetWare servers make sure that
everything is connected / reachable.
This was all a couple of years ago, and having read Don Provan's FAQ i want to
go for a single frame type if possible. I just need a few answers from you
net-people out there..
QUESTIONS
---------
1. Will putting more than one NIC in a server increase performance if they're
both connected to the same segment? My suspicion is not, since the server
now will start routing between the NIC's.
2. Will running two protocols on one frame type (say, Ethernet II) decrease
performance somehow? I've always thought the separation of Novell on 802.3
and Unix on Ethernet II nice.
3. Will the WAN performance of IPX be affected somehow by going for Enet II
instead of 802.3 'raw' ?
Thanks
Roger
|
--+-------------------------+---------------------------
Roger Foss | Voice: +47 22 85 33 67
Unix & Network consultant | Fax: +47 22 85 33 45
SiO IT, OSLO, Norway | Email: edb...@sio25.uio.no
----------------------------+---------------------------
Teo Kirkinen
> 1. Will putting more than one NIC in a server increase performance if they're
> both connected to the same segment? My suspicion is not, since the server
> now will start routing between the NIC's.
If you have one NIC with ipx bound to two frame types, the server is
already routing between the networks defined by these frame types.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Teo Kirkinen Teo.Ki...@Helsinki.FI
University of Helsinki, Computing Centre
Roger Foss
EXACTLY my point. So what with NetWare always routing between frame types
*and* NIC's, can I assume that several NIC's / frame types always will
decrease performance??
James Harvey
> In article <2oe9ic$9...@klaava.Helsinki.FI> kirk...@cc.Helsinki.FI (Teo Kirkinen) writes:
>>Roger Foss (edb...@sio25.uio.no) wrote:
>>> 1. Will putting more than one NIC in a server increase performance if they're
>>> both connected to the same segment? My suspicion is not, since the server
>>> now will start routing between the NIC's.
>>
>>If you have one NIC with ipx bound to two frame types, the server is
>>already routing between the networks defined by these frame types.
>>
>>
>>--
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Teo Kirkinen Teo.Ki...@Helsinki.FI
>>University of Helsinki, Computing Centre
>
>
> EXACTLY my point. So what with NetWare always routing between frame types
> *and* NIC's, can I assume that several NIC's / frame types always will
> decrease performance??
1. Today's Ethernet NICs have no trouble keeping up with the speed of the
network, so having more than one on the same segment is a total waste
in the sense that you could trade the extra NIC for more server memory and
be better off. The bottom line is, where is your bottleneck? If you
have a modern Ethernet NIC, it most certainly isn't there. So scratch
this idea completely.
2. You have to load another copy of the NIC driver in the server for every
frame type. Thus there is a (IMHO rather small) advantage to avoiding
multiple frame types when using multiple protocols.
3. Loading multiple frame types for the same protocol (IPX is the only
practical case I can think of) can be useful while you are migrating to
a new frame type. You really don't want to run this way for long though.
This increases the number of IPX networks, increases routing complexity,
and could cause performance problems. Consider the following network
configuration when client C using Enet II wants to communicate with server
B which only speaks raw802.3.
A-server (Enet II & raw802.3) B-server (raw802.3)
----------------------------------------------------- <- Net 27 (Enet II)
C-client (Enet II) and 26 (raw802.3)
Every IPX packet and the corresponding acknowledgement from server B
has to be routed through server A. This instantly doubles your traffic
due to this connection. Not good. Plus, since A is turning around and
sending the packet right back out on to the same wire (with a different
frame type of course) it could conceivably be increasing the traffic in
a pathological manner. This is yet another reason not to run this way
for any longer than is absolutely necessary.
In summary, there is no complete cookbook answer that works for everybody
all the time under every conceivable set of circumstances.
Here is a first draft of an attempt at a checklist for frame type conversion:
0. Don't change frame types unless you have a good reason. Raw802.3
is falling by the wayside. It will never be able to support IPX
checksumming. Since it is no longer the default frame type, support
for it is likely to become harder to come by in the future. These
may be good enough reasons for you. But perhaps your accounting
dept has some ancient equipment (e.g. old print server) that requires
raw802.3. That may be reason enough for you to put it off indefinitely
or until you have money in the budget to upgrade their old equipment,
or isolate them on a legacy net. Educate yourself about the alternatives
and make an informed decision.
1. If you do decide to switch, know what you are getting into. This means
at least a complete inventory of *all* your equipment and what its needs
are (boot ROMs, NICs, drivers etc.), network topology, IPX network and
internal network numbers, router configurations, etc. You don't want
to get halfway into the process of conversion and then stumble on that
old print server in the accounting dept. If you are unsure of anything,
do some preliminary testing. I've seen drivers that claimed to support
more than one frame type that in fact did not.
2. Remember that with suitable configuration changes to your routers, you
will only have to switch one segment at a time. This makes the conversion
much more manageable. You may have to keep a few legacy segments that
will remain with raw802.3 indefinitely (that old print server again).
3. You may want to switch everything on a segment all at once. If this is
not possible, you may want to run for a time with two frame types on
the same segment. If you do this, set a cutoff date for completion and
stick to it, to avoid the potential performance problems described above.
Corrections and enhancements to this checklist are welcome...
--
James Harvey har...@iupui.edu IUPUI OIT Technical Support/VMS/Unix/Networks
Disclaimer: These are my own opinions. I do not speak for Indiana University.
Lawrence V. Stefani
In article <1994Apr12.184311.4951@ivax>, har...@indyvax.iupui.edu (James Harvey) writes:
|>2. You have to load another copy of the NIC driver in the server for every
|> frame type. Thus there is a (IMHO rather small) advantage to avoiding
|> multiple frame types when using multiple protocols.
Good note overall, especially the checklist. Just one small "nit", however.
If your LAN driver is reentrant (as most are) there is only one copy of the
driver source code in memory regardless of the number of frame types loaded
or multiple NICs loaded. There is a memory hit however in terms of adapter
data space and frame data space. There is an adapter data space created on
a per physical board basis. There is a frame data space created on a per
logical board (ie frame type) basis. FYI - The first few chapters of the
ODI spec covers this in greater detail.
+---------------------------------------------------------------------------+
| Larry Stefani ste...@yesway.lkg.dec.com |
| High Performance Networks Digital Equipment Corporation |
| Comments are mine, of course... |
+---------------------------------------------------------------------------+