Networking vendors are good for free lunches, hopeless for networks

Fire your network administrators, hire developers instead, and stop expecting networking equipment vendors to provide anything more valuable than free lunches. That's the advice from games-maker Electronic Arts director of technical engagement Peyton Koran, who delivered a talk titled “The Impacts of Cloud Computing and Open …

[Nate Amsden]

if it works, use it

for me anyway, I have been building networks the same way for 13 years now(I'm not a dedicated networking person just a generalist(?) that does networking among other things), works great, so I use it. (and no I have never used STP, and no I don't use Cisco either). The vendor I do use doesn't even actively promote the method I use to build networks(even though it is technically proprietary to their equipment at least at the core switch level), though I find this approach to be great.

Though I'm sure the likes of EA has far more fancy requirements for their networks than I ever have had or will ever have.

I've seen what developers do with shiny things(having worked with developers for the past 17 years), often times end result is not stable. Most developers don't even understand basic networking concepts, so wouldn't let them near networking equipment.

[mr. deadlift]

Fuck E.A

that is all.

money, yes.

gamers, no.

[Anonymous Coward]

Re: Fuck E.A

They publish good games... but yeah, agreed.

[FrankAlphaXII]

Re: Fuck E.A

But we're all supposed to like pay-to-win and day one DLC. Get with the program!

[Dan 55]

Re: Fuck E.A

Why's he bothered operating at scale? EA drops server-side support for multiplayer as soon as they can.

Not that I care about multiplayer but they make it affect single player to get you to play it in the first place. A year after launch multiplayer is a desolate wasteland and you can't progress in single player because you don't have the MacGuffin which is only available in multiplayer.

[Voland's right hand]

That works for a simple network

The approach does not stand a chance for a complex large scale network connected to the Internet.

1. Routing protocols (and their implementations out of which ~95%+ are commercial) have had decades to sort out feedback loops and stability issues. You do not get any of that if you start trying to code "direct network control" yourself. As a result you quickly learn that optimal control is hard. It is one of the highest paid areas in math for a reason. It often takes man-millenia to learn that too (and some people and companies are yet to learn it to the full extent).

2. If you want to participate in the Internet as an equal you need to peer with other people and TALK THE RIGHT LANGUAGE. That means talk BGP and not talk gibberish. If you think that you will be tolerated until your developers polish their home grown implementation, well, think again. I highly doubt it.

[CheesyTheClown]

Re: That works for a simple network

Let me come to the table on this. As a former developer of infrastructure networking equipment scaling from chip architecture to routing protocols as well as feeding my family for 5 years by being a Cisco network engineer and quite successfully to now working as hard as I can to automate out as many low level network consultants as possible.

Interior gateway protocols are long overdue for a refresh. The fact that we still run internal networks as opposed to internal fabrics is absolute proof that companies like Cisco, HP, Juniper, etc... are far out of touch with modern technology. The simple fact that we need IGPs is fundamentally wrong.

We depend on archaic standards like OSPF, IS-IS, EIGRP and RIP for networking and all four of these architectures are absolutely horrible and the only redeeming feature they have is that they're compatible with other vendors and old stuff. OSPFv3 with address family support is possibly the worst thing that ever happened to networking.

As for BGP. Don't get carried away. BGP as a protocol will remain necessary, but it's for the purpose of communicating between WANs. BGP is less of a routing protocol as opposed to a dog pissing on a tree to inform the world who owns which IP addresses. BGP doesn't really route so much as force traffic in a general direction. There are multiple enterprise grade open source BGP implementations out there and there's no reason to make your internal network suck because you are concerned about BGP support.

Peering to the Internet requires edge devices which may or may not speak BGP.

When you design a modern network infrastructure, you can completely disregard inter-vendor operability and design a fabric instead. There's a few things you probably want to do. Instead of inventing new fiber standards, it would be profitable to attempt to depend on commercial SFPs. As for vendor codings, I spent a long time making different vendor's SFPs work with my hardware... those codings actually mean something.

So... consider this. Imagine building a network based mostly on a new design where the entire enterprise is a single fabric. By this, I mean that you have a single router for the entire enterprise. That router is made up of 10-100000 boxes which all speak proprietary protocols and are engineered for simplicity and actually route traffic intelligently... without any switching.

You may think this is unrealistic or stupid, but it's really quite possible to do with far fewer transistors than you would use to support modern standards based layer-2 and layer-3 switching. Eliminate the routing table from your network altogether and instead implement something similar to Cisco's fast-caching forwarding mechanism with centralized databases for IP management.

Then to connect to the outside world, you simply buy a Cisco router or three and connect them at the edges.

I can say with confidence after considerable thought (years) on this topic that there's absolutely no reason this couldn't be much simpler and cleaner than modern networking and while three-tier network design would still make sense... or at least spine-leaf... any partial mesh with no single point of failure would work without any silliness like "you need to aggregate your routing tables to keep your routing table small."... we are long past the point where routing table lookups are O(32 > n > 0) where n = bits complexity. Then route learning via conversational characteristics would keep the per interface FIB small.

So... let's be honest... a developer can see the problem of networking clearly ... especially if they know networking.

A network engineer starts by spouting about how things like BGP are really hard... fine... use it as a boundary and stop filling my network with that crap... buy someone else's box for that or run a Linux box to do it.

[Anonymous Coward]

"a developer can see the problem of networking clearly ... especially if they know networking."

I'd say "only of they know networking". I can see many ways developers without a clue about networking can fire in their feet trying to reinvent the wheel.

[Rob Crawford]

Re: "a developer can see the problem of networking clearly ... especially if they know networking."

Available data seems to imply that deveropers know very little about developing (unless cut and paste from examples on the internet counts as development)

sadly I know of way too many 'network engineers' who do the same thing <sigh>

[Anonymous Coward]

Re: That works for a simple network

I think you'll find that's how Google for one actually runs their internal network :-)

