Archived from groups: comp.dcom.lans.ethernet (More info?)
I am trying to make a GVRP host to an endstation. The idea is that
this host has static VLAN entries and it sends GVRP messages to a
switch which creates dynamical VLAN entries and propagates GVRP
messages further.
I have read (=tried to understand) GVRP section of IEEE 802.1Q and
some other GVRP related documents but lots of things are unclear for
me.
IEEE 802.1Q has "skeleton code" for implementing GVRP but I'm
surprised that there doesn't seem to be any complete (or even less
complete) source codes published in internet. There are few things,
which I don't understand in above mentioned skeleton code. For
example:
- include files require gip.h but GIP is not needed to implement in
endstation (only 1 participant), right?
- where is the implementation of these "system supplied routines" such
as syspdu_tx & syspdu_alloc? What does sys.h include?
- are there any clear instructions anywhere how to build GVRP frame?
IEEE code just uses some gvf_wrmsg & gvf_rdmsg routines without a word
of their implementation.
I also wonder what IEE 802.1Q means by ES_REGISTER_VLAN_MEMBER &
ES_DEREGISTER_VLAN_MEMBER service primitives. Are these primitives
implemented somewhere? If not, why such specific name?
I do see an alternative way to implement GVRP functionality by using
SNMP to configure static VLANs to switch which endstation is connected
and therefore not needing to simulate GVRP functionality in endstation
itself. However this might be less optimal solution.
Archived from groups: comp.dcom.lans.ethernet (More info?)
nospamplz@jippii.fi (Hess) wrote in message news:<47493026.0408050344.7f7bf542@posting.google.com>...
> I am trying to make a GVRP host to an endstation. The idea is that
> this host has static VLAN entries and it sends GVRP messages to a
> switch which creates dynamical VLAN entries and propagates GVRP
> messages further.
>
> I have read (=tried to understand) GVRP section of IEEE 802.1Q and
> some other GVRP related documents but lots of things are unclear for
> me.
>
> IEEE 802.1Q has "skeleton code" for implementing GVRP but I'm
> surprised that there doesn't seem to be any complete (or even less
> complete) source codes published in internet. There are few things,
> which I don't understand in above mentioned skeleton code. For
> example:
[..]
Since GVRP is an application of GARP, you would really need to
understand GARP before you can fully implement GVRP. GARP is
described in IEEE 802.1D. You might want to take a look at that
since it'll answer most of your questions. That is, for example,
where you would find sys.h.
Archived from groups: comp.dcom.lans.ethernet (More info?)
anoop@alumni.duke.edu (Anoop Ghanwani) wrote in message news:<50bde0e6.0408060601.2d290664@posting.google.com>...
> [..]
>
> Since GVRP is an application of GARP, you would really need to
> understand GARP before you can fully implement GVRP. GARP is
> described in IEEE 802.1D. You might want to take a look at that
> since it'll answer most of your questions. That is, for example,
> where you would find sys.h.
Yeah but I have been reading GARP section of IEEE 802.1D as well
without getting answers For example that sys.h included some other
libraries which are unknown to me. And I am more interested about code
files than header files
Archived from groups: comp.dcom.lans.ethernet (More info?)
nospamplz@jippii.fi (Hess) wrote in message news:<47493026.0408081220.5a1fa1f0@posting.google.com>...
> anoop@alumni.duke.edu (Anoop Ghanwani) wrote in message news:<50bde0e6.0408060601.2d290664@posting.google.com>...
> > [..]
> >
> > Since GVRP is an application of GARP, you would really need to
> > understand GARP before you can fully implement GVRP. GARP is
> > described in IEEE 802.1D. You might want to take a look at that
> > since it'll answer most of your questions. That is, for example,
> > where you would find sys.h.
>
> Yeah but I have been reading GARP section of IEEE 802.1D as well
> without getting answers For example that sys.h included some other
> libraries which are unknown to me. And I am more interested about code
> files than header files
In that case, you might try posting your queries to the IEEE 802.1
mailing list. See http://www.ieee802.org/1/email-pages/ for more
information on this. I am not aware of a public-domain GVRP
implementation, so I doubt you will be able to get any code.
However, the folks there are pretty good about clarifying concepts
for anyone posting to the list.
Archived from groups: comp.dcom.lans.ethernet (More info?)
ghanwani@gmail.com (Anoop Ghanwani) wrote in message news:<67582204.0408082213.388979f@posting.google.com>...
> In that case, you might try posting your queries to the IEEE 802.1
> mailing list. See http://www.ieee802.org/1/email-pages/ for more
> information on this. I am not aware of a public-domain GVRP
> implementation, so I doubt you will be able to get any code.
> However, the folks there are pretty good about clarifying concepts
> for anyone posting to the list.
>
> Anoop
Ok, I'll take a look of it. Thanks for your suggestion. It just really
makes me wonder why there isn't any freeware GVRP implementations out
there (and not many commercial ones either) - haven't people found the
concept of it helpful?
Archived from groups: comp.dcom.lans.ethernet (More info?)
nospamplz@jippii.fi (Hess) wrote in message news:<47493026.0408091248.7d9546ea@posting.google.com>...
> Ok, I'll take a look of it. Thanks for your suggestion. It just really
> makes me wonder why there isn't any freeware GVRP implementations out
> there (and not many commercial ones either) - haven't people found the
> concept of it helpful?
To the best of my knowledge GVRP is not a very
widely deployed protocol, and certainly not one that
a network administrator would trust users to run on
an end-station. In general, however, freeware versions
of bridging software are sparse.
You are about to answer a thread that has been inactive for more than 6 months. If you still wish to proceed, please ensure that your posting is original and does not duplicate or overlap any prior responses to this thread.