Re: BGP Hijack/Sickness with AS4637

[Brad Hooper]

Hello,

Just to clear up a few things. We are not running any route optimization 
software (ever). The reason we "refused" to help is because we were not 
going to contact our transit providers NOC regarding other parties 
routes, even if we did they wouldn't be of assistance.


We are purely passing on the routes we receive from our transit 
providers to our customers. We are not modifying the routes in any way 
shape or form.


We incest routes from a lot of transit providers and send most of the 
data to route views (As do a number of our customers) which is why this 
route was seen from us.


I have completed a soft clear on our BGP session towards AS4637 and the 
route still exists. Sorry we can't be of assistance in this case but 
this is fully out of our control.


x...@re0-cr1.ty8.ty.jp> show route 128.10.4.0/24 detail

vrf-international.inet.0: 696465 destinations, 1194388 routes (696461 
active, 0 holddown, 4 hidden)

128.10.4.0/24 (1 entry, 1 announced)
    *BGP    Preference: 170/-101
    Next hop type: Router, Next hop index: 790
    Address: 0xff29810
    Next-hop reference count: 1279932
    Source: 202.127.69.33
    Next hop: 202.127.69.33 via ae0.401, selected
    Session Id: 0x181
    State: 
    Peer AS:  4637
    Age: 2w4d 11:08:17
    Validation State: unverified
    Task: BGP_4637.202.127.69.33
    Announcement bits (4): 1-KRT 2-BGP Route Target 
5-BGP_RT_Background 6-Resolve tree 6

    AS path: 4637 3257 29909 16532 16532 16532 16532 I
    Communities: 4637:32031 4637:32314 4637:32504 4637:60952
    Accepted
    Localpref: 100
    Router ID: 202.84.219.12


Regards,
Brad
ColoAU (AS63956)

Colocation Australia Pty Ltd 



Brad Hooper / Network Architect
b...@coloau.com.au / +61 7 3106 3810

Colocation Australia Pty Ltd
http://coloau.com.au

Facebook  Twitter 
 skype 




On 01/06/18 06:36, Job Snijders wrote:

On Thu, May 31, 2018 at 02:40:06PM +, Job Snijders wrote:

Upon further inspection, it seems more likely that the bgp optimiser is
in ColoAU's network. Given the scale of AS 4637, if it were deployed
inside Telstra I'd expect more problem reports. AS 4637 may actually
just be an innocent bystander.

It is interesting to note that the /23 only appears on their Sydney
based routers on https://lg.coloau.com.au/

Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps
you should just straight up ask whether they use any type of "network
optimisation" appliance.

I found a few more interesting routes inside ColoAU's looking glass:

128.10.4.0/24 - AS_PATH 63956 4637 3257 29909 16532 16532 16532 16532
 (should be 128.10.0.0/16 originated by AS 17, Purdue
 University)

192.54.130.0/24 - AS path: 135069 9439
(does not exist in the DFZ, a peering lan 
prefix? a typo?)

67.215.73.0/24 - AS path: 2764 1221 36692
(does not exist in the DFZ, a peering lan 
prefix? a typo?)

ColoAU propagated the above routes to their transit customers, so the
128.10.4.0/24 and 18.29.238.0/23 announcements definitely count as BGP
hijacks with fabricated an AS_PATH.

Kind regards,

Job

RE: BGP Hijack/Sickness with AS4637

[Phil Lavin]

What is the relationship of 103.97.52.2 (Colocation Australia - Japan) to you? 
Is this, for example, a peering over an IX? If so, did you learn the route from 
route servers or do you peer directly with them?


Phil

-Original Message-
From: NANOG  On Behalf Of Alain Hebert
Sent: 31 May 2018 14:50
To: nanog@nanog.org
Subject: Re: BGP Hijack/Sickness with AS4637

     Hi,

     Well bad news on the ColoAU front, they refused to cooperate.

     We'll pushback thru our GTT accounts...  But I'm running out of ideas.

     If anyone has any good ideas how to proceed at this point feel free to 
