| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <525D495C.7040004@redhat.com> Date: Tue, 15 Oct 2013 09:55:40 -0400 From: Vlad Yasevich <vyasevic@...hat.com> To: Toshiaki Makita <toshiaki.makita1@...il.com> CC: Toshiaki Makita <makita.toshiaki@....ntt.co.jp>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org, Fernando Luis Vazquez Cao <fernando_b1@....ntt.co.jp>, Patrick McHardy <kaber@...sh.net> Subject: Re: [PATCH net 0/4] bridge: Fix problems around the PVID On 10/13/2013 12:11 PM, Toshiaki Makita wrote: > On Fri, 2013-10-11 at 10:14 -0400, Vlad Yasevich wrote: >> On 10/11/2013 03:34 AM, Toshiaki Makita wrote: >>> On Wed, 2013-10-09 at 11:01 -0400, Vlad Yasevich wrote: >>>> On 10/01/2013 07:56 AM, Toshiaki Makita wrote: >>>>> On Mon, 2013-09-30 at 12:01 -0400, Vlad Yasevich wrote: >>>>>> On 09/30/2013 07:46 AM, Toshiaki Makita wrote: >>>>>>> On Fri, 2013-09-27 at 14:10 -0400, Vlad Yasevich wrote: >>>>>>>> On 09/27/2013 01:11 PM, Toshiaki Makita wrote: >>>>>>>>> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote: >>>>>>>>>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote: >>>>>>>>>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote: >>>>>>>>>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote: >>>>>>>>>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote: >>>>>>>>>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote: >>>>>>>>>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote: >>>>>>>>>>>>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote: >>>>>>>>>>>>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David >>>>>>>>>>>>>>>>>>> Miller wrote: >>>>>>>>>>>>>>>>>>>> From: Toshiaki Makita >>>>>>>>>>>>>>>>>>>> <makita.toshiaki@....ntt.co.jp> Date: Tue, >>>>>>>>>>>>>>>>>>>> 10 Sep 2013 19:27:54 +0900 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> There seem to be some undesirable >>>>>>>>>>>>>>>>>>>>> behaviors related with PVID. 1. It has no >>>>>>>>>>>>>>>>>>>>> effect assigning PVID to a port. PVID >>>>>>>>>>>>>>>>>>>>> cannot be applied to any frame regardless >>>>>>>>>>>>>>>>>>>>> of whether we set it or not. 2. FDB >>>>>>>>>>>>>>>>>>>>> entries learned via frames applied PVID >>>>>>>>>>>>>>>>>>>>> are registered with VID 0 rather than VID >>>>>>>>>>>>>>>>>>>>> value of PVID. 3. We can set 0 or 4095 as >>>>>>>>>>>>>>>>>>>>> a PVID that are not allowed in IEEE >>>>>>>>>>>>>>>>>>>>> 802.1Q. This leads interoperational >>>>>>>>>>>>>>>>>>>>> problems such as sending frames with VID >>>>>>>>>>>>>>>>>>>>> 4095, which is not allowed in IEEE >>>>>>>>>>>>>>>>>>>>> 802.1Q, and treating frames with VID 0 as >>>>>>>>>>>>>>>>>>>>> they belong to VLAN 0, which is expected >>>>>>>>>>>>>>>>>>>>> to be handled as they have no VID >>>>>>>>>>>>>>>>>>>>> according to IEEE 802.1Q. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Note: 2nd and 3rd problems are potential >>>>>>>>>>>>>>>>>>>>> and not exposed unless 1st problem is >>>>>>>>>>>>>>>>>>>>> fixed, because we cannot activate PVID >>>>>>>>>>>>>>>>>>>>> due to it. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please work out the issues in patch #2 with >>>>>>>>>>>>>>>>>>>> Vlad and resubmit this series. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thank you. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm hovering between whether we should fix >>>>>>>>>>>>>>>>>>> the issue by changing vlan 0 interface >>>>>>>>>>>>>>>>>>> behavior in 8021q module or enabling a bridge >>>>>>>>>>>>>>>>>>> port to sending priority-tagged frames, or >>>>>>>>>>>>>>>>>>> another better way. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If you could comment it, I'd appreciate it >>>>>>>>>>>>>>>>>>> :) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BTW, I think what is discussed in patch #2 is >>>>>>>>>>>>>>>>>>> another problem about handling priority-tags, >>>>>>>>>>>>>>>>>>> and it exists without this patch set >>>>>>>>>>>>>>>>>>> applied. It looks like that we should prepare >>>>>>>>>>>>>>>>>>> another patch set than this to fix that >>>>>>>>>>>>>>>>>>> problem. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Should I include patches that fix the >>>>>>>>>>>>>>>>>>> priority-tags problem in this patch set and >>>>>>>>>>>>>>>>>>> resubmit them all together? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I am thinking that we might need to do it in >>>>>>>>>>>>>>>>>> bridge and it looks like the simplest way to do >>>>>>>>>>>>>>>>>> it is to have default priority regeneration >>>>>>>>>>>>>>>>>> table (table 6-5 from 802.1Q doc). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> That way I think we would conform to the spec. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -vlad >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Unfortunately I don't think the default priority >>>>>>>>>>>>>>>>> regeneration table resolves the problem because >>>>>>>>>>>>>>>>> IEEE 802.1Q says that a VLAN-aware bridge can >>>>>>>>>>>>>>>>> transmit untagged or VLAN-tagged frames only (the >>>>>>>>>>>>>>>>> end of section 7.5 and 8.1.7). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> No mechanism to send priority-tagged frames is >>>>>>>>>>>>>>>>> found as far as I can see the standard. I think >>>>>>>>>>>>>>>>> the regenerated priority is used for outgoing >>>>>>>>>>>>>>>>> PCP field only if egress policy is not untagged >>>>>>>>>>>>>>>>> (i.e. transmitting as VLAN-tagged), and unused if >>>>>>>>>>>>>>>>> untagged (Section 6.9.2 3rd/4th Paragraph). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If we want to transmit priority-tagged frames >>>>>>>>>>>>>>>>> from a bridge port, I think we need to implement >>>>>>>>>>>>>>>>> a new (optional) feature that is above the >>>>>>>>>>>>>>>>> standard, as I stated previously. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> How do you feel about adding a per-port policy >>>>>>>>>>>>>>>>> that enables a bridge to send priority-tagged >>>>>>>>>>>>>>>>> frames instead of untagged frames when egress >>>>>>>>>>>>>>>>> policy for the port is untagged? With this >>>>>>>>>>>>>>>>> change, we can transmit frames for a given vlan >>>>>>>>>>>>>>>>> as either all untagged, all priority-tagged or >>>>>>>>>>>>>>>>> all VLAN-tagged. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That would work. What I am thinking is that we do >>>>>>>>>>>>>>>> it by special casing the vid 0 egress policy >>>>>>>>>>>>>>>> specification. Let it be untagged by default and >>>>>>>>>>>>>>>> if it is tagged, then we preserve the priority >>>>>>>>>>>>>>>> field and forward it on. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This keeps the API stable and doesn't require >>>>>>>>>>>>>>>> user/admin from knowing exactly what happens. >>>>>>>>>>>>>>>> Default operation conforms to the spec and allows >>>>>>>>>>>>>>>> simple change to make it backward-compatible. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What do you think. I've done a simple prototype of >>>>>>>>>>>>>>>> this an it seems to work with the VMs I am testing >>>>>>>>>>>>>>>> with. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Are you saying that - by default, set the 0th bit of >>>>>>>>>>>>>>> untagged_bitmap; and - if we unset the 0th bit and >>>>>>>>>>>>>>> set the "vid"th bit, we transmit frames classified as >>>>>>>>>>>>>>> belonging to VLAN "vid" as priority-tagged? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If so, though it's attractive to keep current API, >>>>>>>>>>>>>>> I'm worried about if it could be a bit confusing and >>>>>>>>>>>>>>> not intuitive for kernel/iproute2 developers that VID >>>>>>>>>>>>>>> 0 has a special meaning only in the egress policy. >>>>>>>>>>>>>>> Wouldn't it be better to adding a new member to >>>>>>>>>>>>>>> struct net_port_vlans instead of using VID 0 of >>>>>>>>>>>>>>> untagged_bitmap? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Or are you saying that we use a new flag in struct >>>>>>>>>>>>>>> net_port_vlans but use the BRIDGE_VLAN_INFO_UNTAGGED >>>>>>>>>>>>>>> bit with VID 0 in netlink to set the flag? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Even in that case, I'm afraid that it might be >>>>>>>>>>>>>>> confusing for developers for the same reason. We are >>>>>>>>>>>>>>> going to prohibit to specify VID with 0 (and 4095) in >>>>>>>>>>>>>>> adding/deleting a FDB entry or a vlan filtering >>>>>>>>>>>>>>> entry, but it would allow us to use VID 0 only when a >>>>>>>>>>>>>>> vlan filtering entry is configured. I am thinking a >>>>>>>>>>>>>>> new nlattr is a straightforward approach to >>>>>>>>>>>>>>> configure it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> By making this an explicit attribute it makes vid 0 a >>>>>>>>>>>>>> special case for any automatic tool that would >>>>>>>>>>>>>> provision such filtering. Seeing vid 0 would mean that >>>>>>>>>>>>>> these tools would have to know that this would have to >>>>>>>>>>>>>> be translated to a different attribute instead of >>>>>>>>>>>>>> setting the policy values. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, I agree with you that we can do it by the way you >>>>>>>>>>>>> explained. What I don't understand is the advantage of >>>>>>>>>>>>> using vid 0 over another way such as adding a new >>>>>>>>>>>>> nlattr. I think we can indicate transmitting >>>>>>>>>>>>> priority-tags explicitly by such a nlattr. Using vid 0 >>>>>>>>>>>>> seems to be easier to implement than a new nlattr, but, >>>>>>>>>>>>> for me, it looks less intuitive and more difficult to >>>>>>>>>>>>> maintain because we have to care about vid 0 instead of >>>>>>>>>>>>> simply ignoring it. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The point I am trying to make is that regardless of the >>>>>>>>>>>> approach someone has to know what to do when enabling >>>>>>>>>>>> priority tagged frames. You proposal would require the >>>>>>>>>>>> administrator or config tool to have that knowledge. >>>>>>>>>>>> Example is: Admin does: bridge vlan set priority on dev >>>>>>>>>>>> eth0 Automated app: if (vid == 0) /* Turn on priority >>>>>>>>>>>> tagged frame support */ >>>>>>>>>>>> >>>>>>>>>>>> My proposal would require the bridge filtering >>>>>>>>>>>> implementation to have it. user tool: bridge vlan add vid 0 >>>>>>>>>>>> tagged Automated app: No special case. >>>>>>>>>>>> >>>>>>>>>>>> IMO its better to have 1 piece code handling the special >>>>>>>>>>>> case then putting it multiple places. >>>>>>>>>>> >>>>>>>>>>> Thank you for the detailed explanation. Now I understand your >>>>>>>>>>> intention. >>>>>>>>>>> >>>>>>>>>>> I have one question about your proposal. I guess the way to >>>>>>>>>>> enable priority-tagged is something like bridge vlan add vid >>>>>>>>>>> 10 dev eth0 bridge vlan add vid 10 dev vnet0 pvid untagged >>>>>>>>>>> bridge vlan add vid 0 dev vnet0 tagged where vnet0 has sub >>>>>>>>>>> interface vnet0.0. >>>>>>>>>>> >>>>>>>>>>> Here the admin have to know the egress policy is applied to a >>>>>>>>>>> frame twice in a certain order when it is transmitted from >>>>>>>>>>> the port vnet0 attached, that is, first, a frame with vid 10 >>>>>>>>>>> get untagged, and then, an untagged frame get >>>>>>>>>>> priority-tagged. >>>>>>>>>>> >>>>>>>>>>> This behavior looks difficult to know without previous >>>>>>>>>>> knowledge. Any good idea to avoid such a need for the admin's >>>>>>>>>>> additional knowledge? >>>>>>>>>> >>>>>>>>>> To me, the fact that there is vnet0.0 (or typically, there is >>>>>>>>>> eth0.0 in the guest or on the remote host) already tells the >>>>>>>>>> admin vlan 0 has to be tagged. The fact that we codify this in >>>>>>>>>> the policy makes it explicit. >>>>>>>>> >>>>>>>>> My worry is that the admin might not be able to guess how to use >>>>>>>>> bridge commands to enable priority-tag without any additional >>>>>>>>> hint in "man bridge", "bridge vlan help", etc. I actually >>>>>>>>> couldn't hit upon such a usage before seeing example commands you >>>>>>>>> gave, because I had never think the egress policy could be >>>>>>>>> applied twice. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, I can see strong argument to be made for an addition >>>>>>>>>> egress policy attribute that could be for instance: >>>>>>>>>> >>>>>>>>>> bridge vlan add vid 10 dev eth0 pvid bridge vlan add vid 10 dev >>>>>>>>>> vnet0 pvid untagged prio_tag >>>>>>>>>> >>>>>>>>>> But this has the same connotations as wrt to egress policy. >>>>>>>>>> The 2 policies are applied: (1) untag the frame. (2) add >>>>>>>>>> priority_tag. >>>>>>>>>> >>>>>>>>>> (2) only happens if initial fame received on eth0 was priority >>>>>>>>>> tagged. >>>>>>>>> >>>>>>>>> If we do so, we will not be able to communicate using vlan 0 >>>>>>>>> interface under a certain circumstance. Eth0 can be receive mixed >>>>>>>>> untagged and priority-tagged frames according to the network >>>>>>>>> element it is connected to: for example, Open vSwitch can send >>>>>>>>> such two kinds of frames from the same port even if original >>>>>>>>> incoming frames belong to the same vlan. >>>>>>>> >>>>>>>> Which priority would you assign to the frame that was received >>>>>>>> untagged? >>>>>>> >>>>>>> Untagged frame's priority is by default 0, so I think 0 is likely. >>>>>>> >>>>>>> 802.1Q 6.9.1 i) The received priority value and the drop_eligible >>>>>>> parameter value are the values in the M_UNITDATA.indication. >>>>>>> >>>>>>> M_UNITDATA is passed from ISS. >>>>>>> >>>>>>> 802.1Q 6.7.1 The priority parameter provided in a data indication >>>>>>> primitive shall take the value of the Default User Priority parameter >>>>>>> for the Port through which the MAC frame was received. The default >>>>>>> value of this parameter is 0, it may be set by management in which >>>>>>> case the capability to set it to any of the values 0 through 7 shall >>>>>>> be provided. >>>>>>> >>>>>>>> >>>>>>>>> In this situation, we can only receive frames that is >>>>>>>>> priority-tagged when received on eth0. >>>>>>>> >>>>>>>> Not sure I understand. Let's look at this config: bridge vlan add >>>>>>>> vid 10 dev eth0 pvid bridge vlan add vid 10 dev vnet0 pvid untagged >>>>>>>> prio_tag >>>>>>>> >>>>>>>> Here, eth0 is allowed to receive vid 10 tagged, untagged, and >>>>>>>> prio_tagged (if we look at the patch 2 from this set). Now, frame >>>>>>>> is forwarded to vnet0. 1) if the frame had vid 10 in the tag or was >>>>>>>> untagged, it should probably be sent untagged. 2) if the frame had >>>>>>>> a priority tag, it should probably be sent as such. >>>>>>>> >>>>>>>> Now, I think a case could be made that if the frame had any >>>>>>>> priority markings in the vlan header, we should try to preserve >>>>>>>> those markings if prio_tag is turned on. We can assume value of 0 >>>>>>>> means not set. >>>>>>> >>>>>>> If we don't insert prio_tag when PCP is 0, we might receive mixed >>>>>>> priority-tagged and untagged frames on eth0. >>>>>> >>>>>> Right, and that's what you were trying to handle in your patch: >>>>>> >>>>>>> + /* PVID is set on this port. Any untagged or priority-tagged + >>>>>>> * ingress frame is considered to belong to this vlan. */ >>>>>> >>>>>> So, in this case we are prepared to handle the "mixed" scenario on ingress. >>>>>> >>>>>>> Even if we are sending frames from eth0.0 with some priority other >>>>>>> than 0, we could receive frames with priority 0 or untagged on the >>>>>>> other side of the bridge. >>>>>>> For example, if we receive untagged arp reply on the bridge port, we >>>>>>> migit not be able to communicate with such an end station, because >>>>>>> untagged reply will not be passed to eth0.0. >>>>>> >>>>>> So the ARP request was sent tagged, but the reply came back untagged? >>>>> >>>>> Yes, it can happen. >>>>> These are problematic cases. >>>>> >>>>> Example 1: >>>>> prio_tagged prio_tagged >>>>> +------------+ ---> +------------+ ---> +----------+ >>>>> |guest eth0.0|------|host1 Bridge|------|host2 eth0| >>>>> +------------+ <--- +------------+ <--- +----------+ >>>>> untagged untagged >>>>> >>>>> Note: Host2 eth0, which is an interface on Linux, can receive >>>>> priority-tagged frames if it doesn't have vlan 0 interface (eth0.0). >>>> >>>> Hmm.. Just to see if this works, I ran the this scenario with >>>> a dumb switch in the middle, and it did not work as you noted. >>>> I then realized that one of the kernels was rather old and after >>>> updating it, behaved differently. The communication still didn't >>>> work, but host2 behaved properly. >>>> >>>>>> >>>>>> How does that work when the end station is attached directly to the >>>>>> HW switch instead of a linux bridge? >>>>>> >>>>>> The station configures eth0.0 and sends priority-tagged traffic to >>>>>> the HW switch. If the HW switch sends back untagged traffic, then >>>>>> the untagged traffic will never reach eth0.0. >>>>> >>>>> Currently we cannot communicate using eth0.0 via directly connected >>>>> 802.1Q conformed switch, because we never receive priority-tagged frames >>>>> from the switch. >>>>> It is not a problem of Linux bridge and is why I wondered whether it >>>>> should be fixed by bridge or vlan 0 interface. >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> IMO, if prio_tag is configured, the bridge should send any >>>>>>>>> untagged frame as priority-tagged regardless of whatever it is on >>>>>>>>> eth0. >>>>>>>> >>>>>>>> Which priority would you use, 0? You are not guaranteed to >>>>>>>> properly deliver the traffic then for a configuration such as: VM: >>>>>>>> eth0: 10.0.0.1/24 eth0.0: 10.0.1.1/24 >>>>>>> >>>>>>> I'd like to use priority 0 for untagged frames. >>>>>>> >>>>>>> I am assuming that one of our goals is at least that eth0.0 comes to >>>>>>> be able to communicate with another end station. It seems to be hard >>>>>>> to use both eth0 and eth0.0 simultaneously. >>>>>> >>>>>> I understand, but I don't agree that we should always tag. >>>>>> >>>>>> Consider config: >>>>>> >>>>>> hw switch <---> (eth0: Linux Bridge: eth1) <--- (em1.0:end station) >>>>>> >>>>>> If the end station sends priority-tagged traffic it should receive >>>>>> priority tagged traffic back. Otherwise, untagged traffic may be >>>>>> dropped by the end station. This is true whether it is connected to >>>>>> the hw switch or Linux bridge. >>>>> >>>>> Though such a behavior is generally not necessary as far as I can read >>>>> 802.1Q spec, it is essential for vlan 0 interface on Linux, I think. >>>>> My proposal aims to resolve it at least when we use Linux bridge. >>>>> >>>>> Example configuration: >>>>> bridge vlan add vid 10 dev eth1 pvid untagged >>>>> bridge vlan add vid 10 dev eth0 >>>>> bridge vlan set prio_tag on dev eth1 >>>>> >>>>> Intended behavior: >>>>> >>>>> VID10-tagged prio_tagged >>>>> +---------+ <--- +------------------------+ <--- +-----------------+ >>>>> |hw switch|------|eth0: Linux Bridge: eth1|------|em1.0:end station| >>>>> +---------+ ---> +------------------------+ ---> +-----------------+ >>>>> VID10-tagged prio_tagged >>>>> (always if egress policy untagged) >>>> >>>> Ok, I think you've convinced me that this is the right approach. The >>>> only thing that I am not crazy about is the API. I'd almost want to >>>> introduce a new flag that can be set in a 'vlan add' or 'vlan set' >>>> command that communicates a new policy. >>> >>> I'm glad that we reached a consensus on the approach :) >>> >>> I agree with you that the API is flag based. >>> I'm guessing your intention is that 'vlan add' means a per vlan per port >>> policy and 'vlan set' means a per port one, that is, >>> 'vlan add': bridge vlan add vid 10 dev eth1 prio_tag >>> 'vlan set': bridge vlan set prio_tag on dev eth1 >>> >>> I think they can behave differently only when we set untagged to >>> multiple vlans on the same port. >>> >>> 'vlan add' example with vid 10 and 20: >>> bridge vlan add vid 10 dev eth1 pvid untagged prio_tag >>> bridge vlan add vid 10 dev eth0 >>> bridge vlan add vid 20 dev eth1 untagged >>> bridge vlan add vid 20 dev eth2 >>> >>> VID10-tagged prio_tagged (from eth0) >>> +---------+ ---> +------------------------+ ---> +-----------------+ >>> |hw switch|------|eth0 eth1|------|em1.0:end station| >>> +---------+ | Linux Bridge | ---> +-----------------+ >>> +---------+ | | *untagged* >>> |hw switch|------|eth2 | (from eth2) >>> +---------+ ---> +------------------------+ >>> VID20-tagged >>> >> >> This is what I was thinking of, but I was actually considering that >> untagged and prio_tag can not co-exist for the same vlan as they don't >> really make sence together anymore. > > You're right. > In this case 'untagged' for 'vid 10' is no longer necessary. > >> >> So one can do: >> bridge vlan add vid 10 dev eth1 pvid prio_tag >> bridge vlan add vid 20 dev eth1 untagged >> >> and recieve VLAN 10 as priority tagged and vlan 20 as untagged. > > Can you make a patch set implementing this? > > I'd like to re-send this patch set related to PVID with more comments > about the unresolved vlan 0 interface problem and the prospect that it > will be addressed by another patch set of yours. > > Is this procedure OK with you? Sure. Can you re-send the patch series, since I think 3 of the paches are really needed. I'll work on the prio_tag stuff. -vlad > > Thanks, > > Toshiaki Makita > >> >> -vlad >> >>> >>> 'vlan set' example with vid 10 and 20: >>> bridge vlan add vid 10 dev eth1 pvid untagged >>> bridge vlan add vid 10 dev eth0 >>> bridge vlan add vid 20 dev eth1 untagged >>> bridge vlan add vid 20 dev eth2 >>> bridge vlan set prio_tag on dev eth1 >>> >>> VID10-tagged prio_tagged (from eth0) >>> +---------+ ---> +------------------------+ ---> +-----------------+ >>> |hw switch|------|eth0 eth1|------|em1.0:end station| >>> +---------+ | Linux Bridge | ---> +-----------------+ >>> +---------+ | | prio_tagged >>> |hw switch|------|eth2 | (from eth2) >>> +---------+ ---> +------------------------+ >>> VID20-tagged >>> >>> Em1.0 can always receive traffic from eth1 if we adopt 'vlan set'. >>> However, I cannot imagine when multiple untagged vlans is required, so >>> cannot figure out whether 'vlan add' is useful or harmful. >>> Anyway, both of approaches are OK with me. >>> >>> Thanks, >>> Toshiaki Makita >>> >>>> >>>> Thanks >>>> -vlad >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Toshiaki Makita >>>>> >>>>>> >>>>>> -vlad >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Toshiaki Makita >>>>>>> >>>>>>>> >>>>>>>> -vlad >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think I am ok with either approach. Explicit vid 0 policy is >>>>>>>>>> easier for automatic provisioning. The flag based one is >>>>>>>>>> easier for admin/ manual provisioning. >>>>>>>>> >>>>>>>>> Supposing we have to add something to help or man in any case, I >>>>>>>>> think flag based is better. The format below seems to suitable >>>>>>>>> for a per-port policy. bridge vlan set prio_tag on dev vnet0 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Toshiaki Makita >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -vlad. >>>>>>>>>> >>>>>>>>>> -vlad >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks -vlad >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Toshiaki Makita >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> How it is implemented internally in the kernel isn't as >>>>>>>>>>>>>> big of an issue. We can do it as a separate flag or as >>>>>>>>>>>>>> part of existing policy. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -vlad >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Toshiaki Makita >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -vlad >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Toshiaki Makita >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Toshiaki Makita >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- To unsubscribe from this list: send the >>>>>>>>>>>>>>>>>>>> line "unsubscribe netdev" in the body of a >>>>>>>>>>>>>>>>>>>> message to majordomo@...r.kernel.org More >>>>>>>>>>>>>>>>>>>> majordomo info at >>>>>>>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- To unsubscribe from this list: send the line >>>>>>>>>>>>>>>>> "unsubscribe netdev" in the body of a message to >>>>>>>>>>>>>>>>> majordomo@...r.kernel.org More majordomo info at >>>>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in >>>>> the body of a message to majordomo@...r.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe netdev" in >>>> the body of a message to majordomo@...r.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >> > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists