When White Seagull , SISL, and IMMS were first designed; our development specialists realized that current planned IP management solutions won’t position Service Providers and Enterprises for future growth because they are:
- Internally focused. Network Administrators will build IP provisioning, billing, and customer care management systems for their own networks -- but these tools will not offer management features across multiple networks. AT&T’s internal systems will be useless when Gillette demands performance monitoring across multiple Network Administrators.
- Proprietary by design. Network Administrators expect to create differentiation by customizing off-the-shelf tools, but this approach will further limit interoperability between different Networks or between the managed zones within an enterprise. If a carrier modifies the way front-office apps like Remedy accept trouble tickets, it will take weeks of custom coding before any partner can link to its customer care system -- even if the partner also uses Remedy software.
- Inflexible. Network Administrators have built management systems by cobbling together best-of-breed software packages with spaghetti code. The result? Innovation rates plummet because making any change requires launching a full-scale integration project. To upgrade to the latest version of Portal Software’s billing software, a carrier will need to recode all the links between Portal’s software and other packaged software in the OSS.
- Insecure. Traditionally NMS and the SNMP protocol have been synonymous with clear text open community strings being transferred on the wire as well as saved in the databases of NMS applications without any encryption. In other words; Known and widely used NMS applications are severely unsecured. Historically “compromised security” was sold to customers as the cost of doing network management. Security of SNMP was introduced through SNMP Version 3. Hence the significance of SNMPv3 support is really critical for building secured solutions.
Server System Requirements
White Seagull is supported on Windows 2003/2008 Servers with advanced server option while many well known management applications doesn’t support the Windows 2003/2008 Servers with advanced server option and Terminal Services.
White Seagull is not currently supported on Linux/Solaris Servers.
Features and Sub-applications
White Seagull management processes could be built to support almost all the features provided by other NMS applications like Software Management, Configuration Management, and Device Management to name a few; with the exception that White Seagull currently present graphical representation of devices in a form of Topology Maps.
White Seagull can support any managed device of any type and vendor provided that the vendor provides the necessary support for the appropriate MIBs on the managed device(s) that supports the application features required.
MRTG pros and cons
Pros: (Supported by White Seagull)
- Can only display 2 ObjectIDs in a single graph.
- No calculations or operations could be performed on the objects. It only scripts reports, and no concept of scripting the polling of those Object.
- No database, only text files to hold collected values. This creates scalability problems for MRTG.
- One web page plus a text file style database for each interface (object).
- No support for any type or level of inventory.
- Cannot handle or recognize any type of changes in network. Once it discovers a device it assumes that the number of interfaces and their associated statuses for example never changes.
- Static and rigid layout of graphs. Always title + labels + daily, weekly, monthly graphs + legend.
- Comprehensive layout of graphs. Daily, weekly, monthly and yearly graph.
- Has a scripting language for the graphs where the title, labels, legend, and x/y scale could be specified by the administrator.