> Naw... that's not how you'd configure it.  Lets say we have this:
> 
> ----------        ----------        ----------         ---------
> |   A    |--------|   B    |--------|    C   |---------|   D   |
> ----------        ----------        ----------         ---------
> 
> Now... if a packet leaves A on vlan 57, it will arrive at B marked
> with vlan 57.  If the BC link is the "same" trunk, the packet might
> continue on vlan 57.  Now if the CD link is a different "trunk" (and
> this is just an organizational issue), then the packet might be
> rewritten to have vlan 225 on it --- and would make that leg of the
> journey with vlan 225.

hmm... my understanding was (but i might be wrong) that _normally_
end hosts do not tag packets, the tag insertion/removal (this is
what i meant by encapsulation/decapsulation in my previous email)
is done by the VLAN bridge when such packets go through a trunk
interface (i.e. the link connected to that interface supports
traffic for multiple independent VLANs).
My point is that you don't know what happens to the traffic on
that link -- your network admin could decide to further aggregate
such traffic by forwarding it into a "normal" port of another
VLAN bridge, which then does the tagging again.

Agreed, this is not how you'd configure it, but as you say

> ........................ The possibilites simply explode ... not the

> In short, vlan tags are not like GRE (which might be the confusion)
> ... they are simply part of the ethernet header.

not fully sure about that. How could you possibly prevent a frame
from being untagged multiple times if the frame has an appropriate
bit pattern ?

        cheers
        luigi
-----------------------------------+-------------------------------------
  Luigi RIZZO, [EMAIL PROTECTED]  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Reply via email to