Q on gvrp

[BT]

Archived from groups: comp.dcom.lans.ethernet (More info?)

I read 802.1q on VLAN. Here are some questions I have about it.
1)If gvrp frames are untagged, what if the receive port is configured as
Only admit tagged packets? Ingres rule applies first right?
2)How does the swicth forward the gvrp packets

Thanks
BT

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

"BT" <guangbutun@hotmail.com> wrote in message news:<c8l4cd$be4$1@news.f.de.plusline.net>...
> I read 802.1q on VLAN. Here are some questions I have about it.
> 1)If gvrp frames are untagged, what if the receive port is configured as
> Only admit tagged packets? Ingres rule applies first right?
> 2)How does the swicth forward the gvrp packets
>
> Thanks
> BT

GVRP frames are sent to a reserved MAC address. Based on this
MAC address, the frames can be recognized as "special frames"
and don't need to go through port filtering as regular frames would.
A switch doesn't blindly flood GVRP frames along the spanning tree.
It must process the received frame, and then propagate any new
information on all of its ports on the spanning tree.

Anoop

 

[Max]

Archived from groups: comp.dcom.lans.ethernet (More info?)

>
> GVRP frames are sent to a reserved MAC address. Based on this
> MAC address, the frames can be recognized as "special frames"
> and don't need to go through port filtering as regular frames would.
> A switch doesn't blindly flood GVRP frames along the spanning tree.
> It must process the received frame, and then propagate any new
> information on all of its ports on the spanning tree.
Does it mean if the bridge receive a GVRP frame on one port for VLAN
X, then every port (in forwrding state) on the bridge will be memeber
of VLAN X?

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

max8y@yahoo.com (Max) wrote in message news:<7800b3f8.0406011244.59507496@posting.google.com>...
> >
> > GVRP frames are sent to a reserved MAC address. Based on this
> > MAC address, the frames can be recognized as "special frames"
> > and don't need to go through port filtering as regular frames would.
> > A switch doesn't blindly flood GVRP frames along the spanning tree.
> > It must process the received frame, and then propagate any new
> > information on all of its ports on the spanning tree.

> Does it mean if the bridge receive a GVRP frame on one port for VLAN
> X, then every port (in forwrding state) on the bridge will be memeber
> of VLAN X?

At a high level, GVRP works as follows. When a GVRP frame is
received on a port, all of the VLANs in that frame are updated
to have a port set that corresponds to the port that the frame
was _received_ on. The set of VLANs is then propagated on
all ports on the spanning tree except that which the frame
was received on. Assuming both edges of the network have GVRP
running (and they have to in order for it to work), all switches
in the network will eventually receive GVRP frames for VLANs
on ports through which those VLAN's members can be reached.

The purpose of GVRP is to simplify (but not eliminate) static
configuration. The idea is to configure switches at the edge
and have the information dynamically propagate into the core.
As such, the edge ports must still be statically configured with
VLAN membership information, and they don't run GVRP. It's this
information that is propagated to create dynamic VLAN membership
in the core of the network.

Anoop

 

[Max]

Archived from groups: comp.dcom.lans.ethernet (More info?)

>
> > Does it mean if the bridge receive a GVRP frame on one port for VLAN
> > X, then every port (in forwrding state) on the bridge will be memeber
> > of VLAN X?
>
> At a high level, GVRP works as follows. When a GVRP frame is
> received on a port, all of the VLANs in that frame are updated
> to have a port set that corresponds to the port that the frame
> was _received_ on. The set of VLANs is then propagated on
> all ports on the spanning tree except that which the frame
> was received on. Assuming both edges of the network have GVRP
> running (and they have to in order for it to work), all switches
> in the network will eventually receive GVRP frames for VLANs
> on ports through which those VLAN's members can be reached.
>
This is the point I dont understand. This pretty much says that ALL
ports on ALL bridges that can be reached in the spanning tree domain,
will become memeber of the VALNs conveyed in the GVRP frame. That does
not seem to be the reason we want VLAN in the LAN, or I
misunderstood...
Max

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Max wrote:


>
> This is the point I dont understand. This pretty much says that ALL
> ports on ALL bridges that can be reached in the spanning tree domain,
> will become memeber of the VALNs conveyed in the GVRP frame. That does
> not seem to be the reason we want VLAN in the LAN, or I
> misunderstood...
> Max

No,
I think all ports in the spanning tree that lead back to the port the
GVRP packet was received on become members. Not every single ports on
every switch in the spanning tree!

so basically just ports that are linking switches together (that are
active when using spanning tree) become members.

That is if I'm reading the explanation right.

"endpoint" or "edge" ports going to workstations, servers, routers, etc.
will have to be manually made members of the VLAN. I think.

My net is small so I don't bother with GVRP.

--
Copyright 2004 T. Sean Weintz
This post may be copied freely without
the express permission of T. Sean Weintz.
T. Sean Weintz could care less.
T. Sean Weintz is in no way responsible for
the accuracy of any information contained in
any usenet postings claiming to be from
T. Sean Weintz. Users reading postings from
T. Sean Weintz do so at their own risk.
T. Sean Weintz will in no way be liable for
premature hair loss, divorce, insanity,
world hunger, or any other adverse relults
that may arise from reading any usenet
posting attributed to T. Sean Weintz

