[PATCH] Updated 802.1p/q patch
Hi, I have tested my 802.1p input patch with vlans configured. So far so good. It is now available from: http://people.FreeBSD.org/~bms/dump/latest-8021p.diff This updated patch moves the 802.1q encapsulation into if_ethersubr.c, allowing M_VLANTAG to be passed up and down the stack for 802.1p priority. I would greatly appreciate wider testing before it is committed. I've noticed that vlan(4) will not put a parent interface into PROMISC if the vlanhwtag capability exists but is disabled. If the main non-vlan input path receives datagrams destined for a layer 3 address configured on a vlan interface, the netinet stack will quite reasonably try to reply on the vlan interface unless net.inet.ip.check_interface is set to 1; something to be aware of. If vlan(4) gets an mbuf which has already been tagged with M_VLANTAG from higher up in the stack, it *should* ignore the vlan id by overwriting it, and using the priority field already assigned to it, so that ALTQ or PF can do its magic. This new patch should do this. The Ethernet code will not use 802.1p by default unless it came from higher up (by way of M_VLANTAG passed to a driver); we should insert the 802.1p tag in the situation where we got an M_VLANTAG from further up without a vlan(4) instance being involved. The new patch should do this. We should also make sure the CFI bit is always cleared in bridging situations as it has special meaning for token ring and FDDI. What has not been tested or considered is the situation where we have nested VLANs. At least one individual has asked about this feature. At the moment, I'd suggest that only Netgraph potentially deals with this rather than the main network stack. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Updated 802.1p/q patch
On Wed, Feb 14, 2007 at 10:18:49PM +, Bruce M Simpson wrote: > > What has not been tested or considered is the situation where we have > nested VLANs. At least one individual has asked about this feature. At > the moment, I'd suggest that only Netgraph potentially deals with this > rather than the main network stack. Do you have any architectural reservations about nested VLANs in the main network stack? Presently, a one-line patch can allow a vlan(4) to attach to another vlan(4), but I haven't heard about the behaviour of the resulting setup yet. Thanks! -- Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Updated 802.1p/q patch
On Wed, Feb 14, 2007 at 10:18:49PM +, Bruce M Simpson wrote:
> Hi,
>
> I have tested my 802.1p input patch with vlans configured. So far so good.
>
> It is now available from:
> http://people.FreeBSD.org/~bms/dump/latest-8021p.diff
>
/*
* If the device did not perform decapsulation of the 802.1q
* VLAN header itself, do this now...
*/
if ((ether_type == ETHERTYPE_VLAN) && !(m->m_flags & M_VLANTAG)) {
...
}
Is it possible to move this block into ether_input() above the bridge
hook? it would be nice if ether_vtag was set consistently early on in
the game.
cheers,
Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Updated 802.1p/q patch
Andrew Thompson wrote:
On Wed, Feb 14, 2007 at 10:18:49PM +, Bruce M Simpson wrote:
Hi,
I have tested my 802.1p input patch with vlans configured. So far so good.
It is now available from:
http://people.FreeBSD.org/~bms/dump/latest-8021p.diff
/*
* If the device did not perform decapsulation of the 802.1q
* VLAN header itself, do this now...
*/
if ((ether_type == ETHERTYPE_VLAN) && !(m->m_flags & M_VLANTAG)) {
...
}
Is it possible to move this block into ether_input() above the bridge
hook? it would be nice if ether_vtag was set consistently early on in
the game.
yes, I would like the tagging to be done before the bridging so that all packets
being filtered by the bridge are the same.
cheers,
Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Updated 802.1p/q patch
Yar Tikhiy wrote: Do you have any architectural reservations about nested VLANs in the main network stack? Presently, a one-line patch can allow a vlan(4) to attach to another vlan(4), but I haven't heard about the behaviour of the resulting setup yet. After looking around it seems there is definite scope and demand for such a feature in scenarios such as ISP Metro Ethernet setups. However, we can't rely on M_VLANTAG alone to implement it. To do it we need to be sure of the following: 1. Output path in vlan(4) changes not to call ether_output_frame() directly if nested. 2. Output path in vlan(4) detects when it's going to re-enter the parent vlan(4), and makes sure the inner 802.1q header is expanded and inserted from M_VLANTAG before passing it down the stack. 3. That the drivers and cards out there can deal with Q-in-Q. 4. That the input path only extracts and applies M_VLANTAG for the outer 802.1q header. 4. That the input path is able to reenter vlan(4) correctly on the way back up the stack; The code which produces/consumes M_VLANTAG from the 802.1q header might need to be made common. The priority field them becomes problematic. As a compromise I'd suggest the priority field in the VLAN tag is derived from the innermost 802.1q header, which will be the first M_VLANTAG which the Ethernet part of the stack sees. This gives ALTQ/RSVP/PF a chance to do its thing without complicated workarounds. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