share =D.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 05/29/18 16:31, Chris Conn wrote:
> Hello,
>
> I am the contact for AS16532.
>
> We never announced nor are we currently advertising this prefix as we 
> are not a transit AS for anyone.  As well, it seems to appear and 
> disappear from AS63956 looking glass.  According to that LG, the route 
> changed 6d ago, and is *still currently visible* at this very moment;
>
> https://lg.coloau.com.au/
>
> Command: show route 18.29.238.0 protocol bgp table 
> vrf-international.inet.0 active-path
>
> vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 
> active, 0 holddown, 103994 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2
>AS path: 4637 3257 29909 16532 16532 16532 
> 16532 I, validation-state: unverified
>
>
> AS16532 is not announcing this prefix.  We have a strict prefix-list that is 
> applied to all sessions.  As well, AS29909 is filtering us using our 
> announced AS-SETS/RPSL to avoid us the ability to do anything dumb.  And 
> lastly, our announcements are being filtered by AS3257 as we are required to 
> provide them via LOA.
>
> There is still something wrong somewhere that is injecting this path, anyone 
> have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the 
> AS path?
>
> I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would 
> change anything, as I am not seeing this prefix in their route-server
>
> pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol 
> bgp active-path
>
> inet.0: 691667 destinations, 11752983 routes (691665 active, 1 
> holddown, 1 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 18.29.0.0/16   *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 
> 213.200.87.23
>AS path: 3257 174 3 I, validation-state: unverified
>  > to 141.136.111.13 via xe-1/0/0.0
>
> {master}
> pub...@route-server.as3257.net-re0>
>
>
> {master}
> pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol 
> bgp | find 16532
>
> Pattern not found
> {master}
>
>
>
> So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can 
> find.
>
>
> Chris Conn
> AS16532
>
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tom Paseka 
> via NANOG
> Sent: Friday, May 25, 2018 6:01 PM
> To: Nikolas Geyer 
> Cc: NANOG list 
> Subject: Re: BGP Hijack/Sickness with AS4637
>
> This looks like a route that has been cached by some ISPs/routers even though 
> a withdrawal has actually happened.
>
> If you actually forward packets a long the path, you'll see its not following 
> the AS Path suggested, instead the real route that it should be.
> Bouncing your session with 4637 would likely clear this.
>
> -Tom
>
> On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer  wrote:
>
>> Greetings!
>>
>> Actually, what you have provided below shows the exact opposite. It 
>> shows ColoAU have received the route from 4637 who have received it 
>> from 3257 who have received it from 29909 who have received it from
>> 16532 who originated it. It infers nothing about who 16532 found the route 
>> to come from.
>>
>> It is evident that GTT are advertising that route to Telstra Global 
>> :)
>>
>> Regards,
>> Nik.
>>
>>>  And I'm pretty sure AS3257 (GTT ) is in the same boat as 
>>> us, as
>> they're not the one advertising those routes to AS4637
>>>  AS16532 found it to come from AS4637 as you can see from this 
>>> ColoAU
>> LG output below
>>>
>>> - https://lg.coloau.com.au/
>>>
>>> vrf-international.inet.0: 696533 destinations, 2248101 route

Re: BGP Hijack/Sickness with AS4637

[Chris Conn]

Hello,

I am the contact for AS16532.

We never announced nor are we currently advertising this prefix as we are not a 
transit AS for anyone.  As well, it seems to appear and disappear from AS63956 
looking glass.  According to that LG, the route changed 6d ago, and is *still 
currently visible* at this very moment;

https://lg.coloau.com.au/

Command: show route 18.29.238.0 protocol bgp table vrf-international.inet.0 
active-path

vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 
holddown, 103994 hidden)
+ = Active Route, - = Last Active, * = Both

18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2
  AS path: 4637 3257 29909 16532 16532 16532 16532 I, 
validation-state: unverified


AS16532 is not announcing this prefix.  We have a strict prefix-list that is 
applied to all sessions.  As well, AS29909 is filtering us using our announced 
AS-SETS/RPSL to avoid us the ability to do anything dumb.  And lastly, our 
announcements are being filtered by AS3257 as we are required to provide them 
via LOA.

There is still something wrong somewhere that is injecting this path, anyone 
have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS 
path?

I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change 
anything, as I am not seeing this prefix in their route-server

pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp 
active-path

inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 
hidden)
+ = Active Route, - = Last Active, * = Both

18.29.0.0/16   *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 
213.200.87.23
  AS path: 3257 174 3 I, validation-state: unverified
> to 141.136.111.13 via xe-1/0/0.0

{master}
pub...@route-server.as3257.net-re0>


{master}
pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp | find 
16532

Pattern not found
{master}



So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can 
find.


Chris Conn
AS16532




-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tom Paseka via NANOG
Sent: Friday, May 25, 2018 6:01 PM
To: Nikolas Geyer 
Cc: NANOG list 
Subject: Re: BGP Hijack/Sickness with AS4637

This looks like a route that has been cached by some ISPs/routers even though a 
withdrawal has actually happened.

If you actually forward packets a long the path, you'll see its not following 
the AS Path suggested, instead the real route that it should be.
Bouncing your session with 4637 would likely clear this.

-Tom

On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer  wrote:

> Greetings!
>
> Actually, what you have provided below shows the exact opposite. It 
> shows ColoAU have received the route from 4637 who have received it 
> from 3257 who have received it from 29909 who have received it from
> 16532 who originated it. It infers nothing about who 16532 found the route to 
> come from.
>
> It is evident that GTT are advertising that route to Telstra Global :)
>
> Regards,
> Nik.
>
> >
> > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, 
> > as
> they're not the one advertising those routes to AS4637
> >
> > AS16532 found it to come from AS4637 as you can see from this 
> > ColoAU
> LG output below
> >
> >
> > - https://lg.coloau.com.au/
> >
> > vrf-international.inet.0: 696533 destinations, 2248101 routes
> > (696249
> active, 0 holddown, 103835 hidden)
> > + = Active Route, - = Last Active, * = Both
> >
> > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from
> 103.97.52.2
> >   AS path: 4637 3257 29909 16532 16532 16532
> > 16532
> I, validation-state: unverified
> >
> > --
> > -
> > Alain Hebertaheb...@pubnix.net
> > PubNIX Inc.
> > 50 boul. St-Charles
> > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> > Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
> >
>

RE: BGP Hijack/Sickness with AS4637

[Michel Py]

There is a good possibility that AS 16532 was trying to prepend 3 times and did 
prepend 16532 3 instead of prepend 16532 16532 16532.   
That tends to happen with very low number AS

Regards,
Michel.

Regards,
Nik.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Nikolas Geyer
Sent: Friday, May 25, 2018 11:59 AM
To: aheb...@pubnix.net
Cc: NANOG list
Subject: Re: BGP Hijack/Sickness with AS4637

Greetings!

Actually, what you have provided below shows the exact opposite. It shows 
ColoAU have received the route from 4637 who have received it from 3257 who 
have received it from 29909 who have received it from 16532 who originated it. 
It infers nothing about who 16532 found the route to come from.

It is evident that GTT are advertising that route to Telstra Global :)

Regards,
Nik.

