ITEM: K7986L
arp, ping between 6000 and PC's running Novell LAN Workplace for DOS
Question:
AIX 3.2.5
Net config:
RISC mod 250------PC's running Novell LAN Workplace for DOS
6000 is on one ring, PC running LAN Workplace for DOS, on another ring,
bridged together by a Crosscom "brouter." When ARP entries fully age
out of these two machines, a ping from the 6000 to the PC is unanswered.
Ping from PC to 6000 is answered, and full communication is possible.
Again aging out arp entries, I can put a permanent arp entry into
the 6000 for the pc, and again, I have communication possible from
6000 to PC.
Why are we unable to ping and establish communication from the 6000
to the PC when there are no arp entries initially?
Summary:
Your bridge from Crosscom is doing both MAC source routing, and
transparent bridging between the 6000's token ring and the PC's
token-ring. But even with that bridge capability, both endpoints
(PC and 6000) must expect and support the same form of bridging.
The 6000 expects token-ring bridging to be MAC level source routed,
and communicates this way accordingly. But a LAN workplace for DOS
PC does not support MAC level source routing unless you have the
route.com driver loaded on the PC.
Detail and Symptom Discovery:
You further discovered the same results when pinging from an
HP9000 across the bridge to the PC. Ping from 9000 to PC
is unanswered, but PC can ping the 9000, and communication is
established.
Also, when you took LAN Workplace for DOS off the PC and put on
FTP Software Inc.'s PC/TCP, you can ping from 6000 or 9000 to PC,
build the dynamic arp entries, and communication is established.
You are curious about the MAC level "routing" information that appears
in arp table examples you have seen from IBM (e.g., a string that
looks something like "rt=8b0:c031:b011:1530" at the end of arp
entries for some token-ring attached machines). This MAC level
routing info is described in the Token-Ring Architecture Reference
(SC30-3374), Chapter 2. The example above shows the two byte routing
control field of 8b0, and three ring-bridge segments. Frames travel
from ring c03, across bridge 1 to ring b01, across another bridge 1
to ring 153 (A couple of rules here, you can have multiple bridges
with the same id attached to one ring, as long as they do not bridge
the same two rings together. Also, the 0 bridge on the 153 route
designator is null; the ring 153 is the last segment). Nothing
special is done on the 6000 for this info to show up in the arp table.
But when you ping from PC to 6000, all that shows up in the 6000's
arp table is IP address and MAC address of the PC, with no MAC routing
information. If no MAC routing information is present, it suggests
the bridge is perhaps maintaining tables of MAC addresses that it
knows of on either side of the bridge, and making forwarding decisions
based on those tables ("transparent" bridging). And once you get
this "non-MAC-routed" arp entry on the 6000, the 6000 will think
the PC is on the same physical subnet, and will attempt to communicate
with that PC without MAC routing the frames. The transparent bridge
picks up this frames, looks for the MAC address of the PC in its
internal tables, and passes it on to the ring where the PC is
attached. The same thing happens when you simply add an arp entry
for the PC at the command line on the 6000.
With no arp entries on either side, traces generated by the bridge
vendor (Crosscom) suggest arp requests from 6000 are MAC level source
routed onto the ring where the PC resides. But without route.com,
the PC is unable to interpret the MAC routing in these frames, and
does not respond.
Why can the PC ping across to the 6000? It likely sends a non-broadcast
arp request to MAC address ffffffffffff, and the transparent function
of the bridge knows to forward an "all-F's" frame to all other attached
rings.
To resolve this issue, you will need route.com loaded on the DOS PCs.
Or, if this were a routed IP network, possibly Novell's LAN Workplace
for DOS would then be able to cross from one subnet to another without
requiring route.com. But being IP routed might block your RUMBA clients
travelling from one ring to a 3745 on another ring. But at one time
you referred to the the crosscom as a "brouter. Maybe it has an IP
routing function that could be enabled, cooresident with the
source-routing-transparent bridging function.
Support Line: arp, ping between 6000 and PC's running Novell LAN Workplace for DOS ITEM: K7986L
Dated: October 1994 Category: N/A
This HTML file was generated 99/06/24~13:30:42
Comments or suggestions?
Contact us