Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Managing Scalable Network Growth

   

Contents Next >

Managing Scalable Network Growth

  

 

How to Best Use This Chapter

Save to MyCKS

 
ACRC Exam Certification Guide

From: ACRC Exam Certification Guide
Author: Clare Gough
Publisher: Cisco Press (Trade/52)
More Information

2. Managing Scalable Network Growth

The objectives for the ACRC exam for CCNP or CCDP certification are taken from the Cisco Web site at http://www.cisco.com/training, under the heading “Cisco Career Certifications.” The following table shows the ACRC exam objectives covered in this chapter and also provides the corresponding Foundation Routing and Switching exam objective number. The objective(s) that are explained within a chapter section are also listed at the beginning of that section.

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

81

Configure Cisco routers for scalable operation in large or growing multiprotocol internetworks.

1

82

Describe the key requirements of a scalable internetwork.

2

83

Select a Cisco IOS feature as a solution for a given internetwork requirement.

3

84

Describe causes of network congestion.

4

85

List solutions for controlling network congestion.

5

86

Introduction to managing traffic and access.

6

87

Configure IP standard access lists.

7

88

Limit virtual terminal access.

8

89

Configure IP extended access lists.

9

90

Verify access list operation.

10

91

Configure an alternative to using access lists.

11

92

Configure an IP helper address to manage broadcasts.

12

93

Describe IPX/SPX traffic management issues.

13

94

Filter IPX traffic using IPX access lists.

14

95

Manage IPX/SPX traffic over WAN.

15

96

Verify IPX/SPX filter operation.

16

97

Describe the need for queuing in a large network.

17

98

Describe weighted fair queuing operation.

How to Best Use This Chapter

By taking the following steps, you can make better use of your study time:

  • Keep your notes and answers for all your work with this book in one place for easy reference.

  • Take the quiz, writing down your answers. Studies show that retention significantly increases by writing facts and concepts down, even if you never look at the information again!

  • Use the diagram in Figure 2-1 to guide you to the next step.

“Do I Know This Already?” Quiz

These questions are designed to test not just your knowledge, but your understanding of the subject matter. It is therefore important to realize that getting the answer the same as stated in Appendix A, “Answers to Quizzes and Q&As,” is less important than your answer having embodied the spirit of the question. In this manner, the questions and answers are not as open and shut as will be found on the exam. Their intention is to prepare you with the appropriate knowledge and understanding to give you mastery of the subject as opposed to limited rote knowledge.

Figure 2-1. How to Use This Chapter

The answers to this quiz are found in Appendix A, “Answers to Quizzes and Q&As;, Answers to Chapter 2 Quiz.” Review the answers, grade your quiz, and choose an appropriate next step in this chapter based on the suggestions diagrammed in Figure 2-1. Your choices for the next step are as follows:

  • Read this chapter.

  • Scan this chapter for sections you need to review.

  • Skip to the exercises at the end of this chapter.

  • Skip this chapter.

Introduction to Corporate Networks—Growth, Scalability, and Congestion

Company networks are growing at a dramatic rate. When designing a network, the challenge is to create a system that will grow with the company and be able to deal with increased demand. Obviously, the size, nature, and maturity of the business will affect the demand for increased network resources.

Networking is still young. It has only very recently extended to the home and small business. Therefore, it is a safe assumption that networks and the demand for network traffic will continue to grow for some time.

In addition to the increase in the number of users, applications have become more complex, evolving into highly graphic and often interactive packages.

If the design and implementation of the original network has been well managed, network growth increases dramatically within the first year. Networks must therefore be adaptive to change in order to allow growth. (Instead of constantly having to buy new clothes for the sprouting child, we can just let down hems and lengthen sleeves.) Companies cannot afford either the capital investment nor the hours involved in accommodating a network that must be redesigned frequently.

The consequence of having a network incapable of scaling is that as it grows it becomes constricted, just like the child squeezed into a coat that is too small. The result within your company would be network congestion.

Identifying the Problem of Network Congestion

The ACRC objectives mastered in this section are as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

1

82

Describe the key requirements of a scalable internetwork.

3

84

Describe causes of network congestion.

4

85

List solutions for controlling network congestion.

Network congestion results, literally, when too many packets are competing for limited bandwidth. The result is similar to that of heavy road traffic: collisions, delays, and user frustration.

Problems Created by Network Congestion

The problems caused by network congestion are easily identified. By using network-monitoring tools such as Cisco's Traffic Director or a standard protocol analyzer, it is possible to ascertain the traffic volume on either an entire network or on individual segments. It is important to understand the context of the traffic flow within your network so that you can appropriately accommodate the requirements of the users and their applications, designing and building a network that will scale.

The traffic on the network typically follows the organization's business flow, responding not only to peaks and valleys in business cycles, but in the direction of the traffic flow, as well. Necessarily, the communication between the accounting department and the marketing department within the organization must be reflected in network traffic. The appropriate placement of network resources such as servers is another important consideration. The original design of the network and the placement of the servers dictate the traffic flow throughout the company. Poor design inevitably leads to congestion.

The next sections cover the following problems created by network congestion:

  • Excessive traffic.

  • Dropping of packets.

  • Retransmission of packets.

  • Routing tables may be incomplete.

  • Server lists may be incomplete.

  • The Spanning-Tree Protocol may break.

  • Runaway congestion.

Excessive Traffic

If the traffic volume outgrows the network capacity, the result is congestion. When this occurs on a single segment, not only is the capacity of the medium overrun—resulting in the dropping of packets—but also the medium can react adversely to excessive traffic. Ethernet has strict rules about accessing the medium. A physical problem—extraneous noise or just too many trying to access too little—results in excessive traffic, causing collisions. A collision requires all transmitting devices to stop sending data and to wait a random amount of time before attempting to send the original packet. Only the nodes involved in the collision are required to wait during the backoff period. Other nodes must wait until the end of the jam signal and the interframe gap (9.6 microseconds). If after 16 attempts the device fails to transmit, it gives up and reports the error to the calling process. If for this or any other reason the device fails to transmit and drops the packet from its buffer, the application typically retransmits the original packet. This may result in increased congestion that grows exponentially, which is often referred to as runaway congestion.

Dropping of Packets

One of the effects of congestion is that not all the packets can get through the network. Essentially, the queues and buffers in the intermediate forwarding devices (for example, routers) overflow and have to drop packets, causing a higher layer of the OSI model on either end device (for example, workstation) to timeout. Typically, the transport and/or the application layer has the responsibility to ensure the arrival of every piece of data.

Maintaining the integrity of the transmission requires the communication to be connection oriented, giving the end devices the mechanisms to perform error detection and correction (for example, the TCP layer of TCP/IP) through sequencing and acknowledgements.

Retransmission of Packets

If packets are dropped, the layer responsible for the integrity of the transmission will retransmit the lost packets. The session or application layer may not receive the packets that were re-sent in time, however, causing either incomplete information or timeouts.

Routing Tables May Be Incomplete

The application may be unaware that it did not receive all the data; this missing data may just appear as an error or may have more subtle and insidious effects. If the routing table of an intermediate forwarding device such as a router is incomplete, it may make inaccurate forwarding decisions, resulting in loss of connectivity or even the dreaded routing loop (see Figure 2-2).

If the WAN connection becomes congested, packets may be dropped, possibly resulting in partial routing updates being received. In Figure 2-2, for example, if Router X hears a full update, the routing table will know subnetworks 10, 20, and 30. Imagine that Router Y does not receive a full update from Router X. It only knows about subnetworks 20 and 30. When Workstation A tries to connect to Server B, Router X can direct the traffic to Router Y. In turn, Router Y can forward to Server B. When Server B responds, Router Y has no way to forward back to Router X, because it has no entry for the remote subnetwork 10. In a more complex environment, routing loops often occur.