>
> And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as 
> they're not the one advertising those routes to AS4637
>
> AS16532 found it to come from AS4637 as you can see from this ColoAU LG 
> output below
>
>
> - https://lg.coloau.com.au/
>
> vrf-international.inet.0: 696533 destinations, 2248101 routes (696249 active, 
> 0 holddown, 103835 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from 103.97.52.2
>   AS path: 4637 3257 29909 16532 16532 16532 16532 I, 
> validation-state: unverified
>
> --
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: BGP Hijack/Sickness with AS4637 - Case closed

[Alain Hebert]

    Hi,

    Looks like it was a RIB<->FIB bug in part.

    How: BGP Optimizator maybe a culprit, but without insights from 
ColoAU it is hard to say.


    Thank to Job, Mark, Tracey for their time.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 05/31/18 14:36, Job Snijders wrote:

On Thu, May 31, 2018 at 02:40:06PM +, Job Snijders wrote:

Upon further inspection, it seems more likely that the bgp optimiser is
in ColoAU's network. Given the scale of AS 4637, if it were deployed
inside Telstra I'd expect more problem reports. AS 4637 may actually
just be an innocent bystander.

It is interesting to note that the /23 only appears on their Sydney
based routers on https://lg.coloau.com.au/

Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps
you should just straight up ask whether they use any type of "network
optimisation" appliance.

I found a few more interesting routes inside ColoAU's looking glass:

128.10.4.0/24 - AS_PATH 63956 4637 3257 29909 16532 16532 16532 16532
 (should be 128.10.0.0/16 originated by AS 17, Purdue
 University)

192.54.130.0/24 - AS path: 135069 9439
(does not exist in the DFZ, a peering lan 
prefix? a typo?)

67.215.73.0/24 - AS path: 2764 1221 36692
(does not exist in the DFZ, a peering lan 
prefix? a typo?)

ColoAU propagated the above routes to their transit customers, so the
128.10.4.0/24 and 18.29.238.0/23 announcements definitely count as BGP
hijacks with fabricated an AS_PATH.

Kind regards,

Job

Re: BGP Hijack/Sickness with AS4637

[Job Snijders]

On Thu, May 31, 2018 at 02:40:06PM +, Job Snijders wrote:
> Upon further inspection, it seems more likely that the bgp optimiser is
> in ColoAU's network. Given the scale of AS 4637, if it were deployed
> inside Telstra I'd expect more problem reports. AS 4637 may actually
> just be an innocent bystander.
> 
> It is interesting to note that the /23 only appears on their Sydney
> based routers on https://lg.coloau.com.au/
> 
> Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps
> you should just straight up ask whether they use any type of "network
> optimisation" appliance.

I found a few more interesting routes inside ColoAU's looking glass:

128.10.4.0/24 - AS_PATH 63956 4637 3257 29909 16532 16532 16532 16532
(should be 128.10.0.0/16 originated by AS 17, Purdue
University)

192.54.130.0/24 - AS path: 135069 9439
(does not exist in the DFZ, a peering lan 
prefix? a typo?)

67.215.73.0/24 - AS path: 2764 1221 36692
(does not exist in the DFZ, a peering lan 
prefix? a typo?)

ColoAU propagated the above routes to their transit customers, so the
128.10.4.0/24 and 18.29.238.0/23 announcements definitely count as BGP
hijacks with fabricated an AS_PATH.

Kind regards,

Job

Re: BGP Hijack/Sickness with AS4637

[Mark Tinka]

On 31/May/18 16:31, Alain Hebert wrote:

>
>     PS: Still curious how, beside some RIB/FIB failure, how our AS
> ended up there.

We've suffered this many times as well, particularly when records show
up on HE's BGP tool.

It's a b**ch to get fixed, because too many fingers get pointed, and
folk running BGP optimizers may not fully understand this side effect.

Mark.

Re: BGP Hijack/Sickness with AS4637

[Job Snijders]

On Thu, May 31, 2018 at 10:31:26AM -0400, Alain Hebert wrote:
> Thanks for the ideas and the hint.  Good read.
> 
> Will do.

Upon further inspection, it seems more likely that the bgp optimiser is
in ColoAU's network. Given the scale of AS 4637, if it were deployed
inside Telstra I'd expect more problem reports. AS 4637 may actually
just be an innocent bystander.

It is interesting to note that the /23 only appears on their Sydney
based routers on https://lg.coloau.com.au/

Is ColoAU's refusal to cooperate a matter of misunderstanding? Perhaps
you should just straight up ask whether they use any type of "network
optimisation" appliance.

> PS: Still curious how, beside some RIB/FIB failure, how our AS ended
> up there.

I don't know why, but often fabricating random AS_PATH stuff seems to be
part of it.

Kind regards,

Job

Re: BGP Hijack/Sickness with AS4637

[Mark Tinka]

On 31/May/18 16:15, Job Snijders wrote:

> I recommend you reach out to AUSNOG and APOPS and hope someone there
> knows someone at Telstra Hong Kong.
I have a friend at Telstra HKG. He's not in the IP team, but he can
summon a warm body if needed.

Mark.

Re: BGP Hijack/Sickness with AS4637

[Alain Hebert]

    Thanks for the ideas and the hint.  Good read.

    Will do.

    PS: Still curious how, beside some RIB/FIB failure, how our AS 
ended up there.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 05/31/18 10:15, Job Snijders wrote:

On Thu, May 31, 2018 at 09:49:47AM -0400, Alain Hebert wrote:

Well bad news on the ColoAU front, they refused to cooperate.

We'll pushback thru our GTT accounts...  But I'm running out of ideas.

If anyone has any good ideas how to proceed at this point feel free to
share =D.

This feels like a BGP "optimiser" at work inside AS 4637.

>From the https://lg.coloau.com.au/ looking glass:

BGP 'show route'
 18.29.238.0/23  *[BGP/170] 1w0d 18:49:44, localpref 90, from 103.97.52.2
 AS path: 4637 3257 29909 16532 16532 16532 16532 I, 
validation-state: unverified

However, a data-plane traceroute:

 AS path: 4637 -> 174 ->  ...

 traceroute to 18.29.238.1 (18.29.238.1), 30 hops max, 40 byte packets
  1  103.52.116.49 (103.52.116.49)  114.573 ms  113.965 ms  117.141 ms
  MPLS Label=691873 CoS=0 TTL=1 S=0
  MPLS Label=17 CoS=0 TTL=1 S=1
  2  202.127.69.34 (202.127.69.34)  113.768 ms  113.763 ms  113.731 ms
  3  202.84.148.113 (202.84.148.113) [AS  4637]  114.759 ms  117.956 ms  
115.796 ms
  4  202.84.141.13 (202.84.141.13) [AS  4637]  181.873 ms 202.84.141.169 
(202.84.141.169) [AS  4637]  181.618 ms  182.688 ms
  5  202.84.253.82 (202.84.253.82) [AS  4637]  181.949 ms 202.40.149.226 
(202.40.149.226) [AS  4637]  183.194 ms 202.84.253.82 (202.84.253.82) [AS  
4637]  201.282 ms
  6  154.54.10.133 (154.54.10.133) [AS  174]  181.055 ms  181.100 ms  
181.065 ms
  7  154.54.27.117 (154.54.27.117) [AS  174]  175.410 ms  182.956 ms 
154.54.3.69 (154.54.3.69) [AS  174]  175.176 ms
  8  154.54.45.161 (154.54.45.161) [AS  174]  212.531 ms 154.54.44.85 
(154.54.44.85) [AS  174]  202.470 ms  187.361 ms
  9  154.54.42.78 (154.54.42.78) [AS  174]  195.585 ms  195.812 ms 
154.54.42.66 (154.54.42.66) [AS  174]  211.713 ms
 10  154.54.30.161 (154.54.30.161) [AS  174]  235.896 ms  216.173 ms  
211.246 ms
 11  154.54.28.129 (154.54.28.129) [AS  174]  233.516 ms  225.413 ms  
225.551 ms
 12  154.54.24.221 (154.54.24.221) [AS  174]  236.432 ms  236.701 ms  
236.595 ms
 13  154.54.40.109 (154.54.40.109) [AS  174]  273.564 ms  279.452 ms  
248.212 ms
 14  154.54.46.33 (154.54.46.33) [AS  174]  248.098 ms  247.802 ms  248.084 
ms
 15  * * *

Discongruity between RIB and FIB like this, and the hijack being a
more-specific of a /16, is a typical sign of BGP 'optimisers'.

I recommend you reach out to AUSNOG and APOPS and hope someone there
knows someone at Telstra Hong Kong.

More thoughts on BGP optimisers: http://seclists.org/nanog/2017/Aug/318

Kind regards,

Job

Re: BGP Hijack/Sickness with AS4637

[Job Snijders]

On Thu, May 31, 2018 at 09:49:47AM -0400, Alain Hebert wrote:
> Well bad news on the ColoAU front, they refused to cooperate.
> 
> We'll pushback thru our GTT accounts...  But I'm running out of ideas.
> 
> If anyone has any good ideas how to proceed at this point feel free to
> share =D.

This feels like a BGP "optimiser" at work inside AS 4637.

>From the https://lg.coloau.com.au/ looking glass:

BGP 'show route'
18.29.238.0/23  *[BGP/170] 1w0d 18:49:44, localpref 90, from 103.97.52.2
AS path: 4637 3257 29909 16532 16532 16532 16532 I, 
validation-state: unverified

However, a data-plane traceroute:

AS path: 4637 -> 174 ->  ...

traceroute to 18.29.238.1 (18.29.238.1), 30 hops max, 40 byte packets
 1  103.52.116.49 (103.52.116.49)  114.573 ms  113.965 ms  117.141 ms
 MPLS Label=691873 CoS=0 TTL=1 S=0
 MPLS Label=17 CoS=0 TTL=1 S=1
 2  202.127.69.34 (202.127.69.34)  113.768 ms  113.763 ms  113.731 ms
 3  202.84.148.113 (202.84.148.113) [AS  4637]  114.759 ms  117.956 ms  
115.796 ms
 4  202.84.141.13 (202.84.141.13) [AS  4637]  181.873 ms 202.84.141.169 
(202.84.141.169) [AS  4637]  181.618 ms  182.688 ms
 5  202.84.253.82 (202.84.253.82) [AS  4637]  181.949 ms 202.40.149.226 
(202.40.149.226) [AS  4637]  183.194 ms 202.84.253.82 (202.84.253.82) [AS  
4637]  201.282 ms
 6  154.54.10.133 (154.54.10.133) [AS  174]  181.055 ms  181.100 ms  
181.065 ms
 7  154.54.27.117 (154.54.27.117) [AS  174]  175.410 ms  182.956 ms 
154.54.3.69 (154.54.3.69) [AS  174]  175.176 ms
 8  154.54.45.161 (154.54.45.161) [AS  174]  212.531 ms 154.54.44.85 
(154.54.44.85) [AS  174]  202.470 ms  187.361 ms
 9  154.54.42.78 (154.54.42.78) [AS  174]  195.585 ms  195.812 ms 
154.54.42.66 (154.54.42.66) [AS  174]  211.713 ms
10  154.54.30.161 (154.54.30.161) [AS  174]  235.896 ms  216.173 ms  
211.246 ms
11  154.54.28.129 (154.54.28.129) [AS  174]  233.516 ms  225.413 ms  
225.551 ms
12  154.54.24.221 (154.54.24.221) [AS  174]  236.432 ms  236.701 ms  
236.595 ms
13  154.54.40.109 (154.54.40.109) [AS  174]  273.564 ms  279.452 ms  
248.212 ms
14  154.54.46.33 (154.54.46.33) [AS  174]  248.098 ms  247.802 ms  248.084 
ms
15  * * *

Discongruity between RIB and FIB like this, and the hijack being a
more-specific of a /16, is a typical sign of BGP 'optimisers'.

I recommend you reach out to AUSNOG and APOPS and hope someone there
knows someone at Telstra Hong Kong.

More thoughts on BGP optimisers: http://seclists.org/nanog/2017/Aug/318

Kind regards,

Job

Re: BGP Hijack/Sickness with AS4637

[Alain Hebert]

    Well,

    None beside they're advertising a fake route of part of a MIT 
subnet using ASNs I care about.  (Which include GTT and MIT)


    Right now their getting it from their outfit in JP which do not 
have a LG, and we cannot find any other crumbs in most LG found on 
lookingglass.org.


    Without any cooperation from the only place we can see it, there 
isn't much we can do.



    PS; Might be a generational gap, but in the olden days we used to 
be able to get cooperation from other operators.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 05/31/18 09:58, Phil Lavin wrote:

What is the relationship of 103.97.52.2 (Colocation Australia - Japan) to you? 
Is this, for example, a peering over an IX? If so, did you learn the route from 
route servers or do you peer directly with them?


Phil

-Original Message-
From: NANOG  On Behalf Of Alain Hebert
Sent: 31 May 2018 14:50
To: nanog@nanog.org
Subject: Re: BGP Hijack/Sickness with AS4637

      Hi,

      Well bad news on the ColoAU front, they refused to cooperate.

      We'll pushback thru our GTT accounts...  But I'm running out of ideas.

      If anyone has any good ideas how to proceed at this point feel free to 
share =D.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 05/29/18 16:31, Chris Conn wrote:

Hello,

I am the contact for AS16532.

We never announced nor are we currently advertising this prefix as we
are not a transit AS for anyone.  As well, it seems to appear and
disappear from AS63956 looking glass.  According to that LG, the route
changed 6d ago, and is *still currently visible* at this very moment;

https://lg.coloau.com.au/

Command: show route 18.29.238.0 protocol bgp table
vrf-international.inet.0 active-path

vrf-international.inet.0: 696764 destinations, 2288960 routes (696480
active, 0 holddown, 103994 hidden)
+ = Active Route, - = Last Active, * = Both

18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2
AS path: 4637 3257 29909 16532 16532 16532
16532 I, validation-state: unverified


AS16532 is not announcing this prefix.  We have a strict prefix-list that is 
applied to all sessions.  As well, AS29909 is filtering us using our announced 
AS-SETS/RPSL to avoid us the ability to do anything dumb.  And lastly, our 
announcements are being filtered by AS3257 as we are required to provide them 
via LOA.

There is still something wrong somewhere that is injecting this path, anyone 
have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS 
path?

I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would
change anything, as I am not seeing this prefix in their route-server

pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol
bgp active-path

inet.0: 691667 destinations, 11752983 routes (691665 active, 1
holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

18.29.0.0/16   *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 
213.200.87.23
AS path: 3257 174 3 I, validation-state: unverified
  > to 141.136.111.13 via xe-1/0/0.0

{master}
pub...@route-server.as3257.net-re0>


{master}
pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol
bgp | find 16532

Pattern not found
{master}



So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can 
find.


Chris Conn
AS16532




-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tom Paseka
via NANOG
Sent: Friday, May 25, 2018 6:01 PM
To: Nikolas Geyer 
Cc: NANOG list 
Subject: Re: BGP Hijack/Sickness with AS4637

This looks like a route that has been cached by some ISPs/routers even though a 
withdrawal has actually happened.

If you actually forward packets a long the path, you'll see its not following 
the AS Path suggested, instead the real route that it should be.
Bouncing your session with 4637 would likely clear this.

-Tom

On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer  wrote:


Greetings!

Actually, what you have provided below shows the exact opposite. It
shows ColoAU have received the route from 4637 who have received it
from 3257 who have received it from 29909 who have received it from
16532 who originated it. It infers nothing about who 16532 found the route to 
come from.

It is evident that GTT are advertising that route to Telstra Global
:)

Regards,
Nik.


  And I'm pretty sure AS3257 (GTT ) is in the same boat as
us, as

they're not the one advertising those routes to AS4637

  AS16532 found it to come from AS4637 as you can see

Re: BGP Hijack/Sickness with AS4637

[Alain Hebert]

    Hi,

    Well bad news on the ColoAU front, they refused to cooperate.

    We'll pushback thru our GTT accounts...  But I'm running out of ideas.

    If anyone has any good ideas how to proceed at this point feel free 
to share =D.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 05/29/18 16:31, Chris Conn wrote:

Hello,

I am the contact for AS16532.

We never announced nor are we currently advertising this prefix as we are not a 
transit AS for anyone.  As well, it seems to appear and disappear from AS63956 
looking glass.  According to that LG, the route changed 6d ago, and is *still 
currently visible* at this very moment;

https://lg.coloau.com.au/

Command: show route 18.29.238.0 protocol bgp table vrf-international.inet.0 
active-path

vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 
holddown, 103994 hidden)
+ = Active Route, - = Last Active, * = Both

