Thread

1. a11r · 1789659411 · focus · HN ↗

   Back in 2008 Fujitsu has one of the best performing 10Gbps Switches. We were building 40 Gbps packet sniffers at Google (4x 10 Gbps NICs) and needed switches that could do things like mirror traffic across ports at line rate. Fujitsu was way ahead of the pack. I always wondered what held them back from building a meaningful networking business in the US.

   1. ricksunny · 1789664155 · focus · HN ↗

      >We were building 40 Gbps packet sniffers at Google (4x 10 Gbps NICs) and needed switches that could do things like mirror traffic across ports at line rate

      I'm sure there were good reaasons for this, but man this just sounds bad. Like that's the spec I think NSA must give to their contractors outfitting 611 Folsom Street's Room 641A

      1. agilob · 1789666296 · focus · HN ↗

         It does sound bad the way OP described it, but packet or HTTP mirroring is a standard feature of A/B testing and blue-green deployments of a very critical code. Mirror traffic between version 1 and 2, then compare response body, response time and return response A to the end users.

         1. fmbb · 1789672865 · focus · HN ↗

            But the comment says ”we were building packet sniffers” … and needed mirroring as part of that.

            1. yabones · 1789673506 · focus · HN ↗

               It's super common and very useful for security systems to work like this. Instead of putting something in-line that might choke on a burst of traffic you put it off to the side and send it a firehose of packets it may or may not be able to handle. If it falls over, no problem.
            2. zamadatix · 1789700546 · focus · HN ↗

               I used to operate several dozen 10G/25G/40G/100G taps which fed a series of tools in the DC at a regional healthcare back in the day.

               80% of the relevant outcome was typically to get a true-to-the-wire sniffer capture (switch mirrors won't always mirror 100% of packets for various reasons) for troubleshooting performance of whatever the complaint of the day from the server team was.

               19% was for feeding a security monitoring systems which looked for abnormal flow patterns to let us know a server was compromised.

               1% was for the call recording system compliance requirement for the emergency department.

               0% was because I was a cool superspy tasked by the government to siphon info to them or trying to sell medical records on the black market or something. I mean, you can try to something nefarious with such tools... but one could say the same about a generic server, SAN, application, etc as well. People are just used to understanding what those would typically be used for so they don't assume it must be for the scary thing they've heard about.

               That said, it doesn't rule it out either. But again, the concern shouldn't be sourcing from their usage of normal infrastructure tools it should be sourcing from... well, all of the user analytics Google very publicly does directly in the server.

               1. totetsu · 1789705560 · focus · HN ↗

                  I was under the impression that the superspy stuff usually happens more at the undersea-cable terminal or at satellite links anyway.

                  1. zamadatix · 1789737582 · focus · HN ↗

                     It would certainly be easiest/cheapest to do it wherever the majority of the traffic already flows.
            3. Hikikomori · 1789716192 · focus · HN ↗

               Common tools for any network engineer

Unofficial Hacker News client; not affiliated with Y Combinator.