Conference noted::netware

>>    We have a customer using Novell on their Ethernet network. Those Novell
>>    servers and clients are configured either with Ethernet II or raw
>>    802.3. Now, they are migrating their Novell servers to FDDI using
>>    DECswitch 900EF. We knew DECswitch has an optional switch can translates 
>>    Ethernet 802.3 to FDDI_SNAP. When they put the Novell server with
>>    FDDI_SNAP on the FDDI ring, there is error message of duplicate network
>>    number. 

There are several notes on this subject in this conference, but the reason
you're seeing the error message is because of the fundamental nature of that
900EF switch you're enabling.

There are only two frame types defined and supported by Novell on FDDI
(FDDI_SNAP and FDDI_802.2).  If you take a standard FDDI-Ethernet bridged
network, these two frame types translate to ETHERNET_II and ETHERNET_802.2,
respectively, for protocols like IPX.

When you enable the 900EF "raw IPX" switch, you're telling the bridge to take
the malformed and non-standard ETHERNET_802.3 IPX frames and translate them
into proper FDDI_SNAP frames.  Of course, these FDDI_SNAP IPX frames look
*IDENTICAL* to the FDDI_SNAP frames that are translated from your ETHERNET_II
IPX clients...

...SO...

...you obviously can't run both ETHERNET_II and ETHERNET_802.3 IPX clients
across a 900EF bridge after throwing the switch because all of the FDDI_SNAP
IPX frames will come back as ETHERNET_802.3.  The bridge can't tell which ones
to translate to ETHERNET_II and which ones to translate to ETHERNET_802.3. 
Besides, NetWare has major problems (as you're noticing) dealing with IPX on
the same frame type using two or more external IPX addresses.  You probably
have NetWare servers on Ethernet announcing different external IPX addresses
for the ETHERNET_II and ETHERNET_802.3 logical networks.

[Mild flame on]

Your customer should have LONG since retired ETHERNET_802.3.  Novell has
been telling their customers this for several years.  Digital has been telling
their customers this for even longer.  Now they're seeing the ramifications of
adopting that non-standard frame type.

[Mild flame off]

Your customer has really two choices at this point:

	1. Isolate ALL of the ETHERNET_802.3 IPX clients on one side of a
	   900EF and move ALL ETHERNET_II IPX clients to another bridge.
	   Naturally, the bridge with the ETHERNET_802.3 IPX clients should
	   have the "raw IPX" switch enabled.  The ETHERNET_II bridge should
	   not.

           Also, consider moving all of the servers to FDDI.  Remember, the
	   FDDI server thinks it's only talking to one frame type (FDDI_SNAP).
	   If you also have ETHERNET_802.3 and ETHERNET_II servers, they'll
	   need to have the same external IPX address, else you'll continue
	   to get the error message about duplicate network numbers.  You can
           simplify the problem by having all of the NetWare servers on FDDI
           running FDDI_SNAP, and have only bridged ETHERNET_802.3 and
           ETHERNET_II clients.

	2. Eliminate all traces of ETHERNET_802.3 on your network and
	   completely standardize on ETHERNET_II.

I, of course, favor the second choice, but either should work.  However, your
customer's long term strategy better be to eliminate ETHERNET_802.3 on their
network.

Regards,
   Larry

    WE need more explanation on the Novell migration solution. The reason
    the customer use EThernet II because the Novell clients need to access
    the VAX host on EThernet. Therefore, they use one of the Novell server
    configured with 802.3 and EThernet II. Besides, the Novell clients are
    diskless and need to network loaded from the server. If they changes it
    to EThernet II, they need to change the boot Rom on the network card but
    not sought yet. There are a lot of Novell clients (802.3) installed in
    other offices and in other countries. This changes will definitely
    impact the migration in terms of time schedule and also the cost.
    Further, they will have Novell hosts on ETherent and FDDI after
    migration.
    
    Please kindly advise what will be the best method to proceed the
    migration.
    
    Thanks,
    cf 

Hello CF,

>>    Please kindly advise what will be the best method to proceed the
>>    migration.

I gave you two suggestions in my last reply.  Current NetWare clients (with the
exception of the new Client32 environments) can only bind IPX to one frame
type.  If they're bootless and the ROMs only support IPX over ETHERNET_802.3,
fine.  If you also need them to access a Digital PATHWORKS server running IPX
over ETHERNET_II, then yes, having an Ethernet NetWare server with IPX bound 
on both ETHERNET_802.3 and ETHERNET_II would give you that routing capability
for the clients.

But now the customer wants to migrate to FDDI and compliant NetWare nodes on
FDDI can't accept "raw 802.3" IPX frames.  So, your customer CANNOT keep the
Ethernet NetWare server with IPX bound on both ETHERNET_802.3 and ETHERNET_II
and then connect a 900EF with the "raw IPX" switch enabled.  If they do that,
any NetWare servers on the FDDI ring with IPX bound to FDDI_SNAP will complain.

Given that your customer can't get rid of ETHERNET_802.3, my recommendation
would be to move ALL of the NetWare servers (including PATHWORKS) to the FDDI
ring.  Then, enable the "raw IPX" switch on the 900EF and only bind IPX to
FDDI_SNAP on the servers.  This was suggestion #1 in my last note.

You won't be able to have any ETHERNET_II IPX clients on the Ethernet side of
the 900EF, but at least your ETHERNET_802.3 clients can still boot and
they should be able to connect to the Digital servers because the bridge will
take care of the frame type problem.

- Larry

    I need more explanation on the solution. Will you mean we move the
    Novell servers including the Pathworks server to FDDI and they can be
    only configured with FDDI_SNAP. Then all the Novell servers or clients
    must be configured with raw 802.3 on Ethernet and the DECswitch 900EF with raw
    802.3 conversion turned on. 
    
    However, can be still let the VAX server 4000 on the EThernet side of
    this DECswtich 900EF (raw 802.3 on) or we need to separate all these
    VAX servers to another DECswtich 900EF with raw 802.3 turned off?
    
    Once again, please help to give me more hints.
    
    Thanks a lot,
    cf
    

>>I need more explanation on the solution. Will you mean we move the Novell
>>servers including the Pathworks server to FDDI and they can be only
>>configured with FDDI_SNAP. Then all the Novell servers or clients must be
>>configured with raw 802.3 on Ethernet and the DECswitch 900EF with raw 802.3
>>conversion turned on. 

This solution could work.  Let's dissect it for a moment:

ON ETHERNET - You have your NetWare servers and clients, all configured for IPX
on ETHERNET_802.3.  All of the NetWare servers on Ethernet should have the same
external IPX address (e.g. "BIND IPX TO E_DRIVER NET=1") assigned to them.

ON FDDI - You have your remaining NetWare servers and clients, all configured
for IPX on FDDI_SNAP.  All of the NetWare servers on FDDI should have the same
external IPX address -AND- it should match the one you're using on Ethernet
(e.g. "BIND IPX TO F_DRIVER NET=1").

ON 900EF - You have it configured with the "raw IPX" switch on.  Now, all
ETHERNET_802.3 IPX frames will go over as FDDI_SNAP IPX frames, and come back
as ETHERNET_802.3 IPX frames.  That's why you'll need to match the external IPX
address assignments, so the Ethernet NetWare servers will think the FDDI
NetWare servers are on Ethernet, and vice-versa.

>>    However, can be still let the VAX server 4000 on the EThernet side of
>>    this DECswtich 900EF (raw 802.3 on) or we need to separate all these
>>    VAX servers to another DECswtich 900EF with raw 802.3 turned off?

You can leave the VAX Server 4000 on the Ethernet side of the 900EF with
"raw IPX" switch enabled IF it's configured for IPX on ETHERNET_802.3 NOT
ETHERNET_II.  After my explanations, that should make sense, right?

Otherwise, you'll either have to move the VAX Server to the FDDI ring and
configure it for FDDI_SNAP -OR- move it to a separate Ethernet network (with
another 900EF with "raw IPX" switch disabled) and configure it for ETHERNET_II.
Remember, if you do this, you'll need to use the same external IPX addresses on
all three networks (ETHERNET_802.3, ETHERNET_II, and FDDI_SNAP).

Even with this ETHERNET_802.3 nonsense, you do have a lot of configuration
options.  You can leave some nodes on Ethernet and others on FDDI.  You just
have to be consistent and careful that you match up the frame types and don't
intermix them.

Good luck,
   Larry

    I still have some further questions on Novell configuration. Initially,
    there is a Novell server on Ethernet required to bind 802.3 and Ethernet II
    such that the other Novell clients binded with 802.3 can connect to the VAX
    server on Ethernet. Now, there is no way for this Novell server to bind 
    802.3 and Ethernet II at the same time on Ethernet or FDDI. I think this 
    Novell server will act as a gateway between Novell and DECnet. Besides, the
    VAX server still need to install some gateway software for Novell
    clients. When doing the FDDI migration, I think we may have different
    approaches, please help to explain will it be feasible.
    
    1. Move this Novell server to the DECswtich 900EF (with raw 802.3
       turned on) and binded with 802.3 ONLY.  
    
       OR
    
    2. Move this Novell server to the DECswitch 900EF (with raw 802.3 
       turned off) and binded with EThernet II ONLY.
    
       OR
    
    3. Move this Novell server to the FDDI ring and binded with FDDI_SNAP.
    
    By doing either the above configuration, will other Novell clients
    binded with Ethernet II or 802.3 need this Novell server to
    connect to the VAX server. 
    
    Thanks,
    cf
    
    Another question is Then, do we need to do anything on this Novell server if we
    put it either on FDDI with FDDI_SNAP 

>>    By doing either the above configuration, will other Novell clients
>>    binded with Ethernet II or 802.3 need this Novell server to
>>    connect to the VAX server. 

They shouldn't need it.  What the NetWare server was doing for you was acting
as an IPX router between the ETHERNET_802.3 IPX network and the ETHERNET_II IPX
logical networks.  Since the VAX only support IPX over ETHERNET_II, you needed
to do this to have your ETHERNET_802.3 clients communicate with the VAX.

Now, if you put the VAX on one side of a 900EF (with switch off) and use
ETHERNET_II -OR- put the VAX on the FDDI ring and use FDDI_SNAP, your
ETHERNET_802.3 clients should communicate with the VAX directly, without the
need for an IPX router.
    
>>Another question is Then, do we need to do anything on this Novell server if we
>>put it either on FDDI with FDDI_SNAP 

Which NetWare server?  The one that had IPX bound to ETHERNET_802.3 and
ETHERNET_II?  If all it was doing was acting as a router for your clients, then
you don't even need it.  If it was also acting as a file server for some
clients, then you can put it on the ETHERNET_802.3, ETHERNET_II, or FDDI_SNAP
networks.  Just be sure to only bind IPX to ONE frame type.

Maybe this explanation will help.  Think about the Ethernet side of a 900EF
with the switch on, the Ethernet side of a 900EF with the switch off, and the
FDDI side of the 900EF's as three separate physical network yet ONE logical IPX
network.

Sure, you've bound ETHERNET_802.3, ETHERNET_II, and FDDI_SNAP to IPX,
respectively, but because of the bridge, every NetWare client and server will
think everyone else is on the same physical network.  You just have to make
sure that you never bind IPX to more than one frame type on the SAME physical
network and that you use the SAME external IPX address assignment on all
bindings.  Does this make sense?

- Larry

    Thanks very much for your crystal explanation!
    
    Regards,
    cf