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.

Re: From Europe to Australia via right way

[Tom Paseka]

you won't find internet packets going that way though (most of the time).
You can buy a L2vpn, p2p, etc, that will though.

On Wed, Apr 1, 2015 at 2:51 PM, joel jaeggli joe...@bogus.com wrote:

 On 4/1/15 3:14 AM, Piotr wrote:
  Hello,
 
  There is some telecom, isp which have route from EU to AU via east or
  south east (via Russia, Red sea or  other ways) ? Now i have path via US
  and looking something in opposite direction.

 telstra ntt reliance retn all have eastbound paths from europe.

  thanks for some info, contact.
  Piotr
 

Re: Searching for a quote

[Tom Paseka]

Be conservative in what you send, be liberal in what you accept

^http://en.wikipedia.org/wiki/Robustness_principle

On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone jason.iann...@gmail.com
wrote:

 There was once a fairly common saying attributed to an early
 networking pioneer that went something like, be generous in what you
 accept, and send only the stuff that should be sent.  Does anyone
 know what I'm talking about or who said it?

Re: Need help in flushing DNS

[Tom Paseka]

On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore patr...@ianai.netwrote:

 On Jun 20, 2013, at 01:30 , Grant Ridder shortdudey...@gmail.com wrote:

  Yelp is evidently also affected

 Not from here.


Patrick:

$ dig NS yelp.com @8.8.8.8 +short
ns1620.ztomy.com.
ns2620.ztomy.com.

Some DNS servers have the bad records - TLD for .com is updated already.

Cheers,
Tom

Re: route for linx.net in Level3?

[Tom Paseka]

On Thu, Apr 4, 2013 at 12:29 PM, Leo Bicknell bickn...@ufp.org wrote:

 But hey, this is a good thing because a DDOS caused issues, right?
 Well, not so much.  Even if the exchange does not advertise the
 exchange LAN, it's probably the case that it is in the IGP (or at
 least IBGP) of everyone connected to it, and by extension all of
 their customers with a default route pointed at them.  For the most
 popular exchanges (AMS-IX, for instance) I suspect the percentage
 of end users who can reach the exchange LAN without it being
 explicitly routed to be well over 80%, perhaps into the upper 90%
 range.  So when those boxes DDOS, they are going to all DDOS the
 LAN anyway.


Yes, thats why everyone needs to set up some sanity in their networks.

This was presented at an APNIC conference a little while back:
http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf

hundreds of networks are improperly set up and are being abused (and
abusing) to the IXP LANs.


 Security through obscurity does not work.  This is going to annoy some
 people just trying to do their day job, and not make a statistical
 difference to the attackers trying to take out infrastructure.


This isn't security through obscurity. This is saving the IXP from
getting 100's of G's over transit, which should just be for their
corporate network.


 How about we all properly implement BCP 38 instead?


Agree.

Re: route for linx.net in Level3?

[Tom Paseka]

On Thu, Apr 4, 2013 at 1:43 PM, Randy Bush ra...@psg.com wrote:
 Even if the exchange does not advertise the exchange LAN, it's
 probably the case that it is in the IGP (or at least IBGP) of
 everyone connected to it,

 yikes!  this is quite ill-advised and i don't know anyone who does
 this, but i think all my competitors should.


Its more common than uncommon.

At WIX (Wellington), 64 out of 93 members will carry packets destined
to APE (Auckland Exchange).  (source:
http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-jager-securing-ixp-connectivity_1346119861.pdf)
 and this is just New Zealand!

Just checked a few exchanges, not just are the IXP ranges being
carried, they're being leaked:

Equinix SG:

$ bgpctl show rib 202.79.197.0/24
flags: * = Valid,  = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination  gateway  lpref   med aspath origin
  202.79.197.0/24  100 0 13335 23947 23947 ?
  202.79.197.0/24  100 0 13335 10026 i

Any2 LA:

bgpctl show rib 206.223.143.0/24
flags: * = Valid,  = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination  gateway  lpref   med aspath origin
  206.223.143.0/24 100 0 13335 9304 i
  206.223.143.0/24 100 0 13335 9304 i
  206.223.143.0/24 100 0 13335 4635 9304 i
  206.223.143.0/24 100 0 13335 9304 i


 I have experience of several networks where that is not the case. IGP
 carries routes for loopback and internal-facing interfaces;

 i have seen some carry external because, for some reason, they do not
 want to re-write next-hop at the border.

 randy

Re: Open Resolver Problems

[Tom Paseka]

On Tue, Mar 26, 2013 at 7:38 AM, Jay Ashworth j...@baylink.com wrote:

 - Original Message -
  From: Jared Mauch ja...@puck.nether.net

  b) locking down your recursive servers to networks you control

 Sure.  But OpenDNS, Google, and the other providers of recursive servers
 for edge cases can't do that anymore?


