University of Houston Uses NetMRI
"We've lost control of a lot of best practices over time. (NetMRI) is bringing them back into the fold. Now we've got [everything] on the radar...It takes a long time to find these things in manual mode. This just automates the process."
—Charles Chambers, Manager of Network Planning and DevelopmentMore Customers
The Network Monitor, Volume 1 Number 3
Take the Next Step:
- Networks: Hot Standby Router Protocol Prevents Network Problems Before They Happen
- TACACS+...(Part One)
- Network Management Wood Chucks
- Consultant Profile: Marty Adkins
- Annapolis: Hands-On Classes, First Class City
Cisco Hot Standby Routing Protocol Solves Problems Before They Start
Network administrators who are designing, building, or running fault-tolerant networks are often in the hot-seat. How do we design the network to fail over to backup routers and paths as quickly as possible?
A fault-tolerant network will likely have two routers servicing each LAN segment. If one router fails, we want the end systems to automatically switch to the alternate router. There are several mechanisms for implementing this functionality. Each has its own set of strengths and weaknesses. The mechanisms include:
- Multiple default routers
- Wire-tap the network routing protocol
- ICMP Router Discovery Protocol (IRDP)
- CiscoÕs Hot Standby Routing Protocol (HSRP)
Multiple Default Routers
Each end system has to support the configuration of multiple default routers and a method of switching between them when the failure of the primary router is detected. Few end systems support this mechanism (Unix typically does not), making this a poor general solution.
Wire-tap The Network Routing Protocol
The end systems must determine (or be configured for) the routing protocol in use on the attached LAN segment and participate in the protocol to the extent necessary to learn routes to external networks. Most typically, the RIP routing protocol is the network protocol used because participation is limited to simply listening to the updates being sent by all routers on the LAN. However, many sites are now using more modern routing protocols (OSPF or EIGRP). This implies also configuring RIP on all routers on each LAN segment just to let the end systems know about the existence of those routers. Using the default RIP timer of 30 seconds and three updates to detect a failed router yields a 90-second time to switch to the backup router. Another assumption is that all the workstations are capable of running a RIP listening process -- something that many PC-based TCP/IP implementations do not supply. Again, this is not a very general solution.
By default, Cisco routers will reply to IP ARP requests made for off-net destinations for which they have routes. For this mechanism to be effective, the end systems must have their IP subnet mask configured to treat all off-net destinations as if they were attached to the local network. For example, to reach all subnets of 184.108.40.206, one would have to use a subnet mask of 255.255.0.0. On some systems (typically Unix), a default route to the local interface will suffice to tell the system that all destinations should be treated as if they were on the attached LAN segment. The problem with this approach is that once the ARP request has been satisfied for a given destination, it is not repeated until the ARP cache entry is cleared (on Unix this is typically 20 minutes).
ICMP Router Discovery Protocol (IRDP)
IRDP (described in RFC 1256) is based on ICMP messages being multicast from all routers on a LAN segment. The end systems hear these multicasts and learn the presence of each router and its priority relative to the priorities of the other routers on the same segment. When an end system boots, a separate ICMP message is used to request that all routers announce themselves to the LAN. End systems which implement IRDP also conform to the Host Requirements standards, which require them to look for alternate routes if TCP connections become stalled. While this is an Internet Standard, it is only implemented in relatively new and featureful IP implementations. Check with your operating system or TCP/IP implementation vendor for support of this feature.
Cisco's Hot Standby Routing Protocol (HSRP)
HSRP is a nifty protocol that shifts the function of selecting a backup router out of the end systems and into the network (well, into the routers). The idea is to create a "Phantom" router to service the high availability LAN segment (13,677 bytes).
In this example, both London1 and London2 are located at a London office and are configured to be part of a single HSRP group -- thus creating the "Phantom" router. The configuration of these two routers, with London1 as the primary and London2 as the standby router is shown below
interface ethernet 0
ip address 220.127.116.11 255.255.255.0
! "Phantom" is at 18.104.22.168
standby 2 ip 22.214.171.124
! Make this the primary router
standby 2 priority 110
! Preempt the backup if we come back
standby 2 preempt
! Reduce our priority if our serial
! goes down
standby 2 track serial 0 110
interface ethernet 0
ip address 126.96.36.199 255.255.255.0
! "Phantom" is at 188.8.131.52
standby 2 ip 184.108.40.206
! Make this the standby router
standby 2 priority 90
! Reduce our priority if our serial
! goes down
standby 2 track serial 0 90
These configurations create the "Phantom" router with an IP address of 220.127.116.11 at a MAC address of 0000.0c07.ac02 (the MAC address is created from 0000.0c07.ac**, where "**" is replaced with the HSRP group number).
By default the two routers exchange HSRP messages every second and the standby router will take over the IP and MAC address of the "Phantom" if it does not receive at least one HSRP message every three seconds. However, one note of caution -- on access routers (4000 and 2500), the backup router's MAC address changes to that of the "Phantom" if the primary router fails. This does not adversely affect most network protocols and provides the rapid failover that is desired.
Reviewing our example shows London1 configured as the primary router and that it will pre-empt London 2 if London 1 fails and is then returned to service. Each router will have its priority significantly decreased if its Serial 0 interface fails. This will allow the standby router to immediately assume the role of the "Phantom" router if the primary router's serial link fails.
HSRP is currently supported on Ethernet, FDDI, and Token Ring networks. Later IOS releases support multiple HSRP groups on the high-end routers (7000 series). More detailed information can be found on UniverCD and by searching for "HSRP" on CIO. The Hot Standby Routing Protocol is a very useful addition to the network administrator's toolbox for designing and building fault-tolerant networks.
TACACS+ Solves Security Problems Of Dial-in Access Networks
Today, networks are providing dial-in access to more and more people. Low-cost, high-speed modems and inexpensive ISDN service are giving telecommuters and mobile users convenient access to corporate-wide network-based resources. Similarly, the explosive growth of the Internet has fueled the need for dial-in access available to the general public.
Companies providing dial-in network access need to secure their systems and corporate information from unauthorized users. Internet service providers need to provide Internet access only to authorized customers. Network Access Servers (NAS) must provide mechanisms to allow dial-in access that will fulfill all these requirements.
A mechanism is also needed to require network administrators to login on each network device when performing maintenance or troubleshooting. This allows the management staff to easily answer the "What changed last?" question regarding changes in the network's operation.
Fortunately, Cisco has been addressing these needs. This article describes the components of dial-in access security, and its implementation in various protocols.
The Components Of Access Security
The three major components of network security are authentication, authorization, and accounting (AAA).
Authentication determines who you are and if you should be allowed access to the network. It allows network managers to bar intruders from their networks. Simple authentication methods use a database of usernames and passwords while more complex methods use one-time passwords.
Authorization determines what you are allowed to do. Authorization allows network mangers to limit which network services are available to different users. It helps to restrict the exposure of the internal network to outside callers and simplifies the view of the network for the less technical remote access user. Authorization allows mobile users to connect to the closest local connection and still have the same access privileges of their local networks. It also can specify what commands a new network administrator can issue on specific network devices.
Accounting keeps track of what you did and when you did it. Network administrators may need to bill departments or customers for connection time or resources used on the network (bytes transferred). Accounting also can track suspicious connection attempts to the network.
Central management of access security servers is desirable. A client/ server architecture allows all security information to be located in a single, centralized database, instead of being scattered around a network in many different devices. Changes to the database are made in a few security servers instead of in every NAS in the network. This type of design allows for easy scalability and extendability.
To address these security issues, Cisco Systems developed the Terminal Access Controller Access Control (TACACS) protocol many years ago. TACACS forwards username and password information to a centralized server, which verifies the validity of the password and tells the NAS whether to allow network access. No other functionality is supported, which implies that TACACS only supports the authentication portion of AAA.
Cisco extended the basic server concept, creating XTACACS, to allow multiple servers and to record the length of time a user was logged in. The logging was accomplished through use of the Unix login accounting system. Both protocols use UDP as their data transport mechanism. The server code for both TACACS and XTACACS has been publicly available from Cisco, with no support provided. The Cisco user community has been active in enhancing the XTACACS server, and this is the server software that most sites are running today.
Radius, a protocol and database server, is a major competitor to XTACACS. Radius is also implemented as a client-server system, similar to the XTACACS system. All authentication and network service access information is located on the server. The latest version of Radius now supports authentication, authorization, and accounting. Like the TACACS and XTACACS systems, its server is only available as free source code with no vendor support.
The market is wide open for a system to take a leadership position in access security. That system is TACACS+.
The TACACS+ protocol includes all three components of network access security: authentication, authorization, and accounting. The data transport used is TCP, which provides a reliable connection between the client and server -- an important aspect for guaranteed network security and accountability. The NAS sends authentication requests to the TACACS+ server, which verifies the password provided by the user and returns a success or failure response to the NAS.
In the next issue of The Network Monitor, this article will conclude with an overview of TACACS+ and its key features.
Network Management Wood Chucks
How much wood could a woodchuck chuck if a woodchuck could chuck wood?
Applied to network management, how many devices could a network management station monitor if a management station could monitor devices? We found a surprising answer to this question: not as many as we would like.
Our investigation of network management systems began over a year and a half ago, prompted by several consulting assignments we performed. In each assignment, we found the tools are expensive, use significant network bandwidth, require very large workstation platforms, and provide little in the way of useful results.
With this experience, we decided to determine whether SNMP was really as inefficient as it seemed on the platforms we had used. To do this, we took the Carnegie Mellon University SNMP package and added our own code to create a highly efficient SNMP polling engine. We then selected 12 router variables (CPU utilization, buffer space, etc.) and 12 interface variables (ifInOctets, ifInPackets, ifInErrors, etc.) to monitor on a five-minute basis. In testing our polling engine, we were able to monitor (on a scaled up basis) approximately 200 devices over a 14.4Kbps link. This proved to us that SNMP is an efficient protocol and that we needed to look for vendors who had designed efficient network monitoring systems.
Our search turned up a company called Netlabs (which has been acquired by Seagate, the disk drive manufacturer). One reference site we contacted was using a Netlabs system to monitor 10,000 devices. This was an order of magnitude larger than any other system we had seen and matched what we thought SNMP was capable of handling. At the time, Netlabs was marketing a DiMONS management platform and applications called NerveCenter and Asset Manager.
Since this time, Netlabs has dropped support for their platform product (DiMONS) and has focused on building applications to be layered on the popular network management platforms such as HP OpenView.
What makes this technology so great? Most network management platforms are great at reporting network events. In fact, they are so good at this that most network managers are soon overwhelmed with network events, many of which are spurious or transient. NerveCenter provides a means of acting upon received events and performing additional specific actions. For example, the management platform reports that a particular router failed to respond to an SNMP query. This should not, by itself, cause a network manager to be alerted. Can we ping the device? NerveCenter can be configured to automatically probe the network to attempt to determine whether the device failed, or is it remote to some other network failure.
On the performance side, we also have found that most management platforms stall when presented with a large number of devices to manage. With NerveCenter, we are able to significantly expand the number of managed devices. This is very important to sites that need or wish to monitor and manage a large number of devices from a single workstation. The real key is efficient use of SNMP, as we discovered in our own research. The staff at Netlabs has done a very good job of being efficient.
By selecting a good management platform and adding the proper management power tools, we can significantly increase the power of our existing management stations. The advantages are several-fold. We reduce need for multiple large management stations. The administration of multiple management stations is minimized, and the control and monitoring of the network is more centralized, increasing communication between the management team members.
Consultant Profile: Marty Adkins
CCIE Solves Network Problems In And Out Of The Classroom
Marty Adkins, both a Cisco Certified Internetwork Expert (CCIE) and a Cisco Certified training instructor for CCCI, is well-prepared for the many questions and network problems that students bring with them to the classroom.
"People come to class with laundry lists, but I find that actually makes teaching more enjoyable," says Marty. "Instead of theoretical problems, you help solve real ones."
Marty has spent almost two decades analyzing and solving information technology problems. Twenty years ago, after receiving a B.E.E.E. from Vanderbilt University (later he earned an M.S.E.E.), Marty started designing digital circuits for Westinghouse.The 18 years he spent there gave him a very diversified technical background, including development of both software and hardware solutions. The years at Westinghouse also gave Marty a historical perspective on the development of LANs, WANs and the current client/server environment, as well as experience being a system administrator. Early on he helped set up and network the first DEC VAXs and handled the in-house support.
This wealth of experience is brought to CCCI's classrooms where Marty brings the experience to the courses he teaches, including Cisco Internetwork Troubleshooting (CIT), Introduction to Cisco Router Configuration (ICRC), and Advanced Cisco Router Configuration (ACRC).
Getting More From Training
As much as possible, Marty tries to customize course content for the skill levels and interests of each student. That way each one gets more out of the course.
In one situation, Marty went out of his way to accommodate a group of knowledge-hungry students, wanting to learn more about TCP/IP. Because TCP/IP was not in the curriculum for the particular course, Marty held a "special lab" for the interested students after regular class hours.
Some students come to a course a little intimidated by the subject matter, fearing they won't be able to learn everything covered. But by keeping the classroom environment relaxed, and spending breaks and lunchtime with students who need extra help, Marty helps students leave with a solid understanding of the subject matter.
When Marty is not teaching, he's doing network consulting jobs. Recently, he was asked by a large pharmaceutical company to evaluate its network in regard to anticipated bandwidth/traffic problems resulting from planned imaging operations. The company was planning to invest heavily in a higher speed network and expanded server capacity.
Marty found that the imaging applications would not create significant bandwidth problems, but he did find inefficiencies in the company's Novell network. Without spending money on new technology, the company reduced traffic and also recovered capacity on their servers. Which role does Marty enjoy most—consulting or teaching?
"I like both, and I think you need both," says Marty. "If you never leave the classroom to see what's happening in the real world, you become stale."
Annapolis: Hands-On Classes, First Class City
Annapolis, Maryland, home to Chesapeake Computer Consultants' headquarters and Education Center, offers trainees easy access and resort-like amenities.
CCCI's Education Center is the site for several of the company's advanced courses, such as Cisco Internetwork Troubleshooting and Advanced Cisco Router Configuration.
Annapolis is less than a half hour by expressway from modern Baltimore-Washington International Airport (BWI). Proximity to Interstate 95 and a host of interconnected super-highways make driving to Annapolis convenient and fast. The city is famous for delightful dining and for its antique and specialty shops and has many first class hotels and historic inns.
On the banks of the Severn River is the sprawling campus of the United States Naval Academy, with special events and attractions for all to enjoy. There are many other attractions in Baltimore, located 25 miles to the north, and in Washington, D.C., which lies 30 miles to the west.
CCCI's superior technical education facilities, combined with hundreds of interesting activities in the region, make Annapolis a great Cisco training and entertaining destination.
Copyright © 1996 Chesapeake Computer Consultants, Inc. All rights reserved.