Server Lists May Be Incomplete

Congestion results in the random loss of packets. Under extreme circumstances, packet loss may result in routing tables and server lists becoming incomplete. Entries may ghost in and out of these tables. Users may find that their favorite service is sometimes unavailable. The intermittent nature of this type of network problem makes it difficult to troubleshoot.

Figure 2-2. Incomplete Routing Tables Cause Loss of Connectivity

The Spanning-Tree Protocol May Break

The Spanning-Tree Protocol is maintained in each Layer 2 device, allowing the device to ensure that it has only one path back to the root bridge. Any redundant paths will be blocked, as long as the Layer 2 device continues to see the primary path. The health of this primary path is ensured by receiving spanning-tree updates (called Bridge Protocol Data Units, or BPDUs). As soon as the Layer 2 device fails to see the updates, panic sets in and it removes the block on the redundant path, falsely believing it to be the only path available. In a short time, spanning-tree loops and broadcast storms will cause your network to seize up and die.

This is one of the reasons that the industry moved toward a routed network solution. However, organizations are beginning to reintroduce spanning tree into their switched environments without any problems. This is due to the vast improvements in the hardware, the increased bandwidth, the use of VLANs to reduce the size of the broadcast domain, and in a Cisco implementation, due to the spanning-tree domain. Refer to the Cisco design guides for more information on these topics.

Runaway Congestion

When packets are dropped, requiring retransmission, the congestion will inevitably increase. In some instances, this may increase the traffic exponentially; this is often called runaway congestion. In relatively unsophisticated protocols, such as the Spanning-Tree Protocol, it is almost unavoidable, although others may have methods of tracking the delays in the network and throttling back on transmission. Both TCP and AppleTalk's DDP use flow control to prevent runaway congestion. It is important, therefore, to understand the nature of the traffic on your network when designing scalable networks.

Symptoms of Congestion

The ACRC objectives mastered in this section are as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

1

82

Describe the key requirements of a scalable internetwork.

3

84

Describe causes of network congestion.

The symptoms of congestion are intermittent. If the link is running near bandwidth capacity, and the connected devices are overwhelmed, any additional traffic will cause problems. Because the packets are randomly dropped, it is difficult to track where the problems have occurred. Therefore, the network will have equally random failures. The symptoms of network congestion are consequently difficult to troubleshoot. Because some protocols are more sensitive than others and will timeout after very short delays are experienced, however, the network administrator who knows his network well will soon identify these recurring problems. The following are three symptoms of network congestion:

  • Applications timeout.

  • Clients cannot connect to network resources.

  • Network death.

Applications Timeout

The session layer of the OSI model is responsible for maintaining the communication flow between the two end devices. This includes assigning resources to incoming requests to connect to an application. To allocate resources adequately, idle timers disconnect sessions after a set time, releasing those resources for other requests. Note that although the OSI model assigns these duties to the session layer, many protocol stacks include the upper layers of the stack in the application. TCP/IP is an example of this practice.

Clients Cannot Connect to Network Resources

In a client/server environment, the available resources are communicated throughout the network. The dynamic nature of the resource tables (offering services, servers, or networks) gives an up-to-date and accurate picture of the network. NetWare, AppleTalk, Vines, and Windows NT all work on this principle. If these tables are inaccurate due to the casualty of packets in your network, however, errors will be introduced as a result of decisions made with incorrect information. Some network systems are moving more toward a peer-to-peer system in which the end user requests a service identified not by the network but by the administrator.

Network Death

The most common problem arising from network congestion is intermittent connectivity and excessive delays—users having to wait a long time for screens to refresh; users being disconnected from applications; print jobs failing; errors resulting when trying to write files to remote servers. If the response of the applications is to retransmit, the congestion could reach a point of no recovery. Likewise, if routing or spanning-tree loops are introduced due to packet loss, the excessive looping traffic could bring your network down.

Key Requirements of a Network

The ACRC objective mastered in this section is as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

1

82

Describe the key requirements of a scalable internetwork.

When designing a network, it is imperative that the requirements of the network be met. Understanding the business structure and current data flow within the existing environment inform the requirements of the network. The relative importance of each of the following broad categories is determined by the needs of the organization in question. A small, growing catering company may place more importance of efficiency, adaptability, and accessibility than a large financial institution that demands reliability, responsiveness, and security. The sections that follow describe the key requirements of a network, including the following:

  • Reliability

  • Responsiveness

  • Efficiency

  • Adaptability

  • Accessibility/security

Reliability

For a hospital or bank, the network must be available 24 hours a day, seven days a week. In the first instance, lives are at stake. If network access cannot be granted to the blood bank, it may not be possible to give a life-saving transfusion. For a finical bank exchanging money throughout the international markets and across every time zone, network downtime can cost up to millions of dollars per fraction of an hour. The capability to isolate and limit any problems that occur is as important as solving the problem quickly.

Responsiveness

Excessive latency within a network appears to the end user as a lack of responsiveness. Frustration sets in and often leads the user to reboot or to repeat keystrokes. This is the same response that might cause you to raise your voice to someone who does not answer your question; you assume that he or she hasn't heard your question, so you repeat it more loudly. In the network environ-ment, however, repeating keystrokes generates more network traffic, which increases congestion and delays. Avoiding this is essential for network health. To do so, build in mechanisms to alleviate congestion and to prioritize certain protocols that are more sensitive to delay.

Efficiency

Designing the network and restricting the traffic to allow only the necessary information to be carried across it proves extremely helpful in preventing congestion. The inefficiency in allowing network and service updates to travel to areas of your network that have no need for the infor-mation can seriously limit the available bandwidth left for data. Allowing users in Brussels, Belgium to see printers in Palo Alto, California is not very helpful and may saturate the 56k serial link.

Adaptability

It is difficult to anticipate every change your company may make in terms of mergers and organizational structure. Therefore, building an adaptable network protects capital investment. It also increases the reliability of the network. Because network administrators are not issued crystal balls, it is essential that attention be given to the interoperability of both products and applications when designing the network.

Accessibility/Security

Security is a popular topic and a major consideration, particularly as more and more companies connect to the Internet and thereby increase the chance of idle hackers wandering in to the network. The needs of the users to access the network, particularly when remote access is required, against the need to secure the company secrets is a difficult balance that requires careful consideration at the executive level.

Cisco's Hierarchical Design

The ACRC objective mastered in this section is as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

4

85

List solutions for controlling network congestion.

Cisco suggests a network design structure that allows for growth. The key to the design is that it is hierarchical. There is a division of functionality between the layers of the hierarchy, allowing only certain traffic—based on clear criteria—to be forwarded through to the upper levels. It is a filtering operation that restricts unnecessary traffic from traversing the network. Thus the network is more adaptable, scalable, and more reliable. Clear guidelines and rules govern how to design networks according to these principles. These guidelines and rules are covered in the Cisco design class as well as design guides provided by Cisco on its Web page. The following section explains how the hierarchical network design proposed by Cisco reduces congestion.

Why Scaling Reduces Congestion

If the network is designed hierarchically, with each layer acting as a filter to the layer beneath it, the network can grow effectively. In this way, local traffic is kept local, and only information about global resources needs to travel outside the immediate domain.

Understanding that the layers are filtering layers begs the question as to how many layers are required in your network. The answer is: It depends.

How Hierarchical Is Hierarchical?

Cisco's design methodology is based on simplicity and filtering. Cisco suggests that the largest networks currently require no more than three layers of filtering.

Because a hierarchical layer in the network topology is a control point for traffic flow, a hierarchical layer is the same as a routing layer. This means the placement of a router or, more recently, a Layer 3 switching device.

The number of hierarchical layers that you need to implement in your network reflects the amount of traffic control required. To determine how many layers are required, you must identify the function that each layer will have within your network.

The Functions of Each Layer