Of cos they can. But they take the security of their open recursive servers
very seriously.  99.9% of the open recursors dont, hence the problem.

Re: Open Resolver Problems

[Tom Paseka]

On Tue, Mar 26, 2013 at 7:04 PM, Matthew Petach mpet...@netflight.comwrote:

 On Tue, Mar 26, 2013 at 6:06 PM, John Levine jo...@iecc.com wrote:
 As a white-hat attempting to find problems to address through legitimate
 means, how
 do you …
 
  You make friends with people with busy authoritative servers and see
  who's querying them.

 I'm confused.  Don't most authoritative servers have to
 answer to just about anyone in order to be useful?

 Matt


Authoritative DNS servers need to implement rate limiting. (a client
shouldn't query you twice for the same thing within its TTL).

Re: Fake or Real Google servers from China Hong Kong (116.92.194.14x)?

[Tom Paseka]

Looks like google cache.

On Mon, Mar 25, 2013 at 2:08 PM, César de Tassis Filho
ctass...@gmail.comwrote:

 Not sure, but it looks like some Google Global Cache inside an ISP.

 César


 On Mon, Mar 25, 2013 at 5:59 PM, Grant Ridder shortdudey...@gmail.com
 wrote:

  Whois record isn't Google.
 
 
  inetnum:116.92.0.0 - 116.92.255.255
  descr:  This field was added to fix syntax error
  netname:PACNET
  remarks:Spam and Security: ab...@pacnet.com
  remarks:Network Issues : r...@pacnet.com
  country:HK
  admin-c:PNH4-AP
  tech-c: PNH4-AP
  mnt-by: APNIC-HM
  mnt-lower:  MAINT-AP-PACNET
  mnt-lower:  MAINT-AP-PACNET-NOC
  changed:r...@pacnet.com
  status: ALLOCATED PORTABLE
  changed:hm-chan...@apnic.net 20080604
  source: APNIC
 
  role:   PACNET NIC Handler
  address:PACNET
  country:HK
  phone:  +65-6872-1010
  e-mail: r...@pacnet.com
  remarks:-
  remarks:Spam and Security: ab...@pacnet.com
  remarks:Network Issues   : r...@pacnet.com
  remarks:-
  admin-c:PR132-AP
  admin-c:AN155-AP
  tech-c: PR132-AP
  tech-c: AN155-AP
  nic-hdl:PNH4-AP
  remarks:http://www.pacnet.com
  notify: r...@pacnet.com
  mnt-by: MAINT-AP-PACNET
  changed:r...@pacnet.com 20090911
  source: APNIC
  changed:hm-chan...@apnic.net 2014
 
  On Mon, Mar 25, 2013 at 3:42 PM, Manu Chao linux.ya...@gmail.com
 wrote:
 
   Could someone confirm me following IP are legitimated from Google China
   (HK) or not (fake=dangerous) ???
  
   116.92.194.140
   116.92.194.141
   116.92.194.142
   116.92.194.143
  
   No DNS resolution from Google DNS, i am suspicious...
  
   Any help appreciate
  
 

Re: Good transit provider @Hutchison Cavendish Centre

[Tom Paseka]

You won't be able to get many choices there. Given its a Hutchison
building, thought about Hutchison?

You'll need a local loop otherwise, coverage is probably not easy too and
being a hutch building, you wont get much choice.

Other recommendations (if you forget about local loop issues), Pacnet,
Telstra/Reach, PCCW, TATA, NTT, etc.

Every provider should be able to meet your DDOS requirements.

On Thu, Feb 28, 2013 at 4:42 AM, Luan Nguyen luan20...@gmail.com wrote:

 Hi Folks,

 Any recommendation for a 1 Gig Transit provider at Hutchison Cavendish
 Centre? Has to be able to black hole DDOS attack using BGP communities.
 Preferable: Tier 1 provider with US present (IAD would be best)
 HK NSP mailing list doesn't exist anymore?

 Thanks.

 Regards,

 -lmn

Re: JunOS IPv6 announcements over IPv4 BGP

[Tom Paseka]

protocols bgp {
   group akamai {
  neighbor x.x.x.x {
  family inet {
 unicast;
  }
  family inet6 {
 unicast;
  }
 }
   }
}

On Fri, Dec 21, 2012 at 10:45 AM, Pete Ashdown pashd...@xmission.comwrote:

 I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP.
 I'm running around in circles with JTAC trying to find out how to do this
 in JunOS.  Does anyone have a snippet they can send me?

Re: JunOS IPv6 announcements over IPv4 BGP

[Tom Paseka]

On Fri, Dec 21, 2012 at 4:07 PM, Owen DeLong o...@delong.com wrote:

 I would push back for a slightly different reason...

 Any inability to forward IPv6 might not impact the IPv4 peering session and
 you might run into a situation where the peering session stays up and
 continues
 exchanging routes, but the traffic cannot pass (or cannot pass in one
 direction
 which is even more fun to diagnose).

 Owen


The OP mentioned this was just for Akamai (for their DNS mapping). BGP
isn't used for forwarding path.

Re: China Telecom VPN problems (again)

[Tom Paseka]

Its quite easy to get MPLS-VPN connectivity into China (Pacnet, Singtel,
CPCNet, etc, will offer), but at a price.

Suzhou and Shenzhen are easily in reach of all the above listed providers.

On Wed, Dec 5, 2012 at 7:50 AM, Warren Bailey 
wbai...@satelliteintelligencegroup.com wrote:

 We tried to get our VPN work from the China Telecom/China Unicom beijing
 POP for over a year. The Chinese always claimed it was kosher, but we had
 something like 60%+ loss across our 4 hop VPN for the entirety of the
 project. Private circuits don't really exist on the mainland, HK and
 (maybe) Shanghai are about the only places for decent connectivity. :/

 On 12/5/12 7:38 AM, Suresh Ramasubramanian ops.li...@gmail.com wrote:

 It's called the great firewall of china. Feel free to shift vendors but it
 won't help.
 
 Meanwhile make sure none of your users are surfing for falun gong,
 dalai lama, ai weiwei or whoever else the chicom censors don't like on
 that
 particular day
 
 On Wednesday, December 5, 2012, Thomas York wrote:
 
  It looks like I'm having China Telecom issues yet again. They're batting
  down our SSL VPN tunnels. Switching ports doesn't help. Tunneling the
 SSL
  tunnel inside of another tunnel doesn't help. At this point I'm tired of
  listening to the screaming by the business users. Can someone contact me
  (here or off-list, I don't care) about circuits in China so that we
 don't
  have to use China Telecom? We'd only need 2-10 Mbit and Ethernet hand
 off.
  We don't need BGP or MPLS or anything remotely fancy. Our main concern
 is
  getting connectivity to the business district in Suzhou, but it'd be
 nice
  if
  we could also use the same carrier in Shenzhen.
 
 
 
  Thanks!
 
 
 
  -- Thomas York
 
 
 
 
 
 
 
 --
 --srs (iPad)
 

Re: China Telecom VPN problems (again)

[Tom Paseka]

On Wed, Dec 5, 2012 at 11:25 AM, Christopher Morrow morrowc.li...@gmail.com
 wrote:

 On Wed, Dec 5, 2012 at 2:19 PM, Tom Paseka t...@cloudflare.com wrote:
  Its quite easy to get MPLS-VPN connectivity into China (Pacnet, Singtel,
  CPCNet, etc, will offer), but at a price.

 mpls != ipsec ... perhaps the OP wants some privacy and authentication and
 such?


run IPSEC over the MPLS-VPN. It'll be a lot more stable than over public
internet.

Re: Technical help required to check routing or filtering of Gobal IP routing range: 1.128.0.0 - 1.159.255.255 in the Level 3 Network Space.

[Tom Paseka]

G'day!

On Mon, Nov 19, 2012 at 10:18 PM, Attila Vekas attilave...@gmail.com wrote:

 Regards,

 Attila Vekas

 Telstra

I'd say its AS23148 / Terremark with a bogon filter.

your fixed line traceroute shows the next-hop being the connection
between level3 and AS23148.

10   208 ms   191 ms   208 ms  
l3-peer.eqnx03.pr.telstraglobal.net[134.159.61.6]
11   209 ms   209 ms   209 ms  ae-42-90.car2.SanJose1.Level3.net[4.69.152.196]
12   193 ms   193 ms   193 ms  
DATA-RETURN.car2.SanJose1.Level3.net[4.53.18.134]

Cheers,
Tom

Re: mail-abuse.org down?

[Tom Paseka]

from the website:

This website has been moved to http://ers.trendmicro.com.
Please update your bookmarks with this URL.

On Sun, Nov 4, 2012 at 2:47 AM, Suresh Ramasubramanian
ops.li...@gmail.com wrote:

 Maps was taken over by trend micro years back, maybe they just retired the
 old domain?

Re: is CERNET part of the Internet?

[Tom Paseka]

On Thu, Sep 27, 2012 at 2:33 AM, Jeroen Massar jer...@unfix.org wrote:

 Everything in China is behind their content filter. Only parts of Hong
 Kong are sometimes not yet. As far as it is known they do not 'allow'
 things but block specific things.

All* of Hong Kong and Macau are not behind the chinese firewalls.

*some hong kong and macau traffic *may* traverse mainland china and
hence be firewalled, but the networks themselves operating in these
two cities/regions do not have filtering per se.