https://www.networkworld.com/article/2189197/lan-wan/google-s-software-defined-openflow-backbone-drives-wan-links-to-100--utilization.html

However, I think you'll find that for those of us for whom customer traffic is a major portion of what is running through their own networks (most of what is running in Google's is Google-Google traffic, and much of the actual customer traffic is pushed to the edge or a CDN) will want to be able to manage exit points intelligently, and that means knowledge of the edge becomes essential..which incentivizes the use of BGP. A lot of service providers (and even larger content providers) have settled on an internal MPLS mesh to allow more intelligent traffic engineering than BGP alone can do, plus the ability to make some routers in the core "dumb", speaking MPLS and RSVP/LDP only.

[Etherealmind]

Re: That works for a simple network

I love everything about this comment. Bravo!

[fibrefool]

cheesy really is a clown...

...or at least needs to read up on recent developments.

the MSDC crowd have already ditched the IGP and run a pure eBGP environment for their leaf/spine fabrics. Once you have a dense, and regular, topology BGP turns out to be a better choice than an IGP. They've also turned summarisation off (doesn't work out so well if you put all the spines in the same AS but don't connect them to each other).

but for the SP WAN you really do need a link-state IGP (i.e. OSPF or ISIS). The topology is just too sparse and irregular, to do otherwise.

and in terms of "route learning via conversational characteristics" we already figured that out years ago with LISP.

at any rate the guy from EA sounds like he's parroting what the Stanford "SDN" guys were saying a few years back. Had they been right OpenFlow might have taken over the world. Looks like it didn't work out that way...

[Anonymous Coward]

Re: cheesy really is a clown...

So... let's be honest... a developer can see the problem of networking clearly ... especially if they know networking.

Very few do. Properly. Under properly I mean after seeing both sides of the coin - the Service Provider and the Vendor.

In fact, based on my own experience of working in a Tier 1 equipment vendor and several large Telcos I can tell you that you can count the people who really do within any one of Cisco, Nokia, Juniper, Google, Facebook, Microsoft, etc before running out of fingers on both hands. So in total, after adding Tier 2 vendors and the few people still at Telcos, you are looking at under a few hundred people worldwide.

