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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 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;
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
public@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} public@route-server.as3257.net-re0>
{master} public@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-bounces@nanog.org] On Behalf Of Tom Paseka via NANOG Sent: Friday, May 25, 2018 6:01 PM To: Nikolas Geyer <nik@neko.id.au> Cc: NANOG list <nanog@nanog.org> 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 <nik@neko.id.au> 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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
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 <nanog-bounces@nanog.org> 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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 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;
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
public@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} public@route-server.as3257.net-re0>
{master} public@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-bounces@nanog.org] On Behalf Of Tom Paseka via NANOG Sent: Friday, May 25, 2018 6:01 PM To: Nikolas Geyer <nik@neko.id.au> Cc: NANOG list <nanog@nanog.org> 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 <nik@neko.id.au> 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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 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 <nanog-bounces@nanog.org> 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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 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;
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
public@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} public@route-server.as3257.net-re0>
{master} public@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-bounces@nanog.org] On Behalf Of Tom Paseka via NANOG Sent: Friday, May 25, 2018 6:01 PM To: Nikolas Geyer <nik@neko.id.au> Cc: NANOG list <nanog@nanog.org> 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 <nik@neko.id.au> 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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
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
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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 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
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
On Thu, May 31, 2018 at 02:40:06PM +0000, 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
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. xxxx@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: <Active Ext> 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 <http://coloau.com.au> Brad Hooper / Network Architect brad@coloau.com.au <mailto:brad@coloau.com.au>/ +61 7 3106 3810 Colocation Australia Pty Ltd http://coloau.com.au Facebook <https://facebook.com/coloau> Twitter <https://twitter.com/coloau> skype <skype:coloau-brad?call> On 01/06/18 06:36, Job Snijders wrote:
On Thu, May 31, 2018 at 02:40:06PM +0000, 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
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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/31/18 14:36, Job Snijders wrote:
On Thu, May 31, 2018 at 02:40:06PM +0000, 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
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.
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.
participants (6)
-
Alain Hebert -
Brad Hooper -
Job Snijders -
Job Snijders -
Mark Tinka -
Phil Lavin