It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an AS3549 customer.
From GBLX looking glass, ATL1
traceroute Protocol [ip]: ip Target IP address: 10.0.0.1 Source address: Numeric display [n]: n Timeout in seconds [3]: 1 Probe count [3]: 2 Minimum Time to Live [1]: 1 Maximum Time to Live [30]: 30 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.0.0.1 VRF info: (vrf in name/id, vrf out name/id) 1 te3-1-10G.par9.CTA1.GRU.gblx.net (67.16.142.26) 120 msec 124 msec 2 122.5.125.189.static.impsat.net.br (189.125.5.122) 120 msec 120 msec 3 10.0.0.1 [AS 262487] 124 msec 120 msec
Apparently the customer didn't have proper inbound filter...... Reply from 10.0.0.1: bytes=32 time=132ms TTL=61
On 08/07/2013 02:20 AM, Martin T wrote:
Hi,
as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible?
regards, Martin