Hi Darren. >> >> 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). > > The implication of the last sentence is that if we were to do a full > GVRP at a later date then the administrative interface for it would > somehow involve talking with the bridging module in Solaris rather > than whatever this current project will do.
I apologize that this isn't clear. The point is that we are an endpoint on the network. Crossbow itself doesn't forward incoming packets. Therefore, we are only sending registration requests, not handling incoming requests -- that's only needed when you have to make a decision where to forward them. If, at some point in the future, the decision is made that full GVRP support is required, then the logical place to implement it is in the bridge module. After all, GVRP is part of the 801.2d bridging spec. > If that were to be the case, how would that impact the link > properties above? GVRP support is defined to operate on ethernet interface "ports". The dladm linkprop interface is probably still the correct way to control it. I believe the Right Thing in this case would be to have this client code in place which registers with bridging module instead of (or in addition to) the attached physical switch. donour
