Re: whois server

[Tom Paseka via NANOG]

the memo:
https://web.archive.org/web/20230523204911/http://www.geektools.com/

On Thu, Jul 13, 2023 at 1:27 PM Randy Bush  wrote:

> ```
> % host whois.geektools.com
> Host whois.geektools.com not found: 3(NXDOMAIN)
> ```
>
> i guess i missed the memo :(
>
> randy
>

Re: Allegedly Tier 1s in Wikipedia

[Tom Paseka via NANOG]

Paying for "peering", doesn't stop you being a tier-1.

Being a Tier-1 means you are "transit free" (technical term, not
commercial). No one is transiting your routes to other Tier-1 providers.

On Mon, Aug 1, 2022 at 11:04 AM Rubens Kuhl  wrote:

> Hi.
>
> Looking at the article on Tier 1 networks, I found one that I know for a
> fact that pays for some transit (12956) and some I usually don't associate
> to Tier 1 status, like 6762.
>
> Is there a list of such transit relationships by those bragging about
> being Tier 1 ?
>
>
> Rubens
>

Re: AT is suspending broadband data caps for home internet customers due to coronavirus

[Tom Paseka via NANOG]

I am not worried. Residential ISPs are usually at peak in the late evening.
They have loads of capacity during the day.

On Thu, Mar 12, 2020 at 3:35 PM Jared Mauch  wrote:

> I do worry if the broadband networks have the capacity. WFH traffic is
> usually different from regular consumer traffic. My neighbors were telling
> me about the mandatory work from home they had today and how the VPN
> struggled to work.
>
> To those upgrading those things, keep at it. You will get there.
>
> Sent from my iCar
>
> > On Mar 12, 2020, at 6:29 PM, Sean Donelan  wrote:
> >
> > 
> > The first data cap waiver I've seen due to coronavirus.  I expect other
> ISPs to quickly follow.
> >
> >
> https://www.vice.com/en_us/article/v74qzb/atandt-suspends-broadband-usage-caps-during-coronavirus-crisis
> >
> > AT is the first major ISP to confirm that it will be suspending all
> broadband usage caps as millions of Americans bunker down in a bid to slow
> the rate of COVID-19 expansion. Consumer groups and a coalition of Senators
> are now pressuring other ISPs to follow suit.
>

Re: China’s Slow Transnational Network

[Tom Paseka via NANOG]

Most of the performance hit is because of commercial actions, not
censorship.

When there is a tri-opoly, with no opportunity of competition, its easily
possible to set prices which are very different than market conditions.
This is what is happening here.

Prices are set artificially high, so their interconnection partners wont
purchase enough capacity. additionally, the three don't purchase enough to
cover demand for their own network. Results in congestion.

On Mon, Mar 2, 2020 at 2:49 PM Pengxiong Zhu  wrote:

> You seem to be implying that you don't believe/can't see the GFW
>
>
> No, that's not what I meant. I thought mandatory content filtering at the
> border means traffic throttling at the border, deliberately or accidentally
> rate-limiting the traffic, now
> I think he was referring to GFW and the side effect of deep packet
> inspection.
>
> In fact, we designed a small experiment to locate the hops with GFW
> presence, and then try to match them with the bottleneck hops. We found
> only in 34.45% of the cases, the GFW hops match the bottleneck hops.
>
> Best,
> Pengxiong Zhu
> Department of Computer Science and Engineering
> University of California, Riverside
>
>
> On Mon, Mar 2, 2020 at 1:13 PM Matt Corallo  wrote:
>
>> > find out direct evidence of mandatory content filtering at the border
>>
>> You seem to be implying that you don't believe/can't see the GFW, which
>> seems surprising. I've personally had issues with traffic crossing it
>> getting RST'd (luckily I was fortunate enough to cross through a GFW
>> instance which was easy to avoid with a simple iptables DROP), but its
>> also one of the most well-studied bits of opaque internet censorship
>> gear in the world. I'm not sure how you could possibly miss it.
>>
>> Matt
>>
>> On 3/2/20 2:55 PM, Pengxiong Zhu wrote:
>> > Yes, we agree. The poor transnational Internet performance effectively
>> > puts any foreign business that does not have a physical presence (i.e.,
>> > servers) in China at a disadvantage.
>> > The challenge is to find out direct evidence to prove mandatory content
>> > filtering at the border, if the government is actually doing it.
>> >
>> > Best,
>> > Pengxiong Zhu
>> > Department of Computer Science and Engineering
>> > University of California, Riverside
>> >
>> >
>> > On Mon, Mar 2, 2020 at 8:38 AM Matt Corallo > > > wrote:
>> >
>> > It also gives local competitors a leg up by helping domestic apps
>> > perform better simply by being hosted domestically (or making
>> > foreign players host inside China).
>> >
>> >> On Mar 2, 2020, at 11:27, Ben Cannon > >> > wrote:
>> >>
>> >> 
>> >> It’s the Government doing mandatory content filtering at the
>> >> border.  Their hardware is either deliberately or accidentally
>> >> poor-performing.
>> >>
>> >> I believe providing limited and throttled external connectivity
>> >> may be deliberate; think of how that curtails for one thing;
>> >> streaming video?
>> >>
>> >> -Ben.
>> >>
>> >> -Ben Cannon
>> >> CEO 6x7 Networks & 6x7 Telecom, LLC
>> >> b...@6by7.net 
>> >>
>> >>
>> >>
>> >>> On Mar 1, 2020, at 9:00 PM, Pengxiong Zhu > >>> > wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> We are a group of researchers at University of California,
>> >>> Riverside who have been working on measuring the transnational
>> >>> network performance (and have previously asked questions on the
>> >>> mailing list). Our work has now led to a publication in
>> >>> Sigmetrics 2020 and we are eager to share some
>> >>> interesting findings.
>> >>>
>> >>> We find China's transnational networks have extremely poor
>> >>> performance when accessing foreign sites, where the throughput is
>> >>> often persistently
>> >>> low (e.g., for the majority of the daytime). Compared to other
>> >>> countries we measured including both developed and developing,
>> >>> China's transnational network performance is among the worst
>> >>> (comparable and even worse than some African countries).
>> >>>
>> >>> Measuring from more than 400 pairs of mainland China and foreign
>> >>> nodes over more than 53 days, our result shows when data
>> >>> transferring from foreign nodes to China, 79% of measured
>> >>> connections has throughput lower than the 1Mbps, sometimes it is
>> >>> even much lower. The slow speed occurs only during certain times
>> >>> and forms a diurnal pattern that resembles congestion
>> >>> (irrespective of network protocol and content), please see the
>> >>> following figure. The diurnal pattern is fairly stable, 80% to
>> >>> 95% of the transnational connections have a less than 3 hours
>> >>> standard deviation of the slowdown hours each day over the entire
>> >>> duration. However, the speed rises up from 1Mbps to 4Mbps in
>> >>>

