Hacker Newsnew | past | comments | ask | show | jobs | submit | more job's commentslogin

This was just now merged in -current and will be part of OpenBSD 6.4 release in fall 2018.


This is a more regular example https://stat.ripe.net/widget/routing-history#w.resource=AS82...

this shows the routing history of the prefixes originated by AS 8283 - and their observed reachability


On April 1st 2015 I tried to create new poems by remixing an existing body of work through reverse DNS: https://bandaancha.eu/foros/april-fools-ntt-1717230 - the original was better perhaps ;-)


I like it a lot. There's something quite endearing about seeing human-legible text (beyond city names / interface names) in reverse DNS.


Thank you for the kind words :-)


... what is that VT510 connected to?

Is that tmux, with some ip config on the left, and an empty shell (with a fortune) on the right?

Do the sunflowers represent anything? :)


PC Engines APU2 with openbsd


I'm glad people like you are part of the community.. Really cool project!


Just to chime in, that made my day. Utterly brilliant.


It might amuse you to know the same NTT people are behind the BGP Nyancat :-)


Is this NTT as in "Nippon Telegraph and Telephone"? It's a surprising and welcome sight to see such shenanigans coming out of a Japanese mega corporation that used to be owned by the government, and now operations in a heavily regulated industry.


yes! It is probably more accurate to think of NTT as many smaller companies.

These guys are from GIN and are some of the best people I've had the pleasure of working with, both on a personal and professional level.


I am amazed/fascinated by this! I would love to hear more for all the non-experts here about how the BGP Nyancat came to be :)


The starting point is a BMP file of the Nyan cat which is read into a simple two dimensional array by a small python script. The script looks at the current time and maps that to a column of pixels in the BMP. Each row of pixels in the BMP is represented by one IPv4 /24. If the pixel is "on" a BGP route announcement is generated, if the pixel is "off" the route is withdrawn. Each pixel in the BMP file represents 8 hours of announcing.


I'm curious how you handled the justification for the IP space to pull this off. ;)


The prefixes are probably announced in aggregated form anyhow further upstream. The announcements and deannouncements are/were therefore redundant.

At least't that's my hunch. We could check the same monitor though :)


AS15562 appears to be an employee of NTT out of the Netherlands. I can't tell if AS15562 is for personal or work, maybe both: http://bgp.he.net/AS15562

I couldn't care less about the IPv6 prefixes, but the IPv4 ones are all /24s made from 209.24.0.0/16, which is registered to NTT (AS2914). 209.24/16 is publicly announced (and has been for a very long time), and is routed through NTT Amsterdam routers.

I haven't looked at BGPlay to review all the data, but it looks like many of the /24s that make up that /16 were individually announced through AS15562, then later withdrawn, gradually over 4 months, to make said graph. I would hope this would be unused v4 space. That AS announced almost 98% of a /16 (probably 209.24/16): https://stat.ripe.net/AS15562#tabId=routing

Another user voiced their concerns, particularly if it was actively used: https://news.ycombinator.com/item?id=14621859 -- there's no way any of us could know this; NTT would be authoritative, and jwhois -h rwhois.gtt.net.net -p 4321 209.24.0.0/16 doesn't give any clues.

While the antic made me smirk, it doesn't (publicly) "look good" when we're living in a world that lacks (or has greatly limited) v4 space. What this says is: "NTT has a /16 they're fooling around with publicly", even though it (presumably) is harmless.


> it doesn't (publicly) "look good" when we're living in a world that lacks (or has greatly limited) v4 space. What this says is: "NTT has a /16 they're fooling around with publicly", even though it (presumably) is harmless.

NTT is one of the larger Tier 1 ISPs. Having some unused IPv4 address space is a good thing when you're such a huge network operator -- it means you can dedicate some globally-routed IPs for testing/prototyping/renumbering and also have some extra IP space for new devices. Given what happens to ISPs that run out of IPs, I am frankly glad NTT has enough free IPs to fool around with nyan cats.

If NTT was dragging its feet on IPv6, then yeah, such a stunt might look awkward, but NTT hasn't -- they've been on the forefront of IPv6 for a while. AFAICT they were the first to offer commercial IPv6 connectivity and their global IP network has been native IPv4/IPv6 since 2004, and anecdotally I see their routers in my IPv6 traceroutes all the time.


> What this says is: "NTT has a /16 they're fooling around with publicly",

While this may be a lot for typical users, it's not huge for a large IT company. You know that HP has 2 /8s, right?


Yeah, I'm familiar with the original companies that have /8 allocations per IANA. I started using the 'net in 1989.

I'm also aware many of those places have either refused to relinquish space, or have done so but have no more to give back. Quoting Doug Barton, former manager at IANA, July 2015: "... Many orgs did give back space and/or swap allocations. But that well ran dry long ago" (if you need a reference link for that quote, let me know).

A recent example of relinquishing space is 18.0.0.0/8 (previously MIT) as of April 2017, which now has many /16 and /24 segments delegated to companies such as Comcast (ex. 18.10.0.0/16), Amazon (ex. 18.145.0.0/16), and Akamai (ex. 18.255.255.0/24), while many larger portions still reside with MIT (ex. 18.128.0.0/12, 18.0.0.0/9, 18.144.0.0/16).

My point of giving examples: note all the /16s. If you need further examples, refer to IANA's Recovered Address Space document and note the subnet sizes (many are much smaller than a /16): https://www.iana.org/assignments/ipv4-recovered-address-spac...

Every little bit counts.


Good news everyone, Cisco re-examined the bug and concluded this particular problem was not a hardware issue after all but can be remedied with a software update: http://mailman.nanog.org/pipermail/nanog/2016-December/08941...


You might enjoy watching https://www.youtube.com/watch?v=cXSwoKu9zOg&t=5s - a video recording about "What's Up With Poor Performance Towards MAC Addresses Starting With 4 or 6?" presented at the North American Network Operator Group (NANOG).


Infinite facepalm


It loads at 100 Kb/sec here in Amsterdam, but does not seem down.

I am not familiar with the GPU error. So far most say the best viewing experience of this app is with Chrome.


This cluster on the left are all of the DoD ASNs http://as2914.net/#/galaxy/ipv4?cx=4134&cy=5005&cz=-884&lx=-... they really stand out as their a group on their own.


Thanks job - I was just going to point this out. Did you notice the connection to AS62010, 3DATA LLC, Moscow, Russia? Whose only other link is to AS29226, CJSC Mastertel, Moscow?


I didnt see that. Who knows why they are connected! Maybe for the Moscow–Washington VOIP hotline ;)


How is the length of path defined? [IE - Why are the DoD so far out?]


Why is this?


In this visualization, you can navigate through all BGP adjacencies as observed from NTT Communications' network. Each star in this galaxy represents an Autonomous System, the edges between stars are derived from all AS_PATHs in the Default-free zone as seen from AS2914.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: