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 <jwbens...@gmail.com> wrote:
>
> On 23 Jun 2017 17:03, "Mel Beckman" <m...@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.
