Re: QoS for Office365

2019-07-10 Thread Alan Buxey
hi, use Direct Access PAC file for clients to get the right endpoints. Apply QoS to that traffic - and use that same PAC file to feed the IP ranges into your QoS rules on the firewall/router ? alan On Mon, 8 Jul 2019 at 17:15, Joe Yabuki wrote: > > Hi all, > > How do you d

Re: QoS for Office365

2019-07-10 Thread Mark Milhollan
On Tue, 9 Jul 2019, Mike O'Connor wrote: :How do you deal with QoS for Office365, since the IPs are subject to changes ? How often is the data in: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges https://docs.microsoft.com/en-us/office365/enterprise/office-365

Re: QoS for Office365

2019-07-09 Thread Mark Andrews
to get the best > performance. Tragedy of the commons. > > > > -Original Message- > From: NANOG On Behalf Of Mark Tinka > Sent: Monday, July 8, 2019 10:40 AM > To: nanog@nanog.org > Subject: Re: QoS for Office365 > > > > On 2/Jul/19 23:18, Joe Yabuk

Re: QoS for Office365

2019-07-09 Thread Mike O'Connor
:How do you deal with QoS for Office365, since the IPs are subject to changes ? How often is the data in: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service out of date? -Mike

Re: QoS for Office365

2019-07-09 Thread Brian Knight
> On Jul 9, 2019, at 9:19 AM, Mark Tinka wrote: > > > >> On 9/Jul/19 16:18, Ross Tajvar wrote: >> I think the difficulty lies in appropriately marking the traffic. Like >> Joe said, the IPs are always changing. > > Does anyone know if they are reasonably static in an Express Route scenario?

Re: QoS for Office365

2019-07-09 Thread Warren Kumari
affic under congestion events) only one of about seven >> did anything at all with the marking, and that wasn't enough to make >> any difference... I briefly toyed with the idea of asking for some >> money back / trying to enforce the terms of the agreements, but >> fi

Re: QoS for Office365

2019-07-09 Thread Edward Salonia
Have you looked into Cisco’s SD-AVC? Also with the o365 connector? https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/avc/sd-avc/2-1-0/ug/sd-avc-2-1-0-ug.pdf On Jul 2, 2019, at 17:18, Joe Yabuki wrote: Hi all, How do you deal with QoS for Office365, since the IPs are subject to changes

Re: QoS for Office365

2019-07-09 Thread Tom Beecher
I looked back into work email from back then and I see where I made my mistake. I had misread the 7.4 change where they added the option for allow IPQoS=none , apparently my brain just skipped the word 'option', and it stuck in my brain as the default behavior being 'none'. That's embarrassing,

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 17:06, Joel Jaeggli wrote: > Express route peering with 12076 gives you more specific routes then you > would otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also > gives you control over what region / application is exported to you. As I had assumed. But of

Re: QoS for Office365

2019-07-09 Thread Saku Ytti
On Tue, 9 Jul 2019 at 18:50, Tom Beecher wrote: > I respectfully just don't agree on that. In my view, software should default > to not setting those bits to anything by default, but should have > configuration options that allow them to be set if required. Every network is > different, and

Re: QoS for Office365

2019-07-09 Thread Paul Thornton
On 09/07/2019 16:27, Jay Ford wrote: On Tue, 9 Jul 2019, Mark Tinka wrote: On 9/Jul/19 16:18, Ross Tajvar wrote: I think the difficulty lies in appropriately marking the traffic. Like Joe said, the IPs are always changing. Does anyone know if they are reasonably static in an Express Route

Re: QoS for Office365

2019-07-09 Thread Tom Beecher
I respectfully just don't agree on that. In my view, software should default to not setting those bits to anything by default, but should have configuration options that allow them to be set if required. Every network is different, and making assumptions based on RFC SHOULD's is an unfortunate

Re: QoS for Office365

2019-07-09 Thread Jay Ford
On Tue, 9 Jul 2019, Mark Tinka wrote: On 9/Jul/19 16:18, Ross Tajvar wrote: I think the difficulty lies in appropriately marking the traffic. Like Joe said, the IPs are always changing. Does anyone know if they are reasonably static in an Express Route scenario? At least sometimes M$ says

Re: QoS for Office365

2019-07-09 Thread Saku Ytti
Hey Tom > That's already been happening. OpenSSH pulled that stunt in 7.8. OpenSSH always coloured interactive and non-interactive SSH. They just used original TOS definition, which no one has used in the field, not in the last 20 years at any rate. And which devices actually cannot even match

Re: QoS for Office365

2019-07-09 Thread Tom Beecher
e best > performance. Tragedy of the commons. > > > > -Original Message- > From: NANOG On Behalf Of Mark Tinka > Sent: Monday, July 8, 2019 10:40 AM > To: nanog@nanog.org > Subject: Re: QoS for Office365 > > > > On 2/Jul/19 23:18, Joe Yabuki wrote: &

Re: QoS for Office365

2019-07-09 Thread Saku Ytti
On Tue, 9 Jul 2019 at 17:37, Valdis Klētnieks wrote: > But how did you verify they "worked" as far as actually dropping packets off > the correct flow (especially since if you have a high-priority QoS, the flow > that > loses may be some other customer's flow)? By congesting queues and

Re: QoS for Office365

2019-07-09 Thread Joel Jaeggli
> On Jul 9, 2019, at 07:19, Mark Tinka wrote: > > > > On 9/Jul/19 16:18, Ross Tajvar wrote: >> I think the difficulty lies in appropriately marking the traffic. Like >> Joe said, the IPs are always changing. > > Does anyone know if they are reasonably static in an Express Route scenario?

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 16:46, Steve Mikulasik wrote: > Even if QoS on the Internet was possible it would be destroyed by everyone > marking all their traffic with the highest priority to get the best > performance. Tragedy of the commons. I kind of like the Internet the way it is. The best-effort

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 16:37, Valdis Kl ē tnieks wrote: > I'll bite. > > It's one thing to verify that no routers molested the QoS bits along the > packet path. > > But how did you verify they "worked" as far as actually dropping packets off > the correct flow (especially since if you have a high-priority

RE: QoS for Office365

2019-07-09 Thread Steve Mikulasik via NANOG
@nanog.org Subject: Re: QoS for Office365 On 2/Jul/19 23:18, Joe Yabuki wrote: > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to > changes ? > > How can we mark the trafic while keeping the security (I fear the > marking based o

Re: QoS for Office365

2019-07-09 Thread Joe Yabuki
Hi all, Thanks for your replies, I'll rephrase just to clarify, our aim is to do QoS within our extended LAN (From remote sites to the Datacenter using the MPLS provider as transit) - and we can't use DIA for a security reasons... So arguably, we still need to mark/queue/police packets at the

Re: QoS for Office365

2019-07-09 Thread Valdis Klētnieks
On Tue, 09 Jul 2019 17:16:52 +0300, Saku Ytti said: > In previous life working with L3 MPLS VPN with deliveries far > exceeding on-net size we bought access from partners and had QoS > contracts in place, which were tested and enforced and they worked > after some ironing during field trials.

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 16:23, Brandon Martin wrote: >   > To be fair, there are some folks who operate national or global big-I > Internet IP networks that do guarantee QoS as long as you stay on > their network. Yes, which is the point... as long as the traffic is on-net, you can guarantee things.

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 16:16, Saku Ytti wrote: > In previous life working with L3 MPLS VPN with deliveries far > exceeding on-net size we bought access from partners and had QoS > contracts in place, which were tested and enforced and they worked > after some ironing during field trials. > Usually

Re: QoS for Office365

2019-07-09 Thread Brandon Martin
On 7/8/19 4:01 PM, adamv0...@netconsultings.com wrote: And yet the SD-WAN promising MPLS experience over the internet and other BS sells like crazy;) To be fair, there are some folks who operate national or global big-I Internet IP networks that do guarantee QoS as long as you stay on their

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 16:18, Ross Tajvar wrote: > I think the difficulty lies in appropriately marking the traffic. Like > Joe said, the IPs are always changing. Does anyone know if they are reasonably static in an Express Route scenario? Mark.

Re: QoS for Office365

2019-07-09 Thread Ross Tajvar
I think the difficulty lies in appropriately marking the traffic. Like Joe said, the IPs are always changing. On Tue, Jul 9, 2019, 9:15 AM Mark Tinka wrote: > > > On 9/Jul/19 16:08, Joe Yabuki wrote: > > Hi all, > > > > Thanks for your replies, > > > > I'll rephrase just to clarify, our aim is

Re: QoS for Office365

2019-07-09 Thread Saku Ytti
On Tue, 9 Jul 2019 at 17:05, Tom Beecher wrote: > Generally speaking, I agree that making QoS features work consistently on an > external network you do not control is a fool's errand. > > But if that language was inserted into the contracts, and you can > demonstrably prove it's not being

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 16:08, Joe Yabuki wrote: > Hi all, > > Thanks for your replies, > > I'll rephrase just to clarify, our aim is to do QoS within our > extended LAN (From remote sites to the Datacenter using the MPLS > provider as transit) - and we can't use DIA for a security reasons... > > So

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 16:01, Tom Beecher wrote: >   > > But if that language was inserted into the contracts, and you can > demonstrably prove it's not being done, enforcing contract terms > should always be done. Depending on the strength of the remedy, could > have been a lot of free service, enough

Re: QoS for Office365

2019-07-09 Thread Tom Beecher
he terms of the agreements, but > figured that there wasn't much point - expecting QoS to work in > someone else's network based upon your markings seems like a fool's > errand. > > W > > > > > > > > > > > As another person stated, the real answer is t

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
To quote from that URL:     QoS only works as expected when implemented on all links between callers. If you use QoS     on an internal network and a user signs in from a remote location, you can only prioritize within     your internal, managed network. Mark. On 9/Jul/19 02:41, cyrus ramirez

Re: QoS for Office365

2019-07-09 Thread Mark Tinka
On 9/Jul/19 01:00, Keith Medcalf wrote: > Using Orifice 342 will hurt you. Can't choose what my customers like :-). Mark.

Re: QoS for Office365

2019-07-09 Thread Radu-Adrian Feurdean
On Mon, Jul 8, 2019, at 18:15, Joe Yabuki wrote: > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to changes ? For "Classic QoS" : you don't. At best you tell the customer it's done without actually doing anything (it very often works).

Re: QoS for Office365

2019-07-08 Thread cyrus ramirez via NANOG
Implement Quality of Service in Microsoft Teams | | | | || | | | | | Implement Quality of Service in Microsoft Teams Prepare your organization's network for Quality of Service (QoS) in Microsoft Teams. | | | | Sent from Yahoo Mail on Android On

RE: QoS for Office365

2019-07-08 Thread Keith Medcalf
Behalf Of Mark Tinka >Sent: Monday, 8 July, 2019 15:50 >To: Robert Webb >Cc: NANOG list >Subject: Re: QoS for Office365 > > > >On 8/Jul/19 21:03, Robert Webb wrote: >> I took the OP's request as for doing QoS at the edge of their >network >> and not necessarily t

Re: QoS for Office365

2019-07-08 Thread Mark Tinka
On 9/Jul/19 00:35, Warren Kumari wrote: > I disagree -- you *can* guarantee what someone else will do with your > ToS fields... they will A: ignore them and / or B: scribble all > over them. I'll rephrase... you can't guarantee that a remote network will handle your packets the way you

Re: QoS for Office365

2019-07-08 Thread Warren Kumari
other person stated, the real answer is to add more bandwidth if > > you are having to QoS to Office365 because it is affecting other > > internet based services. > > Yes and no. > > More bandwidth never hurt anyone, but packet loss in the remote network > toward the clou

Re: QoS for Office365

2019-07-08 Thread Mark Tinka
On 8/Jul/19 22:01, adamv0...@netconsultings.com wrote: > And yet the SD-WAN promising MPLS experience over the internet and other BS > sells like crazy ;) Where have we seen that before... Still waiting for the ATM port on my laptop :-). Mark.

Re: QoS for Office365

2019-07-08 Thread Mark Tinka
fields. > > As another person stated, the real answer is to add more bandwidth if > you are having to QoS to Office365 because it is affecting other > internet based services. Yes and no. More bandwidth never hurt anyone, but packet loss in the remote network toward the cloud will hurt you. Mark.

RE: QoS for Office365

2019-07-08 Thread adamv0025
> Warren Kumari > Sent: Monday, July 8, 2019 8:06 PM > > On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka wrote: > > > > > > > > On 8/Jul/19 20:50, Warren Kumari wrote: > > > > > Depends -- I'd note that the OP said "How can we mark the trafic > > > while keeping the security..." -- some people use the

Re: QoS for Office365

2019-07-08 Thread Warren Kumari
On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka wrote: > > > > On 8/Jul/19 20:50, Warren Kumari wrote: > > > Depends -- I'd note that the OP said "How can we mark the trafic while > > keeping the security..." -- some people use the COS / DSCP bits to > > annotate packets with security information, and

Re: QoS for Office365

2019-07-08 Thread Robert Webb
I took the OP's request as for doing QoS at the edge of their network and not necessarily the entire path. As another person stated, the real answer is to add more bandwidth if you are having to QoS to Office365 because it is affecting other internet based services. Robert On Mon, Jul 8, 2019