Each hierarchical layer in the network design is responsible for preventing unnecessary traffic from being forwarded to the higher layers (and then being discarded at a higher point in the network or by the receiving stations). The goal is to allow only relevant traffic to traverse the network and thereby reduce the load on the network. If this goal is met, the network can scale more effectively. The three layers of a hierarchy are as follows:

  • The access layer

  • The distribution layer

  • The core layer

The Access Layer

In accordance with its name, the access layer is where the end devices connect to the network—where they gain access to the company network. The Layer 3 devices (such as routers) that guard the entry and exit to this layer are responsible for ensuring that all local server traffic does not leak out to the wider network. Service Advertisement Protocol (SAP) filters for NetWare and AppleTalk's GetZoneLists are implemented here, in reference to the design consideration of client/server connectivity.

The Distribution Layer

The distribution layer is responsible for determining access across the campus backbone, by filtering out unnecessary resource updates as well as by selectively granting specific access to users and departments. Access lists are used not just as traffic filters, but as the first level of rudimentary security.

Access to the Internet is implemented here, requiring a more sophisticated security or firewall system.

The Core Layer

The responsibility of the core layer is to connect the entire enterprise. At the pinnacle of the network reliability, it is of the utmost importance. A break in the network at this level would result in large sections of the organization no longer being able to communicate across the network. To ensure continuous connectivity, the core layer should be designed to be highly redundant and, as much as possible, all latency should be removed. At the core layer, functions relating to connectivity, such as filters, should not be implemented. They should already have been implemented at the access or distribution layers, leaving the core layer with the simple duty of relaying the data as fast as possible to the remote site.

General Design Rules for Each Layer

A clear understanding of the traffic patterns within the organization—who is connecting to whom and when—helps to ensure the appropriate implementation of filtering at each layer. Unless you have a profound knowledge of the current network and the placement of the servers, it is impossible to design networks with hierarchy. Without hierarchy, networks have less capacity to scale because the traffic must traverse every path to find its destination.

It is important for each layer to communicate only with the layer above or below it. Any connectivity or meshing within a layer impedes the hierarchical design.

Organizations often design their networks with duplicate paths. This is to build network resilience so that the routing algorithm can immediately use the alternative path if the primary line fails. If this is the design strategy of your company, care should be taken to ensure that the hierarchical topology is still honored.

Figure 2-3 shows an illustration of the appropriate design and traffic flow.

Figure 2-3. Redundant Connections between Layers

Alleviating Congestion with Cisco Routers

The ACRC objectives mastered in this section are as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

81

Configure Cisco routers for scalable operation in large or growing multiprotocol internetworks.

2

83

Select a Cisco IOS feature as a solution for a given internetwork requirement.

4

85

List solutions for controlling network congestion.

5

86

Introduction to managing traffic and access.

6

87

Configure IP standard access lists.

8

89

Configure IP extended access lists.

9

90

Verify access list operation.

Cisco router features enable you to control traffic, primarily through access lists. Access lists give you “what if” control of the network.

Given that the router operates at Layer 3, the control that is offered is extensive. The router can also act at higher layers of the OSI model. This proves useful when identifying particular traffic and protocol types for prioritization across slower WAN links.

With the assumption of connections between Cisco routers, Cisco has optimized many network operations. The various standards mean that organizations have to tolerate a wide range of variation in the interpretation of a specification. While defying many of the standards that streamline network traffic to a minimum, Cisco has been conscientious by providing the standard solution and a sophisticated method of translation between the standard and the proprietary Cisco solution. The clearest example of this is the use of redistribution between Cisco's routing protocol, Enhanced Interior Routing Protocol (EIGRP), and any other routing protocol such as Open Shortest Path First (OSPF).

Managing Network Congestion for IP

IP is generally considered a well-behaved protocol because its communication is typically peer to peer, removing the necessity for excessive broadcasts throughout the network. The only broadcasts are routing updates and Address Resolution Protocol (ARP) requests. These characteristics can no longer be assumed, however, because client/server technologies are starting to offer IP as a communication protocol. It should be understood that the application demands determine the nature of the traffic on the network. Therefore, if the application relies on broadcasts to locate its server, the protocol used to communicate that broadcast is of little concern. NetBIOS, AppleTalk, and IPX are the obvious examples of client/server applications utilizing TCP/IP as the transport method.

It would be misleading to suggest that there have not been improvements in network utilization by these protocols, which were originally designed for small LAN environments as opposed to the enterprise solutions for which they are now being sold. Nevertheless, it is important to emphasize the need to do careful analysis of the network traffic flow and to understand the communication requirements between the client and the server.

The Implementation of IP Access Lists

Access lists are used to restrict traffic from a specified source to a specified destination. They are also used to implement “what if” logic on a Cisco router. This gives you the only real mechanism of programming the Cisco router. The access lists used for IP in this way enable you to apply great subtlety in the router's configuration.

IP Access Lists Reviewed

Access lists are “linked lists” with a top-down logic, ending in an implicit deny any command (which will deny everything). Top-down logic means that the process will read from the top of the access list and stop as soon as it meets the first entry in the list that matches the packet's characteristics. Therefore, it is crucial that careful attention be given to their creation. Writing down the purpose of the proposed access list before attempting to program the system also proves helpful.

Access lists block traffic traversing the router. Remember, however, that an access list will not block traffic destined to the router.

Standard IP Access Lists

The following is syntax for a standard access-list command:

Router(config)#
access-list access-list-number {permit|deny}
{source [source-wildcard|any]}
Router(config-if)#
ip access-group access-list-number {in|out}

Note that the access-list-number is within the range of 1-99.

Standard access lists are implemented at Layer 3 and, in general, identify source and destination addresses as criteria in the logic of the list. IP access lists work slightly differently, however; they use the source address only.

The placement of the access list is crucial because it may determine the effectiveness of the control imposed. Because the decision to forward can be made on the source address only, the access list is placed as close to the destination as possible (to allow connectivity to intermediary devices).

You can place an access list on either an incoming or outgoing interface. The default is for the access list to be placed on the outgoing interface.

To ensure that all paths to the remote location have been covered, access lists should be implemented with careful reference to the topology map of the network.

Extended IP Access Lists

Although the same rules apply for all access lists, extended access lists allow for a far greater level of control because decisions are made at higher levels of the OSI model.

The following is syntax of an extended access-list command:

Router(config)#
access list access-list-number {permit|deny}
{protocol|protocol-keyword}
{source source-wildcard|any}
{destination destination-wildcard|any}
[protocol-specific options] [log]
Router(config-if)#
ip access-group access-list-number
{in|out}

The access-list-number range is between 100-199.

When using extended access lists, it is important to consider the sequence of conditions within the list. Because top-down logic is employed, the ordering of the list may alter the entire purpose of the list. For more information about access lists, refer to the CCNA Exam Certification Guide from Cisco Press.

Guidelines for Writing Access Lists

You should adhere to the following guidelines when writing an access list:

  • Write out the purpose to be achieved by the access list in clear, simple language.

  • Determine the placement of the access list in reference to a topology map of the network.

  • Write out the access list, ensuring that the following is considered:

    1. The most frequent instance of traffic is placed first in the list, if possible, to reduce CPU processing.

    2. Specific access is stated before group access is defined.

    3. Group access is stated before world access is defined.

    4. There is an implicit deny any at the end of the list.

    5. If there is a deny statement in the access list, there must be a permit statement in it as well; otherwise, the interface will be shut down for all IP traffic in the direction that the access list was applied. That is, every access list must have at least one permit statement; otherwise, it will deny everything.

    6. If no wildcard mask has been defined in a standard access list, the mask of 0.0.0.0 is assumed. This mask would match every bit in the address. If the address was that of a subnet rather than an end station, no match would be found and the router would move on to the next criteria line. If that line is the ending deny any, problems may occur.

    7. The access list will not take effect until it has been applied to the interface. The access list will default to an outgoing access list if a direction is not specified.

  • Test the access list with a utility such as ping.

  • Use the show commands to verify the placement of the access list.

  • If the access list needs to be modified, the list will have to be removed from the interface, deleted, and re-created as additional criteria is appended to the bottom of the list.

    It is useful to save the access list to a TFTP server and just edit it offline.

  • Note that in some older versions of the IOS, deleting the access list at the global level without removing it from the interface may cause the interface to restrict all traffic through the interface in the direction it was applied. This is because the access list, although still applied to the interface, has no content; therefore, the implicit deny any takes effect. Standard system management calls for making changes to the specific before moving back to the general—that is, removing the access group from a specific interface before deleting the global access list.

