Date: Sun, 23 Jan 2005 11:05:19 +0500 From: Boris Kovalenko <boris@tagnet.ru> To: freebsd-net@freebsd.org Subject: Re: [PATCH] 802.1p priority (fixed) Message-ID: <41F33E9F.9090301@tagnet.ru>
next in thread | raw e-mail | index | archive | help
Hello! >I'm not sure why you need trust and override. It seems like you only >need the ability to set or remove values as well as acting on already >attached tags (which we're going to need to carry around as m_tags so >we >can filter on and modify them in conjunction with layer 3 information). For example I have vlan of devices, which can set 802.1p themself (Cisco IP Phones for example) based on their knowledge of situation. I should just pass-trough their 802.1p because I don't know the situation. In this case I should trust. Another example - I have devices that can not set 802.1p (or more simply - it always 0), so I should set (or in other words - override received value :) 802.1p myself. > 3. Mark 802.1p at vlan drivers like 2 > ifconfig vlan0 > vlan: 100 802.1p: 6 CFI: 0 mode: trust vlandev: bge0 > Here we are trusting received from low level information and set 6 if it > is omitted > ifconfig vlan0 > vlan: 100 802.1p: 6 CFI: 0 mode: override vlandev: bge0 > Here we silently set 6. >If you're not going to do separate interfaces per priority (or >perhaps set of priorities[0]) I'm not sure what the point of having the >interface do anything is. Filtering is the job of the firewall so I'm >not convinced we should be doing it in the vlan device. There's also Hmm... If You remember, the idea of filtering is not mine :) I wrote it may be realized, but see no sense in that. The only thing I suggested is to set 802.1p values. Again, there are working realizations of 802.1p in a world. Cisco for example. I can not access/modify 802.1p in firewall (PIX/ACL/VACL). The only place where I may set 802.1p is the Catalyst port. And on trunking port I may trust received values or reset them. So, may be we should not to invent a bicycle? >the complication that we need to handle the vlan=0 case which shouldn't >be treated as a vlan at all and should be decapsulated in the actual >device without a trip through the vlan code. What the vlan=0 is? On a wire we may receive tagged or untagged frames. Untagged should go usual way, tagged via vlan driver (IMHO). >My suspicion is that we need to rethink the current separation of >ether and vlan code. Making vlans less optional and doing more of the >handling in ether_input and ether_output might be a good thing. I'm not a guru of FreeBSD net infrastructure, so I can not raise an objection on this words. >[0] What I've read says that many switches group sets of priority >values together reducing the set of valid values. And what this changes? Some switches totally ignore 802.1p. We're talking about IEEE standard and should fully support it. Also, may You point me where You have read this? ---- Regards, Boris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F33E9F.9090301>