Re: QoS for Office365

2019-07-08 Thread Mark Tinka
On 8/Jul/19 20:50, Warren Kumari wrote: > Depends -- I'd note that the OP said "How can we mark the trafic while > keeping the security..." -- some people use the COS / DSCP bits to > annotate packets with security information, and use that to make > *security decisions* instead of using it to

Re: QoS for Office365

2019-07-08 Thread Warren Kumari
On Mon, Jul 8, 2019 at 12:31 PM Jared Mauch wrote: > > > > > On Jul 2, 2019, at 5:18 PM, Joe Yabuki wrote: > > > > Hi all, > > > > How do you deal with QoS for Office365, since the IPs are subject to > > changes ? > > > > How can we mark

Re: QoS for Office365

2019-07-08 Thread Mark Tinka
On 8/Jul/19 18:18, Jared Mauch wrote: > > Add bandwidth? > > QoS is a great tool when you’re constrained and must classify your critical > traffic, but it’s not a substitute of getting enough capacity to offices. > > I have only applied QoS to voice traffic to ensure it gets through, the rest

Re: QoS for Office365

2019-07-08 Thread Mark Tinka
On 2/Jul/19 23:18, Joe Yabuki wrote: > Hi all,  > > How do you deal with QoS for Office365, since the IPs are subject to > changes ? > > How can we mark the trafic while keeping the security (I fear the > marking based on TCP/UDP Ports since they are not without an >

Re: QoS for Office365

2019-07-08 Thread Jared Mauch
> On Jul 2, 2019, at 5:18 PM, Joe Yabuki wrote: > > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to changes ? > > How can we mark the trafic while keeping the security (I fear the marking > based on TCP/UDP Ports since they are n

QoS for Office365

2019-07-08 Thread Joe Yabuki
Hi all, How do you deal with QoS for Office365, since the IPs are subject to changes ? How can we mark the trafic while keeping the security (I fear the marking based on TCP/UDP Ports since they are not without an additional risk coming from worms/virus using those ports for example, and doing