Figure 2-4 illustrates the process logic used for access lists.

Access lists are extremely powerful when you are configuring the router to tune the data flow through the device. Because access lists take both CPU and memory, however, you must consider alternatives. The following section discusses these alternatives.

Figure 2-4. Processing of an IP Access List, Incoming and Outgoing

Alternatives to Access Lists

The ACRC objective mastered in this section is as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

10

91

Configure an alternative to using access lists.

Because of the resources required to process them, access lists are not always the most suitable solution. The null interface is a good example of when a technology can be used imaginatively to produce a low-resource solution.

Null Interface

The null interface is a virtual interface. It exists only in the imagination of the router. Traffic may be sent to it, but it disappears because the interface has no physical layer. It is a virtual interface that does not physically exist. Administrators have been extremely creative and have used the interface as an alternative to access lists. Access lists require CPU processing to determine which packets to forward. The null interface just routes the traffic to nowhere.

The null interface command syntax is as follows:

Router(config)#
ip route address mask null0

For example:

ip route 10.0.0.0 255.0.0.0 null0

Figure 2-5 clearly shows how you might implement a null interface in an organization. The example shows how it can be used to filter the private network from the Internet.

If the router receives traffic to be forwarded to network 10.0.0.0, it will be dropped through null0 into a black hole. Because this is a private address to be used solely within an organi-zation, never to stray on to the Internet, this is a command that may well be configured on routers within the Internet.

Figure 2-5. The Use of the Null Interface in the Internet

Within the organization, there is often a use for the null interface command. Figure 2-6 and the following text explain their use.

Configuring the static route to null0 on an internal company router prevents connectivity to the defined network because all traffic to that destination is forwarded to a “black hole.” In Figure 2-6, Workstation A is not able to connect to Server C, the development server used by the Research and Development department. The result is that the Research and Development department can see the rest of the organization. Indeed, the rest of the world can see the Research and Development department in a routing table. Any attempt to direct traffic to the network will be unsuccessful, however. The first router that sees the traffic will statically route it to the null interface, which metaphorically is a black hole. There will be no error messages sent to the transmitting node because the traffic was successfully routed, although unfortunately to a black hole. This is considered beneficial for several reasons, one of which is additional security.

Because the static route is entered into the routing table, it is important to remember that all the rules of static routing apply. If the router hears of the destination route via another source, it is ignored in favor of the static route that has a lower administrative distance (which gives it a higher priority).

Figure 2-6. The Use of the Null Interface within an Organization

Prioritization

The ACRC objective mastered in this section is as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

16

97

Describe the need for queuing in a large network.

Access lists are not used just to determine which packets will be forwarded to a destination. On a slow network connection where the bandwidth is at a premium, access lists are used to determine the order in which traffic is scheduled to leave the interface. Unfortunately, some of the packets may timeout; therefore, it is important to carefully plan the prioritization based on your understanding of the network, ensuring that the most sensitive traffic (that most likely to timeout), such as IBM's System Network Architecture (SNA), is handled first.

Many types of prioritization are available. They are implemented at the interface level and are applied to the interface queue. They are referred to as queuing techniques. Some of these techniques are turned on by default and may not be tuned by the router administrator. These include the following:

  • Weighted Fair QueuingTurned on automatically by the Cisco IOS, the queuing process analyzes the traffic patterns on the link and transmits traffic on the basis of its conclusions.

  • Cisco Express ForwardingThis is a very high-end solution and is available on 7500 routers with Versatile Interface Processors (VIPs) and the 8510. It is extremely fast and used for high volumes of traffic. On some of the Cisco platforms, the Cisco processor automatically turns on this feature if the appropriate hardware and software are available.

Those queuing techniques that are manually configured with access lists are as follows:

  • Priority QueuingThis is a method of dividing the outgoing interface into four virtual queues. Importance or priority ranks these queues. Traffic is queued based on its impor-tance and will be sent out of the interface accordingly. This method ensures that sensitive traffic on a slow or congested link is processed first.

  • Custom QueuingThe interface is divided into many subqueues. Each queue has a threshold stating the number of bytes that may be sent before the next queue must be processed. In this way, it is possible to determine the percentage of bandwidth that each protocol is given.

These are dealt with in Chapter 7, “WAN Options: ISDN, DDR, and Configuration.”

Access lists are mainly used to manage traffic patterns (although it has already been shown that they may have a part to play in security). They are essentially a simple logic based on whether to forward traffic. Certain issues arise when using access lists for security purposes.

Security Using Access Lists

The ACRC objectives mastered in this section are as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

2

83

Select a Cisco IOS feature as a solution for a given internetwork requirement.

7

88

Limit virtual terminal access.

16

97

Describe the need for queuing in a large network.

17

98

Describe weighted fair queuing operation.

Cisco recommends that alternative methods to access lists be used for security. Although complex to conceive and write, they are fairly easy to spoof and break through. The 11.3 IOS has implemented full security features and these sophisticated features should be utilized in preference to access lists. The best way to use access lists as security is as a first pass, to alleviate processing on a separate firewall security device. Whether the processing on the firewall device is better designed for dealing with the whole security burden or whether this task should be balanced between devices is a capacity-planning project.

Some simple security tasks are well suited to access lists. Remember, however, that although access lists do not constitute complex security, they will deter the idle user exploring the company network.

Controlling Terminal Access

Because access lists do not prevent traffic generated by the router or traffic destined for the router, another method is required. If the router is being used as an end device for Telnet, an access list can be placed on the virtual terminal line (vty).

Five terminal sessions are available: vty 0-4. Because anticipating which session will be assigned to which terminal is difficult, control is generally placed uniformly on all virtual terminals.

The syntax for vty commands is as follows:

Router(config)#
Line {vty-number|vty-range}
          
Router(config-line)#
access-class access-list-number {in|out}

Standard access lists are used for inbound access because the destination is known. The access-class command is the same as the access-group command, but is used for terminal access. It could be applied either as an inbound or an outbound list. The access list used has the same structure as the standard access lists; even the range used in the command is the same, 1-99.

When applied as an inbound access-class command to the vty, an access list restricts users from connecting to the router from the specified source addresses.

When applied as an outbound access-class command to the vty, an access list restricts users who have connected to the router and then attempt to connect to another system from that router. This is because the access list is still using the source address.

Other methods of restricting access are slightly more brutal. It is possible to issue the following command:

Router(config)#
no line vty 0 4

This command removes all terminal access.

It is also possible to issue the following commands:

Router(config)#
Line vty 0 4
Login
No password

This requires a password. Because a password has not been sent, however, it is impossible to correctly input a password. The result is no access. In the previous examples, the console is used to configure and manage the router.

Final Connectivity and CPU Considerations

The ACRC objective mastered in this section is as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

11

92

Configure an IP helper address to manage broadcasts.

Access lists require CPU processing from the router. The more complex or long the access list, the greater the amount of CPU processing required. In earlier versions of the Cisco IOS, pre-10.3, complex access lists prevented the caching of routing decisions, for example, fast, autonomous, and silicon switching. These functions are now supported, particularly if Netflow features are turned on. In this context, switching refers to a Cisco solution that was implemented in the earliest of Cisco's products and that has been consistently enhanced.

