|
|
|
Managing Scalable Network Growth
|
| |
 |
|
|
|
|
 |
|
From:
ACRC Exam Certification Guide
Author: Clare Gough
Publisher: Cisco Press (Trade/52)
More Information
|
|
|
|
|
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.
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.
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.
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:
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. The ACRC objectives mastered in this section are as follows: 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. 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.
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. 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. 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. 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. 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. 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. 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. The ACRC objectives mastered in this section are as follows: 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: 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. 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. 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. The ACRC objective mastered in this section is as follows: 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
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. 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. 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. 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. 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. The ACRC objective mastered in this section is as follows: 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. 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. 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. 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
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 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 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. 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. The ACRC objectives mastered in this section are as follows: 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). 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. 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.
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.
The following is syntax for a standard
access-list
command:
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. 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:
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. 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: The most frequent instance of traffic is placed first in the
list, if possible, to reduce CPU processing. Specific access is stated before group access is defined. Group access is stated before world access is defined. -
There is an implicit deny any at the end of the list.
-
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.
-
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.
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. The ACRC objective mastered in this section is as follows: 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. 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: For example: 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.
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). The ACRC objective mastered in this section is as follows: 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 Queuing—Turned
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 Forwarding—This
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 Queuing—This
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 Queuing—The
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. The ACRC objectives mastered in this section are as
follows: 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. 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:
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: This command removes all terminal access. It is also possible to issue the following commands: 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. The ACRC objective mastered in this section is as follows: 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. 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. 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:
The IP helper address forwards broadcasts for the following UDP ports:
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:
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 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.
The ACRC objectives mastered in this section are as follows:
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.
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.
All access lists follow the same rules of logic. The previously discussed
rules that apply to IP also apply to IPX traffic.
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.
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:
The IPX standard access list number range is 800-899.
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:
Extended IPX filters use an access list
range between 900-999.
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.
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 100×480=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,000×8=384,000 bits per minute
How long this would take to send this across a 56 kbps line can be simply
converted as:
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:
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.
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:
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.
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.
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.
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.
The format of the ipx
input-network-filter is as follows:
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.
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 packets—Type
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.
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:
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.
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.”
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:
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-rip—This
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 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:
-
Data from the application layer is passed down the OSI model to the
network layer.
-
Once at the network layer, the data is encapsulated in an IPX packet.
-
While at the network layer, the IPX packet is encapsulated into an
IP packet.
-
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.
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:
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. 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. |
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. 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.
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. 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. 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. 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. 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: 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.
- 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.
- 1.
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:
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. The commands that you can use to verify the configuration of the helper
addresses are as follows: |
| |
|
|
|
|
|
|
|
Breaking News
|
|
One of the primary architects of OpenCable, Michael
Adams, explains the key concepts of this initiative in his book
OpenCable Architecture.
|
|
|
|
|
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.
|
|
|
|
|
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}