| 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: <525807B9.2060201@redhat.com> Date: Fri, 11 Oct 2013 10:14:17 -0400 From: Vlad Yasevich <vyasevic@...hat.com> To: Toshiaki Makita <makita.toshiaki@....ntt.co.jp> CC: Toshiaki Makita <toshiaki.makita1@...il.com>, 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/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. 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. -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