18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2
   AS path: 4637 3257 29909 16532 16532 16532 16532 I, 
validation-state: unverified


AS16532 is not announcing this prefix.  We have a strict prefix-list that is 
applied to all sessions.  As well, AS29909 is filtering us using our announced 
AS-SETS/RPSL to avoid us the ability to do anything dumb.  And lastly, our 
announcements are being filtered by AS3257 as we are required to provide them 
via LOA.

There is still something wrong somewhere that is injecting this path, anyone 
have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS 
path?

I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change 
anything, as I am not seeing this prefix in their route-server

pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp 
active-path

inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 
hidden)
+ = Active Route, - = Last Active, * = Both

18.29.0.0/16   *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 
213.200.87.23
   AS path: 3257 174 3 I, validation-state: unverified
 > to 141.136.111.13 via xe-1/0/0.0

{master}
pub...@route-server.as3257.net-re0>


{master}
pub...@route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp | find 
16532

Pattern not found
{master}



So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can 
find.


Chris Conn
AS16532




-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tom Paseka via NANOG
Sent: Friday, May 25, 2018 6:01 PM
To: Nikolas Geyer 
Cc: NANOG list 
Subject: Re: BGP Hijack/Sickness with AS4637

This looks like a route that has been cached by some ISPs/routers even though a 
withdrawal has actually happened.

