Hardware Requirements

To run FreeNAC, you'll need

• a Linux server (or VM) with FreeNAC installed
• a Cisco Switch
• a Windows PC to run the Windows Administration User Interface
  (this software can also run from a Windows share, and does not need to be actually 'installed').

FreeNAC server hardware requirements

Example: a site running with ~2'000 active end-devices. The server is rarely loaded (CPU or I/O). The slowest part is the Windows GUI with its complex SQL queries - not the VMPS back-end.

• A PC server which is compatible with the brand of Linux you choose.
  The FreeNAC core team use Ubuntu now (so we recommend the latest ubuntu stable server release), but Suse, Fedora, Gentoo, Rehat/CentOS have been used too. Solaris has also been used. Ironically, it can be more difficult to get the non-free, Commercial Enterprise versions of Linux working (RedHat, Suse) since the software is older and not all graphics libraries may be available.
• Disk
  • A hard-disk of at least 20G, recommended 100G: the more the better for backups.
  • Have a second disk for backups or RAID, for additional data security. Ensure the RAID system is Linux compatible.
  • IDE is fine, but SCSI or SATA are often more reliable, faster and you can boot from each disk without changing cables.
• Network Interfaces: Have two if possible.
  The second interface is useful for a dedicated switch management, or backup network. 100Mb speed is fine (Gb is not necessary).
• CPU is not a bottleneck, 2GHz should be fine.
• Memory is always good for databases. 1GB will work fine, but the more the better.
• A dual, hot plug power supply improves reliability.
• A dual, hot plug fan also improves reliability.
• Remote console management should be included in the Server Bios (e.g. HP Lights out, Sun LOM, Dell DRAC5), for easier remote installation, troubleshooting and monitoring of hardware status.

Its recommended to have at least 2, and perhaps 3 servers. If you are used to Virtual Machines, do the Master as a VM, and one or more replicas as 'real' machines. Point the switches at the replicas, and use the master for serving GUI requests, scanning and polling switches/routers and processing syslogs.

By doing the master as a VM, snapshots can be used before system upgrades, and roll backs are easier.