ISU Network Memo

From New IAC Wiki
Revision as of 02:03, 31 December 2010 by Oborn (talk | contribs) (Protected "ISU Network Memo" ([edit=comp] (indefinite) [move=comp] (indefinite) [read=comp] (indefinite)))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Arbitrary limits on connected computers

The undocumented limit on the number of machines connected to a single netel provided port has little to no security benefit and is detrimental in many situations.

The existing security restrictions that limit the migration of MAC addresses between ports works well and has desirable security benefits. The limitation of each port to only 10 connected devices has little benefit because any MAC or IP address spoofing attack would be shut down quickly.

There are many situations where legitimate uses would exceed the limit. In the IAC server room we require gigabit connections between our servers in order to allow our backup programs to complete in a reasonable amount of time. Currently branching a gigabit switch off of the netel switch allows this easily and cheaply. Using one netel port per server would either incur a very large cost per port, or would incur a large cost and necessitate a private back-end network for data transfers.

Additionally, with the rise in server virtualization, a single machine could easily exceed the per-port limit. One dual-quad core server can easily host 8 virtual machines, and with 2 IPs would fill the allotment.

There are other instances such as the instrumentation racks where electrical concerns make connecting more than 10 devices desirable. In order to avoid electrical noise, our instrumentation racks are isolated from the network with fiber uplinks. Using multiple netel ports to accomplish this would not only increase complexity, but would open the possibility of many points of failure in transceivers and other networking equipment where adjacent devices couldn't talk to eachother because of a problem half-way across the building. This possible disruption in our bread-and-butter service would have dire consequences. Because of the nature of our facility, different groups from around the world could come in with completely different equipment week-to-week and may necessitate connections for any number of devices.

Additionally, false errors in network problem detection, while uncommon, are disrupting to work, especially when they happen at random times with no known cause and require manual intervention from netel staff to remedy.

Some of the decisions of netel seem to evolve with no external communication. In fact, the 10-device limit was unknown to me or any other on-campus administrator I talked to until I had critical server randomly cut off with no warning after-hours.

Finally, the communication of problems on the network is almost non-existent. If violations on netel policy are severe enough to warrant cutting users off from the network, disrupting thier work, and causing wasted time and resources, then these same violations should warrant immediate notification of responsible computer people to help fix the problem. All too often major network failures are apparent to netel staff upon inspection, but cause hours of both user and computer staff time to troubleshoot what should be readily known.