ALSO - FWIW, The following WHOIS Record is years out of date:
Weintz, Sean (SW2893) tweintz@MAIL.IDT.NET
Sean Weintz
462 Sixth Street , #A
Brooklyn, NY 11215

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

max8y@yahoo.com (Max) wrote in message news:<7800b3f8.0406040635.40948814@posting.google.com>...
> >
> > > Does it mean if the bridge receive a GVRP frame on one port for VLAN
> > > X, then every port (in forwrding state) on the bridge will be memeber
> > > of VLAN X?
> >
> > At a high level, GVRP works as follows. When a GVRP frame is
> > received on a port, all of the VLANs in that frame are updated
> > to have a port set that corresponds to the port that the frame
> > was _received_ on. The set of VLANs is then propagated on
> > all ports on the spanning tree except that which the frame
> > was received on. Assuming both edges of the network have GVRP
> > running (and they have to in order for it to work), all switches
> > in the network will eventually receive GVRP frames for VLANs
> > on ports through which those VLAN's members can be reached.
> >
> This is the point I dont understand. This pretty much says that ALL
> ports on ALL bridges that can be reached in the spanning tree domain,
> will become memeber of the VALNs conveyed in the GVRP frame. That does
> not seem to be the reason we want VLAN in the LAN, or I
> misunderstood...

Consider the following example (you must view this in
fixed-width font or the pictures will get messed up).


Original configuration of VLANs on edge ports

| 1,2
+++
|A|
+++
|
|
|
+++ +++ +-+
1 |B+-----+C+-----+D| 2
+-+ +++ +-+


GVRP frame sent from A to C

| 1,2
+++
|A|
+++
|
|
|1,2
+++ +++ +-+
1 |B+-----+C+-----+D| 2
+-+ +++ +-+


GVRP frame sent from D to C

| 1,2
+++
|A|
+++
|
|
|1,2
+++ +++ +-+
1 |B+-----+C+-----+D| 2
+-+ +++ 2 +-+


GVRP frame sent from B to C

| 1,2
+++
|A|
+++
|
|
|1,2
+++ +++ +-+
1 |B+-----+C+-----+D| 2
+-+ 1 +++ 2 +-+


GVRP frame sent from C to B

| 1,2
+++
|A|
+++
|
|
|1,2
+++1,2 +++ +-+
1 |B+-----+C+-----+D| 2
+-+ 1 +++ 2 +-+


GVRP frame sent from C to D

| 1,2
+++
|A|
+++
|
|
|1,2
+++1,2 +++ 1,2+-+
1 |B+-----+C+-----+D| 2
+-+ 1 +++ 2 +-+


GVRP frame sent from C to A

| 1,2
+++
|A|
+++
|1,2
|
|1,2
+++1,2 +++ 1,2+-+
1 |B+-----+C+-----+D| 2
+-+ 1 +++ 2 +-+


As you can see, switch C has only VLAN 1 on the left
port and only VLAN 2 on the right port. This ensures
that it doesn't flood a VLAN's traffic on a port
where there are no interested receivers.

Hope this helps clarify things.

Anoop

 

[Max]

Archived from groups: comp.dcom.lans.ethernet (More info?)

>
>
> Original configuration of VLANs on edge ports
>
> | 1,2
> +++
> |A|
> +++
> |
> |
> |
> +++ +++ +-+
> 1 |B+-----+C+-----+D| 2
> +-+ +++ +-+
>
>
> GVRP frame sent from A to C
>
> | 1,2
> +++
> |A|
> +++
> |
> |
> |1,2
> +++ +++ +-+
> 1 |B+-----+C+-----+D| 2
> +-+ +++ +-+
>
OK at this point, assum that C and D both active, the registeration
frames will be forwarded to B and D (Then B and D have both VLANs)?
Thanks a lot for your detail diagrams.
Max

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

max8y@yahoo.com (Max) wrote in message news:<7800b3f8.0406220955.5515d5d1@posting.google.com>...
> >
> >
> > Original configuration of VLANs on edge ports
> >
> > | 1,2
> > +++
> > |A|
> > +++
> > |
> > |
> > |
> > +++ +++ +-+
> > 1 |B+-----+C+-----+D| 2
> > +-+ +++ +-+
> >
> >
> > GVRP frame sent from A to C
> >
> > | 1,2
> > +++
> > |A|
> > +++
> > |
> > |
> > |1,2
> > +++ +++ +-+
> > 1 |B+-----+C+-----+D| 2
> > +-+ +++ +-+
> >
> OK at this point, assum that C and D both active, the registeration
> frames will be forwarded to B and D (Then B and D have both VLANs)?
> Thanks a lot for your detail diagrams.

Yes, they will have both VLANs on the inner port only, but that doesn't
mean anything because they will never receive a frame on that
port for the "other" VLAN since they are only connected to C and
the port that C connects from belongs to only one VLAN.

Looking back at the example, C only forwards VLAN 1's frames to B,
so even though B has a membership for VLAN 1 & 2 on that port, B
doesn't really enable forwarding of traffic for VLAN 2; it needs
to have another port in that VLAN 2 in order to enable forwarding,
in which case that is what would be the desirable behavior.

Anoop