> We are aware of the requirement to prevent two users on the same VSWITCH > from talking to each other.
*grump* That's what VLANs are for. Don't want two hosts to talk? Don't put them on the same VLAN. Frame-based ACLs are very rare in the real world; do we need packet inspection on that level here? I think not. > Restricting the details of the VSWITCH simply makes it more difficult for > the guest to be configured correctly. I mean, does the sysprog *really* > want to be involved in every "guest A can't ping guest B" quandry? That doesn't really make sense. Hosts should either be statically configured (at which point they don't need access to the switch info at all), or dynamically configured with DHCP (at which point they STILL don't need to know the switch configuration and who else is connected). And yes, I *DO* want to know about connectivity problems. If host A can't ping host B, then they are either 1) in the wrong VLAN, 2) connected to the wrong switch, or 3) misconfigured in some way. All of which imply I need to do something about it, and the networking people certainly aren't going to fix it. > And if I wanted to, I'd just start ARPing for different IP addys and see > what responses I get. Not have the QUERY output would slow me down for a > few minutes. On the other hand, there's no reason to hand someone a list of "interesting" MAC addresses for free, either. You couldn't get that information from a real switch without logging into the management interface, and there's *some* kind of authentication for that configuration information, regardless of how strong that authentication might be. I think I'd agree with Marcy: it seems odd to tell a class G guest anything about the other guests attached to a switch. Class B, sure, but not class G. -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
