[rbridge] Consensus Check: Configure ports todisableendstationtraffic

[Eric Gray]

James,

	Please see below...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com] 
> Sent: Wednesday, January 09, 2008 11:18 AM
> To: Eric Gray
> Cc: Joe Touch; Rbridge at postel.org
> Subject: RE: [rbridge] Consensus Check: Configure ports 
> todisableendstationtraffic
> Importance: High
> 
> 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.

That is not strictly true in many cases.  For example, if the 
"marooned node" has used DHCP to obtain an IP address and the
information for the default router, DNS server, etc. - then
it will be in the bridge (and presumably RBridge) forwarding
tables, and if the DHCP server is also the local LAN's default
router (or, in many cases, any router), then it will have the 
MAC<->IP address mapping to respond to an ARP request from 
anywhere else.

This is the common case in many enterprise networks.

Note that - if broadcast traffic is bi-directionaally disabled,
then the DHCP request will not have been forwarded and the end
station ("marooned node") will truly be marooned.  However, I
suggest that this could be a very bad idea over the long run.
This could break things that work today and will very probably
break things (or make it difficult to work around) in anything
new proposed - for example - by IEEE.

> 
>   - 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.

Again, this is difficult to imagine unless the "marooned node"
is unable to contact the DHCP server, or DHCP is not in use.

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

Yes - at least to the extent that the "marooned node" counts on
receiving broadcast messages.  And?

Given the prevalence of VLAN technologies, and the detrimental
effect that broadcast-based protocols have in a VLAN environment,
how common is it in today's networks for workstations to use many
protocols that uses broadcast for both query and response?

> 
> 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."

Try it in your home network, if you can.  Better yet, use Ethereal
to see what happens when you add a laptop to your local network.

Chances are you will see only one broadcast message associated with
adding the laptop and that will be coming from it, not going to it.

Also, once you start using the laptop, it may send one or more ARP 
queries to your default router (or it may simply forward everything 
to the default router's MAC, which it may have acquired from the 
DHCP response, and rely on IP re-directs if necessary).  Again,
broadcast messages come from the "marooned node" instead of going
to it.

If you let the laptop stay idle long enough, it may get lost from 
bridge/switch forwarding tables.  But even if this happens, it is
very likely that the user will release and re-acquire an IP address
(via the DHCP server) - or reboot - and all will be well.  Note 
that the need to do that is not uncommon for some operating systems
as it is.

Meanwhile, if you were thinking that merely disabling forwarding of
broadcast traffic to a link would prevent someone (e.g. - a hacker)
from putting an end-station on the link and accessing the network,
you should think again.  This is especially true if the person in
question merely wants to access the network for a short period of
time and then leave.

It will "work", sometimes without special effort, but almost any 
time with some minimal amount of manual configuration at the end 
station being inserted.

> 
> -- 
> 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
>