| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1511.1 | | NETCAD::ANIL | | Fri Sep 30 1994 20:50 | 31 |
| The best way to fix this problem is to configure the IPX stations
with "Ethernet v2" encapsulation rather than "raw 802.3". Most
Novell customers seem to have realized this through experience.
If you must use raw 802.3, you need to enable the "raw 802.3 IPX"
mode on both DECbridges. You can do this with HUBwatch, from the
bridge configuration screen.
Having said that, I'm not sure that it will work even if you do so.
The packets that you've shown are even more illegal than the
usual Novell raw 802.3 stuff. The 802.3 Length field says that
there are more bytes than there actually are in the frame. When
translating the packet in order to transmit it on the FDDI, the bridge
has to get rid of the length field (since the FDDI packet format
is different). However it uses the length field to determine the
number of bytes it must transmit. Now the bridge doesn't mind if
the length field is LESS than the number of actual bytes in the
packet, it treats the extra bytes like padding. However if the length
field indicates that there is MORE data than the packet contains,
it assumes that a byte has been lost and the packet is corrupted.
This works from Ethernet to Ethernet, since the packet is not
changed in that path. However, in going via the FDDI you lose
some header (ie, the length field), and the packet needs to be
reconstructed on the way back out to another Ethernet. There's no
way that an 802.3 violation like this can be tracked across an FDDI.
Please contact the manufacturer of the software that is sending
out these packets - they need to use a correct Length field.
Anil
|
| 1511.2 | Is this a well traveled road? | AKRON1::SMITH | Sic Semper Potatum Reclinus | Mon Oct 03 1994 16:46 | 64 |
|
Thanks for the quick response!!!
>> The best way to fix this problem is to configure the IPX stations
>> with "Ethernet v2" encapsulation rather than "raw 802.3". Most
>> Novell customers seem to have realized this through experience.
I think that this customer realize this now, too.
I may have to recommend a 802.3 to Ethernet_II novell "router" to
fix some of these issues....or use the PATHworks Novell client
which function correctly across the FDDI.
>> If you must use raw 802.3, you need to enable the "raw 802.3 IPX"
>> mode on both DECbridges. You can do this with HUBwatch, from the
>> bridge configuration screen.
We've tried both settings for Raw IPX...no change.... I believe this
only has purpose if either the client or the server is on FDDI.
>> Having said that, I'm not sure that it will work even if you do so.
>> The packets that you've shown are even more illegal than the
>> usual Novell raw 802.3 stuff. The 802.3 Length field says that
>> there are more bytes than there actually are in the frame. When
>> translating the packet in order to transmit it on the FDDI, the bridge
>> has to get rid of the length field (since the FDDI packet format
>> is different). However it uses the length field to determine the
>> number of bytes it must transmit. Now the bridge doesn't mind if
>> the length field is LESS than the number of actual bytes in the
>> packet, it treats the extra bytes like padding. However if the length
>> field indicates that there is MORE data than the packet contains,
>> it assumes that a byte has been lost and the packet is corrupted.
Does this mean that this frame would never make it to FDDI from the
"client side" bridge or that it would be discarded by the "server side"
bridge?
>> This works from Ethernet to Ethernet, since the packet is not
>> changed in that path. However, in going via the FDDI you lose
>> some header (ie, the length field), and the packet needs to be
>> reconstructed on the way back out to another Ethernet. There's no
>> way that an 802.3 violation like this can be tracked across an FDDI.
See above question.
>> Please contact the manufacturer of the software that is sending
>> out these packets - they need to use a correct Length field.
I will recommend this....
>> Anil
Could you please identify youself (what group you work for?)?
You seem to have gone down this road before.
Thanks again!
Jeff Smith
|
| 1511.3 | Related notes in other conferences | NPSS::MDLYONS | Michael D. Lyons - Young enough and dumb enough | Mon Oct 03 1994 18:23 | 10 |
| This road has been arrived at through a variety of routes:
See also:
RANGER::NETWARE notes conference 725.*, 1400.*
NOTED::DECNIS notes conference 1378.*, 1488.*, 1801.*
UPSAR::FDDI notes conference 881.*
SCHOOL::GIGASWITCH notes conference 269.*
...if you're bored
|
| 1511.4 | | NETCAD::ANIL | | Mon Oct 03 1994 21:33 | 15 |
| > Does this mean that this frame would never make it to FDDI from the
> "client side" bridge or that it would be discarded by the "server side"
> bridge?
The former (the packet would be discarded on the Enet->FDDI path
because it is a corrupted packet).
> Could you please identify youself (what group you work for?)?
> You seem to have gone down this road before.
Hub Engineering; Technical leader for the product under discussion.
Yes, I have been down the raw 802 IPX road before, however this is the
first I have heard of this particular problem.
Anil
|
| 1511.5 | whats it good for? | BSS::AMBER | Mark Amber, CNS-West (DTN)592-4645 | Tue Oct 04 1994 17:42 | 6 |
| Not to go too far off the beaten path, but I'm curious...
Over and over it seems customers have problems when then attempt to
use IPX RAW 802 mode. The answer most often given is "turn it off".
So I keep wondering, what good is it? Why do people even want to
try it? It seems to break a lot of rules among other things.
|
| 1511.6 | | CSC32::B_GOODWIN | MCI Mission Critical Support Team | Tue Oct 04 1994 19:45 | 11 |
| Mark,
It really started some years ago when novell broke the 802.3 spec and didn't
adhear to it. Now there are some legacy networks out there that are still
running this type of format. When you got hundreds of pc's out there running
this, it makes it hard to convert to ethernet format or 802.3 format. Most new
customers running novell are running ethernet/802.3 format. Novell no longer
suggests running the raw 802.3 because of the problems it causes mixing the
network with other protocols.
Brad
|
| 1511.7 | summary | IDEFIX::COWBURN | Legacy Networks Consultant | Fri Mar 31 1995 08:51 | 168 |
| I have written a summary of this subject for a customer, and as this appears
to be the latest related note, I thought I'd put the summary here.
If anyone has the time to verify this, I'd appreciate it.
Thanks,
Ian
Summary
-------
DECbridge 500/600
DECswitch EF
DECNIS
will switch any protocols concurrently with IPX using
Ethernet II
IEEE 802.2 SAP
IEEE 802.2 SNAP
when IPX is using IEEE 802.3 ("raw" IPX):
the first two bytes of the data are FF-FF (=checksum field, defaults
to this as checksum not enabled). This corresponds to an IEEE 802.2
frame with DSAP=SSAP=FF (=Global LSAP).
The result of this is that the frames can be switched between
Ethernets via the FDDI (being converted to/from FDDI SNAP), allowing
stations on the Ethernets to communicate, but not allowing a station
on the Ethernet to communicate with one on the FDDI.
The DECbridge 500/600 and DECswitch EF have a setting to enable "raw
IEEE 802.3" processing. When this is enabled, the raw IPX frame is
converted to a valid FDDI SNAP IPX frame (and vice-versa) allowing
communication between IPX stations both on the Ethernet and on FDDI.
However, as this mechanism converts valid FDDI SNAP IPX frames to raw
802.3 IPX frames, it is not possible to use simultaneously raw IPX
802.3 and IPX 802.2 SNAP encapsulation on the Ethernets - the stations
using IPX 802.2 SNAP encapsulation on the Ethernets will not be able
to communicate across the FDDI.
Novell and Digital recommend that IEEE 802.3 ("raw" IPX) is NOT used.
Conversions:
Ethernet II IEEE 802.2 SAP IEEE 802.2 SNAP
| | |
FDDI 802.2 SNAP FDDI 802.2 SAP FDDI 802.2 SNAP
| | |
Ethernet II IEEE 802.2 SAP Ethernet II
IEEE 802.3
|
FDDI 802.2 SNAP (DSAP=SSAP=FF)
|
IEEE 802.3 [~ IEEE 802.2 SNAP (DSAP=SSAP=FF)]
with "raw IEEE 802.3" enabled on the DECbridge/DECswitch
IEEE 802.3
|
FDDI 802.2 SNAP (DSAP=SSAP=E0)
|
IEEE 802.3
Details
-------
IPX:
Possible frame formats on Ethernet
Ethernet II
IEEE 802.2 SAP
IEEE 802.2 SNAP
IEEE 802.3 ("raw" IPX)
Conversions to/from FDDI:
Ethernet II
Ethernet II
DA SA type data crc
=8137
|
V
FDDI SNAP SAP with CTRL=UI(03) and OUI=000000
FC DA SA DSAP SSAP CTRL OUI Type data crc
=AA =AA =03 =000000 =8137
|
V
Ethernet II
DA SA type data crc
=8137
IEEE 802.2 SAP
IEEE 802.2
DA SA Len DSAP SSAP CTRL data crc
=E0 =E0
|
V
FDDI IEEE 802.2 LLC
FC DA SA DSAP SSAP CTRL data crc
=E0 =E0
|
V
IEEE 802.2
DA SA Len DSAP SSAP CTRL data crc
=E0 =E0
IEEE 802.2 SNAP OUI=000000
IEEE 802.2
DA SA Len DSAP SSAP CTRL OUI type data crc
=AA =AA =000000 =8137
|
V
FDDI SNAP SAP with CTRL=UI(03) and OUI=000000
FC DA SA DSAP SSAP CTRL OUI type data crc
=AA =AA =000000 =8137
|
V
Ethernet II
DA SA type data crc
=8137
IEEE 802.3 "raw" IPX, with "raw IEEE 802.3" disabled
IEEE 802.3
DA SA Len data crc
=FFFF...
|
V
FDDI IEEE 802.2 LLC
FC DA SA DSAP SSAP CTRL data crc
=FF =FF
|
V
IEEE 802.3
DA SA Len data crc
=FFFF...
IEEE 802.3 "raw" IPX, with "raw IEEE 802.3" enabled
IEEE 802.3
DA SA Len data crc
=FFFF...
|
V
FDDI SNAP SAP with CTRL=UI(03) and OUI=000000
FC DA SA DSAP SSAP CTRL OUI type data crc
=AA =AA =000000 =8137 =FFFF...
|
V
IEEE 802.3
DA SA Len data crc
=FFFF...
|