Long AS Path

Sat Jun 24 12:10:54 UTC 2017

James,

By "experienced by someone else" I mean someone who is not one of your customers.

The better strategy, I think, is to not filter long paths unless you have a reason to see their creating a problem. Otherwise you're just operating on superstition, no?

-mel via cell

> On Jun 24, 2017, at 12:42 AM, James Bensley <jwbensley at gmail.com> wrote:
> 
> On 23 Jun 2017 17:03, "Mel Beckman" <mel at beckman.org> wrote:
> 
> James,
> 
> The question is whether you would actually hear of any problems. Chances
> are that the problem would be experienced by somebody else, who has no idea
> that your filtering was causing it.
> 
> -mel beckman
> 
> 
> Hi Mel,
> 
> For us this the answer is almost definitely a yes. We are an MSP (managed
> service provider) as opportunities to a traditional ISP, so our customers
> know they can open a ticket with us for pretty much anything and we'll try
> and look into it.
> 
> We have had some weird issues with far away sites, first line can't find
> any issue, it works it's way up to somebody who knows how to check if we
> would be filtering a route on our transit and peering sessions.
> 
> Earlier when I said that care is required when filtering long AS_PATH
> routes or certain AS numbers, we looked at the BGP table to see exactly
> which routes we'd drop before hand and communicated out these changes. I
> think for an MSP this shouldn't be hard to implement and manage, I can
> appreciate for a "flat" ISP ("he's some transit, help yourself") it could
> be more challenging.
> 
> In relation to the OPs question, long AS_PATH routes can be filtered I just
> wouldn't bother except for very long paths to drop as little as possible
> and be sure of whY you drop/filter.
> 
> Cheers,
> James.