From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 06:05:22 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A827F16A4D0 for ; Sun, 23 Jan 2005 06:05:22 +0000 (GMT) Received: from ns.tagnet.ru (ns.tagnet.ru [80.64.16.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE2D343D46 for ; Sun, 23 Jan 2005 06:05:21 +0000 (GMT) (envelope-from boris@tagnet.ru) Received: from p-242.secure.tagnet.ru ([80.64.16.242]) by ns.tagnet.ru with esmtp (Exim 4.43 #0) id 1CsasB-0004gF-9S for ; Sun, 23 Jan 2005 11:05:20 +0500 Message-ID: <41F33E9F.9090301@tagnet.ru> Date: Sun, 23 Jan 2005 11:05:19 +0500 From: Boris Kovalenko Organization: JSC "TAGNet" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] 802.1p priority (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2005 06:05:22 -0000 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