Re: AS 3356 (Level 3) -- Community 3356:666

[Patrick Schultz]

$ whois AS3356 -h rr.level3.net | grep -E 'blackhol|666'
remarks:   3356:666 - Peer route
remarks:   3356: - blackhole (discard) traffic

--
Patrick

Am 04.08.2021 um 15:28 schrieb Sriram, Kotikalapudi (Fed) via NANOG:

There is an old NANOG thread from 2005 that said AS 3356 (Level 3) were 
applying 3356:666 to indicate Peer route:
https://archive.nanog.org/mailinglist/mailarchives/old_archive/2005-12/msg00280.html
Also, see: https://onestep.net/communities/as3356/

Now network operators commonly use ASN:666 for BGP Blackholing Community.
(ASN = the operator's AS number)
See, for example, https://www.he.net/adm/blackhole.html

Does anyone know if AS 3356 has changed how it uses 3356:666?
I.e., is it known if they now use it for Blackholing Community?

Thank you.

Sriram
 

Re: [nanog] Famous operational issues

[Patrick Schultz]

opening the link currently gives me a HTTP 500 error, very fitting :)

Am 12.06.2021 um 04:42 schrieb Dan Mahoney:
> I only just now found this thread, so I'm sorry I'm late to the party, but 
> here, I put it on Medium.
>
> https://gushi.medium.com/the-worst-day-ever-at-my-day-job-beff7f4170aa
>
>> On Mar 12, 2021, at 10:07 PM, Mark Tinka  wrote:
>>
>> Hardly famous and not service-affecting in the end, but figured I'd share an 
>> incident from our side that occurred back in 2018.
>>
>> While commissioning a new node in our Metro-E network, an IPv6 
>> point-to-point address was mis-typed. Instead of ending in /126, it ended in 
>> /12. This happened in Johannesburg.
>>
>> We actually came across this by chance while examining the IGP table of 
>> another router located in Slough, and found an entry for 2c00::/12 floating 
>> around. That definitely looked out of place, as we never carry parent blocks 
>> in our IGP.
>>
>> Running the trace from Slough led us back to this one Metro-E device in 
>> Jo'burg.
>>
>> It took everyone nearly an hour to figure out the typo, because for all the 
>> laser focus we had on the supposed link of the supposed box that was 
>> creating this problem, we all overlooked the fact that the /12 configured on 
>> the point-to-point link was
>> actually supposed to have been a /126.
>>
>> The reason this never caused a service problem was because we do not 
>> redistribute our IGP into BGP (not that anyone should). And even if we did, 
>> there are a ton of filters and BGP communities on all devices to ensure a 
>> route such as that would have
>> never made it out of our AS.
>>
>> Also, the IGP contains the most specific paths to every node in our network, 
>> so the presence of the 2c00::/12 was mostly cosmetic. It would have never 
>> been used for routing decisions.
>>
>> Mark.
>

Re: BGP route hijack by AS10990

[Patrick Schultz]

I'd like to direct you to Job's writeup on this :) 
https://mailman.nanog.org/pipermail/nanog/2017-August/191897.html
While these "optimizers" CAN be beneficial to the individual operator, they're 
apparently used incorrectly in some instances.
Telia should've filtered, that's for sure. But the leak shouldn't have occured 
in the first place.

Am 30.07.2020 um 20:09 schrieb Florian Brandstetter:
> Never read something that silly, bgp optimizers are perfectly fine
> and every network operator is well within the right to run optimizers,
> you should much more ask Telia as to why they accepted the prefixes,
> and EVEN MORE ask the operator of 7219 for what specific reason they
> are blowing out their full table to 1299. Anyone with a sane mind has
> export filters where a specific community or tag serves as some kind
> of "do advertise" sign, as opposed to announcing anything BUT external.
> 
> May I know the specific reason for such poor attempt of shifting
> responsibility for this incident to bgp optimizers instead of those
> who clearly don't have a single clue about proper filtering policies?
> 
> -- 
> Greetings,
> 
> Florian Brandstetter
> Chief Executive Officer
> SquareFlow Corporation
> www.squareflow.net
> 
> Confidential: Please be advised that the information contained in this
> email message, including all attached documents or files, is privileged
> and confidential and is intended only for the use of the individual or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
> 
> On 2020-07-30 19:09, Patrick Schultz wrote:
>> so, bgp optimizers... again?
>>
>> -- 
>> Patrick
>> Am 30.07.2020 um 18:58 schrieb Töma Gavrichenkov:
>>
>>> Peace,
>>>
>>> On Thu, Jul 30, 2020, 5:48 AM Clinton Work 
>>> wrote:
>>>
>>>> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT
>>>> until 20:23 MDT.   Anybody else have problems with that.
>>>
>>> Here's what we discovered about the incident.  Hope that brings some
>>> clarity.
>>>
>>> https://radar.qrator.net/blog/as10990-routing-optimization-tale
>>>
>>> -- 
>>> Töma
>>>
>>>>

