Re: Sniffer Can't see cluster traffic
From: JF Mezei (jfmezei.spamnot_at_teksavvy.com)
Date: 09/23/04
- Next message: JF Mezei: "OT: Spam protection software"
- Previous message: Jonathan Cronin: "Re: RMS and threads"
- In reply to: John E. Malmberg: "Re: Sniffer Can't see cluster traffic"
- Next in thread: Bart Zorn: "Re: Sniffer Can't see cluster traffic"
- Reply: Bart Zorn: "Re: Sniffer Can't see cluster traffic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 23 Sep 2004 00:06:29 -0400
"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: JF Mezei: "OT: Spam protection software"
- Previous message: Jonathan Cronin: "Re: RMS and threads"
- In reply to: John E. Malmberg: "Re: Sniffer Can't see cluster traffic"
- Next in thread: Bart Zorn: "Re: Sniffer Can't see cluster traffic"
- Reply: Bart Zorn: "Re: Sniffer Can't see cluster traffic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
