Re: Relationship Between VLANs and Physical Interfaces in PF
On Wed, Aug 6, 2014 at 3:38 PM, Stuart Henderson s...@spacehopper.org wrote: 1. Don't use different _in and _out names, use syntax like queue foo on em0 and queue foo on em1. That way you assign packets to the correct queues on both interfaces in one step with something like match to port 53 queue fast. The queue name is associated with the PF state; packets matching that state get assigned to that queue. Very useful recommendation, thanks. 1a. Confirm your queue setup by running systat queue (as root) and making sure that you see packets assigned to the various queues that you have configured. Is there anyway to monitor set prio queues? my prio statements don't seem to make any effect... 2. In my (admittedly very limited) testing with the new queueing system, it hasn't done very well with low bandwidth queues (ADSL type speeds) that used to work OK with altq (symptom, packets being assigned to queues as expected, but rates not being controlled). Next step in my testing there will be to build a kernel with a higher HZ value (faster timer) but I haven't got round to that yet. I've just started using queues today with: OpenBSD 5.6-current (GENERIC.MP) #364: Thu Sep 4 02:57:22 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP on my home ADSL link (6mbps down/700kbps up) and pf seems to be good at managing queues as small as 100kbps. Thanks. regards
Re: Relationship Between VLANs and Physical Interfaces in PF
On 2014/09/05 03:49, Abel Abraham Camarillo Ojeda wrote: On Wed, Aug 6, 2014 at 3:38 PM, Stuart Henderson s...@spacehopper.org wrote: 1. Don't use different _in and _out names, use syntax like queue foo on em0 and queue foo on em1. That way you assign packets to the correct queues on both interfaces in one step with something like match to port 53 queue fast. The queue name is associated with the PF state; packets matching that state get assigned to that queue. Very useful recommendation, thanks. 1a. Confirm your queue setup by running systat queue (as root) and making sure that you see packets assigned to the various queues that you have configured. Is there anyway to monitor set prio queues? my prio statements don't seem to make any effect... set prio is not queues (except when it's on vlan interfaces, then it is transferred to vlan headers which *may* be handled as queues by your switch). 2. In my (admittedly very limited) testing with the new queueing system, it hasn't done very well with low bandwidth queues (ADSL type speeds) that used to work OK with altq (symptom, packets being assigned to queues as expected, but rates not being controlled). Next step in my testing there will be to build a kernel with a higher HZ value (faster timer) but I haven't got round to that yet. I've just started using queues today with: OpenBSD 5.6-current (GENERIC.MP) #364: Thu Sep 4 02:57:22 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP on my home ADSL link (6mbps down/700kbps up) and pf seems to be good at managing queues as small as 100kbps. Good for you. It doesn't work at all for me like that.
Re: Relationship Between VLANs and Physical Interfaces in PF
* Andy a...@brandwatch.com [2014-08-05 18:06]: Correct me if I'm wrong here Henning, but we have always used the approach of only ever assigning queues to the physical interface (whether it has VLANs or not), as this means that both the physical interfaces untagged network, plus all the tagged networks on that interface get to share the queues. correct. Having lots of physical internal interfaces with queues on each simply means you have to divide our total WAN download bandwidth across the interfaces as they cannot borrow from each other. obviously, cross-interface borrowing doesn't work indeed :) But if you use VLANS and place the queues on the physical interface, if the public WIFI VLAN for example is not using any bandwidth, the internal LAN can use all the bandwidth until the public WIFI wants some. yup Considering all this, there should never be a good reason to apply queues to the VLAN interfaces at all? I can't see any. There's always an interface (or a stack of interfaces even) with a queue underneath, so THAT is the point to do the queueing. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Relationship Between VLANs and Physical Interfaces in PF
* Giancarlo Razzolini grazzol...@gmail.com [2014-08-05 18:36]: On 05-08-2014 03:36, Henning Brauer wrote: the 90s are over. Yep, I know Henning. Vlan's are pretty secure. But they add complexity and if you use physical separation you can mitigate problems caused by misconfiguration. Either on OpenBSD itself or on the switches. As I said, my personal preference is to physically separate the networks. But I've used vlans and I will use again, surely. I just don't like to use them, specifically, when I don't have control of the entire network. Your preferences are your preferences, you're free to do that - just like you're free to stab a knife in your eye. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). sth like match out on vlanX queue foo really just tags the packet should go to queue foo. once the packet hits an outbound interface, we check wether queue foo exists there and if so use it. This is one of the greatest features of pf, in my opinion. This flexibility is what make pf what it is. this bit is not so much pf actually. we have stopped looking at pf as an isolated component many many years ago, and instead take the whole picture approach - so it's really our network stack. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Relationship Between VLANs and Physical Interfaces in PF
Am Dienstag, den 05.08.2014, 17:05 +0100 schrieb Andy: Considering all this, there should never be a good reason to apply queues to the VLAN interfaces at all? Well, there may be. For example a VLAN may indeed just represent a port on a switch elsewhere. Where a certain policy applies (e.g. do not send me more than 2Mbit, even if the physical connection is 1GE). But of course, one may realize that with several (non-sharing) queues on the physical interface and the right selectors, as Henning suggested. David -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: Relationship Between VLANs and Physical Interfaces in PF
On 06-08-2014 05:34, Henning Brauer wrote: Your preferences are your preferences, you're free to do that - just like you're free to stab a knife in your eye. Not sure I'd go with this analogy. Here in my country things are a little different. Not always the networks are correctly configured. Specially the switches. And many times you need to work around things on your side. this bit is not so much pf actually. we have stopped looking at pf as an isolated component many many years ago, and instead take the whole picture approach - so it's really our network stack. That's why I use OpenBSD. It gives me the flexibility and security I need even when it need to go along with insecure machines and hardware. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Relationship Between VLANs and Physical Interfaces in PF
On 2014-08-04, Eric Dilmore ericdilm...@gmail.com wrote: I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The gateway has one external interface and one internal, with the internal network split into several VLANs: one for secure traffic, one for guests, one for internal phones, and one for our external Asterisk phone server. I'm trying to use queues to set up QoS for the Asterisk server. There is limited bandwidth in our location, and we would like to ensure that the Asterisk server has priority over other traffic. I would prefer a bandwidth specification over a simple priority, but either would be fine. However, I believe that pf queues are tied to an outbound interface. None of the rules I have attempted on the internal interface have matched at all. I can specify each vlan explicitly, but the internal interface itself doesn't seem to match any packets. tcpdump shows traffic passing both in and out when I specify the internal interface. I am confused about the relationship between the physical interface and the vlan interfaces in pf. I would also like to know if there are any suggestions for how to set up the queues in order to provide QoS for phone traffic. My current pf.conf is hosted in a gist here: https://gist.github.com/geppettodivacin/8fc8dc044b122154d137 1. Don't use different _in and _out names, use syntax like queue foo on em0 and queue foo on em1. That way you assign packets to the correct queues on both interfaces in one step with something like match to port 53 queue fast. The queue name is associated with the PF state; packets matching that state get assigned to that queue. 1a. Confirm your queue setup by running systat queue (as root) and making sure that you see packets assigned to the various queues that you have configured. 2. In my (admittedly very limited) testing with the new queueing system, it hasn't done very well with low bandwidth queues (ADSL type speeds) that used to work OK with altq (symptom, packets being assigned to queues as expected, but rates not being controlled). Next step in my testing there will be to build a kernel with a higher HZ value (faster timer) but I haven't got round to that yet.
Re: Relationship Between VLANs and Physical Interfaces in PF
* Giancarlo Razzolini grazzol...@gmail.com [2014-08-05 00:02]: On 04-08-2014 18:09, Eric Dilmore wrote: I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The gateway has one external interface and one internal, with the internal network split into several VLANs: one for secure traffic, one for guests, one for internal phones, and one for our external Asterisk phone server. Vlans work, but they add complexity. I'd prefer physical interfaces separating the networks, both for performance and security reasons. the 90s are over. However, I believe that pf queues are tied to an outbound interface. None of the rules I have attempted on the internal interface have matched at all. I can specify each vlan explicitly, but the internal interface itself doesn't seem to match any packets. tcpdump shows traffic passing both in and out when I specify the internal interface. The most indicated way is to queue your downloads on the internal interface and your uploads on the external interface. If I'm not mistaken, you need to set the queues on each vlan if. you are mistaken, queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). sth like match out on vlanX queue foo really just tags the packet should go to queue foo. once the packet hits an outbound interface, we check wether queue foo exists there and if so use it. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Relationship Between VLANs and Physical Interfaces in PF
On 2014 Aug 04 (Mon) at 19:01:06 -0300 (-0300), Giancarlo Razzolini wrote: :On 04-08-2014 18:09, Eric Dilmore wrote: : I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The : gateway has one external interface and one internal, with the internal : network split into several VLANs: one for secure traffic, one for : guests, one for internal phones, and one for our external Asterisk phone : server. :Vlans work, but they add complexity. I'd prefer physical interfaces :separating the networks, both for [...] and security reasons. Both of those are blatent lies. -- We should declare war on North Vietnam. We could pave the whole country and put parking strips on it, and still be home by Christmas. -- Ronald Reagan
Re: Relationship Between VLANs and Physical Interfaces in PF
Am Dienstag, den 05.08.2014, 08:36 +0200 schrieb Henning Brauer: queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). Strangely, the following (simplified) setup seems to work here on 5.5 nevertheless: queue vlan33q on vlan33 bandwidth 2M, max 2M match out on vlan33 all set queue vlan33q In pfctl -sq this looks exactly like I expected and it does exactly what I intended it to do. But as you (if anybody) indeed should known, what happens. Please tell me, what the above config actually does. Will the first line silently add a vlan33q to re0 that still does what it is intended? OTOH, adding a queue to a GRE interface does not work indeed. Regards David -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: Relationship Between VLANs and Physical Interfaces in PF
* David Dahlberg david.dahlb...@fkie.fraunhofer.de [2014-08-05 10:17]: Am Dienstag, den 05.08.2014, 08:36 +0200 schrieb Henning Brauer: queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). Strangely, the following (simplified) setup seems to work here on 5.5 nevertheless: queue vlan33q on vlan33 bandwidth 2M, max 2M match out on vlan33 all set queue vlan33q In pfctl -sq this looks exactly like I expected and it does exactly what I intended it to do. except that the underlaying physical if's queue destroys the effects - not necessarily always, but most of the time. by just chaning your queue def to queue vlan33q on vlan33's vlandev bandwidth 2M, max 2M (no, NOT literal .., you expand that yourself) does what you intended in the first place. But as you (if anybody) indeed should known, what happens. Please tell me, what the above config actually does. Will the first line silently add a vlan33q to re0 that still does what it is intended? no, it does queueing on vlan33. but since we end up queueing the packets on vlan33's vlandev again, the effects often just aren't there. queueing is a lot about timing... at some point we used vlans with a queue depth of 1, since there really is no point in queueing there at all, but that exposed some otehr bugs. we might eventually go back to that. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Relationship Between VLANs and Physical Interfaces in PF
On 05/08/14 10:23, Henning Brauer wrote: * David Dahlberg david.dahlb...@fkie.fraunhofer.de [2014-08-05 10:17]: Am Dienstag, den 05.08.2014, 08:36 +0200 schrieb Henning Brauer: queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). Strangely, the following (simplified) setup seems to work here on 5.5 nevertheless: queue vlan33q on vlan33 bandwidth 2M, max 2M match out on vlan33 all set queue vlan33q In pfctl -sq this looks exactly like I expected and it does exactly what I intended it to do. except that the underlaying physical if's queue destroys the effects - not necessarily always, but most of the time. by just chaning your queue def to queue vlan33q on vlan33's vlandev bandwidth 2M, max 2M (no, NOT literal .., you expand that yourself) does what you intended in the first place. Correct me if I'm wrong here Henning, but we have always used the approach of only ever assigning queues to the physical interface (whether it has VLANs or not), as this means that both the physical interfaces untagged network, plus all the tagged networks on that interface get to share the queues. Having lots of physical internal interfaces with queues on each simply means you have to divide our total WAN download bandwidth across the interfaces as they cannot borrow from each other. But if you use VLANS and place the queues on the physical interface, if the public WIFI VLAN for example is not using any bandwidth, the internal LAN can use all the bandwidth until the public WIFI wants some. Considering all this, there should never be a good reason to apply queues to the VLAN interfaces at all? But as you (if anybody) indeed should known, what happens. Please tell me, what the above config actually does. Will the first line silently add a vlan33q to re0 that still does what it is intended? no, it does queueing on vlan33. but since we end up queueing the packets on vlan33's vlandev again, the effects often just aren't there. queueing is a lot about timing... at some point we used vlans with a queue depth of 1, since there really is no point in queueing there at all, but that exposed some otehr bugs. we might eventually go back to that.
Re: Relationship Between VLANs and Physical Interfaces in PF
On 05-08-2014 03:36, Henning Brauer wrote: the 90s are over. Yep, I know Henning. Vlan's are pretty secure. But they add complexity and if you use physical separation you can mitigate problems caused by misconfiguration. Either on OpenBSD itself or on the switches. As I said, my personal preference is to physically separate the networks. But I've used vlans and I will use again, surely. I just don't like to use them, specifically, when I don't have control of the entire network. you are mistaken, queueing on vlan is pretty meaningless. Never did tried to queue on vlans, so I was clearly mistaken. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). sth like match out on vlanX queue foo really just tags the packet should go to queue foo. once the packet hits an outbound interface, we check wether queue foo exists there and if so use it. This is one of the greatest features of pf, in my opinion. This flexibility is what make pf what it is. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Relationship Between VLANs and Physical Interfaces in PF
On 04-08-2014 18:09, Eric Dilmore wrote: I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The gateway has one external interface and one internal, with the internal network split into several VLANs: one for secure traffic, one for guests, one for internal phones, and one for our external Asterisk phone server. Vlans work, but they add complexity. I'd prefer physical interfaces separating the networks, both for performance and security reasons. I'm trying to use queues to set up QoS for the Asterisk server. There is limited bandwidth in our location, and we would like to ensure that the Asterisk server has priority over other traffic. I would prefer a bandwidth specification over a simple priority, but either would be fine. I suggest you first try prio, and only if it doesn't work, use queues. I've used queues, but recently, I've been using only prio. It almost always does the job. However, I believe that pf queues are tied to an outbound interface. None of the rules I have attempted on the internal interface have matched at all. I can specify each vlan explicitly, but the internal interface itself doesn't seem to match any packets. tcpdump shows traffic passing both in and out when I specify the internal interface. The most indicated way is to queue your downloads on the internal interface and your uploads on the external interface. If I'm not mistaken, you need to set the queues on each vlan if. I am confused about the relationship between the physical interface and the vlan interfaces in pf. I would also like to know if there are any suggestions for how to set up the queues in order to provide QoS for phone traffic. When using VLAN you'll almost always only filter on the vlan interfaces. As I already mentioned, you'll mostly get away with prio. My current pf.conf is hosted in a gist here: https://gist.github.com/geppettodivacin/8fc8dc044b122154d137 I've took a quick look and you are on the right direction. You'll just need to invert your queues. As I mentioned, use your queues on the vlans for connections initiated by your networks. And queue on the external interface connections coming from the internet. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Relationship Between VLANs and Physical Interfaces in PF
Thank you for the reply, Giancarlo. There are some things I'm not quite sure about from your response, however. prio sounds great on paper, but I'm pretty sure they are a per-interface priority queue. Could it still prioritize packets from the Asterisk vlan above those from other vlans? Also, I was fairly sure from the pf.conf man page that queues were on the outbound interface, not the inbound. Is that wrong? On Mon, Aug 04, 2014 at 07:01:06PM -0300, Giancarlo Razzolini wrote: On 04-08-2014 18:09, Eric Dilmore wrote: I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The gateway has one external interface and one internal, with the internal network split into several VLANs: one for secure traffic, one for guests, one for internal phones, and one for our external Asterisk phone server. Vlans work, but they add complexity. I'd prefer physical interfaces separating the networks, both for performance and security reasons. I'm trying to use queues to set up QoS for the Asterisk server. There is limited bandwidth in our location, and we would like to ensure that the Asterisk server has priority over other traffic. I would prefer a bandwidth specification over a simple priority, but either would be fine. I suggest you first try prio, and only if it doesn't work, use queues. I've used queues, but recently, I've been using only prio. It almost always does the job. However, I believe that pf queues are tied to an outbound interface. None of the rules I have attempted on the internal interface have matched at all. I can specify each vlan explicitly, but the internal interface itself doesn't seem to match any packets. tcpdump shows traffic passing both in and out when I specify the internal interface. The most indicated way is to queue your downloads on the internal interface and your uploads on the external interface. If I'm not mistaken, you need to set the queues on each vlan if. I am confused about the relationship between the physical interface and the vlan interfaces in pf. I would also like to know if there are any suggestions for how to set up the queues in order to provide QoS for phone traffic. When using VLAN you'll almost always only filter on the vlan interfaces. As I already mentioned, you'll mostly get away with prio. My current pf.conf is hosted in a gist here: https://gist.github.com/geppettodivacin/8fc8dc044b122154d137 I've took a quick look and you are on the right direction. You'll just need to invert your queues. As I mentioned, use your queues on the vlans for connections initiated by your networks. And queue on the external interface connections coming from the internet. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Relationship Between VLANs and Physical Interfaces in PF
Eric Dilmore [ericdilm...@gmail.com] wrote: Thank you for the reply, Giancarlo. There are some things I'm not quite sure about from your response, however. prio sounds great on paper, but I'm pretty sure they are a per-interface priority queue. Could it still prioritize packets from the Asterisk vlan above those from other vlans? Also, I was fairly sure from the pf.conf man page that queues were on the outbound interface, not the inbound. Is that wrong? Why are you putting a router between your phone server and your phones? Just put them on the same vlan and be happy.
Re: Relationship Between VLANs and Physical Interfaces in PF
On 04-08-2014 19:17, Eric Dilmore wrote: prio sounds great on paper, but I'm pretty sure they are a per-interface priority queue. Could it still prioritize packets from the Asterisk vlan above those from other vlans? Yes, it is per-interface. But the prio is applied on the dequeuing. You can prioritize asterisk on the vlans and also on your external interface. Also, I was fairly sure from the pf.conf man page that queues were on the outbound interface, not the inbound. Is that wrong? I've went and read the man page to be sure. It only mentions outgoing interface one time. But you were confused by the terminology. outgoing interface only mean the interface the packet is leaving. It can, or can't be the external interface, the one were your internet link is. Packets can be queued and dequeued many times as they cross the interfaces. They can even be assigned to queues when specifying rules referring another interface. Queuing is a very complicated matter. And the examples both on the pf.conf man page, and it's faq, are meant as a starting point. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
