Sebastien Roy wrote: > An additional protocol, MVRP, exists for registering VLANs. MVRP > is intended to supersede and replace GVRP. However, few switch > designers have adopted MVRP and GVRP remains the standard protocol > for this function. Moreover, customers have specifically requested > support for announcing VLAN IDs to the network with GVRP.
I'm a little surprised by this. GVRP has effectively no security, meaning that either clients can register for arbitrary VLANs in your network (often a bad thing, given that VLANs are usually used to segregate traffic for security reasons) or that you're forced to configure per-port filters of allowed registrations. If you do the latter, it's usually simpler just to configure the required per-port VLANs and be done with it, not needing the complexity of dynamic registration at all. So what's the deal with the folks wanting GVRP? Are they unaware of the security issues, or do they have a usage case where they don't care? Also, one detailed question on the intended implementation: there's no need to send any GVRP messages if the only link in use on a port is the PVID. Is that optimization made? If I have "vlan-announce" set to "gvrp" and I have only (say) "e1000g0" plumbed, do I get empty GVRP messages? > Although this system uses GVRP to announce VLAN IDs, it is > not an implementation of full 802.1d GVRP protocol and state > machine. This project only sends request -- in order to > propagate VLAN information from VNICs/VSwitches/to real switches > and bridges. Specifically, the system does not process incoming > GVRP packets. An appropriate place to implement the full GVRP > state machine would be in the ethernet bridge module > (PSARC 2008/055). For what it's worth, we didn't bother doing this in the bridging code because (A) there's no security, (B) the implementation is pretty complex, and (C) there's no point in it if typical clients today aren't bothering to announce their desires. If GVRP is "real," I'd suggest defaulting "vlan-announce" to "gvrp." Otherwise, we're just perpetuating the environment in which it's impossible to deploy GVRP for real: if clients aren't asking by default, then you can't really use it. There's a chicken-and-egg problem here. I realize this project should be a quite simple change, and is perhaps a good idea just on spec, but I can't help wondering whether anyone benefits. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
