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
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
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?
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
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,
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
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
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
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
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
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
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:
&
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
> 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?
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
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 o
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
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.
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.
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
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
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
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
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
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
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
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 often works).
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
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
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
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
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.
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.
> 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
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
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