10 Replies Latest reply: Sep 3, 2013 12:03 PM by cahunt RSS

QoS designs and network borders in a BYOD, bandwidth hungry world

buraglio

Taking a step back from internal QoS designs, one thing that I have worked on for a large portion of both my professional and consulting career is border queuing. To take a walk down memory lane and help explain where my perspective is rooted, I wrote a custom OpenBSD based distribution back in the early 2000s that used OSU flow tools flow data and some poorly written perl to jam multi dwelling unit abusers in large apartment campuses into QoS groups dynamically, built and deployed some early L7filter based gateways in Linux for the same application, wrote L7 Linux based scripts for DD-WRT and generally played with any open source or commercial QoS devices within a reasonable budget.

Nowadays, I spend my consulting time tuning pfsense installs for HSFC based QoS and professionally have extensively tested A10 devices, IOS micro flow based rate limiting, Juniper MX based rate limiting, Palo Alto Networks devices, Procera applicances, Sonicwall devices and a number of other boxes capable of doing >1Gbps deep packet and L7 based QoS at network borders.

In my experience, I have yet to find one that I'm completely satisfied with.   I'll admit that I'm a tad idealistic.  Some are very, very close, but I am curious as to what others are using?  How do others ensure user experience on a potentially free-for-all network?  How is user experience ensured in this BYOD, bandwidth hungry world?

  • Re: QoS designs and network borders in a BYOD, bandwidth hungry world
    buraglio

    To take a step back, is anyone managing their traffic at the ingres/egress at all?  What mechanisms or products are you using?  How well do they perform (or not perform)?

    • Re: QoS designs and network borders in a BYOD, bandwidth hungry world
      zackm

      We have a guest Wifi for the BYOD crowd that never seems to bog down on my iPad.

       

      Ironically, for a large technology company, I actually can count on one hand the number of people I know who bring anything more than a cell phone and their work-issued laptop to the office. The company does not have any kind of reimbursement plan for using your own equipment, so I guess the desire just is not present.

       

      Maybe that puts us in the magical land of unicorns in today's marketplace, but unicorns don't hog bandwidth and they aren't a headache to the infosec team either

  • Re: QoS designs and network borders in a BYOD, bandwidth hungry world
    wbrown

    I wish we had more control on the BYOD segments.
    We have 3 main groups using the BYOD segments:  1) patients with XBOX, tablet, etc, 2) doctors with tablets, smartphones, etc, and 3) everyone else walking in off the street with wifi enabled.

    Egress filtering quickly became an administrative nightmare because of the ports needed by the various MMORPGs and Facetime-type apps.

    Bandwidth limiting died after enough doctors did speedtests on dslreports and complained about not getting enough bandwidth (that they'll never really use anyway).

  • Re: QoS designs and network borders in a BYOD, bandwidth hungry world
    michael stump

    I spent some quality time at an agency that acted more like a university when it came to Internet access and traffic filtering. Actually, make that IT in general. PhDs would rotate in for a few years and expect the same freedoms that they enjoyed on campus. That meant no egress filtering at all. And little to no management of BYOD, since IT was afraid to tell a PhD "no" on any matter. When I started sharing bandwidth utilization reports with IT management (yes, via Orion NPM ), the response was not to limit or implement QoS at the border. It was... you guessed it... buy more bandwidth.

     

    Of course, the government loves to solve problems with a check.

    • Re: QoS designs and network borders in a BYOD, bandwidth hungry world
      buraglio

      I work in a research environment so I understand that mentality and I don't necessarily disagree with it. My personal preference is a completely open network with full packet capture at the egress points with middleware for RTBH.  I don't believe in NAT and I advocate for BCP filtering inbound, no outbound filtering outbound and very little or no firewalls unless something is special case (financial data, medical data, PCI compliance or other PII data).

      I know I'm in the minority; I come from the service provider world and that's the way my mind works. 

      However, in some cases I believe shaping abusive users is appropriate.  There are a lot of schools of thought on this, I tend to lean toward priority queuing mechanisms, allowing everything but setting actual "work" protocols higher. Are others just blocking ports, then?

  • Re: QoS designs and network borders in a BYOD, bandwidth hungry world
    802jr

    I have worked at a couple of places where the BYOD policy was to just have those device on a guest wireless segment. It worked out fine for the most part because the actual productionnetwork was firewalled of from the guest network and had very little limitations placed on it. So people would do their daily streaming of music, videos, you name it on the production network. If something was of limits they just used the guest wireless network which was for the more part unfiltered. Since it was just considered a "guest network" no one ever really complained because it was not intended to be used as an actual production network.

     

    I did make a few bandwidth limiting QoS changes to the egress ports of the guest network. This was to ensure that the production network did not feel any side affects of users bogging down the guest network.

  • Re: QoS designs and network borders in a BYOD, bandwidth hungry world
    cahunt

    I have experienced the same as wbrown and michael stump in this case. Appeasing Dr.'s in the past has been the standard response. I don't see the issue with corralling the highly edjucated uninformed users when need be. The thing is with BYOD each user has their own experience with their list of likes and dislikes creating an extensive list of devices to interact and interfere with the network. HP has a wifi mouse that shows as a Rogue network and can cause interference with your wifi connection when your neighbor is using this device. Trying to search this bad boy out was a beast; and thats just one case of a device not connected to the network. We have a guest network, but in order for Dr.'s to get the use out of their tools purchased with their own money or department funds that do not match the institutional standard they must be on our internal secure wireless network. Now the issue is their browsing habbits and a lack of security software when they come on site.  This tends to keep our information security department quite busy. I am just happy the monitoring team has been removed from the remediation process(though i exect we will be handed back the process due to my teams attentiveness to detail and ability to find more specific data than some of our engineer's).  A Patients connection to MS Live is crucial when tied to a bed for treatment, so we pass this traffic through. Revently we enabled on of our guests with a faster 'internal' connection for the use of a Vgo to attend classes. Our pipe for the quest is constantly at 95 to 100% due to our size so it was needed for his connectivity(A/V stream)