If you actually forward packets a long the path, you'll see its not following 
the AS Path suggested, instead the real route that it should be.
Bouncing your session with 4637 would likely clear this.

-Tom

On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer  wrote:


Greetings!

Actually, what you have provided below shows the exact opposite. It
shows ColoAU have received the route from 4637 who have received it
from 3257 who have received it from 29909 who have received it from
16532 who originated it. It infers nothing about who 16532 found the route to 
come from.

It is evident that GTT are advertising that route to Telstra Global :)

Regards,
Nik.


 And I'm pretty sure AS3257 (GTT ) is in the same boat as us,
as

they're not the one advertising those routes to AS4637

 AS16532 found it to come from AS4637 as you can see from this
ColoAU

LG output below


- https://lg.coloau.com.au/

vrf-international.inet.0: 696533 destinations, 2248101 routes
(696249

active, 0 holddown, 103835 hidden)

+ = Active Route, - = Last Active, * = Both

18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from

103.97.52.2

   AS path: 4637 3257 29909 16532 16532 16532
16532

I, validation-state: unverified

--
-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

Re: BGP Hijack/Sickness with AS4637

[Tom Paseka via NANOG]

This looks like a route that has been cached by some ISPs/routers even
though a withdrawal has actually happened.

If you actually forward packets a long the path, you'll see its not
following the AS Path suggested, instead the real route that it should be.
Bouncing your session with 4637 would likely clear this.

