| I don't think the addressing has much to do with this. The problem is that
the Wellfleed box seems to be configured wrong. You can act like a bridge
or you can act like a router -- but if you want to act like a router, you
have to do it on all ports. Your analysis sounds reasonable, and it explains
clearly why the setup you described is not valid.
paul
|
| Is it a requirement for routers (in general) that all ports must be set up
to route DECnet? For this Wellfleet, three ports are set up to route DECnet,
IP and IPX, and to bridge between the Etehrnet segments. The fourth port is
set up to route IP and IPX, and no bridging.
A question the customer had, was if DECnet specs required all ports to have the
Physical address enabled on all ports, even if DECnet routing was not wanted on
all of them. He also ask me if a DECnis will have the Physical address set on
all ethernet ports, even if you don't want to route DECnet between them.
For me it seems logically that you don't have to enable DECnet routing on all
ports, as you do with host-based routing. If you have 2 Ethernet interfaces,
you don't want to run DECnet on both if you have a connection to the same LAN
from both of them. In that case, you have to at least SET LINE STATE OFF on
one of them, OR remove the entry from NCP.
BUT, back to my question on how DECnet is handled on FDDI. If a packet (or
frame or whatever) is passed from a node on a LAN via a DECbridge onto the
FDDI-ring, where the Physical Address of the Wellfleet is seen by the
DECbridge, will the Wellfleet pick it up, and throw it away, because it don't
route DECnet over the FDDI port? I'm a bit slow - I have a flue.
Bj�rn Olav
|
| If you're participating in Phase IV (as router or endnode) you have to have
a phase IV style datalink address on each datalink port that you're using
for routing.
So if you're not doing routing on port A, it certainly is reasonable to use
some other address for A. (It's also legal to use the Phase IV style address.)
As far as enabling routing only on some ports, that can be ok, but it seems
that in the specific case you're talking about it's not done properly.
Basically, the requirement (which may or may not be stated, but is a requirement
nevertheless) of every protocol I know about is that communication must be
symmetric: if A can talk to B, B can talk to A. (It must also in general
be transitive: if A can talk to B and B can talk to C, then A must be able
to talk to C.)
Bridge filtering creates many opportunities for creating non-symmetric or non-
transitive networks, which is why it's so easy to mess it up. Configuring
bridge/routers apparently creates similar problems. In the situation you
described, you said that BB sends to the Wellfleet which forwards to AA.
(Presumably it did that because routing is enabled on the port where the message
from BB is received. But how can the Wellfleet box know about AA unless it
hears its hellos, which it should do only if routing is enabled on the port
where the hellos from AA are received?) Since AA received from BB, it assumes
that it can talk to BB, as the routing protocol requires. Apparently the
Wellfleet box, at least in this particular setup, violates that requirement,
so when AA attempts to send return traffic, it doesn't go through.
Solution: always set up bridge filtering and bridge/router configuration so
that operation is symmetric and transitive.
paul
|