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 deal
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/offic
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
: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
> 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?
On Tue, Jul 9, 2019 at 10:02 AM Tom Beecher wrote:
>>
>> At a previous employer (AOL, doing VoIP for customer service / call
>> centers, ~2004) we had a number of contractual agreements with
>> multiple providers to honor our QoS markings -- as far as I could tell
>> (marking test traffic under co
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
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, tha
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 cour
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 ma
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
sce
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 choi
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 th
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 fo
et 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 Yabuki wrote:
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 verifyin
> 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?
E
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 natur
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
@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 on TCP/UDP Por
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 Ed
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.
I'l
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.
Larg
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 contrac
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
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.
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 t
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 done
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 arguabl
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 fi
>
> At a previous employer (AOL, doing VoIP for customer service / call
> centers, ~2004) we had a number of contractual agreements with
> multiple providers to honor our QoS markings -- as far as I could tell
> (marking test traffic under congestion events) only one of about seven
> did anything a
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 wr
On 9/Jul/19 01:00, Keith Medcalf wrote:
> Using Orifice 342 will hurt you.
Can't choose what my customers like :-).
Mark.
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 oft
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 M
n 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 nec
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 int
On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka wrote:
>
>
>
> 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 the entire path.
>
> Indeed, but even then, you could be handing off the traffic to a
> downstream custom
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.
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 the entire path.
Indeed, but even then, you could be handing off the traffic to a
downstream customer, and can't guarantee what they do to those ToS fields.
>
>
> 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
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 u
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 at
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
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
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
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
>
> 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
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
49 matches
Mail list logo