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]"
