> 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 > >
