Re: Office 365 Calendar support for macOS Calendar App

2023-05-23 Thread Steve Lalonde
Hi Mark,

I’m using macOS native calendar app with office365, I just setup as exchange in 
the add account dialogue.

It used to get stuck and refuse to update previous to 13.2, just disabling 
calendar in the account and then reenabling seemed to fix it, but did take a 
while, not seen that since recently, 

I’m on 13.4 now. 

I only fire up outlook to adjust filters on e-mail.

Steve

> On 23 May 2023, at 12:42, Mark Tinka  wrote:
> 
> Hi all.
> 
> It may just be me, or it may not, but figured I'd ask... it seems like 
> Microsoft's 365 cloud service does not support the native Calendar app on 
> macOS.
> 
> Oddly, it works without issue for the native Calendar app in iOS.
> 
> A bit of Googl'ing and speaking with some 365 customer admins. suggests that 
> "Microsoft do not support Apple products in 365", which sounds most odd to 
> me, as I know a number of Microsoft apps do run on macOS and iOS.
> 
> Am I off the mark, are others seeing the same, is this a known issue, is it a 
> non-issue?
> 
> Mark.



Re: Setting sensible max-prefix limits

2021-08-18 Thread Steve Lalonde
On 18 Aug 2021, at 10:33, Lars Prehn mailto:lpr...@mpi-inf.mpg.de>> wrote:
> 
> As I understand by now, it is highly recommended to set a max-prefix limit 
> for peering sessions. Yet, I can hardly find any recommendations on how to 
> arrive at a sensible limit.
> 
> I guess for long standing peers one could just eyeball it, e.g., current 
> prefix count + some safety margin. How does that work for new peers? Do you 
> negotiate/exchange sensible values whenever you establish a new session? Do 
> you rely on PeeringDB (if available)? Do you apply default values to everyone 
> except the big fishes?
> 
> Apart from your peers, do you also apply a limit to your transit sessions?

We always use PeeringDB data and refuse to peer with networks not in PeeingDB ( 
I think there are only 2 exceptions ) Automation keeps the max_prefix numbers 
up to date. 

Our transits we use data from the weekly routing table reports and allow some 
expansion room.

So far this works for us

Regards

Steve

Re: Long AS Path

2017-06-22 Thread Steve Lalonde
Mel,

There was a Cisco bug many years ago that caused lots of issues. Since then we 
have limited max-as to 50 and it has not caused any reported issues yet.

Link that does not require a CCO login to view.
http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html

Regards

Steve Lalonde


> On 21 Jun 2017, at 16:49, Mel Beckman <m...@beckman.org> wrote:
> 
> Steinar,
> 
> What reason is there to filter them? They are not a significant fraction of 
> BGP paths. They cause no harm. It's just your sense of tidiness. 
> 
> You might consider contacting one of the operators to see if they do have a 
> good reason you haven't considered. But absent a good reason *to* filter 
> them, I would let BGP mechanics work as intended.
> 
> -mel beckman
> 
> On Jun 21, 2017, at 12:57 AM, "sth...@nethelp.no" <sth...@nethelp.no> wrote:
> 
>>> Just wondering if anyone else saw this yesterday afternoon ?
>>> 
>>> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D AS_SEQ(2=
>>> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 234=
>>> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 =
>>> 23456 23456 23456 23456 23456 ... attribute length (567) More than configur=
>>> ed MAXAS-LIMIT
>> 
>> There are quite a few examples of people using stupidly long AS paths.
>> For instance
>> 
>> 177.23.232.0/24*[BGP/170] 00:52:40, MED 0, localpref 105
>> AS path: 6939 16735 28163 28163 28163 28163 28163 28163 
>> 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 262401 262401 
>> 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 
>> 262401 262401 262401 262949 52938 52938 52938 52938 52938 52938 52938 52938 
>> 52938 52938 52938 I
>> 
>> I currently have 27 prefixes in my Internet routing table with 40 or
>> more ASes in the AS path (show route aspath-regex ".{40,}").
>> 
>> I see no valid reason for such long AS paths. Time to update filters
>> here. I'm tempted to set the cutoff at 30 - can anybody see a good
>> reason to permit longer AS paths?
>> 
>> Steinar Haug, Nethelp consulting, sth...@nethelp.no