Future Network Considerations
RMON2 defines the specification for monitoring traffic for distributed applications such as Lotus Notes, Microsoft Mail, and Sybase by outlining how logical filters can be constructed for remote agents. With this capability, the network manager can proactively monitor and troubleshoot any essential application-layer traffic within an enterprise network. RMON Alarms, Statistics, History, and Host/conversation groups are used for troubleshooting and maintaining network availability based upon application layer traffic—the most critical traffic in the network. What Is the Difference Between RMON and SNMP?Although the Simple Network Management Protocol (SNMP) is useful for monitoring network resources, it is geared toward node management rather than network management. SNMP is used to monitor device-specific information by polling different resources (routers, etc.) on the network but it provides no consistent view of overall network operation and health. SNMP also uses frequent polling as its foundation of operation. SNMP polling consumes valuable network bandwidth as well as network node resources such as router and server CPU cycles. On the other hand, if polling is done too infrequently, valuable information is lost. This is truly a catch 22 associated with managing an efficient network. Figure 12-4 shows the true extent of how SNMP consumes valuable bandwidth.
RMON addresses these problems by transparently monitoring network operation from a network agent. Various groups of information, defined in the RMON MIBs, allow an RMON agent to collect information on network statistics, hosts, and conversations. The RMON agent compiles this information by observing the traffic on the network. The polling that takes place between the management station and the probe is just to transfer statistics that have already been gathered by a RMON probe. A history group enables an agent to collect historical information about network operation, further reducing the amount of polling required. Other RMON groups set thresholds for any RMON-defined operational parameter, enabling management by exception. Traps are generated when the thresholds are exceeded. Conclusions on SNMP Versus RMONBoth SNMP and RMON are useful within a network. However, it is this author’s opinion that the future is going to be found in primarily using RMON-based solutions. There is a chance that the upcoming SNMPv3 will address some of its predecessor’s shortcomings. As with many things, only time will tell which becomes dominant—or maybe they both have a place. Internet Protocol Addressing v6 (IPv6)The Internet Protocol, Next Generation (also known as IPv6), was designed to combat the growing concerns of the quickly shrinking Internet address supply. IPv4 host implementations also lack essential features such as auto configuration and network layer security. IPv6 brings with it several advances in the field of Internet protocols. IPv6 is a set of specifications from the Internet Engineering Task Force (IETF) designed as a Darwin-like evolutionary step from IPv4—the current version. IPv6 provides expanded addressing, added security, and investment protection for those standing firm with IPv4. The following list covers several of the key advances included with the IPv6 proposed standard
The first questions you should be asking yourself is, “Why do we need another version?” The reasons for adding another version are numerous:
IPv6 is designed to interoperate with IPv4. Specific mechanisms were embedded within IPv6 to support an easy transition and compatibility with IPv4. IPv6 also supports large hierarchical addresses, which will enable the Internet to continue to grow. The address structure of IPv6 is designed to support carrying addresses of other Internet protocol suites, such as IPX. IPv6 also provides a platform for new Internet compatibility, to include support for real-time flows, provider selections, host mobility, end-to-end security, and auto configuration and reconfiguration. Each of the key advances in IPv6, as listed previously, are detailed in the pages that follow. There are many books and white papers available on IPv6, but none of them address the reluctance behind implementing it. Confusion and concern is to be expected regarding the massive change IPv6 represents to the networking arena as a whole. Nevertheless, some disturbing myths have surrounded IPv6. The following will address the myths surrounding IPv6. Myth 1: We Need IPv6 Because We Are Running Out of Address Space!There is a fact in this myth: yes, we will run out of address space in IPv4, but so will IPv6. The InterNIC is the authority that assigns IP addresses, and since 1991 the InterNIC has become more stringent about handing out IP addresses. However, most predictions for IPv4 address depletion state that will not happen until well into the next century. Fortunately, the creators of IPv6 have taken the 32-bit address of IPv4 and increased it to 128 bits in IPv6, which will provide us with: 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses You can figure out how to write that in words, but to me it is just a HUGE number of addresses. Estimates state that IPv6 will support thousands of unique addresses for each square meter on the surface of the earth.
|
EAN: 2147483647
Pages: 200