Re: BGP Hijack/Sickness with AS4637
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
> >
>
FW: BGP Hijack/Sickness with AS4637
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: gmail.com contact
: -Original Message- From: Markus [mailto:unive...@truemetal.org] Sent: 26 septembre 2013 07:37 To: nanog@nanog.org Subject: gmail.com contact Hi list, We had a user account compromised a couple of days ago, spam naturally, and now the IP is blocked for delivering to gmail.com. We've completed the delivery problem form at support.google.com but if there is any way to speed up the process our customer and we would appreciate it. Could anyone put me in touch with a gmail.com contact? Hi, Good luck. I have been going through the regular channels for over a month, to try and de-list a server that has not sent an email for over a month to Google or anyone for that matter, and no such luck. If you get a hold of somebody, pls forward me contact info. I am trying again this morning, I will do the same for you. Cheers, Chris
AS174 - cogent - someone without denial syndrome please
Any BGP admins from AS174 monitoring NANOG? I would appreciate a quick email exchange regarding access to www.cogentco.com from some prefixes. Thanks, Chris
Re: Facebook broken over v6?
On 2013-06-08 15:29, Chris Conn wrote: It's affecting anyone running dual stack, as the server responds, hangs, times out and then it tries again on v6. At least in the latest FF and Safari browsers, I've not tried chrome. I've cc'd this over to Nanog, as I've not seen anything about it there, and I'm sure others are seeing it. www.v6.facebook.com works fine as a workaround for the time being. -- Indeed, I have seen this behaviour for at least a week. It seems to somehow be related to geo-located DNS (akamai?) since the timeouts and RSTs I see in the traffic are from IPv6 akamai servers, not facebook itself. I tried de-peering from a number of networks to try and isolate it and it was not transit-specific. I stopped questioning my network when I saw a thread on Sixxs and tunnelbroker about this very issue. Hopefully it won't persist as right now as having Facebook intermittently connect is likely hurting deployment slightly. Chris
IPv6 Cogent customers
Hello, Any single-homed or more IPv6 AS174 customers willing to take a 5 minute test for me? Please contact me off-list. We are not single homed to them but we have a particular destination that is having issues, and the funky part is that any outbound traffic over the Cogent transit is just bezerk. TCP SYN packets never reach the remote end. Return traffic, even when forced over Cogent however, is fine. I can force outbound traffic to flow over two other transit providers, and all is kosher so long as I never use AS174 to try and _get_ there. Cogent is blaming Level3 just because they appear in the traceroute, therefore I would like if possible a third party to help me since Cogent doesn't seem inclined to do anything other than ping. Thanks in advance and sorry for the noise, Chris
Re: cloudmark?
On 2013-04-09 10:27, Chris Conn wrote: Hi, rant it seems that many large providers are using cloudmark services. As far as I can tell: their policy is unclear, they can hardly be reached, mails to support are bouncing (delayed, then bounce). yes, the mailserver from one of our customers was blocked and this was OK and rightful, because they had a problem (cracked account). After the problem was resolved we started removing their IPv4 address from blacklists and almost all lists removed the ban immediately. cloudmark CSI service (reset request form) wants a form to be filled ... and they claim that they send out an email ... but it doesn't make its way to my inbox (no, no filters ...) and support can't be reached. Where are the good old times when the 'net was controlled by techs and not by lawyers? I can't recommend cloudmark. /rant Your experience does not mirror mine at all. I have less than 30 minutes of wait time for any support case, and they are few and far between. Reliability is high and FP rate is low. I have no idea what your reference to lawyers pertains to, however the only issue we have ever had was for them to take our money when we renewed for the umpteenth time. Maybe they cater to smaller providers more efficiently. Chris
Re: IP Address Management IPAM software for small ISP
looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. Nobody uses HaCI?
Earthlink/RIR1.ORG admin with a clue?
Hello, If a Earthlink/rir1.org hosting admin would care to contact me off-list since it appears the abuse department at earthlink does not understand what hosting a phishing site means. I am being asked for logs to prove something, yet the URL I supply which clearly brings someone to a phishing site is apparently not proof. Thanks, Chris Conn B2B2C.ca
SORBS?!
Hello, Is anyone from SORBS still listening? We have a few IP addresses here and there that are listed, one in particular that has been for a spam incident from over a year ago. The last spam date is 03/05/2011 according to their lookup tools. We don't have access to their Net Manager even if our ARIN POC corresponds to the account on their system we opened a while ago. We use their ISP feedback form and never get any responses back. Is SORBS still relevant and functional? Sincerely, Chris Conn B2B2C.ca
Re: SORBS?!
On 2012-04-04 17:33: Hi, Actually knowing Chris, and his outfit, that 18k request seems unwarranted :( As for SORBS, they have a ticket system at http://support.sorbs.net/ which use the same username/password as https://www.us.sorbs.net. You can follow up there with your ticket #, if their robot is being a bit too fascist. ( ecarbonel was the guy that help us in our case ) PS: The ticketing system is not that fast, so be patient. /wave Chris Hi Alain! The 18K thing was another operator, but we have not had much luck. I will give my attention to the ticket for now and wait until something happens. Its not a crucial issue since from what I can tell its mostly a cosmetic thing (and a bit of a managerial pain to have to explain the implications to a customer). I have no beef with SORBS, we even rsync their zone on our DNS servers so we can provide faster access to it to our customers that might use it. However recently, getting listing action seems to fall into a void. Cheers, Chris
Re: SORBS contact?
Hello, Thank you to all that answered, all helpful info. Surprisingly minutes after my Nanog post, a couple of my tickets saw action and the /24 was finally removed a short while later. Thanks again, Chris
SORBS contact?
Hello, We have opened a number of tickets in the SORBS DUHL system to notify them of the use of a former dialup /24 for static assignments to no avail. Anyone from SORBS reading this? Thank you, Chris Conn B2B2C.ca
Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
On 27/01/11 08:17 -0600, Jack Bates wrote: On 1/27/2011 12:57 AM, Frank Bulk wrote: Have you looked at D-Link's DIR-825? It has most of the things you're looking for. The DIR-655 is a more affordable option. Haven't had the chance to look at that one. Will check it out. In regards to (2), is it even possible to do DHCPv6-PD on with a SLAAC WAN? It had better be, as IOS 12.2 SRE only supports SLAAC + DHCPv6-PD. Most of the Cisco documentation I've seen, says that is their beautiful layout. No more proxyarp/nd. Instead, assign a /64 to each subinterface, perform SLAAC, then hand out prefixes via DHCPv6-PD if someone needs a prefix. The DIR-825(Rev B) running firmware 2.05NA does. From the status screen: IPv6 Connection Type : Autoconfiguration (SLAAC/DHCPv6) Network Status : Connected WAN IPv6 Address : 2610:b8:0:234:218:e7ff:fef8:66dc/64 IPv6 Default Gateway : fe80::c67d:4fff:fed6:5401 LAN IPv6 Address : 2610:b8:100f:1:218:e7ff:fef8:66db/64 LAN IPv6 Link-Local Address : fe80::218:e7ff:fef8:66db/64 Primary IPv6 DNS Server : 2610:b8:0:3:215:c5ff:fef3:f9c8 Secondary IPv6 DNS Server :2610:b8:0:3:215:c5ff:feee:9448 DHCP-PD : Enabled IPv6 network assigned by DHCP-PD : 2610:b8:100f::/48 The latest firmware has fairly good support, but is lacking configurable v6 firewall settings. I haven't done any firewall testing yet, but I'd imagine all incoming v6 connections are blocked. The Emulator hasn't been updated yet to reflect the options in the new firmware, but this should give you an idea of what the configuration looks like: http://www.support.dlink.com/emulators/dir825_revB/203NA/adv_link_local.html The DIR-615 should have similar support, but I haven't upgraded it yet. Hello, As for the DIR-615, it should, but it doesn't...At least, the E3/E4 revisions I had. I contacted D-LINK support and was able to get a beta build that seems promising. But DHCP-PD over PPPoE works relatively well, minus a couple of little features. I am hoping to have that hammered out soon, as the 615 is a capable little sub-50$ home CPE. But D-Link engineering seems receptive to my observations. I have to check the state of the firewalling in it too ;) Chris
Cogeco MX/SMTP administrator?
Hello, Could a Cogeco MX/SMTP admin contact me off list please, we seem to be suffering from the same fate as these individuals; http://www.dslreports.com/forum/r24888256-Email-sent-to-AOL-is-timing-out Thanks, Chris Conn B2B2C.ca