Re: 99% of HK internet traffic goes thru uni being fought over?

[Tom Paseka via NANOG]

In terms of bits, MOST Hong Kong traffic does NOT traverse HKIX.

However, Hong Kong ISPs, almost entirely communicate with each other of
HKIX.

Sources like Akamai and Google, however, do not typically traverse HKIX.
These are the majority of traffic.

99% of Hong Kong is connected to HKIX, by traverses? No.

On Wed, Nov 20, 2019 at 1:42 PM  wrote:

>
> Thanks everyone for the replies. My conclusion is that no one here
> knows whether HKIX handles 99% of internet traffic for HK or not.
>
> It's a number.
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>

Re: CloudFlare issues?

[Tom Paseka via NANOG]

a Verizon downstream BGP customer is leaking the full table, and some more
specific from us and many other providers.

On Mon, Jun 24, 2019 at 7:56 AM Robbie Trencheny  wrote:

> *1147 UTC update* Staring at internal graphs looks like global traffic is
> now at 97% of expected so impact lessening.
>
> On Mon, Jun 24, 2019 at 04:51 Dovid Bender  wrote:
>
>> We are seeing issues as well getting to HE. The traffic is going via
>> Alter.
>>
>>
>>
>> On Mon, Jun 24, 2019 at 7:48 AM Robbie Trencheny  wrote:
>>
>>> From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now:
>>>
>>> This appears to be a routing problem with Level3. All our systems are
>>> running normally but traffic isn't getting to us for a portion of our
>>> domains.
>>>
>>> 1128 UTC update Looks like we're dealing with a route leak and we're
>>> talking directly with the leaker and Level3 at the moment.
>>>
>>> 1131 UTC update Just to be clear this isn't affecting all our traffic or
>>> all our domains or all countries. A portion of traffic isn't hitting
>>> Cloudflare. Looks to be about an aggregate 10% drop in traffic to us.
>>>
>>> 1134 UTC update We are now certain we are dealing with a route leak.
>>>
>>> On Mon, Jun 24, 2019 at 04:04 Antonios Chariton 
>>> wrote:
>>>
 Yes, traffic from Greek networks is routed through NYC (alter.net),
 and previously it had a 60% packet loss. Now it’s still via NYC, but no
 packet loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the
 problem definitely exists.

 Antonis


 On 24 Jun 2019, at 13:55, Dmitry Sherman  wrote:

 Hello are there any issues with CloudFlare services now?

 Dmitry Sherman
 dmi...@interhost.net
 Interhost Networks Ltd
 Web: http://www.interhost.co.il
 fb: https://www.facebook.com/InterhostIL
 Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157


 --
>>> --
>>> Robbie Trencheny (@robbie )
>>> 925-884-3728
>>> robbie.io
>>>
>> --
> --
> Robbie Trencheny (@robbie )
> 925-884-3728
> robbie.io
>

Re: AS3266: BitCanal hijack factory, courtesy of many connectivity providers

[Tom Paseka via NANOG]

Hi,

I've been casually observing the connectivity to Bitcanal / AS3266 /
AS197426 since the thread started.

After GTT shared that bitcanal had been disconnected, bitcanal was only
visible behind Cogent. But the Cogent path now also seems to have been
disconnected. After Cogent they popped up behind BICS (but just for a few
days), that circuit seems to have been disconnected too.

On the IX front: I noticed that Bitcanal's IP addresses on LINX (since
yesterday) and FranceIX (since today) are no longer responding.

It is good to see that discussing BGP hijacking abuse complaints actually
results in clean up activities. I hope the remaining IX's they're still
connected to can act too.

Thanks!
-Tom

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: Wave service providers in Hong Kong metro area

[Tom Paseka via NANOG]

HKBN are great, highly recommend them
Traxcomm (owned by the MTR/subways)
Towngas (fiber in the natural gas lines)
Superloop - new entrant. good guys.



On Thu, May 10, 2018 at 7:09 AM, Matthew Walster 
wrote:

> On 8 May 2018 at 18:58,  wrote:
>
> > Can anyone recommend wave providers on the Hong Kong area? I need to
> reach
> > between two colo facilities there. Feel free to ping me off-list.
> >
>
> ​Hong Kong island (e.g. REACH near Admiralty or Mega i-advantage near Chai
> Wan) or in the Tsuen Wan area​ (e.g. Equinix HK1 etc) or somewhere else?
> All the providers have waves throughout the main districts, but some are
> far better if it's within the boundaries of their specific service areas.
>
> I've used Wharf T in the past, now known as WTT HK, for waves between
> office buildings in Central / Admiralty and colo in Tseung Kwan O. They
> were very fast to install, reasonably priced (for cross-harbour circuits at
> least) and were happy to handle arrangement of wayleaves without too much
> hand holding.
>
> M
>

Re: isp/cdn caching

[Tom Paseka via NANOG]

Hi,

Cloudflare does deploy caches, however we usually look to do so in unique
locations, ie. where an ISPs network isn't already in reach of one of our
existing deployments/peering points.

You can email peer...@cloudflare.com directly if seeking this.

-Tom

On Fri, Sep 29, 2017 at 7:22 AM, Marco Slater  wrote:

> Do they publicly have any more info on this?
>
> I thought CloudFlare didn’t consider doing that because of their vast
> coverage and peering arrangements provided by their PoPs.
>
> Regards,
> Marco Slater
>
> > On 29 Sep 2017, at 14:38,  <
> michalis.bersi...@hq.cyta.gr> wrote:
> >
> > I think that Cloudflare has a caching solution, but I think they have
> strict requirements towards the isp in order to install them on their
> premises.
> >
> > Best Regards,
> >
> > Michalis Bersimis
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Aaron Gould
> > Sent: Thursday, September 28, 2017 6:25 PM
> > To: Nanog@nanog.org
> > Subject: isp/cdn caching
> >
> > Hi, I've been aware of a few caching providers for a few years now, but
> I'm learning of others as time goes on. which makes me curious if there are
> more springing up and gaining popularity.  I'm speaking of ISP-type caching
> whereas the cache provider sends hardware servers and perhaps a switch to
> the local ISP to install locally in their network.  Can someone please send
> a simple list of what they know is the current players in this ISP Caching
> space?  I'll list the ones I know about and you please let me know of
> others.  This seems to be an evolving/growing thing and I'm curious of
> where we are today for significant providers and possibly up-and-coming
> ones that I should know about.  (amazon prime has my wondering also.)
> >
> >
> >
> > Google (GGC)
> >
> > Netflix (OCA)
> >
> > Akamai (AANP)
> >
> > Facebook (FNA)
> >
> > Apple (I heard this isn't isp-located like the others, but unsure)
> >
> > ? others ?
> >
> > ? others ?
> >
> > ? others ?
> >
> >
> >
> > -Aaron Gould
> >
>
>

Re: BGP Optimizers (Was: Validating possible BGP MITM attack)

[Tom Paseka via NANOG]

We regularly see poorly configured "optimizers" or networks hijacking our
prefixes (originating /25's, /24 of /23's etc).

Thankfully, most of the time filters are in place to stop them leaking
badly, but I agree, these are toxic.

-Tom

On Fri, Sep 1, 2017 at 6:06 AM, Job Snijders  wrote:

> Dear all,
>
> disclaimer:
>
> [ The following is targetted at the context where a BGP optimizer
> generates BGP announcement that are ordinarily not seen in the
> Default-Free Zone. The OP indicated they announce a /23, and were
> unpleasantly surprised to see two unauthorized announcements for /24
> more-specifics pop up in their alerting system. No permission was
> granted to create and announce these more-specifics. The AS_PATH
> for those /24 announcements was entirely fabricated. Original thread
> https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ]
>
> On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote:
> > Presuming it was a route optimizer and the issue was ongoing, what
> > would be the suggested course of action?
>
> I strongly recommend to turn off those BGP optimizers, glue the ports
> shut, burn the hardware, and salt the grounds on which the BGP optimizer
> sales people walked.
>
> It is extremely irresponsible behavior to use software that generates
> _fake_ BGP more-specifics for the purpose of traffic engineering. You
> simply cannot expect that those more-specifics will never escape into
> the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see
> software bugs related to NO_EXPORT, and community-squashing
> configuration mistakes happen all the time.
>
> Consider the following: if you leak your own internal more-specifics, at
> least you are the legitimate destination. (You may suffer from
> suboptimal routing, but it isn't guaranteed downtime.) However if you
> generate fake more-specifics for prefixes belonging to OTHER
> organisations, you essentially are complicit in BGP hijacking. If those
> fake more-specifics accidentally leak into the DFZ, you are bringing
> down the actual owner of such prefixes, and depriving people from access
> to the Internet. Example case:
> https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html
>
> > reach out to those 2 AS owners and see if they could stop it?
>
> Yes, absolutely! And if everyone of the affected parties of this
> localized hijack leak (or should we say 'victims') reaches out to the
> wrongdoers, they contribute peer pressure to rectify the situation. Just
> make sure you assign blame to the correct party. :)
>
> > Or is it something I just have to live with as a traffic engineering
> > solution they are using and mark the alerts as false positives?
>
> No, this is not something we should just accept. The Default-Free Zone
> is a shared resource. Anyone using "BGP optimizers" is not only risking
> their own online presence, but also everyone else's. Using a BGP
> optimizer is essentially trading a degree of risk to society for the
> purpose of saving a few bucks or milliseconds. It is basically saying:
> "The optimizer helps me, but may hurt others, and I am fine with that".
>
> An analogy: We don't want transporters of radioactive material to cut
> corners by using non-existant roads to bring the spent nuclear fuels
> from A to B faster, nor do we want them to rely on non-robust shielding
> that works "most of the time".
>
> We share the BGP DFZ environment, 'BGP optimizers' are downright
> pollution contributors.
>
> Kind regards,
>
> Job
>
> ps. If you want to do BGP optimization: don't have the BGP optimizer
> generate fake BGP announcements, but focus only on manipulating
> non-transitive attributes (like LOCAL_PREF) on real announcements you
> actually received from others. Or Perhaps BGP optimizers shouldn't even
> talk BGP but rather push freshly generated TE-optimized routing-policy
> to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come
> to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate
> real announcements)... there are ways to do this, without risk to others!
>
> p.s. providing a publicly available BGP looking glasses will contribute
> to proving your innocence in cases like these. Since in many cases the
> AS_PATH is a complete fabrication, we need to manually check every AS in
> the AS_PATH to see whether the AS carries the fake more-specific. A
> public looking glass speeds up this fault-finding process. If you don't
> want to host a webinterface yourself, please consider sending a BGP feed
> to the Route Views Project or RIPE RIS, or for something queryable in a
> real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/
>

