Date: Thu, 6 Jul 2000 08:47:35 -0400 (EDT) From: David Gilbert <dgilbert@velocet.ca> To: Luigi Rizzo <luigi@info.iet.unipi.it> Cc: tim@iafrica.com.na, David Gilbert <dgilbert@velocet.ca>, Kevin Oberman <oberman@es.net>, "Louis A. Mamakos" <louie@TransSys.COM>, Joerg Micheel <joerg@cs.waikato.ac.nz>, freebsd-stable@FreeBSD.ORG Subject: Re: Ethernet MTUs > 1500? Message-ID: <14692.32743.852986.408436@trooper.velocet.net> In-Reply-To: <200007060640.IAA82096@info.iet.unipi.it> References: <396368C9.C3C5A50F@polytechnic.edu.na> <200007060640.IAA82096@info.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Luigi" == Luigi Rizzo <luigi@info.iet.unipi.it> writes: Luigi> ok think of the following: I have a st machine which goes Luigi> through a VLAN bridge out to a trunk interface, which in turn Luigi> goes into a VLAN bridge which does trunkinking again Luigi> ... basically you might end up with frames being encapsulated Luigi> multiple times (and decapsulated on the reverse path). Now i Luigi> wonder if this is allowed by the vlan spec and also how does a Luigi> vlan bridge behaves when it sees a vlan-tagged frame on a Luigi> non-trunk port. I do know how my FreeBSD-based vlan bridge Luigi> behaves -- it does multiple encaps, but then if a packet Luigi> becomes too large it is silently dropped by the interface. 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. to reverse the path, D would send a packet on vlan 225 to C, which would rewrite the packet to have vlan 57 and it would pass through B unchanged to A. Basically, I suppose you could "encapsulate" a vlan packet, but in practice, you don't. In practice the vlan tags are shared only between a pair of devices ... although you can administratively make them the same over several segments (but you don't have to). As a side issue, what's really cool in the netgraph scheme of things is that if ethernet interfaces are netgraph nodes, then it makes sense that hooks on the ethernet interfaces are vlan interfaces (among other hooks). This means, for instance, that if you attach a net"graph" to the ethernet nodes vlan-233 hook, packets will flow in and out vlan-233 on that link. This also means that your FreeBSD box could perform the function of a vlan switch by simply attaching the vlan-57 hook of one interface to the vlan-225 of another, the FreeBSD box would perform like box C above. (This, of course, leads to the ideal extension that I have expoused before where jail(8) gets a netgraph node rather than an IP address as it's network interface. The possibilites simply explode ... not the least of which being able to encapsulate the jail(8)'s traffic in a vlan and/or having multiple addresses (or even multiple protocols) available in the vlan). In short, vlan tags are not like GRE (which might be the confusion) ... they are simply part of the ethernet header. Can anyone tell me what cards do and what cards don't support larger packets ... or is it largely our interface code that's dropping "long" frames? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14692.32743.852986.408436>