[184376] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Wrong use of 100.64.0.0/10

daemon@ATHENA.MIT.EDU (Justin M. Streiner)
Fri Oct 2 12:28:58 2015

X-Original-To: nanog@nanog.org
Date: Fri, 2 Oct 2015 12:19:52 -0400 (EDT)
From: "Justin M. Streiner" <streiner@cluebyfour.org>
To: nanog <nanog@nanog.org>
In-Reply-To: <CAOAnmEhW5RSg17CsDAPB7as=QGQHC6Qp+TGXCK9zj-WKRQZZHA@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Fri, 2 Oct 2015, Marco Paesani wrote:

> I know that we must filter this type of route, but AS9498 (upstream) MUST
> accept only correct networks.
> Or not ?

They should filter out routes that are not supposed to be globally 
routable, but many providers don't do this, unfortunately.

jms

> 2015-10-02 16:52 GMT+02:00 Justin M. Streiner <streiner@cluebyfour.org>:
>
>> On Fri, 2 Oct 2015, Marco Paesani wrote:
>>
>> Hi,
>>> probably this route is wrong, see RFC 6598, as you can see:
>>>
>>> show route 100.64.0.0/10
>>>
>>> inet.0: 563509 destinations, 1528595 routes (561239 active, 0 holddown,
>>> 3898 hidden)
>>> + = Active Route, - = Last Active, * = Both
>>>
>>> 100.100.1.0/24     *[BGP/170] 2d 14:46:05, MED 100, localpref 100
>>>                      AS path: 5580 9498 9730 I, validation-state:
>>> unverified
>>>                   > to 78.152.54.166 via ge-2/0/0.0
>>>
>>
>> My guess is someone leaking an internal route.  It's not uncommon to see
>> people using random IPv4 space for internal purposes.  Ranges such as
>> 100.100.x.0/24 or 20.20.x.0/24 are often mis-used in this way.
>>
>> It also looks like at least one of their upsteams is not filtering out any
>> advertisements from 100.64/10.
>>
>> jms
>>
>
>
>
> -- 
>
> Marco Paesani
> MPAE Srl
>
> Skype: mpaesani
> Mobile: +39 348 6019349
> Success depends on the right choice !
> Email: marco@paesani.it
>

home help back first fref pref prev next nref lref last post