Paul Koning wrote:
...
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.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00,
ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last
two
addresses are sent to seems to differ from node to node, and I haven't
figured out exactly how yet).
That fits what I said. Ab:00:00:03:00:00 is "all routers". So the
hellos sent to that address are received by routers but not by endnodes.
Ab:00:00:04:00:00 is "all endnodes". The hello that goes to that
address is from the designated router. In your example I guess that was
an L2 router but that's just a coincidence. And there will only be one
router (L1 or L2) sending to that address, the designated router.
09:00:2b:02:00:00 was a later addition. It's not in the routing 2.0.0
spec, it would be in the 2.1.0 spec if we could find one. That would be
the "all L2 routers" address. The idea for adding that address was to
allow L2 routing messages to be sent to that address instead of the "all
routers" address, so L2 route updates would not bother L1 routers.
...
So, obviously, routers and endnodes both send, and listen to the same
messages.
No, you're making an incorrect assumption. The multicast addresses you
send to, and the ones you listen to, are not necessarily the same. In
IP, yes (ARPs go to broadcast and everyone listens to that). Not so in
DECnet. End nodes listen to all-endnodes and send to all-routers.
Routers listen to all-routers and send to all-routers and (if DR) to
all-endnodes.
DECnet very deliberately used multicast rather than broadcast because
control packets are of interest only to some of the nodes, so by using a
specific multicast address, you can enable that if you need to hear the
traffic and disable it if you don't.
In fact, it's clear that the existence of broadcast is a design error
(and so is the fact that ARP uses it). Broadcast is defined as "traffic
that everyone wants to hear" and there IS no such traffic. For example,
you don't want to hear ARPs unless you speak IP, so clearly those should
have used an "All IP nodes" multicast address.
paul
Paul Koning wrote:
...
The routing message size isn't an issue in Phase IV because the data
can
be sent in pieces. That was another important change from Phase
III,
which always sends the route data for all nodes (up to 255 of them)
whether there is a change or not. 255 nodes just barely fits into a
standard DDCMP packet, but 1023 nodes would not. (Nor in a standard
Ethernet frame, for that matter.) And it's wasteful to send data
that
hasn't changed. So Phase IV has a way to send routing data for
selected
nodes.
Looking at traffic, I'd say that systems seems to be sending out
routing
packet updates although nothing is changing.
Oh right... I forgot one detail.
Routing updates are sent when something changes, and those (in Phase IV)
can be optimized to omit what hasn't changed.
In addition, full routing messages (all destinations) are sent
periodically. That makes the system "self-stabilizing": if any node is
confused about the routing data, it will reasonably soon be straightened
out by a full update.
paul
On 30.6.2010 19:41, Johnny Billquist wrote:
Hi, Paul. I see that I'll have to be way more careful with how I choose
my words around you... :-)
Paul Koning wrote:
...
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.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00,
ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last two
addresses are sent to seems to differ from node to node, and I haven't
figured out exactly how yet).
The multicast address AB 00 00 03 00 00 is to all Phase IV routers (=endnode hello)
The multicast address AB 00 00 04 00 00 is to all Phase IV endnodes
(=router hello)
All Level 1 and Level 2 routers should send router hellos to endnodes and endnodes should send endnode hellos so that routers know of all endnodes.
IIRC the 09-00-2B-02-00-00 multicasts are from DECdns.
(looking at live traffic right now)
I can give you a longer snapshot of live traffic if you want to see more
details...
So, obviously, routers and endnodes both send, and listen to the same
messages. If we ignore the weird other addresses of L2 routers, they in
fact all send messages on the same channel.
So, they all also pick up all the same information.
But, in addition to the hello messages, which all pick up and process,
and which are rather short messages sent fairly often, routers also send
level 1 and level 2 routing information messages. These are all just
thrown away by end-nodes. And level 1 routers more or less just throw
away level 2 routing messages as well.
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).
Sorry. Very sloppy wording on my part.
By "snooping" just meant that they receive the hello multicast messages,
and figure it out from there.
In essence, I meant snooping, since the messages aren't sent explicitly
to them, but they do not go into promiscous mode and look at all traffic
that pass over the ethernet.
But no, end-nodes will actually hear hello messages from everybody on
the same ethernet segment. From that, they remember all the nodes that
they can hear in their cache, and also remembers which is the routing
node with highest priority (priority of the router is carried in the
hello message).
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.
Yes, it starts by consulting the cache, and if the destination is in
there, it is used.
If not, it is sent to the designated router.
I think that if no designated router exist, and it's not in the cache,
any traffic will just result in an error return right away.
Incoming traffic fills in the previous-hop cache, so once you get past
the first message, end node traffic goes via the optimal path.
No. The hello messages fills the cache. That's how it can work even if
there is no router.
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.
Well... I don't know if I'd call it good. But that's probably because it
spoiled a feature I had wanted to do in my bridge... :-)
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.
Hmm... I don't think so. The first leg to another area from an end-node
will be to the designated level 1 router. From there it will travel to
the designated level 2 router, only then will it go by the most
efficient path to the right area (which might not in fact be the best
for the actual end destination), and only once inside that area will it
go by the most efficient path to the destination.
It all breaks down if you have several L1 or L2 routes on an area. (And
by break down I mean it can go suboptimal ways, it will still definitely
work just fine.)
Johnny
.
On Wed, Jun 30, 2010 at 05:02:37PM +0200, Johnny Billquist wrote:
In that case you should definitely not use my bridge...
Hmmm, I'll have to see what I want to do back to the house then. I'll deal
with that when the time comes. :-D
L1? L2? As in layers in the network stack?
I'm talking DECnet Level 1 or Level 2.
In talking to Steve I think I've sorted out how I want to get things setup.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Noted.
Johnny
Brian Hechinger wrote:
Node 52.1 will be named SUN
Sent from my iPhone
On Jun 30, 2010, at 11:31, Johnny Billquist <bqt at softjar.se> wrote:
Noted.
Johnny
Brian Hechinger wrote:
I would like to claim area 52.
-brian
Paul Koning wrote:
... Well, level 1 routers gives you pretty much the same isolation as
areas.
Unless you consider the relative size of the level 1 routing messages
a
problematic burden compared to level 2 routing messages. However, I'm
not even sure you can make the system not transmit level 1 routing
messages on all interfaces, meaning they will go out anyway, even if
you
only have another area at the other end of the line.
I think if you have a point to point out of area link you won't see L1
routing messages, but you probably will see them on an Ethernet.
Hmm. I have not tried, so I wouldn't be able to tell for sure. You might be right.
The routing message size isn't an issue in Phase IV because the data can
be sent in pieces. That was another important change from Phase III,
which always sends the route data for all nodes (up to 255 of them)
whether there is a change or not. 255 nodes just barely fits into a
standard DDCMP packet, but 1023 nodes would not. (Nor in a standard
Ethernet frame, for that matter.) And it's wasteful to send data that
hasn't changed. So Phase IV has a way to send routing data for selected
nodes.
Looking at traffic, I'd say that systems seems to be sending out routing packet updates although nothing is changing.
Johnny
Hi, Paul. I see that I'll have to be way more careful with how I choose my words around you... :-)
Paul Koning wrote:
...
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.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00, ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last two addresses are sent to seems to differ from node to node, and I haven't figured out exactly how yet).
(looking at live traffic right now)
I can give you a longer snapshot of live traffic if you want to see more details...
So, obviously, routers and endnodes both send, and listen to the same messages. If we ignore the weird other addresses of L2 routers, they in fact all send messages on the same channel.
So, they all also pick up all the same information.
But, in addition to the hello messages, which all pick up and process, and which are rather short messages sent fairly often, routers also send level 1 and level 2 routing information messages. These are all just thrown away by end-nodes. And level 1 routers more or less just throw away level 2 routing messages as well.
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).
Sorry. Very sloppy wording on my part.
By "snooping" just meant that they receive the hello multicast messages, and figure it out from there.
In essence, I meant snooping, since the messages aren't sent explicitly to them, but they do not go into promiscous mode and look at all traffic that pass over the ethernet.
But no, end-nodes will actually hear hello messages from everybody on the same ethernet segment. From that, they remember all the nodes that they can hear in their cache, and also remembers which is the routing node with highest priority (priority of the router is carried in the hello message).
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.
Yes, it starts by consulting the cache, and if the destination is in there, it is used.
If not, it is sent to the designated router.
I think that if no designated router exist, and it's not in the cache, any traffic will just result in an error return right away.
Incoming traffic fills in the previous-hop cache, so once you get past
the first message, end node traffic goes via the optimal path.
No. The hello messages fills the cache. That's how it can work even if there is no router.
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.
Well... I don't know if I'd call it good. But that's probably because it spoiled a feature I had wanted to do in my bridge... :-)
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.
Hmm... I don't think so. The first leg to another area from an end-node will be to the designated level 1 router. From there it will travel to the designated level 2 router, only then will it go by the most efficient path to the right area (which might not in fact be the best for the actual end destination), and only once inside that area will it go by the most efficient path to the destination.
It all breaks down if you have several L1 or L2 routes on an area. (And by break down I mean it can go suboptimal ways, it will still definitely work just fine.)
Johnny
Node 52.1 will be named SUN
Sent from my iPhone
On Jun 30, 2010, at 11:31, Johnny Billquist <bqt at softjar.se> wrote:
Noted.
Johnny
Brian Hechinger wrote:
I would like to claim area 52.
-brian
...
Well, level 1 routers gives you pretty much the same isolation as
areas.
Unless you consider the relative size of the level 1 routing messages
a
problematic burden compared to level 2 routing messages. However, I'm
not even sure you can make the system not transmit level 1 routing
messages on all interfaces, meaning they will go out anyway, even if
you
only have another area at the other end of the line.
I think if you have a point to point out of area link you won't see L1
routing messages, but you probably will see them on an Ethernet.
The routing message size isn't an issue in Phase IV because the data can
be sent in pieces. That was another important change from Phase III,
which always sends the route data for all nodes (up to 255 of them)
whether there is a change or not. 255 nodes just barely fits into a
standard DDCMP packet, but 1023 nodes would not. (Nor in a standard
Ethernet frame, for that matter.) And it's wasteful to send data that
hasn't changed. So Phase IV has a way to send routing data for selected
nodes.
paul
