[rbridge] Consensus Check: Configure ports todisable endstationtraffic

[James Carlson]

Eric Gray writes:
> 	I disagree that you would necessarily break the 
> normal operation of end-stations running on the link.
> I thought I had said that previosuly, so maybe I am
> not getting your point.  However, I am pretty sure 
> Joe was talking about "silent end stations" which is
> pretty far from the "normal case" these days.

Silent end stations are but one instance of the breakage -- and those
can actually happen if (as another poster pointed out) there's a
repeater or an ordinary bridge in the way that prevents the link
up/down transitions that would ordinarily cause chatter.

> 	Many of today's end stations would work, as long 
> as you don't explicitly disable ARP (as in both sending
> requests and receiving responses) because many of them 
> do not rely on being discovered by flooding.

I don't see how that's true.  The original message in this thread
(lost in context due to odd quoting practices) said this:

           Currently broadcast, unknown unicast, and
      non-IP-derived multicast frames are output to all links. This is
      wasteful if there are no end stations on the link. Provide that
      a port can be configured so as to be disabled for end station
      traffic.

Suppose we have such a switch, and someone enables it to disable that
traffic.

If that's done, then:

  - Broadcast ARP queries from other nodes on other Ethernet
    subnetworks will not be relayed to this link.  There will be no
    way for other nodes to _find_ the marooned node.

  - Broadcast ARP probes for address use (duplicate address detection)
    will not be sent to this link, allowing nodes on other links
    within the same broadcast domain to use the same IP address,
    undetected.

  - Non-IP broadcast messages won't be sent to this link.  Any
    protocols built on broadcast will fail.

I'm not sure what functionality you're intending to describe, but it
doesn't sound at all to me like this configuration will "work."

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677