[HECnet] Attaching to hecnet

Paul Koning Paul_Koning at Dell.com
Wed Jun 30 16:09:01 PDT 2010


...
The 2.0.0 (phase IV) routing spec talks about the "on Ethernet"
cache
instead, and describes it in a way that makes it help only for
directly
attached nodes.   The "previous hop" flavor was a generalization in,
I
think, 2.1.0 (Phase IV+).

Hmm, yuck. Now I'll have to try to remember some details, as well as
extrapolating some stuff.

No, as far as I can remember, the end-nodes will only remember (or
know)
of one level 1 router. It will pick the one with the highest priority
in
case there are more than one on the local segment. That will become
the
designated router, and will be used for all traffic I believe.

The way this works is that there are two multicast addresses used on
Ethernet segments.   (Well, three later on, a separate one for all L2
routers.)   One is "all routers", one is "all endnodes".   Routers listen
to the first, endnodes to the second.   Hellos are sent to "all routers"
so ONLY routers hear hellos.   Both endnodes and routers send hellos
(different types).   So routers build a list of all the nodes on each
interface.   The routers on an Ethernet pick one to be the designated
router, and only that router sends a hello to "all endnodes".   That's
how endnodes know the DR. 

End-nodes will, however, just snoop hello-messages, and know about
other
nodes that are on the same ethernet segment (I'm not sure if this
generalizes to other mediums than ethernet, I think the manuals only
talked about ethernet). So, you can actually have an ethernet segment
with only end-nodes, and communication will actually work anyway. Even
though if you look at adjacent nodes with NCP, you'll not see any.
That's the ethernet cache unless I read things wrong here, btw.

No, endnodes don't do any snooping (nor do routers).   DECnet
intentionally was designed to rely on advertisements (hello messages)
and those were done in a way that limits overhead.   So end nodes hear
only hellos from a single system (the designated router).

If an end node is asked to talk to some address, it consults the cache.
If it's in the cache, the data there is used.   If not, the message goes
to the designated router if one is known.   Finally, if there is no DR
(single endnode-only LAN) then it sends directly to the destination
using the calculated MAC address.

Incoming traffic fills in the previous-hop cache, so once you get past
the first message, end node traffic goes via the optimal path.

What I find "horrible" about this is that end-nodes will (atleast in
VMS) will actually happily even talk with machines in another area, if
they happen to be sitting on the same ethernet segment (this has
bitten
me with my bridge and HECnet).

Yes, that was considered a feature.   It's a side effect of the way the
previous hop cache works, and when we realized this we decided it was a
good thing so that's how it ended up.

Anyway, the comment is that the path might not be optimal. End nodes
pick the level 1 router with the highest priority. If you have two
level
1 routers, the one you didn't communicate with might have been more
optimal, but you'll never know. And the same is true for area routers.

For out of area traffic you're definitely right, the first leg is to the
best L2 router for the destination area, which may not be the best way
to get to the final destination.   (In a sensibly layed-out hierarchical
network, the difference should not be large.)   But end nodes do
communicate just as efficiently as routers, thanks to the previous hop
cache.   And in fact, for the multi area Ethernet case, they do better
than routers because routers will not talk directly to an out of area
node, even if it's on the same Ethernet.

	paul



More information about the Hecnet-list mailing list