Proposal: Networking has been tried in various forms (all of which are gone now) many times.
All have been closed as duplicates of Server Fault.
Why do we need another networking proposal that overlaps completely with Server Fault?
Network design and engineering has almost zero overlap with systems administration, which is why there is so little networking content on Server Fault. Search for terms like "Cisco" and "router" there and you'll find very few questions and even fewer answers. This is because the very name of the site, Server Fault, implies that its focus is on systems administration.
Network engineering is its own category of profession and includes disciplines ranging from routing and switching to security to voice to data center technologies, and deserves its own site if Stack Exchange ever hopes to draw in network engineers as it has programmers and sysadmins.
And yes, most of the people supporting this proposal are new to Stack Exchange, precisely for the reason I've described: Prior to the potential of a networking-focused site, there simply hasn't been anything of general interest to us on the SE network.
Maybe thats your answer. When you say most people have a 51 reputation score and no other accounts its because most Networking People don't use the site because Server Fault doesn't provide adequate coverage of the topics that I work with like routers, ASA firewalls, ToR Switches and so on...
Networking topics are explicitly on topic on Server Fault. From the FAQ:
If your question is about…
- Server and Business Workstation operating systems, hardware, software and virtualization
- Enterprise storage, backup, and disaster recovery
- Network routing, switches, and firewalls
- Operations, maintenance, and monitoring
There are a decent number of questions (
networking is the 6th most popular tag on the site), and there are certainly a number of active SF users who know their stuff when it comes to networking.
Given all of that, I think having a separate site is a good idea. The Cisco tag is included on a little over 1% of the questions on SF, which is pretty slim - a lot of the networking tag is more on the server side of things. Actually working with the design and administration of networks is present on SF, but it's not thriving.
Having a focused site for the network engineering community seems very similar to the situation with DBA and IT Security sites. Both were always on-topic on Server Fault, but were created afterward in recognition of the experts in those fields doing better with a separate community.
There will certainly be some overlap with Server Fault, but that's fine - we have overlap with several other sites already.
To Warren and Renan
I am one of those low rep individuals that you are speaking of and to be honest, I had never heard of Stack Overflow or the Stack Exchange network of sites until Jeremy Stretch brought it up on Twitter. Our field of networking is quickly becoming more involved as a community and I think this site would be very beneficial to help others and get help from others. That is the reason I signed up and support this cause. I hope you all understand and just let the process speak for itself.
I work at a major University. We have a systems group and a network group for a reason. They are different disciplines. The network is more than the switch port. At Server Fault I'd expect someone to talk about creating trunks for VMs. maybe some VPN remote access methods. In Networking I'd expect to find answers on Layer 3 VPNs, dual hub single cloud DMVPN, and To discuss the finer points of Nexus deployment methods or Load Balancing. Server guys will not have these answers just as I can't answer stuff on the finer points of Debian or making Apache dance. We may all be Doctors but you don't see a GP for heart surgery.
Trends within the SMB market lead to a lot of "folks with many hats" types of roles. There is nothing wrong with that, and some folks prefer that route. In that realm, the concept of system administration typically also envelops the networking infrastructure - thus, your routing/switching infrastructure, your SAN, your IP telephony system, etc.
The influx of new users (like myself) are specialists in the umbrella of networking technologies - perhaps operators in larger enterprise teams, NOC engineers, consultants in the VAR space, etc.
There is a line between day to day operations and the planning/implementation/operation of larger scale (or perhaps just unique/complex) infrastructures. The relevance to sysadmin work is there, so I can see the argument from both sides. As others have pointed out however, the majority of the content in Server Fault pertains to sysadmin operations/planning/design versus network infrastructure.
I support the move for a separate designation, but if the stack exchange community disagrees, so be it.
I think the best test of this would be to re-post some of our example questions to ServerFault and gauge the quantity and quality of responses. In my opinion SF includes networking in-name-only.
Questions like the recent "When multicast client has obtained the first data packed (pim sparse) and switched to SPT, what happens when another multic source appears on the net?" may fall on deaf ears there.
I am at 51 rep as well so probably not going to get a lot weight behind this response, but there is a huge difference between a true network engineer and your IT generalist who happens to plug a few switches in or configure a firewall via the GUI. There is years upon years of expertise that goes into becoming the caliber of engineer that can design large telecom or massive datacenter networks. It is that type of expertise we hope to congregate and tap into here. I don't put myself in the former pool, but I do hope to be there some day, and feel that a community like this would be most helpful all of us who are involved networking.
If it has a hard drive in it, i am not interested in it.. i am wanting a community to discuss Cisco enterprise routers, switches, Cisco IOS command help, and certifications. Server fault does not address any of these. The above subjects are the only reason why i would frequent stackexchange. If this "networking" does not go through, i will not have a reason to go to stackexchange.
I'm a new "low rep" member here on stackexchange.com as well. I also heard about this proposal as a result of a tweet by Jeremy Stretch on twitter. I'm interested in Cisco (and to a degree Junos and other competitors) networking questions and answers. I just took a look at the Server Fault section mentioned above and see absolutely zero overlap in topics that network engineers would be interested in. Moreover, looking at the front page I do not see a single question that would be of interest to me as a network engineer. Sorry, server guys and network guys are not even close to the same in my book.
I don't know what happened. This was closed and now the proposal was reopened. On with it:
Just to make it clear: I think the network engineering field and the server administration field have no real overlap. They have well defined intersections but no network engineer would identify with a site like "ServerFault" and so this site will never attract networking traffic. There are over 200 people here, many of them networking professionals who committed to answer questions on the new site. That is a remarkable start.
If there is a dedicated site for network engineering and there are many professionals answering them then this will generate additional audience and I think will help this new site to get traction very fast.
For example, just look at http://blog.ioshints.info/ and see how many of these articles would be relevant to ServerFault audience.
On the other hand, no network engineer I know would ask questions at ServerFault because we KNOW that server administration is not our field of work. It's not OUR community. We would be allowed entry (as per the FAQ) but could not identify with it.
Please support this proposal to create a central place where network engineering questions can be asked in our own community.
I think the question domains (technology) is different enough to warrant two different question sites... I do server admin as well as network admin, yes, there is some commonality on the interface point between the two, but vastly different knowledge needed to admin the two. So I don't think this site would "steal" the server admin crowd away from ServerFault; they may even be glad to have our esoteric netadmin q's on another site and not crudding up their server questions site :)
I think a possible answer to your question could be answered with this type of example.
If you take a look in the enterprise's network field in this last years, subjects like BYOD became one of the majors topics & preoccupation to our managers and IT teams. Is true, that in some cases a NAC solution based only on 802.1X with a radius server will fulfill the security requirements of some companies. For this case, maybe ServerFault was enough to comment about various radius servers or for a Freeradius configuration... but, where should I look for the difference in the configuration on a Cisco, Juniper and HP switch in order to apply the 802.1X config?
At last, now let take this one step further and think that you need to check the device complies also some security policies or you need to do a MDM (Mobile Device Management). In order to resolve this situation, you will surely face today some issues with the design & configuration in a multi-network vendor environment. I do not think these questions could be resolved for example in the ServerFault forum.
We could continue the list with subjects like firewalls, load balancing, proxys, traffic classification, VoIP, wifi etc...
For my part I think a networking forum could have this place here.
Network engineering is a different area than system admin. One forum fits all doesn't work well. One field is irrelevant from the experience of the other. If a company let the system team do networking the result is pretty much a totally messed up network. Network engineers (especially in service provider) does not necessarily need to do much server admin and some server admins (at least those I met) don't think they need to know how traffic engineering works to do their job...The questions are at different level (network vs system).