level3 dia egress filtering?

Paul S. contact at winterei.se
Tue May 13 14:08:12 UTC 2014


You can't really have your cake, and eat it too.

If this is a deal breaker for anyone, getting it in writing within the 
contract should be the most basic of steps to undertake. Asking 
beforehand will also actually let you know who will and won't do this, 
thus avoid surprises like these altogether.

Otherwise, as Mark mentioned, they're entirely within the contractual 
agreement.

On 5/13/2014 午後 10:51, Blake Dunlap wrote:
> I would personally look at leaving Level 3 over that kind of response.
> I consider it basic service to throw a 1 line acl on an interface
> temporarily in exceptional circumstances. Transit guys can argue if
> they wish, but it won't change my expectations as a customer.
> Eventually I'll find a carrier that will offer reasonable service.
>
> I know it's why I kept UUnet back in the day, and dropped all my other
> providers at the time. Heck ATT even blackholed our traffic with a
> static null, so we were broken even after depeering for several hours
> until we could find someone who knew what a route was via their
> support.
>
> -Blake
>
> On Tue, May 13, 2014 at 4:02 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>> On Monday, May 12, 2014 11:58:20 PM Petter Bruland wrote:
>>
>>> We contacted Level3 a few weeks back, and were told that
>>> they do not provide any filtering service. I've not been
>>> able to confirm this from anyone else, besides the
>>> Level3 customer service rep we spoke with.
>> We've received such requests from customers as well, and our
>> policy is we do not implement any kind of filtering, even
>> though it is restricted to just one customer.
>>
>> If the customer is looking for DoS/DDoS Mitigation services,
>> that is something else that can be offered.
>>
>> But as an ISP, filtering in the data plane that is not for
>> the protection of our core's control plane is not our deal.
>> It is not something I'd ask of my IP Transit provider, nor
>> support that they do.
>>
>> Mark.




More information about the NANOG mailing list