To improve the capability of the router to forward traffic—after the routing process has made a routing decision and sent the packet to the appropriate outbound interface—the router holds a copy of the outbound frame in memory along with a pointer to the appropriate outbound interface. This means that incoming traffic can be examined as it comes into the router. The router looks in the cache or memory to see whether a routing decision has already been made for that set of source and destination addresses. If an entry exists, the frame can be switched directly to the outbound interface, and the routing process is bypassed. This not only increases the apparent throughput of the router but also reduces the memory and CPU resources required. The different names for the available switching methods refer to where the cache is stored. For more information on this subject, refer to the Cisco documentation set.

If the router is not caching any of the routing decisions, but is instead processing every packet with process switching, there may be implications on the router's CPU and memory utilization.

Placement of Client/Server

The location of the servers in relation to the clients dramatically affects the traffic patterns within the network.

The current philosophy is to create server farms so that the servers can be centrally admin-istered. If the client finds the server via broadcasts, however, a serious problem will arise if there is a router between the broadcasts: Because routers are a natural broadcast firewall, they treat broadcasts as an unknown address and discard them. In such a scenario, the client sending a broadcast to locate a server will fail in the endeavor.

Even carefully designed centralized server farms on different networks will not work because the intervening router discards broadcasts sent between the clients and the server. The clients will have no connectivity with their servers. The solution is to configure a helper address on the router.

IP Helper Address

The IP helper address removes the broadcast destination address of a UDP packet received on an identified interface and replaces it with a specific destination address. The router has been programmed to say, “If a broadcast comes in on this interface, forward it to this destination address,” where the destination address is that of the server.

A helper address is configured on the incoming interface. The destination address may be either an individual server or a subnet address. Multiple helper addresses can be identified, and all broadcasts received on the interface will be forwarded to each destination. This is a good way to create backup servers on different segments. The syntax for the ip helper-address command is as follows:

Router(config-if)#
ip helper-address address

The IP helper address forwards broadcasts for the following UDP ports:

  • TFTP (69)

  • DNS (53)

  • Time (37)

  • NetBIOS name server (137)

  • NetBIOS datagram service (138)

  • BOOTP server (67)

  • BOOTP client (68)

  • TACAS (49)

In addition to the helper address is the IP forward protocol, which instructs the router to forward broadcasts. By stating the port number, particular types of broadcast may be identified. This is very useful when used in conjunction with the helper address because it identifies those broadcasts to be readdressed to specified destinations. It is possible to either add to the list of broadcasts that will be forwarded with the helper address or remove certain traffic types. You can tailor the ip helper-address command so that only necessary traffic is forwarded, which not only optimizes bandwidth but also prevents the servers from being overloaded. (Server overload can result in servers overflowing their buffers; this causes them to slow down or hang.) The syntax for the ip forward-protocol command is as follows:

Router (config)#
ip forward-protocol {UDP [port]|nd|sdns}

Uses of IP Access Lists

Because access lists can be used so subtly in system programming, they are used in many ways to solve many problems. IP access lists are used mainly to manage traffic.

Traffic Control through Routing Updates

Traffic on the network must be managed. Traffic management is most easily accomplished at Layer 3 of the OSI model. You must be careful, however, because limiting traffic also limits connectivity. Therefore, careful design and documentation is required.

Routing updates convey information about the available networks. The updates are sent out periodically to ensure that every router's perception of the network is accurate and current.

Access lists applied to routing protocols restrict the information sent out in the update. Certain networks are omitted based on the criteria in the access list. Remote routers unaware of these networks will not be able to deliver traffic to them. Networks hidden in this way are typically research and development sites, test labs, or secure areas.

These access lists are also used to prevent routing loops in networks that have redistribution between routing protocols.

When connecting two separate domains, the connection point of the domains or the entry point to the Internet are areas through which only limited information needs to be sent. Otherwise, routing tables become unmanageably large and consume large amounts of bandwidth.

It is popular to tune the update timers between routers, trading currency of the information for optimization of the bandwidth. All routers running the same routing protocol expect to hear these updates with the same frequency that they send out their own. If any of the parameters defining how the routing protocol works are changed, these alterations should be applied consistently throughout the network; otherwise, routers will timeout and the routing tables will become unsynchronized.

Across WAN networks it may be advantageous to turn off routing updates completely and to manually or statically define the best path to be taken by the router. Note also that sophisticated routing protocols such as EIGRP or OSPF send out only incremental updates; be aware, however, that these are correspondingly more complex to design and implement.

To optimize the traffic flow throughout a network, you must carefully design and configure the IP network. In a client/server environment, the control of the network overhead is even more important. The following section discusses some concerns and strategies.

Managing Network Access for IPX

The ACRC objectives mastered in this section are as follows:

ACRC Exam Objective Number

Corresponding FRS Exam Objective Number

Description

12

93

Describe IPX/SPX traffic management issues.

13

94

Filter IPX traffic using IPX access lists.

14

95

Manage IPX/SPX traffic over WAN.

15

96

Verify IPX/SPX filter operation.

NetWare, a client/server product, relies heavily on broadcasts to locate servers, to acquire client addresses, and to transmit network information.

In a large network, service updates must be filtered. As a general rule, the router should have no more than 600 SAP service advertisements in the SAP table. This recommendation is concerned with the amount of network overhead that results from communicating all these services between the routers and servers as well as the resources required in the network devices. This number is not rigid; it really depends on the size of the network, the capacity of the network devices, and bandwidth available.

The Implementation of IPX Access Lists

Access lists are used predominantly in the IPX environment to control broadcast traffic. Security concerns are typically dealt with using the NetWare product features.

Access lists are also used for “what if” programming on the Cisco router, primarily in the WAN for dial-up access.

IPX Access Lists Reviewed

All access lists follow the same rules of logic. The previously discussed rules that apply to IP also apply to IPX traffic.

IPX Addressing Reviewed

IPX is a Layer 3 protocol. As such, the address can be broken into two parts: the network portion and the node portion. When implementing IPX, remember that the node address is acquired. The server or router gives the network address on the segment where the network administrator has configured it. The node portion of the address is provided by Layer 2, which lends the MAC address for the interface to complete the Layer 3 address.

Serial interfaces, which have no MAC address, borrow the MAC address from the nearest LAN interface. Although it is often assumed that this is the first Ethernet address, it is not always the case. Therefore, it is wise to check the IPX address on the serial interface before any config-uration requiring such things as mapping statements. A Cisco router that has only serial interfaces will have to have a MAC address configured for the router by the administrator.

It is important to understand the addressing structure and corresponding use of wildcards when configuring access lists.

Standard IPX Access Lists

As standard access lists make decisions at Layer 3, the addressing structure and the wildcard determine the scope of restriction defined in the access list. Standard IPX access lists allow control to be applied to both the source and destination addresses. This is unlike standard IP access lists, which only allow the source address to be applied.

Because the standard IPX access list states both the source and the destination, it does not have to be applied as near to the destination as possible. Care should be taken in the use of the wildcard and the placement of the access list in reference to the design topology and addressing of the network. The syntax for a standard IPX access-list command is as follows:

Router(config)#
access-list access-list-number {permit|deny}
source-network[.source-node[source-node-wildcard mask]]
destination-network[.destination-node[destination-node-wildcard mask]]
            
Router(config-if)#
ipx access-group access-list-number [in|out]

The IPX standard access list number range is 800-899.

Extended IPX Access Lists

Because the extended access list allows for socket numbers to be specified, filtering at Layer 4 and higher is possible (limiting access on an application basis).

Again, it must be stressed that this level of security is typically applied at the server level. Although routers are connectivity devices and offer sophisticated security in some versions (11.3), these features tend not to be implemented in the LAN environment.