Re: BGP route hijack by AS10990

[Patrick Schultz]

so, bgp optimizers... again?

-- 
Patrick

Am 30.07.2020 um 18:58 schrieb Töma Gavrichenkov:
> Peace,
>
> On Thu, Jul 30, 2020, 5:48 AM Clinton Work  > wrote:
>
> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 
> 20:23 MDT.   Anybody else have problems with that.
>
>
> Here's what we discovered about the incident.  Hope that brings some clarity.
>
> https://radar.qrator.net/blog/as10990-routing-optimization-tale 
> 
>
> --
> Töma
>

Re: idiot reponse

[Patrick Schultz]

I've also seen employees leaving companies and their addresses being rerouted 
to the support mailbox.

-- 
Patrick

Am 27.02.2020 um 01:25 schrieb Mark Rousell:
> On 26/02/2020 16:24, Randy Bush wrote:
>> act...@nanog.org seems to no longer exist.  how should i be whining
>> about the following?
>>
>> From: Electric Forest Festival 
>> Subject: Forest HQ Has Received Your Message: Re: Hi-Rise Building Fiber 
>> Suggestions
>> To: ra...@psg.com
>> Date: Wed, 26 Feb 2020 16:15:25 +
>>
>>   Electric Forest 2020 will take place on June 25-28, 2020.   Forest HQ has 
>> received your email. Help save precious resources by reviewing the 
>> information below and looking up common questions in The Forest Frequently 
>> Asked Questions: Experience.ElectricForestFestival.com  Please contact 
>> Festival Ticketing Support at 855-279-6941 for all issue regarding your 
>> purchase or for account troubleshooting.  Electric Forest is sold out. Lyte 
>> is the only HQ endorsed way to get passes now that it’s sold out.  To know 
>> when all things Electric Forest 2020 are happening sign up to the EF 
>> Newsletter.  Happy Forest!  
>
> This (or what it appears to be) is happening on an increasing number of mail 
> lists. It's not many but it's there I don't know who is behind it or why, but 
> it's an increasing annoyance.
>
> This is a quick summary of what seems to be happening:
> (1) A legitimate company's or organisation's helpdesk email address is signed 
> up to a mail list like this one.
> (2) Every time someone posts to the list, they receive an automated 
> notification from the helpdesk.
> (3) On mail lists where DMARC mitigation is in effect, the notification comes 
> back to the mail list.
> (4) A consistent pattern is that the helpdesk staff seem utterly incapable of 
> unsubscribing themselves from the list. They always seem to need to be 
> unsubscribed by a list admin.
>
> The key question to my mind is how do these helpdesks get signed up at all? 
> Presumably it's not the helpdesk staff themselves signing them up. It would 
> appear that someone, somewhere has found a vulnerability in Mailman (as far 
> as I can recall I've only
> seen this on Mailman lists) and is intentionally signing up legitimate 
> company helpdesks to mail lists.
>
> Lists with an active admin/mod can fix the problem quickly by unsubscribing 
> the helpdesk.
>
> Is it an attempted (rather feeble) DoS on the mail lists affected, on the 
> concept of a mail list, or on the companies affected? I don't know. I can't 
> see any real point to it. But it's happening.
>
>
>
> -- 
> Mark Rousell

Re: Geo locate change for IP ?

[Patrick Schultz]

Hey Jason,
try the geo database providers first: 
http://thebrotherswisp.com/index.php/geo-and-vpn/

-- 
Patrick

Am 08.01.2020 um 18:53 schrieb JASON BOTHE via NANOG:
> Hi guys
>
> Something odd has happened and I’m not sure how to sort. One of our public 
> prefixes, 205.174.3.0/24 issued from ARIN has suddenly had its geo changed 
> and now everyone accessing the internet from it is showing up as a UK IP, 
> London specifically. We announce this and every other prefix we have out all 
> of our peers globally and are pretty mystified on how this happened and how 
> to resolve. Any help is appreciated. 
>
> Thanks
>
> Jason 

Re: Level(3) DNS Spoofing All Domains

[Patrick Schultz]

Just to weigh in: Here in Germany, the largest internet provider (Deutsche 
Telekom) did the same thing.
It's basically just a "search guide", it redirects you to a search page and 
assumes you just had a typo in the URL.