We pretty much know each other too (or at the very least have common acquaintances).

I do not recall the EA clueless clown being one of them though. He sounds like someone who has had his eyes glazed by one of the Stanford idiots. That is how they got their single digit serial number Teslas (they are not into Ferrari, it's not the modern valley spirit) without producing anything working besides buzz for the last 5+ years.

[razorfishsl]

Re: That works for a simple network

Simple cisco equipment sucks cock as regards security.

Why compromise a little bit of your system when you can compromise it all?

Then there is the issue of something called the Sherman act.

Developers "develop" and a developer who works on software is called a "software developer" a developer who works with networks is at least called a "network engineer", just becasue you have the "mind" for software , does NOT mean you have the mind for networks or indeed visa versa.

What this guy suggests is that be default software engineers make good systems designers, be it network, cloud or mobile phones, after all a mobile phone could be built with cloud resources.

The one thing that everyone overlooks , is that if something like NK kicks off, then any war manufacturing will rapidly come to an end... a single air burst Nuke could completely decimate all technology & manufacturing.

[Ole Juul]

I think he got it wrong.

“The networking ecosystem is too fragile and slow, too hard for users to participate in,”

Yes, it's hard for users to participate on the deeper levels, but the networking ecosystem is not so fragile. That's how it got the way it is. However, if this guy gets his way, we'll certainly learn the real meaning of fragile.

As for slow, well that's mostly a political problem, at least in North America. Talk to your politicians about some anti monopoly controls.

[h3nb45h3r]

'users buy into a vendor's approach to running networks'

Surely IEEE standards and standards of that ilk are created to prevent propriety network solutions.

I appreciate people will still use vendor driven solutions if they don't have their own network team and outsource to vendors professional services, but every project I've worked on stipulated COTS products and non propriety network configurations (so no EiGRP, despite no longer propriety etc.).

What about basic things such as network segmentation? InterVLAN policing of traffic? 802.11 wireless standards? 802.1x and 802.1ae protections?

[Anonymous Coward]

What we need is gamification of networks...

Races to deliver packets first, kicking packets around to score in the right port, shooting down malicious packets, building your VLAN empire, etc...

[Anonymous Coward]

Hmmm

Wonder how long that will be the mantra.

My guess is until the developers (may not always be security aware) accidentally mis-configure (or leave settings as default) and EA lose the code to an about to be released game.

[sjiveson]

Cloud

I think everyone so far has missed the point that Peyton Koran said cloud was the 'game-changing' answer. No need for most networking vendors and their over-priced products and support, STP, VLANs, HSRP, IGPs or most of what's been mentioned thus far.

As an aside, where routing protocols are concerned, there are plenty of very good FOSS packages available and in use today (without the need for Google scale). Linux in general now has a highly capable and performant networking stack and feature set. Whilst performance will never match an ASIC, feature wise its comparible with 80% of what most 'top' network vendors provide for silly money running on a low end Intel processor in a green 1RU metal case.

[Sir Runcible Spoon]

Re: Cloud

Everyone seems to be focusing on the software aspect of routing. What about the physical?

Plenty of enterprise architecture revolves around processing packets very quickly, and in parallel with other networks that might be logically separated (but on the same physical links).

I can understand that there are savings to be made in a server based approach, but from a security point of view that's always just going to introduce more ways to circumvent your policy control points.

Security engineers won't necessarily be aware that their virtual firewall can be bypassed by a bug in the underlying host that is subject to a different patching/update policy and not necessarily under their control.

[Blotto]

Re: Cloud

so how does everyone connect to the cloud and how does the cloud connect to itself and others?

People don't seem to understand what a data network is or its significance in enabling everything else that runs on it.

People don't realise their cars contain high speed data networks, or the mobile phone masts are connected via high speed nets or even that the analogue phone lines are now actually digital, with voice being encoded and sent along high speed data network from the cab or exchange. if 3 or more machines need to connect then they will do so likely over a high speed network with its own rules and processes that at some point will interface with other networks that have their own rules and processes and all needs to be seamless to the user.

We all want it reliable, scalable, extensible, quick, secure and above all cheap. The cloud is not the answer to this EA chaps networking woes, its actually a huge risk to him as he won't have control.

[Anonymous Coward]

Remind me...

...is this the same EA that have had multiple outages this year?

OH I forgot "Cloud". where 95% up time is classed as excellent.

[Tikimon]

“The networking ecosystem is too fragile and slow, too hard for users to participate in"

So the users can't handle the existing networks, but are somehow going to design their own on the fly? How the bleep does that work?

[Christian Berger]

Essentially its about detecting crap

Unfortunately we live in a world with lots of crap. So as always:

Use well defined standards with more than one implementation.

Check for interoperability

Avoid having only one vendor

Avoid people who buy you lunches, their only useful function to you is to lend you equipment for tests.

[Etherealmind]

Re: Essentially its about detecting crap

Why should I test ? Equipment should work as promised and returned for credit if faulty.

[Christian Berger]

Re: Essentially its about detecting crap

Well yes, but replacing equipment while it's running in the field is very expensive, and most vendors will try to weasel themselves out of their liability. Essentially it would mean that you have to do extensive fault analysis on a device which is currently running on a productive system.

Most companies won't even have the equipment to fully diagnose a problem like a faulty implementation of Ethernet link negotiation. Without that most vendors will simply shrug off the problem as they can always blame it on other components.

[Anonymous Coward]

Learning fatigue

Just that something is hard is no indicator that it needs to be replaced, brain surgery is I think generally considered hard because it is interfacing at a simple "cut here" level with a complex and highly evolved system.

I sometimes find people who are specialists in one field consider other areas irritating because they are too complicated to master in the time allocated, I'm not saying there aren't ways to improve networking but listening to one field like gamers on how it "could be better bro'" probably over simplifies the issue and will ultimately fail to improve networking for the wider user base unless the full user requirements are budgeted into the redesign

[Christian Berger]

Well we do have a different problem now

We have simple solutions to simple problems, but then someone claims there to be some usecase that doesn't actually exist (or only exists because of stupidity) which results in people replacing something simple with something _much_ more complex.

Typical examples are HTTP/2, SystemD or UEFI.

[steviebuk]

The same EA...

...they release Simcity 5 that everyone hated. The same EA that managed to kill the Simcity franchise with that release. And the same EA that didn't have adequate servers setup for the release of Simcity 5 so everything was overloaded and no one could play.

If you fired your network admins and got the developers to do it, the developers I know, they'd be no security. EA are idiots. Don't listen to the bullshit they speak. The amount of games they've screwed up over the years and destroying the once loved Maxis.

[Anonymous Coward]

Smart guy

where is peyton the magnificent working now? Not sure at EA any longer during his 1+ month career there. It is difficult to keep up with his many jobs in the past year. He must be in very high demand!

[fghdfgh]

First, layer three switches use ASICs for most functions. That allows them to perform switching functions much faster than generic x86-based servers. which rely much more heavily on their CPUs and software. Second, network engineering is a very complex field. You have to study it full-time and work with the technology full-time to become proficient. I wouldn't just take a developer, who may be good at OOP, Java, and so on, and ask him to configure our BGP peering relationship with our ISP, for example. You'd have to spend weeks training them in BGP before setting them loose. And that defeats the whole purpose of not using network engineers, because network engineers are already trained in things like BGP! That's one technology but there are hundreds more. I can't believe this guy was hired on as a "technology director" because he doesn't really seem to really understand networking.

[jase_san99]

Advise for networking using Win NT

Hi All Win NT experts here, need an advise here.

I have 2 Win NT computers linked together by TCP/IP serial connection. However, at times the communication just break off without any warning or error. I wanted to write something (a script or autobat file) that will constantly monitor the communication and give a warning once it break off. Is there any software or script that I can use to do that? Hope to hear from the experts here. Thanks.