Re: Cogent BGP Hijack

[Tom Paseka via NANOG]

Looking at bgplay data, Hetzner possibly had some outages at the time?
Cogent isn't quick at withdrawing routes and will often blackhole inside
their network, but i can't see a large leak/hijack as happened.

On Tue, May 23, 2017 at 10:32 AM,  wrote:

> On Tue, 23 May 2017 10:10:25 +0300, Scott Christopher said:
> > https://www.lowendtalk.com/discussion/114865/hetzner-and-
> other-traffic-passin
> g-cogent-rerouted-over-moscow#latest
> >
> > A report that all Cogent traffic got re-routed into Moscow. Looks
> > innocent but happened right after UA blocked RU websites (e.g.,
> > VKontakte, Yandex, etc)
> >
> > Any thoughts ?
>
> Similar happened like 3 weeks ago.  Big collective yawn when I posted
> about it.
>

Comcast IPv6 issues

[Tom Paseka via NANOG]

Can someone from Comcast please reach out? Looks like you're black holing
some prefixes.

-Tom

Re: Is it safe to use 240.0.0.0/4

[Tom Paseka via NANOG]

You'll find as well, a lot of hosts (eg, I know at least Windows XP)
won't forward to Class E destinations.

-Tom

On Wed, Jun 17, 2015 at 2:50 PM, Ray Soucy r...@maine.edu wrote:
 There is already more than enough address space allocated for NAT, you
 don't need to start using random prefixes that may or may not be needed for
 other purposes in the future.

 For all we know, tomorrow someone could write an RFC requesting an address
 reserved for local anycast DNS and it could be assigned from this block.

 On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen lngu...@opsource.net wrote:

 Is that safe to use internally? Anyone using it?
 Just for NATTING on Cisco gears...




 --
 Ray Patrick Soucy
 Network Engineer
 University of Maine System

 T: 207-561-3526
 F: 207-561-3531

 MaineREN, Maine's Research and Education Network
 www.maineren.net

Re: AS4788 Telecom Malaysia major route leak?

[Tom Paseka via NANOG]

Looks to be edited from their original tweet.

On Fri, Jun 12, 2015 at 9:07 AM,  niels=na...@bakker.net wrote:
 * milln...@gmail.com (Martin Millnert) [Fri 12 Jun 2015, 12:54 CEST]:

 Also, possible explanation for why nobody's fixing it:
 https://twitter.com/TMCorp/status/609167065300271104 :)

 https://scontent-sea1-1.xx.fbcdn.net/hphotos-xat1/t31.0-8/10914977_10152809997716851_748171875526832420_o.jpg

 Is that tweet for real?  How is that company (not TM) still in business?


 -- Niels.