Telekom stopped doing that in April, after a user reported them to the district 
attorney for supposed data manipulation, a misdemeanor.

Am 18.11.2019 um 18:45 schrieb Marshall, Quincy:
> This is mostly informational and may have already hit this group. My 
> google-foo failed me if so.
> 
>  
> 
> I discovered that the CenturyLink/Level(3) public DNS (4.2.2.2, etc) are 
> spoofing all domains. If the hostname begins with a “w” and does not exist in 
> the authoritative zone these hosts will return two Akamai hosts.
> 
>  
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.gov @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.net @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.com @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.org @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
>  
> 
> My apologies if this is old news.
> 
>  
> 
> *Lawrence Q. Marshall*
> 
>  
> 
> 
> 
> ---
> This email has been scanned for email related threats and delivered safely by 
> Mimecast.
> For more information please visit http://www.mimecast.com 
> 
> ---

Re: Intermittent "bad gateway"

[Patrick Schultz]

citing https://www.cloudflarestatus.com/
>Cloudflare has implemented a fix for this issue and is currently monitoring 
>the results

Seems to be a CloudFlare hiccup.

Am 02.07.2019 um 16:16 schrieb Stephen Satchell:
> Are we having another BGP problem this morning?

Re: Google weird routing?

[Patrick Schultz]

Seems to be more end-user oriented rather than targeted at netadmins.
There's no real contact to the GeoIP team besides the peering portal and that 
form, except maybe the NOC. (at least none I found yet)

Am 23.05.2019 um 23:23 schrieb Ross Tajvar:
> Yeah, that's honestly a pretty crappy form. No room for an explanation, no 
> individual contact, and an ETR of a month. I'm surprised there's not a better 
> way to address issues like this 
> 
> On Thu, May 23, 2019, 5:13 PM Matt Harris  <mailto:m...@netfire.net>> wrote:
> 
> On Thu, May 23, 2019 at 4:01 PM Patrick Schultz  
> wrote:
> 
> https://support.google.com/websearch/contact/ip/
> 
> 
> Thanks!  
> 
> Giving that a shot.  It's still loading www.google.com 
> <http://www.google.com> though if I try to hit it in a browser (not 
> redirecting to a different language/CCTLD specific site though) so I had to 
> put that in along with that I'm in the US, not sure
> that whoever sees that form will understand my issue and there's no 
> freeform comments section to mention "but it's loading from India!" 
> 

Re: Google weird routing?

[Patrick Schultz]

https://support.google.com/websearch/contact/ip/

Am 23.05.2019 um 22:55 schrieb Matt Harris:
> On Thu, May 23, 2019 at 3:24 PM Filip Hruska  > wrote:
>
> Google maintains their own GeoIP database. If you peer with them and have 
> access to the peering portal, you can correct the location yourself.
> Otherwise they have a public form somewhere.
>
> --- Filip
>
>
> Googling around a bit does not yield results for that form... any chance 
> anyone here has a link to that?  Would be much appreciated!  
>
> Thanks,
> Matt
>  

Re: Widespread Firefox issues

[Patrick Schultz]

or use the hotfix without restarting: 
https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi

Am 04.05.2019 um 19:46 schrieb Randy Bush:
>>> to do it, i have to start ffox.  and 100 tabs will open and
>>> javascript will flood in.
> recipe
>   - turn off internet connectivity
>   - start firefox
>   - `kill -s sigkill` it
>   - restart it, do not restore sesstion
>   - turn internet back on
>   - go to prefs / privacy and enable studio
>   - wait until `about:studies` shows you got the two updates
>   - allow sessions to restart
>
> randy

Re: Retarus (AS 48328)

[Patrick Schultz]

Hi Martin,
the only address I can point you at is "support at retarus dot com".
We once had to contact them about a SMTP problem and this was the only working 
contact.

Best,
Patrick

Am 04.05.17 um 06:31 schrieb Martin Hannigan:
> I hate to do this, but I have exhausted _all of my sources of data
> including the SOA (points at VRSN) and domain name contact addresses for:
> 
> Registrant Name: Retarus GmbH
> Registrant Organization: Retarus GmbH
> Registrant Street: Aschauerstrasse 30
> Registrant City: Muenchen
> Registrant State/Province: Bav
> Registrant Postal Code: 81549
> Registrant Country: DE
> 
> I worked backwards from a domain name of RMX.DE. I don't know what the
> distinction is other than this name perhaps being an operational domain for
> their mail security services.
> 
> If someone has a pointer or can do an offline introduction to someone in
> tech-ops or networking there, I'd appreciate it.
> 
> Best,
> 
> -M<
>