Re: Sniffer Can't see cluster traffic
From: Bart Zorn (Bart.Zorn_at_xs4all.nl)
Date: 09/23/04
- Next message: Doc.: "Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command"
- Previous message: Charlie Hammond: "Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command"
- In reply to: JF Mezei: "Re: Sniffer Can't see cluster traffic"
- Next in thread: briggs_at_encompasserve.org: "Re: Sniffer Can't see cluster traffic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 23 Sep 2004 06:29:24 -0700
One addition to your excellent expose:
None of the original Digital designed Ethernet protocols (SCS, LAT,
MOP, DECnet, to name some) ever use Ethernet broadcasts, but only
protocol specific multicasts.
In my opinion that conforms to the ideas behind the original Ethernet
specification. Not so strange when you remember which companies have
written that specs: Intel, Xerox and Digital!
IP over Ethernet on the other hand is full of Ethernet broadcasts. IP
is never properly designed in that respect.
Regards,
Bart Zorn
JF Mezei <jfmezei.spamnot@teksavvy.com> wrote in message news:<41524BC4.515A0D0C@teksavvy.com>...
> "John E. Malmberg" wrote:
> > As I remember from looking at the protocol traces, they were sent to a
> > protocol and cluster specific multicast MAC address, from a protocol and
> > node specific source MAC address.
>
> When I signed up to a cable ISP years ago and found out it theyr service
> didn't work, they, like any good civil servant, blamed my setup. I had to do
> protocol traces to show to them that I was sending DHCP requests and not
> getting any response from the modem, although I was seeing ARP requests coming
> from the modem.
>
> In the process, I got to see many SCS packets that were specifically adressed
> to each of the 2 nodes on my lan. When BIKE has an MSCP request to a disk
> served by VELO, there is no reason to broadcast that request.
>
> > There are bits in the packets that the switches use to determine if it
> > is a multi-cast packet or a directed packet.
>
> Yep and that is solely at the ethernet packet level. There is actually a good
> explanation of these in the good old VMS do set (grey wall) for the ethernet driver.
>
> > Typically the characteristics of a non-routable protocol are that it
> > communicates with broadcast destination addresses so it will not depend
> > on keeping a mapping table of MAC addresses to the remote hosts.
>
> My understanding and experience is that both LAT and SCS do have tables of MAC
> adresses to whom they talk. For instance, a terminal server talking to node A
> will be sending packets to NODE A's ethernet address with a protocol field of
> LAT. The ethernet card on Node A, upon seeing the protocol field, then feeds
> that packet to the LAT driver.
>
> Similarly, when Node A wants to send a packet to a terminal, the packet will
> be adresses specifically to the terminal server in charge of that terminal.
> Where there are broadcasts is the regular service announcements. (in terms of
> LAT). And there would also be broadcasts for SCS when a node needs to send a
> packet to all other nodes in the network.
>
> > The
> > upper level of the protocol handler then filters out what packets that
> > it cares about.
>
> nop. The ethernet card filters out packets that are not supposed to be seen by
> that ethernet address (packets adressed to specifically to another MAC address
> for instance). For those packets that this nodes is sopposed to see, it then
> looks at the protocol field and then delivers that packet to the approriate
> driver (decnet, lat, scs, tcpip, whatever).
>
> A standard (non vlan) switch only deals with MAC addresses. It has a table of
> which MAC adresses live on which port of the switch. And only sends to that
> port packets that should be seen by that any of the MAC adresses that reside
> on that PORT. And this includes multicast and broadcasts since they are
> designed to be seen by everyone on an ethernet.
>
> VLANS complicate things because more sophisticated ones can filter out
> protocols. However, they still do not route nor do they look inside the
> ehthernet packet contents. They only look at the ethernet header, and as such
> as protocol independant.
- Next message: Doc.: "Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command"
- Previous message: Charlie Hammond: "Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command"
- In reply to: JF Mezei: "Re: Sniffer Can't see cluster traffic"
- Next in thread: briggs_at_encompasserve.org: "Re: Sniffer Can't see cluster traffic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