-Tom

On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer  wrote:

> Greetings!
>
> Actually, what you have provided below shows the exact opposite. It shows
> ColoAU have received the route from 4637 who have received it from 3257 who
> have received it from 29909 who have received it from 16532 who originated
> it. It infers nothing about who 16532 found the route to come from.
>
> It is evident that GTT are advertising that route to Telstra Global :)
>
> Regards,
> Nik.
>
> >
> > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as
> they're not the one advertising those routes to AS4637
> >
> > AS16532 found it to come from AS4637 as you can see from this ColoAU
> LG output below
> >
> >
> > - https://lg.coloau.com.au/
> >
> > vrf-international.inet.0: 696533 destinations, 2248101 routes (696249
> active, 0 holddown, 103835 hidden)
> > + = Active Route, - = Last Active, * = Both
> >
> > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from
> 103.97.52.2
> >   AS path: 4637 3257 29909 16532 16532 16532 16532
> I, validation-state: unverified
> >
> > --
> > -
> > Alain Hebertaheb...@pubnix.net
> > PubNIX Inc.
> > 50 boul. St-Charles
> > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> > Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
> >
>

Re: BGP Hijack/Sickness with AS4637

[Nikolas Geyer]

Greetings!

Actually, what you have provided below shows the exact opposite. It shows 
ColoAU have received the route from 4637 who have received it from 3257 who 
have received it from 29909 who have received it from 16532 who originated it. 
It infers nothing about who 16532 found the route to come from. 

It is evident that GTT are advertising that route to Telstra Global :)

Regards,
Nik.

> 
> And I'm pretty sure AS3257 (GTT ) is in the same boat as us, as 
> they're not the one advertising those routes to AS4637
> 
> AS16532 found it to come from AS4637 as you can see from this ColoAU LG 
> output below
> 
> 
> - https://lg.coloau.com.au/
> 
> vrf-international.inet.0: 696533 destinations, 2248101 routes (696249 active, 
> 0 holddown, 103835 hidden)
> + = Active Route, - = Last Active, * = Both
> 
> 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from 103.97.52.2
>   AS path: 4637 3257 29909 16532 16532 16532 16532 I, 
> validation-state: unverified
> 
> -- 
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>