The syntax for an extended access-list command is as follows:

Router(config)#
access-list access-list-number {permit|denyprotocol
[source-network][[[.source-node]source-wildcard-mask]]
[source-socket] [destination-network]
[[[.destination-node]destination-wildcard-mask]] [destination-socket]
[log]

Extended IPX filters use an access list range between 900-999.

Uses of IPX Access Lists

IPX access lists are used primarily to control traffic flow. When used in a hierarchical design, these are easily implemented and allow the network to scale very effectively.

Traffic Control

IPX traffic using RIP/SAP updates over IPX has problems scaling. Each SAP packet holds seven service advertisements. The packet is up to 480 bytes in length, without the header. Each server and router will exchange its SAP table every 60 seconds by default.

Imagine an enterprise network with 700 services available worldwide—a moderately sized network. Note that the number 700 identifies the number of services advertised; it does not reflect 700 servers. The servers may number less than 200. However, 700 services is a convenient number because it renders 100 packets—or 48,000 bytes (B), or 48 kilobytes (KB)—of traffic generated by every server or router every 60 seconds.

Within a LAN environment, this amount of traffic would be a consideration. The bandwidth available today diminishes this concern, however. Across a WAN 56 kbps leased line, on the other hand, the amount of traffic would be a major bottleneck—particularly because the 48 KB does not include headers, and the 56 kbps line is bits per second.

For example, consider 100 packets at 480 bytes each, which would be 100480=48,000 bytes per minute.

Because the speed of the serial line is stated in bits per second and not bytes per second, a conversion is clearly needed:

    48,0008=384,000 bits per minute

How long this would take to send this across a 56 kbps line can be simply converted as:

    384,000/56,000=6.86

Therefore, the serial line is busy transmitting SAP network overhead for almost seven seconds out of every minute.

You can also determine the percentage of serial line devoted to the SAP traffic by using the Erlang measurement:

    384,000/60=6400 kbps

    6400/56,000=0.11

0.11*100=11% of the serial line's capacity is devoted to SAP traffic.

For this network to survive the SAP traffic updates, filtering is essential.

Service Advertisement Protocol (SAP) Filters

A SAP filter is the most common form of filtering used within an IPX environment with NetWare 3.x and 4.x servers that are not using NetWare Directory Services (NDS). Careful design makes it possible to create a network that allows client/server connectivity and yet still has enough bandwidth for data to traverse the network. The syntax for a SAP filter command is as follows:

Router(config)#
access-list access-list-number (deny|permit)network[.node]
[network-wildcard mask.node-wildcard mask] [service-type[server-name]]
            
Router(config-if)#
ipx input-sap-filter access-list-number
            
Router(config-if)#
ipx output-sap-filter access-list-number
            
Router(config-if)#
ipx router-sap-filter access-list-number          

IPX SAP filters use an access list range of 1000-1099.

As seen in the use of access lists in general, the placement of the list is crucial to the effect that it has on the network traffic. With IPX SAP filters, both the placement of the filter and the function of the filter must be considered.

You can assign the filter to the interface as either an input, output, or router SAP filter. The input filter determines what is accepted into the interface and placed into the SAP table. The output filter determines what is allowed out of the interface in SAP updates from the router. The router filter determines which router the SAP updates will be accepted from. Figure 2-7 illustrates the use of SAP filters within an Enterprise network.

Figure 2-7. The Use of SAP Filters within an Enterprise Network

The SAP table on Router Y would have all the services listed on it. If the SAP filter permitted only the File Server Services to be propagated, then although Workstation A could connect to Servers B and C across the WAN, they would not be able to see or connect to the printers on the other side of the serial link. The use of the output filter allows a lot of subtlety in the filtering because each interface can be defined to allow different services in the updates. The input filter is broader in application because it determines how the SAP table is populated.

Get Nearest Server (GNS) Filters

SAP filters are often used in conjunction with the GNS filter. When a client boots up, it sends out a GNS request. The servers and routers will respond. In the case of the servers, the reply will be to advertise themselves as a resource. The router will advertise the server from which it last heard an update, on the basis that it is the most likely to still be available. Note that the manner in which the router responds depends on the version of the IOS. The earlier versions have some problems because the client attaches to the first server that it hears is available. In this race contention, the router, with superior CPU, will provide the server for the client. Unfortunately, the last server the router heard from may be in a distant land across a very slow WAN link. The client could connect to a server 4,000 miles away across an X25 56 kbps link, as opposed to its local server.

In the latest versions of IOS, the router listens for SAP traffic on the LAN and, if it hears none, responds to a client's GNS. If SAP traffic is heard on the LAN, the router will not respond because it “believes” a server is present.

Another solution is to create a GNS filter. This is a LAN filter and as such does not control traffic (because the SAP updates will have been sent across the network). These filters determine what the client will see onscreen, and thus function as a first-level security filter.

The GNS filter is configured as a SAP filter and implemented on the interface as a GNS filter. The access list number will therefore be in the range of 1000-1099. Figure 2-8 shows the use of GNS filters.

Routing Information Protocol (RIP) Filters

Filtering RIP updates using distribute lists makes it possible to determine the networks sent between the routers and servers. It is important to note that although the SAP and RIP protocols are described as independent, they are very dependent on each other. Care must be taken when implementing either SAP or RIP filters to ensure that the required connectivity is available.

NetWare clients learn about services from advertising servers. The first server to respond to the GNS request from the client returns a GNS reply with a list of the services it has learned from the other advertising servers along with the network addresses of the advertising servers. The client then requests the route to the server it is configured to use. If you block the RIP update to a server, it will remove the route from its routing table and no longer advertise services from that location. Consequently, the client will never learn of services where either RIP or SAP updates have been filtered.

Therefore, if the information in the RIP/SAP tables is not synchronized, entries from the tables will drop out and create intermittent and difficult-to-troubleshoot errors. The use and application of RIP filters is very similar to that of the SAP filters. The RIP filters use the standard or extended access list configuration, however, with the list numbers of 800-899, 900-999.

Figure 2-8. The Application of GNS Filters

The format of the ipx input-network-filter is as follows:

Router(config)# 
access-list access-list-number {deny|permit}network[.node]
[network-wildcard mask.node-wildcard mask] [service-type[server-name]]
            
Router(config-if)#
ipx input-network-filter access-list-number
            
Router(config-if)#
ipx output-network-filter access-list-number
            
Router(config-if)#
ipx router-filter access-list-number
          
Security

Security within the LAN client/server environment is typically implemented at the server. Within the WAN and in connectivity to the outside world, such as to the Internet, an independent device in the form of a firewall is used.

Other Issues

Advanced and complex configurations may be designed using these filtering techniques. These become particularly relevant in the design of the WAN, where limiting network traffic is a major concern. Careful consideration must be given to the design of the network in relation to the traffic flow and data patterns.

NetWare also supports NetBIOS application traffic. If your network is running these applications, you must consider the following:

  • NetBIOS Filtering—NetBIOS is a protocol that was developed by IBM. It is an application interface that allows applications to use various transport protocols, such as SPX/IPX.

  • Propagation of Type 20 packetsType 20 packets are IPX packets that are NetBIOS broadcasts. If your network is using NetBIOS applications, it will be necessary to allow the Type 20 packets to flood the network so that registration to name servers can happen.

Verifying Filter Configuration

Whenever a network is configured, that configuration must be tested and the changes documented. This enables you to maintain a clear knowledge of the network functionality and is called maintaining baseline.

The commands to verify the filter configuration for either IP or IPX filters is most easily accomplished through the show commands:

Router#
show access list
          
Router#
show ip interface
          
Router#
show IPX interface        
Design of Client/Server

To design an effective network, it is essential to understand the data flow within a network. Where to place the server relative to the clients should be decided only after considering the following factors:

  • The frequency of connection to the server

  • The duration of the connection to the server

  • The volume of traffic sent across the link to and from the server at a specific moment of the day

  • The daily quantified average

Analyzing the traffic patterns over time to create a baseline of the network documents how the network functions today and allows the correct determination of server/client placement. Using standard systems analysis methodology, the status of the network must then be set against the future needs of the organization (to ensure the appropriate design of the network). Understand that the design of the network directly influences the traffic patterns experienced within the network.

Enhanced Interior Gateway Routing Protocol (EIGRP)

EIGRP was designed to make efficient use of the available network bandwidth. The routing protocol carries both RIP and SAP information in the updates. The advantage of EIGRP is that it is incremental, sending updates only when a change in the network is experienced.

EIGRP automatically redistributes routing updates into RIP and SAP updates if the IPX RIP/SAP protocol is also configured on the router. EIGRP is proprietary to Cisco and is only understood by other Cisco devices. A powerful use of this technology would be to have EIGRP as the routing protocol between the routers across the WAN and RIP/SAP traffic on the local segments.

It is advisable to use the latest versions of the Cisco IOS when implementing this technology and to ensure that all the devices are running the same version of the protocol. This subject is dealt with in more detail in Chapter 6, “EIGRP, BGP, and Redistribution.”

Static SAPs

Another method of restricting unnecessary traffic is to build the SAP table locally and to prevent any SAP update communication between the devices. Although this view is very attractive, it requires manual configuration and removes any concept of dynamic reconfiguration of the network. Used throughout a network, it would severely limit the capability of the network to grow. It is used very effectively across WANs, where connectivity to remote locations is carefully managed, particularly in the dial-up environment where periodic updates interfere with the desired functionality of the connection. The syntax for the static SAP command is as follows:

Router(config)# 
ipx sap service-type name network.address hop        

A less-rigid solution is to send the updates less often. Although this reduces the traffic on the network, it also makes the network less responsive to change. The design considerations are therefore centered on the importance of the resource and the utilization of the bandwidth.

If the update timers for SAP and RIP traffic are changed, the effects of this change on the entire network must be considered. In later releases of the Cisco IOS (11.2(4)F and up), the commands for changing the RIP and SAP update timers were integrated into one command. Other commands were added to reduce communication across the WAN to the minimum required for connectivity.

Other commands to research include the following:

  • ipx update interval {rip|sap} {value|changes-only—This command changes the interval at which the updates will be sent. The timer is typically set higher than the default, which is 60 seconds.

  • no ipx linkup-request {rip|sap}—This command suppresses the “General RIP and SAP Query” when the interface comes up. This is useful in a dial-up link because it reduces the communication to one update.

  • ipx update sap-after-ripThis command automatically sends the SAP update following the RIP update and ensures the synchronization of the two databases. Although this does not reduce the network traffic, it does fix a problem of the past: Because the timers were set differently, networks and servers would appear and disappear from the tables.

Tunneling IPX into IP

Tunneling one protocol into another is the process by which a protocol at a specific layer of the OSI model is wrapped into another protocol of the same layer or one higher in the stack. An example of this would be IPX, which is a Layer 3 protocol being wrapped inside IP, another Layer 3 protocol. Other examples include AppleTalk inside IP and SNA inside IP, which is an example of a Layer 2 protocol being wrapped inside a Layer 3 protocol.

Figure 2-9 illustrates the following steps of the IPX protocol being encapsulated and transported through an IP tunnel:

  1. Data from the application layer is passed down the OSI model to the network layer.

  2. Once at the network layer, the data is encapsulated in an IPX packet.

  3. While at the network layer, the IPX packet is encapsulated into an IP packet.

  4. The IP packet is then inserted into the frame format at the data link layer for the media in which the frame will be sent out.

Figure 2-9. Tunneling IPX within IP

Why would anyone wish to configure anything quite so torturous? Such a configuration certainly will not reduce or control the traffic propagated on to the network. Conversely, it will increase the traffic load because the original data will now have the additional header.

On the end routers, which are responsible for adding this extra header, there are obviously increased CPU requirements.

The reasons for this configuration are not justified on the basis of network optimization, but rather on the ease of management of the entire network.

If the client/server traffic is kept local to the user LAN networks, with traffic to remote networks connected via TCP/IP, the administrator of the core no longer has to understand or worry about the vagaries of the disparate protocols. Instead, the administrator can focus on the one protocol: TCP/IP.

Although the use of IP enables the administrator to utilize all the available optimization tools for IP, it should be understood that the nature of the traffic would still be inherently that of the originating protocol. A NetBIOS application generating a broadcast will be transformed into an IPX broadcast and tunneled in the IP protocol. It would be delivered to the tunnel destination, stripped of the IP header, and the IPX broadcast would be dealt with as normal. Some of the reasons for tunneling IPX through IP include the following:

  • The traffic can utilize the advantages of IP and sophisticated routing algorithms.

  • The two ends of the tunnel, although in reality separated by many routers, appear as a single point-to-point link.

  • The network administrator for the backbone network to which the two LANs connect need only understand TCP/IP.

  • The addressing scheme is simplified.

  • Simple routing protocols may have a limited hop count, which is extended by the tunnel, which advertises the path across the tunnel as one hop.

Some things to consider when creating an IP tunnel for IPX include the following:

  • The delay, or latency, created in tunneling the IPX traffic into IP may cause some applications to timeout.

  • Because the tunnel is viewed as a point-to-point link, separate tunnels are required for multiple links. Many tunnels on a physical interface can cause some memory problems on the interface.

  • Care must be taken in redistributing routing protocols because the tunnel is often seen as a preferred path. This is because the route is advertised as a single hop. It may involve a much-less-favorable path, however. The tunnel may advertise the path as two hops, one hop through the tunnel and one hop to the destination. However, the one hop actually represents 10 hops across mixed media; the other path, which is rejected because it advertised three hops, is really only three hops away.

Syntax for the tunnel interface command is as follows:

Router(config)# 
interface tunnel interface-number
          
Router(config-if)#
tunnel source interface-number|network.node address of Router interface
          
tunnel destination network.node address of remote network interface          

Conclusion

Before it is possible to manage traffic flow within your network, it is necessary to understand the network structure and the needs the users and applications have of the network.

A structural topology map of the physical and logical layout of the network is necessary to allow the design and appropriate implementation of the features described in this chapter.

Foundation Summary

Tables 2-1 through 2-4 summarize the main points of the chapter as well as providing additional points that are not directly related to the exam objectives; these may be useful, however. The intention is that the tables be used to remind you of the key points of the most important subjects that were dealt with in the chapter. If any of the points need clarification, refer to the body of the chapter for greater detail. The additional information is of use to the advanced student, who will see the chapter subjects in a wider context.

In these tables, identify the reasons for congestion within a network and the solution that Cisco proposes. The subsequent tables deal with access lists, including their configuration and application.

Table 2-1. Network Congestion: Causes and Cisco Solutions

Causes of Network Congestion

Cisco Solutions

Excessive application traffic

Compression across slow serial links

Use traffic shaping for Frame Relay with BECN

Use priority queuing across slow serial links

Use Serial Backup commands for dual point-to-point links

Adjust application and other timers so that they do not timeout and retransmit

Increase the bandwidth using EtherChannel

Use load balancing, policy routing for IP

Ensure appropriate server location in network design

Broadcast traffic due to large network

Filter unnecessary networks from routing updates

Use snapshot routing across dial-up lines

Manually configure static routes

Use a sophisticated routing protocol with incremental updates (for example EIGRP, OSPF)

Use address summarization

Broadcast traffic due to large client/server network

Filter unnecessary servers/services/zones from service updates

Use a sophisticated routing protocol (for example, EIGRP)


Table 2-2. Access List Features

Access List Feature

Purpose

Decision to forward based on:

Layer 3 source and destination address (standard access list)

Layer 3 and above (extended access list)

Determine packet movement through network or “what if?” programming

Ability to filter on port number, packet size, as well as Layer 3 addresses

Give high level of granularity

Named access lists

Ease of management

Keywords for ports and wildcards

Ease of management

Ability to apply access list as inbound or outbound

Flexibility in design considerations

Ability to prevent ICMP messages from being generated when a packet is denied access

Increased security by making spoofing more difficult

Use of the established parameter to allow outgoing TCP applications, but to restrict incoming attempts

To allow users to Telnet into the Internet while preventing access to anyone trying to initiate a connection from the outside

Ability to filter in TCP/IP by precedence

To speed up the propagation of traffic

Lock and key

Allow users normally blocked to gain temporary access, after the user is authenticated

Reflexive access list

Dynamic filtering at the IP session layer


Table 2-3. Applications for Access Lists

Type of Access List

Purpose

Standard

Packet movement through the network or “what if?” programming

Virtual terminal access

Restrict access to and from the VTY line interfaces on the router

Distribute lists

Filtering of networks from the routing updates

Service filtering (for example, IPX SAP, GNS or AppleTalk ZIP, or GetZoneList filters)

Filtering of services from the server updates or from the replies to client requests

Queuing (for example, priority or custom queuing)

To prioritize traffic leaving an interface

Dial-on-demand routing (DDR)

To determine traffic that is defined as important enough to dial the remote site


Table 2-4. Points to Remember When Configuring Access Lists

Point to Remember

Consideration

The access list is processed as a top-down link list. The list will be tested for a match.

When the first match is found, deny or permit will be applied and the process terminated.

Place the most specific criteria first. If more than one criteria is specific, place the most frequent match first.

There is an implicit deny any at the end of every list.

There must be at least one permit statement.

The wildcard uses zeros to indicate bits of the address to match, and ones for those to ignore.

This is the reverse of the use of the subnet mask and is easily confused.

Additional criteria statements are added to the bottom of the access list.

Because there is no editing and placement of the criteria is important, it is advisable to save the access list configuration to a TFTP server where it can be edited with ease.

The access list is not active until applied to the interface.

The access list will not work.

Q&A

The following are questions to test your understanding of the topics covered in this chapter. After you have answered the questions, you will find the answers in Appendix A, “Answers to Quizzes and Q&As, Answers to Chapter 2 Q&A; Questions.” If you get an answer wrong, review the answer and ensure that you understand the reason for your mistake. If you are confused by the answer, refer back to the text in the chapter to review the concepts.

5. Associate the appropriate IOS feature to solve the network congestion problem experienced on the network in the following table.

Network Congestion Problem

IOS Solution

Large SAP tables on the routers

Routing access list

Clients cannot connect to the centralized servers

Prioritization on the interface

Cisco environment in a large network with a large number of WAN connection

Reduce the size of the broadcast domain by adding a router

Large routing tables using RIP for IP

IP helper address

Spanning tree is failing

EIGRP

SNA sessions are failing

SAP filters

Scenarios

The following case studies and questions are designed to draw together the content of the chapter and exercise your understanding of the concepts. There is not necessarily a right answer. The thought process and practice in manipulating the concepts is the goal of this section.

The answers to the scenario questions are found at the end of each scenario.

Scenario 2-1

The users are complaining that the network is very slow. They are using an IPX NetWare version 3.12 system. The servers are locally administrated. Each user connects to the local file server and print server and has access to a centralized server for email. The email system is using TCP/IP. There is a gateway server that deals with the translation from IPX to TCP/IP. Figure 2-10 illustrates the network. This diagram has been simplified for the purposes of the exercise. In reality, this network, as drawn, would not generate enough traffic to create congestion problems.

Scenario 2-2

Your company has recently created a lab for you to test TCP/IP configurations and explore new solutions. Although the lab needs to be connected to the entire network, it is important that access to this environment be limited. Although you need to be able to connect from anywhere in the lab to the network, no one else should have this access.

Scenario 2-3

In one of the buildings of the network campus, the local administrators have decided that they want to centrally administer the building servers. Each floor of the building is a separate IPX and IP network. The network in the basement is where the server farm is located. The server farm consists of a DHCP server, DNS server, and an IPX file server. None of the clients have been configured with the addresses of the servers.

The IPX network address for the basement network is FAB. The IP network address for the basement is 10.10.10.0.

Scenario Answers

The answers provided in this section are not necessarily the only possible answers to the questions. The questions are designed to test your knowledge and to give practical exercise in certain key areas. This section is intended to test and exercise skills and concepts detailed in the body of this chapter.

If your answer is different, ask yourself whether it follows the tenets explained in the answers provided. Your answer is correct not if it matches the solution provided in the book, but rather if it has included the principles of design laid out in the chapter.

In this way, the testing provided in these scenarios is deeper: It examines not only your knowledge, but also your understanding and ability to apply that knowledge to problems.

If you do not get the correct answer, refer back to the text and review the subject tested. Be certain to also review your notes on the question to ensure that you understand the principles of the subject.

Scenario 2-1 Answers

The administrator could implement the following recommendations to ascertain that delays were being experienced on the network. Also listed here are some possible solutions to the problems.

  • Use a protocol analyzer to verify that there is network congestion.

  • Write an IPX extended access list to prevent users from connecting to any server other than their local server, the e-mail server, or the gateway server.

  • Write an output SAP filter, one that limits service updates, to be placed on the outbound interface of the router.

  • Write a static SAP entry stating the IPX/IP gateway on every local router and prevent all SAP updates.

The command to configure a static SAP entry on the router is as follows:

Router(config)#ipx  sap 107 MAILSERV FAB.082b.0000.1223 8104 4          

The following are some suggestions of first-line security that could be implemented:

  • Ensure the routers are held in a physically secure environment.

  • Write a standard access list to be applied on the vty line interfaces.

  • Change the passwords on the routers.

  • Turn on logging and accounting at the router.

Scenario 2-2 Answers

1.

To permit access from anywhere in the lab for only the administrator, you must apply extended access lists to the fddi 0 interface of Router Y. The access lists would be applied in both the inbound and outbound direction. A diagram has also been included to show the configuration in a simpler environment, where the administrator may well be working from home and dialing in to the network. In this case, the configuration would be the same, but S0 is the interface that has the access lists applied. If the link were a dial-up, there would be additional configuration determining which traffic would raise the line. This is dealt with in the section on DDR later in this book.

Example 2-1 shows the commands required to achieve this:

Example 2-1. Scenario 2-2 Configuration
Router Y
Router(config)#
access-list 102 permit ip 10.0.0.0  0.255.255.255  0.0.0.0 255.255.255.255
Router(config)#
access-list 103 permit tcp 0.0.0.0  255.255.255.255 10.0.0.0 0.255.255.255 
 established
Router(config)#inter FDDI 0
Router(config-if)# ip access-group 102 in
Router(config-if)# ip access-group 103 out

Figure 2-11 shows where the access lists described in question 2 would be applied.

Figure 2-11. Answer to Scenario 2-2, Applying Access Lists

Scenario 2-3 Answers

1.

Figure 2-12 shows a diagram of the network.

To ensure that the clients could connect to the servers that had been moved to a separate network, the Helper address command must be used.

The following commands allow the IP clients to connect to the remote servers:

Router(config-if)# ip helper-address 10.10.10.255

The IPX clients will need no additional configuration because they will find their servers using the normal method of GNS requests and SAP updates.

Refer to Figure 2-11.

Figure 2-12. Answer to Scenario 2-3

The commands that you can use to verify the configuration of the helper addresses are as follows:

Router# show startup-config
Router# show running-config
Router# show ip interface
Router# show ipx interface
   

Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.