Cisco Ios Access Lists 1st Edition Jeff Sedayao

Cisco Ios Access Lists 1st Edition Jeff Sedayao
download
https://ebookbell.com/product/cisco-ios-access-lists-1st-edition-
jeff-sedayao-930168
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Cisco Ios Xr Fundamentals Birhanu Dawit Dawit Birhanu Ccie No 5602
Ghattas
https://ebookbell.com/product/cisco-ios-xr-fundamentals-birhanu-dawit-
dawit-birhanu-ccie-no-5602-ghattas-21984344
Cisco Ios Cookbook 2nd Edition Cookbooks Oreilly 2nd Edition Kevin
Dooley
https://ebookbell.com/product/cisco-ios-cookbook-2nd-edition-
cookbooks-oreilly-2nd-edition-kevin-dooley-2404960
Cisco Ios In A Nutshell 2nd Ed James Boney
https://ebookbell.com/product/cisco-ios-in-a-nutshell-2nd-ed-james-
boney-4116740
Cisco Ios In A Nutshell A Desktop Quick Reference For Ios On Ip
Networks 1st Edition James Boney
https://ebookbell.com/product/cisco-ios-in-a-nutshell-a-desktop-quick-
reference-for-ios-on-ip-networks-1st-edition-james-boney-1307712

Cisco Ios In A Nutshell 2nd Edition James Boney
https://ebookbell.com/product/cisco-ios-in-a-nutshell-2nd-edition-
james-boney-2466962
Cisco Ios Configuration Fundamentals Command Reference Cisco Systems
https://ebookbell.com/product/cisco-ios-configuration-fundamentals-
command-reference-cisco-systems-10886498
Implementing Cisco Ios Network Security Iins 1st Edition Catherine
Paquet
https://ebookbell.com/product/implementing-cisco-ios-network-security-
iins-1st-edition-catherine-paquet-2016252
Tcl Scripting For Cisco Ios Raymond Blair Arvind Durai John Lautmann
https://ebookbell.com/product/tcl-scripting-for-cisco-ios-raymond-
blair-arvind-durai-john-lautmann-5475340
Ccie Professionaldevelopment Inside Cisco Ios Software Architecture
1st Edition Vijay Bollapragada
https://ebookbell.com/product/ccie-professionaldevelopment-inside-
cisco-ios-software-architecture-1st-edition-vijay-bollapragada-918282

Cisco IOS Access Lists
Jeff Sedayao
Publisher: O'Reilly
First Edition June 2001
ISBN: 1-56592-385-5, 272 pages
This book focuses on a critical aspect of the Cisco IOS--access lists, which are central to securing routers and networks. Administrators cannot
implement access control or traffic routing policies without them. The book covers intranets, firewalls, and the Internet. Unlike other Cisco router
titles, it focuses on practical instructions for setting router access policies rather than the details of interfaces and routing protocol settings.

Cisco IOS Access lists
Page 2
TABLE OF CONTENTS
Preface....................................................................................................................................5
Organization........................................................................................................................6
Audience .............................................................................................................................7
Conventions used in this book............................................................................................8
Acknowledgments...............................................................................................................9
Chapter 1. Network Policies and Cisco Access Lists.......................................................10
1.1 Policy sets ...................................................................................................................11
1.1.1 Characteristics of policy sets ...............................................................................13
1.1.2 Policy sets in networks.........................................................................................13
1.2 The policy toolkit........................................................................................................16
1.2.2 Controlling packets passing through a router ......................................................18
1.2.3 Controlling routes accepted and distributed...............................................................19
1.2.4 Controlling routes accepted and distributed based on route characteristics...................20
1.2.5 Putting it all together............................................................................................21
Chapter 2. Access List Basics.............................................................................................22
2.1 Standard access lists....................................................................................................22
2.1.1 The implicit deny .................................................................................................23
2.1.2 Standard access lists and route filtering...............................................................24
2.1.3 Access list wildcard masks ..................................................................................25
2.1.4 Specifying hosts in a subnet versus specifying a subnet .....................................25
2.1.5 Access list wildcard masks versus network masks..............................................26
2.1.6 The implicit wildcard mask .................................................................................27
2.1.7 Sequential processing in access lists....................................................................28
2.1.8 Standard access lists and packet filtering ............................................................28
2.1.9 Generic format of standard access lists................................................................30
2.2 Extended access lists...................................................................................................31
2.2.1 Some general properties of access lists................................................................34
2.2.2 Matching IP protocols..........................................................................................34
2.2.3 More on matching protocol ports.........................................................................35
2.2.4 Text substitutes for commonly used ports and masks .........................................37
2.2.5 Generic format of extended access lists...............................................................38
2.3 More on matching.......................................................................................................40
2.3.1 Good numbering practices...................................................................................44
2.4 Building and maintaining access lists.........................................................................46
2.4.1 Risks of deleting access lists as an update technique ..........................................48
2.4.2 Displaying access lists .........................................................................................49
2.4.3 Storing and saving configurations .......................................................................50
2.4.4 Using the implicit deny for ease of maintenance.................................................51
2.5 Named access lists ......................................................................................................51
Chapter 3. Implementing Security Policies ......................................................................52
3.1 Router resource control...............................................................................................52
3.1.1 Controlling login mode........................................................................................53
3.1.2 Restricting SNMP access.....................................................................................56
3.1.3 The default access list for router resources..........................................................57

Page 3
3.2 Packet filtering and firewalls ......................................................................................58
3.2.1 A simple example of securing a web server ........................................................58
3.2.2 Adding more access to the web server.................................................................59
3.2.3 Allowing FTP access to other hosts.....................................................................60
3.2.4 Allowing FTP access to the server ......................................................................61
3.2.5 Passive mode FTP................................................................................................62
3.2.6 Allowing DNS access ..........................................................................................63
3.2.7 Preventing abuse from the server.........................................................................64
3.2.8 Direction of packet flow and extended access lists .............................................66
3.2.9 Using the established keyword to optimize performance....................................68
3.2.10 Exploring the inbound access list ......................................................................68
3.2.11 Session filtering using reflexive access lists......................................................75
3.2.12 An expanded example of packet filtering..........................................................79
3.3 Alternatives to access lists ..........................................................................................88
3.3.1 Routing to the null interface ................................................................................88
3.3.2 Stopping directed broadcasts ...............................................................................89
3.3.3 Removing router resources ..................................................................................89
Chapter 4. Implementing Routing Policies.......................................................................90
4.1 Fundamentals of route filtering...................................................................................90
4.1.1 Routing information flow ....................................................................................90
4.1.2 Elements in a routing update................................................................................91
4.1.3 Network robustness..............................................................................................93
4.1.4 Business drivers and route preferences................................................................96
4.2 Implementing routing modularity...............................................................................98
4.2.1 Minimizing the impact of local routing errors.....................................................99
4.2.2 Managing routing updates to stub networks......................................................101
4.2.3 Redistributing routing information between routing protocols .........................102
4.2.4 Minimizing routing updates to stub networks using default networks..............103
4.2.5 Filtering routes distributed between routing processes .....................................106
4.3 Implementing route preferences ...............................................................................106
4.3.1 Eliminating undesired routes .............................................................................107
4.3.2 Route preferences through offset-list.................................................................110
4.3.3 Route preferences through administrative distance...........................................114
4.4 Alternatives to access lists ........................................................................................119
4.4.1 Static routing......................................................................................................119
4.4.2 Denying all route updates in or out of an interface............................................122
Chapter 5. Debugging Access Lists .................................................................................123
5.1 Router resource access control lists..........................................................................123
5.1.1 Checking for correctness....................................................................................124
5.1.2 When access lists don't work .............................................................................125
5.1.3 Debugging router resource access lists..............................................................126
5.2 Packet-filtering access control lists...........................................................................127
5.2.2 Debugging extended access lists........................................................................133
5.3 Route-filtering access control lists............................................................................140
5.3.2 Debugging route-filtering access lists................................................................151

Page 4
Chapter 6. Route Maps.....................................................................................................155
6.1 Other access list types...............................................................................................156
6.1.1 Prefix lists ..........................................................................................................156
6.1.2 AS-path access lists............................................................................................159
6.1.3 BGP community attribute ..................................................................................164
6.2 Generic route map format .........................................................................................165
6.3 Interior routing protocols and policy routing............................................................168
6.4 BGP...........................................................................................................................171
6.4.1 Match clauses in BGP........................................................................................171
6.4.2 Route maps as command qualifiers ...................................................................173
6.4.3 Implementing path preferences..........................................................................174
6.4.4 Propagating route map changes .........................................................................185
6.5 Debugging route maps and BGP...............................................................................186
Chapter 7. Case Studies....................................................................................................189
7.1 A WAN case study....................................................................................................189
7.1.1 Security concerns...............................................................................................191
7.1.2 Robustness concerns ..........................................................................................191
7.1.3 Business concerns ..............................................................................................191
7.1.4 Site 1 router configurations................................................................................191
7.2 A firewall case study.................................................................................................199
7.2.1 Screening router configuration ..........................................................................201
7.2.2 Choke router configuration................................................................................204
7.3 An Internet routing case study..................................................................................207
7.3.1 Robustness concerns ..........................................................................................209
7.3.2 Security concerns...............................................................................................209
7.3.3 Policy concerns ..................................................................................................209
7.3.4 Router configurations.........................................................................................210
Appendix A. Extended Access List Protocols and Qualifiers.......................................219
Appendix B. Binary and Mask Tables............................................................................222
Appendix C. Common Application Ports.......................................................................226
Colophon............................................................................................................................227

Page 5
Preface
Building and maintaining a network involves more than just making sure that packets can
flow between devices on the network. As a network administrator, you also want to ensure
that only the right people can access resources on your network, and that your network will
continue to run even if parts of that network fail or are configured incorrectly. Your
organization may have directives that you need to implement, like using cheaper network
paths whenever possible. In short, while maintaining connectivity is important, you also need
to implement security, robustness, and business policies with your network.
This book is about network policies and how to implement those policies using Cisco IOS
access lists. I present a way to think about access lists and network policy, describe how
access lists are built, and give examples of how to apply those access lists in different
situations. Along the way, there are a number of sidebars and notes about concepts and
information important to using access lists, and at the end of the book, there are appendixes
with useful reference material.
A brief note about what I cover: the access lists in this book deal only with the Internet
Protocol (IP), though you could probably use many of the same techniques with other
network protocols as well. While all the examples involve Cisco IOS access lists, many of the
concepts are generic and can be applied to other router vendors' equipment. I've tried to make
the examples in this book applicable to as many IOS versions as possible; most examples
should work with Versions 10.* and above. If a feature is only available later or is known to
fail with certain platforms and versions, I try to point that out. Please note, also, that the terms
"access list" and "access control list" are used interchangeably throughout the book.
It is unfortunate that the general policy mechanism for Cisco routers is known as an access
list. The term access connotes that access lists apply only to the area of security, while in fact
access lists are used for a whole range of policies, not just for security concerns. I envision
this book as a guide and reference for implementing network policies with access lists on
Cisco routers.

Page 6
Organization
Chapter 1, motivates our discussion of access lists by giving examples of why you need to
implement network policies. It then describes a framework for thinking about access lists and
provides an idea of how we use access lists and the tools for implementing policy.
Chapter 2, describes access list fundamentals: the format of the basic types, masking, and
ways to maintain access lists. It also discusses some tricks and traps of access lists (like the
difference between network masks and access list masks), some common mistakes, and ways
to reduce the number of access list entries and access list changes you may need to make.
Chapter 3, shows how to use access lists to implement security policies. It has examples of
access lists that control access to router resources and to hosts, and discusses the tradeoffs of
different kinds of access lists. The chapter includes explanations of how certain protocols
work and ends with a discussion of access list alternatives.
Chapter 4, describes using access lists to control routing. Network administrators typically
use access lists for routing to make sure that their networks are robust and to implement
business policy decisions; I include a number of examples demonstrating these tasks.
Chapter 5, is about (what else?) debugging access lists. It first goes over how to check that
your access lists are correct, and then shows what to do if you discover that they are wrong.
Chapter 6, describes more advanced forms of access lists, including community lists, AS path
access lists, and route maps. The chapter goes over policy routing and ends with a discussion
of using access lists and routes with BGP, the Border Gateway Protocol.
Chapter 7, concludes the book with some case studies of how different types and applications
of access lists are used together in a variety of scenarios. There are three cases: an example of
routers that connect sites within an organization, a firewall example, and a BGP routing
example.
Appendix A, has a number of tables listing keywords and qualifiers for extended access lists.
Appendix B, contains a decimal/binary conversion chart and a table of prefix lengths and their
corresponding network masks, access list masks, and valid networks.
Appendix C, contains a table of commonly used application ports.

Page 7
Audience
This book is designed for network administrators and others who use Cisco routers to
implement policies, whether the policies are for security or to ensure that networks are robust.
Basic knowledge of Cisco routers and TCP/IP is assumed. Those who are relatively new to
using Cisco routers should start with Chapter 1 and work their way through Chapter 5.
Network administrators who need to implement policy-based routing using route maps,
whether with interior routing protocols or with BGP, should read Chapter 6. Chapter 7
contains case studies that readers may find useful.
Administrators who are experienced in using Cisco routers can use this book as a reference
for policy implementation, debugging, and access lists in general. Chapter 2 describes
masking techniques that may reduce access list sizes and reduce the number of necessary
changes. Chapter 3, Chapter 4, Chapter 6, and Chapter 7 have many examples of
implementing basic security, robustness, and business policies. Readers interested in
debugging access list problems should find Chapter 5 useful. The three appendixes contain
helpful reference tables of access list keywords, decimal to binary conversions, and masks
and ports that common applications use. Network administrators may find the table showing
network masks, access list masks, and valid networks for each possible prefix length
particular useful.

Page 8
Conventions used in this book
I have used the following formatting conventions in this book:
• Italic is used for router commands (commands that are typed at the router command
prompt, whether in privileged mode or not), as well as for emphasis and the first use
of technical terms.
• Constant width is used for router configurations (configuration commands that are
either typed in while in configuration mode or read in from files loaded over the
network). It is also used for strings and keywords that are part of configuration
commands.
• Constant width italic is used for replaceable text.
• Constant width bold is used for user input.

Page 9
Acknowledgments
There are several people and organizations I want to acknowledge. Clinton Wong needs to be
mentioned because he was the person who let me know that O'Reilly was looking for authors
in this area. Several organizations deserve thanks, particularly O'Reilly & Associates for
being interested in my book, Intel for giving me the chance to learn about Cisco routers, and
Cisco for making the routers I am writing about. I'd like to thank my editors—Mike Loukides,
Simon Hayes, and Jim Sumser—for putting up with me through all of these years. Andre
Paree-Huff, Sally Hambridge, Lynne Marchi, and Mark Degner deserve acknowledgment for
providing excellent technical reviews. Finally, I'd like to thank Susan, Stephanie, Kevin, and
Chris for enduring me throughout the writing of this book, and to Mom and Dad for watching
the kids numerous times while I went off writing.

Page 10
Chapter 1. Network Policies and Cisco Access Lists
In the best of all possible worlds, network administrators would never need network policies.
Crackers would never break into a router to invade a network, routers would never pass bad
routing information, and packets would never take network paths that network administrators
did not intend. Sadly, we live in a hostile, imperfect world. Consider the following scenarios:
• Crackers penetrate Company A's public web site. The intruders replace the company's
web content with pornography. Company A's management and public relations are
consumed with dealing with the resulting negative publicity, much to the detriment of
the company's core business.
• A network administrator works at Site O, one of many sites within a large,
geographically dispersed intranet. Instead of typing "19", he types "10" ("9" and "0"
are next to each other on the keyboard) when configuring a local router. As a result,
Site O begins to advertise a route to network 10.0.0.0/8 instead of network 19.0.0.0/8.
Since network 10.0.0.0/8 belongs to Site P, users on network 10 are unable to access
the rest of the intranet. Network 19.0.0.0/8 users are also isolated because their route
in Site P is also not getting advertised. Users at Sites O and P can't do any work
requiring access to network resources outside their respective sites.
• A company has two connections to the Internet through different Internet service
providers (ISPs), both at the same bandwidth. This has been implemented to provide
backup routing in case one connection goes down. One of the ISPs has traffic-based
prices while the other has a fixed price. To reduce costs, the company wants to use the
fixed-price ISP unless the line to it goes down, in which case it will use the traffic-
based Internet connection. Because a routing policy has not been implemented to
enforce this preference, all Internet IP traffic passes through the usage-based
connection, forcing the company to incur higher than necessary costs.
What can we conclude by looking at these scenarios? We see that crackers may try to
penetrate networks, router configuration mistakes can happen, and network traffic may not
flow through the path that network administrators intend. We see that these problems can
occur accidentally or intentionally, often despite good intentions. In all these cases, if certain
network policies had been formulated and enforced, costly problems could have been
avoided.
Let's look more closely at these scenarios. The first involves crackers breaking into a web site
and modifying the contents. What kind of policy could prevent this situation? Allowing only
HTTP (web) access to the web server from the Internet can greatly reduce the probability of a
break-in, since such a policy makes it much more difficult for crackers to exploit operating
system weaknesses or application software security holes. Even if someone gains access to
the web server, preventing the use of services such as Telnet or FTP to or from the Internet
would make it difficult to exploit the server as a platform for further attacks. It would also be
difficult to upload pictures or other content to the server.
This first scenario deals with security. A network administrator must worry about the
definitive network security concerns: unauthorized modification of information, denial-of-
service attacks, unauthorized access, and eavesdropping. Throughout this book, you'll learn
how to use Cisco access lists to enforce security policies.

Page 11
The intranet scenario describes how a configuration mistake at one site in an enterprise
network can create problems for another site far away. In this case, an intranet Site O
advertised a route for a Site P, causing users in Site O and Site P to be cut off from the rest of
the intranet. Again, why are both cut off? Typos happen. Errors in judgment happen. Even
with injections of bad routing information and the best of intentions, a network should keep
running. Network policies that help retain tight control over routes can minimize the impact
of human error.
This scenario illustrates the robustness problem. This problem is conceptually different from
the first scenario and, in many ways, more difficult to deal with. In the security-oriented
scenario, we are trying protect against hostile attacks. In the intranet scenario, we are trying to
protect against operator mistakes. The difference in intent makes it much harder to anticipate
where a problem can occur. Despite the difficulty, it is important that this type of scenario be
anticipated. As intranets and the Internet become mission critical, configuration errors should
not shut down networks. Configuration errors become more and more common as intranets
and the Internet get bigger—the larger a network is, the more components it has that can fail
in strange ways. Also, as more people are involved with maintaining a network, the greater
the chance that one of them will make a configuration mistake. Access policies can minimize
these risks. Maintaining a healthy and robust network is a major motivation for network
access policies, as we will see repeatedly in future chapters.
In the final scenario, traffic should go to the cheaper path, which is identical to the other path
in every respect except for the way it is billed. In this scenario, security and robustness are not
prime motivations. Instead, nontechnical business factors drive traffic policy. Business drivers
are a third major motivation for network access policies.
So these are the three key concerns that motivate the need for access policies: security,
robustness, and business drivers. It should be mentioned that they are not always easily
separated and distinct. Security is often (and should be) a major business reason for access
policies. Good security also helps with network robustness: preventing denial-of-service
attacks keeps the network up and healthy. Conversely, policies intending to maintain network
robustness—minimizing the impact of accidental misconfiguration and equipment failures—
can also minimize the impact of deliberate sabotage. Having a highly available, robust
network is often a business goal that is key to an organization's effectiveness. Despite some
overlap, I mention our three motivations as separate goals because they are distinct and
important enough to help us focus on why we implement access policies.
1.1 Policy sets
Now that you know why you should have policies, how do you implement them in Cisco
router networks? How are Cisco access lists involved with policy at all? In this section, I
describe a conceptual framework that can help with the design and implementation of
policies. The key concept in this framework is the policy set.
If you think about policies in general (not just network access policy), every policy has two
parts, what and how. "What" designates the objects included in a policy. "How" describes
how those objects are affected by the policy. When a policy is enforced, some set of objects
or is evaluated against whether it is affected by that policy. Let's look at policies in a
department store. The store has a policy on business hours. Employees may come in during a
specific range of hours, and customers are allowed in during another range. How is this policy

Page 12
divided into the two parts? The affected objects (the "what") are the store's employees and
customers. The "how" is that employees are allowed in during certain hours, and customers
are permitted to shop during certain hours. Of course, people other than employees, such as
delivery workers, also go into stores. As each person goes in, the policy is enforced, and we
check to see whether they are employees, deliverers, or customers. If they are customers, they
may enter only during certain hours.
Let's look at other policies a store might have. Many stores do not permit customers to bring
in knapsacks or large bags. The "what" in the policy are the knapsacks and large bags brought
by people coming to a store. The "how" is a rule forbidding customers from bringing them
into the store and forcing them to check those items into lockers or drop them off in some
area. Also, stores typically have a policy that only employees may enter certain areas. The
"what" in this policy is employees. The "how" is that only employees are permitted in some
area.
When implementing traffic policies in Cisco router networks, we have to partition them in a
similar way. The "what" of a policy, the set of objects affected, is what I will call the policy
set. Let's look at the policy sets in the department store example. For the business-hours
policy, the policy set consists of the store's customers. For the knapsack policy, the policy set
consists of the knapsacks and large bags that customers bring into the store. For the restricted-
area policy, the policy set is made up of the stores' employees.
Policy sets are defined using a series of policy set entries. These entries include or exclude
objects of interest from a policy set. Let's go back to our department store policies to show
how these policy set entries work. The store may have a policy that only employees who have
undergone cashier training, supervisors, or managers may operate a cash register. In this case,
the policy set is made of employees with the approved characteristics. We define the policy
set with the following policy set entries:
Employees with cashier training
Supervisors
Managers
When an employee tries to operate a cash register, he enters an employee ID number, which is
checked against a database to see whether the employee is in the policy set. Is he an employee
with cashier training? Is he a supervisor? Is he a manager? If any of these conditions apply,
that employee is permitted to operate the cash register. In our knapsack policy example,
knapsacks and large bags are included in our policy set, which is defined with the following
policy set entries:
Knapsacks
Large bags
To enforce this policy, each person coming into the store with a bag is checked. Is the bag a
knapsack? Then it is not permitted. Is the bag very large? Again, it is not permitted. If it is not
one of the choices in the policy set (a purse, say), the policy does not apply, and the customer
may bring the bag into the store.
If the store changes its policy to allow large bags containing merchandise to be returned or
exchanged, the policy set is then defined with the following policy set entries:

Page 13
Knapsacks
Exclude large bags with merchandise for exchange or return
Large bags
When this bag policy is enforced, people coming into the store have their bags checked. Do
they have a knapsack? The bag may not be brought in. Does the bag have merchandise to
exchange or return? Then it may be brought in. Is the bag large? If so, it may not be brought
in. Policy set entries, as mentioned earlier, can either include or exclude objects from the
policy set.
1.1.1 Characteristics of policy sets
Notice that we add each entry to the policy set in the order specified. This is important
because objects are compared sequentially against a policy set. As soon as an object matches
a policy set entry, no more matching is done. If we had the policy set entries in the following
order:
Knapsacks
Large bags
Exclude large bags with merchandise for exchange or return
then "Large bags" are matched before excluding large bags with merchandise to be
exchanged, and no exception is made.
Enforcing policies takes up resources and has costs. The longer the policy set, the longer it
takes to enforce the policy, and more resources are required. Using our department store
example, if our policy set spelled out different colors of knapsacks and bags:
Green knapsacks
Purple knapsacks
Red knapsacks
Beige knapsacks
All other knapsacks
Aquamarine bags
Blue bags
Yellow bags
Exclude pink bags with merchandise for exchange or return
Exclude all large bags with merchandise for exchange or return
All other bags
it would obviously take longer for an employee to inspect incoming bags. The number of
points where policies are enforced also has an effect on resources. A store with many
entrances would need to have an employee at each entrance to enforce the bag policy. This is
why many department stores have only one entrance: to minimize the number of employees
needed to enforce such a policy.
1.1.2 Policy sets in networks
In network policies, policy sets are sets of the network objects that pass through or into a
router. The three types of network objects that routers process are host IP addresses, packets,
and routes. Network administrators implement policies by defining policy sets of these
objects and applying rules to them. The policies are enforced as routers check the host IP

Page 14
addresses, packets, and network numbers going through them to see if they are members of a
defined policy set. If so, rules are applied to those network objects.
1.1.2.1 Policy sets of host IP addresses
Let's give a few examples to show how network policies and policy sets work. I'll describe a
network policy, then break down each policy into a policy set and its rules. Let's start with the
following policy:
Only hosts in network 192.168.30.0/24 can log into Router A
This is the network analog of the department store policy of allowing only employees into
certain areas. In this case, the policy set is composed of the IP addresses in the network
192.168.30.0/24, which we can define as follows:
Policy Set #1: Hosts with IP addresses in network 192.168.30.0/24
We implement this policy by allowing only hosts in the policy set to log into Router A. The
rule that we apply is the following:
Router logins are permitted only from Policy Set #1
When someone tries to log into the router, the IP address of the host is checked. If the IP
address is in Policy Set #1, the person is permitted to log on. This is one way of limiting who
can make changes to a router.
For convenience, policy sets are labeled with numbers and, in some instances, names. This
permits us to reuse policy sets. Let's add another policy as follows:
Only hosts in network 192.168.30.0/24 may use Router A as an NTP (time)
server
We can then have the following policy setting without redefining a new policy set:
Only hosts in Policy Set #1 may use the NTP Service
1.1.2.2 Policy sets of packets
The previous example showed how sets of host addresses form a policy set. Another type of
network object that can be used to form policy sets is a packet. A security-oriented policy
might state:
Only web traffic is allowed to Host A
Such a policy is designed to prevent scenarios like the one mentioned previously, where a
web server was penetrated and altered. The policy set in this example consists of IP packets
carrying the HTTP protocol (the web protocol) going to Host A:
Policy Set #101: HTTP Packets to Host A

Page 15
The policy set is applied against the router interface leading to Host A:
Only packets in Policy Set #101 can pass through the router interface leading
to Host A
Only packets in Policy Set #101 are allowed through the interface to the host. Since web
packets are the only packets defined in Policy Set #101, traffic to Host A is effectively limited
to web traffic.
In addition to host IP addresses and packets, policy sets can be comprised of routes. A policy
might say the following:
Accept only routes to network 192.168.65.0/24 from other routers
A policy like this could be used to send only traffic to network 192.168.65.0/24 through a
given router. It might also be used if we know that only routes to 192.168.65.0/24 arrive at the
router. Any other routes received would be there only because of configuration mistakes
(robustness being the key concern) or intentional attacks (security the key concern). Whatever
our motivation, the policy set would be the following:
Policy Set #2: Network 192.168.65.0/24
How would the policy set be affected? It would be as follows:
Routing protocol: Accept only Policy Set #2
The result would be that network 192.168.65.0/24 is the only route allowed into the router's
routing table.
1.1.2.3 Complex policy sets
As policies get more complex, it can be difficult to separate out a policy set. Take the
following policy:
Network traffic should pass through Organization X only as a last resort
In other words, traffic should not go through Organization X unless no other route is
available. This type of policy deals with scenarios like those discussed previously, where for
business reasons like cost, certain network paths are preferred. How do we specify a policy
set for this? Because traffic will not flow through a router to a given destination unless routing
information exists for that destination, we can implement this policy by defining a policy set
of all the routes going through Organization X:
Policy Set #3: All routes going through Organization X
We can then weight the metrics of the routes from the policy set to make them less appealing
to routing processes and usable only as a last resort:
Routing protocol: Add extra routing metric values to routes in Policy Set #3

Page 16
So far, I have focused only on policy sets, so you might be wondering how Cisco access lists
come into the picture. The function of Cisco access lists is to hold the specification of a policy
set. The term "access list" is somewhat deceptive in that it implies only a security function.
Though access lists are indeed used for security functions, they are properly understood as a
general mechanism used by Cisco routers to specify a set of network objects subject to policy.
Access lists are built of access list entries, which directly correspond with policy set entries.
The framework described here is useful because it helps us think about network policies in
ways that are almost directly translatable into Cisco access lists. In future chapters, I will
almost always define network policies in terms of a policy set and a policy imposed upon it.
1.2 The policy toolkit
What do we do with our policy sets once we define them? How can we use those policy sets
to prevent the described scenarios from happening? This section talks about the "policy
toolkit," a set of four "tools" that are general techniques for manipulating policy sets.
As we know, policy sets can be described as the "what" of a policy. The policy tools fit into
our conceptual framework as the "how." Once we define a policy set, we must do something
with it to implement a policy. There are four kinds of tools we can use with policy sets to
implement network policy. These tools control the following:
• Router resources
• Packets passing through the router
• Routes accepted and distributed
• Routes based on characteristics of those routes
It may not be obvious why a network administrator would use these tools. To understand this,
think about the functions that a router performs in a network. First, in many ways, a router
functions like a host in that there are certain services it provides—logins, network time,
SNMP MIB data. These are router resources that a network administrator can control.
Secondly, a router's key function is to forward packets from one network interface to another.
Hence the network administrator can do packet filtering, i.e., can control the packets passing
through the router. The last key function of a router is to accept and distribute routing
information. Thus, there must be a way to control routes that are accepted and distributed. The
most common way to do this is with the routes themselves: by filtering routes based on their
network numbers. A second, more complex way to filter routes is to use another characteristic
of the routes, like last hop or some other arbitrary route attribute. It can be argued that all
route filtering is done based on some route characteristic, be it the network number or some
other attribute, but we keep them in separate categories because route filtering based on route
characteristics tends to be much more complex than filtering using network numbers.
Controlling routes based on route properties also tends to use radically different access list
constructs.
For each of the four policy tools, I describe the typical policy set and provide an example of
how the tool is used. I'll come back to these examples in later chapters when I show how to
build and use access lists.

Page 17
1.2.1 Controlling router resources
In the original scenarios, we saw how letting unauthorized people log into a web server
created problems. Similar problems can arise when unauthorized people are allowed to log
into routers. Logins over the Internet can allow the theft of passwords and therefore the
penetration of networks. Problems occur when unqualified people are allowed to make
changes. For these reasons, as well as in a more general sense, network administrators need to
have control over the resources on a router. The main concern here is, of course, security, but
network robustness and business policy also play a large part.
Earlier in this chapter, I mentioned that policy sets are composed of one of three things: host
IP addresses, packets, or network addresses. When we control router resources, the policy set
we use consists of host IP addresses: the IP addresses of systems that can access the resource.
Let's look at a policy that defines which machines can access a certain router, restricting
router logins to the hosts at IP addresses 192.168.30.1 and 192.168.33.5. Figure 1.1 shows
how the network is configured with the router, the two hosts allowed to access it, and other
hosts and networks.
Figure 1.1. A router and hosts that could potentially access it
The first step in defining the access policy is to define the policy set of hosts that can access
the router. We do that as follows:
Policy Set #1: IP address 192.168.30.1
Policy Set #1: No other IP addresses
Each of the first two policy set entries adds a specific IP address to the policy set: Policy Set
#1 contains the IP addresses 192.168.30.1 and 192.168.33.5. The third entry explicitly denies
all other IP addresses.
Once the policy set is defined, we apply Policy Set #1 to router logins:
Router logins: Use Policy Set #1
The policy we have just defined says that only hosts with IP addresses 192.168.30.1 and
192.168.33.5 may log into the router.

Page 18
1.2.2 Controlling packets passing through a router
On the Internet, high-profile web servers are constantly probed for potential security
vulnerabilities and opportunities for crackers to penetrate a web server and alter its contents.
These web servers can be substantially protected from this and other kinds of attacks by
limiting the type of packet a router passes on to the servers. With this policy tool, also known
as packet filtering, we define in our policy sets the kinds of IP packets that can pass through
router interfaces. Packet filtering with access lists is a very common use of Cisco routers,
particularly as part of firewalls. Although the primary concern here is security, robustness and
business policy are also considerations, since an organization may find that certain kinds of
packets cause problems. It may decide that it doesn't want a certain type of network traffic
passing through, thus conserving bandwidth or reducing costs.
Almost all organizations now have some kind of web presence, so let's use the web server
example to show how to specify a packet-filtering policy.
The policy will limit access to a web server on an interface of a router to the web protocols
HTTP and SSL. Figure 1.2 shows a typical network configuration that a company might use
for this purpose.
Figure 1.2. Restricting packets to a web server
This configuration shows a web server 192.168.35.1 on router interface Ethernet 0. The
interface Ethernet 1 connects to other hosts and network segments with the company, while
the serial line connects directly to the Internet.
First, let's specify the policy set:
Policy Set #101: HTTP packets to the host at 192.168.35.1
Policy Set #101: SSL packets to the host at 192.168.35.1
Policy Set #101: No other packets
The first two policy set entries permit HTTP and SSL. The last entry excludes all other
packets.

Page 19
Finally, the policy set is applied to the router interface:
Ethernet interface 0: Apply Policy Set #101 to outgoing packets
The result is that the web server at 192.168.35.1 on interface Ethernet can be accessed only
with web protocols.
1.2.3 Controlling routes accepted and distributed
In a previous scenario, a typographic error by a network administrator at one site causes both
the site's own users and those at a remote site to lose network connectivity. Networks would
function perfectly if routers always distributed routes correctly and with the metrics and
directionality that the network designers intended. But as I said, operator mistakes do happen.
In another scenario, network traffic paths are not optimal to an organization in terms of cost.
Often the desire for traffic between networks to flow in certain paths goes against what would
naturally happen with no intervention. To prevent routing errors from causing problems and
to implement traffic-flow preferences, network implementers use the policy tool called route
filtering. Route-filtering policies specify what routes are accepted into a router and what
routes and routing metric values are distributed from a router. The policy sets used are
composed of network numbers and are applied to routing protocols to indicate what routes are
accepted and distributed from a router or what route metric values those routes should
contain.
The main motivations for using this policy tool are robustness and business policy. A network
administrator wants to make sure that a network operates despite the presence of
configuration mistakes, or a business may decide it wants traffic flowing over some paths
instead of others to make a cost-effective use of bandwidth. Security can also be a motivation
for implementing these policies since one way to attack a network is to inject bad routing
information. Route filtering can effectively stop this attack.
Let's look at a simple but very common application of route filtering. To implement such a
policy, we first need to define what networks we want to accept. We then declare that these
routes are the only routes accepted by a given routing protocol. In this example, we accept
only two routes, 192.168.30.0/24 and 192.168.33.0/24, into an EIGRP routing process 1000.
Figure 1.3 shows this network configuration.
Figure 1.3. A configuration where route acceptance and distribution must be controlled

Page 20
The policy set used with route filtering is composed of network numbers. For this example,
we have the following policy set:
Policy Set #2: No other networks
It contains the two networks we specified and excludes all other networks. We then use this
policy set to express the routes accepted for a given routing process:
Routing process EIGRP 1000 accepts only routes in Policy Set #2
Only routes for networks 192.168.30.0/24 and 192.168.33.0/24 are accepted by EIGRP
routing process 1000. All other routes are excluded, so only traffic for the two networks
included will be permitted through the router.
1.2.4 Controlling routes accepted and distributed based on route characteristics
Networks would be much easier to configure and manage if network numbers were the only
criteria we had for route policies, but there are other criteria for making routing decisions,
including route characteristics. For instance, in a previous scenario, a company connecting to
the Internet wants to prefer all routes coming from a particular Internet service provider. An
ISP may want to route traffic depending on preferences that its customers send along with
their route advertisements. In these cases, policy decisions must be made on some route
characteristic other than just the network number. Like the previous policy tool, the policy
sets themselves are still made up of network numbers, but membership in this type of policy
set is based on route characteristics. Although this kind of access policy is typically
implemented when dealing with Internet connectivity using the BGP-4 routing protocol, it can
be done with interior routing protocols as well. The main motivations for using this technique
are business drivers and robustness, but security (e.g., preventing denial-of-service routing
attacks) can also drive its use.
In the next example, we'll see how to control routing based on the properties of routes. In this
case, we route based on the path that routing information has taken. Organization A has a
policy to never route traffic through Organization B. Figure 1.4 shows how network
connectivity might look in this situation.

Page 21
Figure 1.4. Organization A restricting traffic based on paths
Organization A connects to other organizations through a number of paths, some that go
through Organization B and some that do not. The policy's goal is to prevent traffic leaving
Organization A from going through Organization B. To do this, Organization A needs to
reject all routes with a path through Organization B. We build a policy set containing only
routes that do not pass through Organization B:
Policy Set #100: Exclude all routes passing through Organization B
Policy Set #100: Include all other routes
Then we apply the policy set to a route process:
BGP Routing process #65001: Accept only routes in Policy Set #100
on the router connecting Organization A to Organization C.
1.2.5 Putting it all together
These four policy tools are the fundamental techniques that network designers use to create
and maintain secure and stable networks. Think of them as four different ways to keep
networks running. When faced with an Internet or intranet network policy issue, you can deal
with it by controlling router resources, packet filtering, or managing route distribution based
on network numbers or route characteristics. We have seen how hosts, packets, and routes are
controlled through access lists. Another way to think about these tools is to picture the router
as a giant filter, taking in service requests from hosts, packets, or routes, and then either
forwarding them, modifying them, or dropping them. When we want to implement a network
policy, we use our four policy tools as different types of filters on the routers. The actual
filters are defined in access lists.
In this book, we'll see how to use access lists to apply these four categories of policy controls,
and will return to these examples in future chapters to demonstrate how access lists are used.

Page 22
Chapter 2. Access List Basics
In Chapter 1, I talked about the need for network policies. I also described how to build
policy sets, how policy sets map to access lists, and how to manipulate policy sets. However,
before actually implementing any policies, we must first understand how to create and
manipulate access lists. This chapter covers the two basic access list types and how to build
and maintain them. The first kind of access list is the standard access list, used to build policy
sets of IP addresses or IP networks. In describing the standard access list, we will examine the
basic syntax used in all Cisco access lists, including the basic permit/deny operation for
including or excluding network objects from a policy set, address specification and masking,
and the sequence used in processing access lists. The standard access list cannot cover all the
policies we may wish to specify, particularly when we want to do packet filtering, which
leads us to the second type of access list: the extended access list. This kind of list extends the
format of the standard access list to specify packet filtering policies. Once we have learned to
build the basic access list types, the chapter covers how to optimize, build, and maintain
access lists.
2.1 Standard access lists
Also in Chapter 1, we discussed the motivations for implementing access policies. All three
motivations—security, robustness, and business drivers—are reasons to use the standard
access list. With these reasons in mind, a network administrator typically uses standard access
lists to implement three types of policy controls:
• Access to router resources
• Route distribution
• Packets passing through a router
These policy controls require policy sets of IP addresses or network numbers, so the standard
access list is used to build policy sets of either IP addresses or network numbers. Once policy
sets are defined with standard access lists, the access list can restrict access to network
resources, determine which routes are accepted and distributed, and change routing metrics to
influence traffic behavior. To illustrate how the standard access list is used, let's look again at
the first example from Chapter 1, which deals with controlling router resources. Recall that
Figure 1.1 showed a router that we control and the hosts that are allowed to access its
resources. We defined Policy Set #1, consisting of the hosts allowed to log into the router, as
follows:
Policy Set #1: No other IP addresses
How does this policy set map to actual access lists? Here is the mapping:
access-list 1 permit 192.168.30.1
access-list 1 deny 0.0.0.0 255.255.255.255

Page 23
The number after the access-list keyword is the access list number, so in this example, we
define access list 1. The number also specifies what kind of access list it is. Different types of
access lists for different network protocols use different ranges of access list numbers (e.g., IP
uses 1-99 for standard access lists and 100-199 for extended access lists; IPX uses 800-899
for its standard access lists, while DECnet uses 300-399). The first two entries use the
keyword permit, which includes the IP address listed in the entry into our policy set. In this
example, we first include the IP address 192.168.30.1 into our policy set, followed by IP
address 192.168.33.5. The third entry contains the keyword deny, which excludes the IP
addresses following from the policy set. IP address and wildcard mask 0.0.0.0
255.255.255.255 means that we should match all packets. Combined with the deny
keyword, this excludes all other packets (we'll discuss this mask format later in the chapter). It
should be noted that access lists can be entered in the router's configuration only after you
have obtained full privileges on the router and entered global configuration mode.
What do we do with the policy set we have just defined? In the example, we want to control
router login access. The policy set application is summarized as:
Router logins: Only from hosts with IP addresses defined in Policy Set #1
In Cisco router configuration language, this maps to be:
line vty 0 4
access-class 1 in
The first command line states that we are about to define some attributes about virtual
terminal sessions (line vty), the Telnet sessions that allow people to log into the router. In
this command we state that we will have five possible simultaneous sessions, labeled 0 to 4.
The next command line states that the policy set defined by access list 1, our selected set of IP
addresses, is the group of IP addresses that have access to the virtual terminal sessions. Only
Telnet sessions initiated from hosts with those sets of IP addresses will be allowed to use one
of the five available logins. In this way, we have just specified what IP addresses can telnet
into our router. The line command makes all the following options we set apply to all possible
Telnet sessions. We can also apply different access lists for each session.
2.1.1 The implicit deny
Notice that we have used deny to exclude all other IP addresses from our policy set. The
keyword deny is used to specify what is not included in the policy set. For example:
access-list 2 deny 192.168.30.1
Access list 2 does not include IP address 192.168.30.1 in the policy set but does include
192.168.33.5. These two access list entries are equivalent to the following single entry:
This is because access lists have an implicit deny at the end of them. Everything not explicitly
permitted in the standard access list is denied. Similarly, in access list 1 listed earlier, we
could have used the following as our access list:

Page 24
and omitted the final deny completely.
The implicit deny is a key feature of Cisco access lists. It is a behavior that effects the way
access lists are written, generally making them easier to deal with. We will use this feature
extensively.
2.1.2 Standard access lists and route filtering
Previously, I mentioned that the standard access list is also used in route filtering. This means
that we can use standard access lists to build policy sets of routes. Let's go back to the
example in Chapter 1 that illustrated how to filter routes. The network configuration is shown
in Figure 2.1.
Figure 2.1. A configuration where route acceptance and distribution must be controlled
We want a policy that restricts Router A (in Figure 2.1) so it forwards only traffic destined for
the two networks 192.168.30.0/24 and 192.168.33.0/24 through the line on serial interface 0.
We can implement this by configuring Router A to accept only routing information for these
two networks from over the serial line. Traffic between the networks connected to Router A,
172.18.0.0/16, 172.19.0.0/16, 172.20.0.0/16, and 192.168.10.0/24, should be permitted, along
with any traffic between those networks and the two networks on the other side of the serial
line. All other traffic should be dropped. In addition to preventing the router from carrying
unwanted traffic, this policy also prevents routing problems in case a configuration error (here
or elsewhere) sends other routes to Router A over the serial line. To implement the policy, we
need to configure the router to accept only the routes 192.168.30.0/24 and 192.168.33.0/24.
Here is the policy set specification:
Policy Set #2: Route 192.168.30.0/24
Policy Set #2: Route 192.168.33.0/24
Policy Set #2: No other routes
When translated into standard access list notation, this policy set specification yields:

Page 25
This access list includes the two networks 192.168.30.0/24 and 192.168.33.0/24 in the policy
set. We do not need an access list entry that excludes all other routes because the implicit
deny at the end of access lists takes care of this. With the policy set established, we then apply
it to a routing process. In our route distribution example, we specified this by saying:
Routing process EIGRP #20: Accept only routes in Policy Set #2 inbound from
interface serial
The analogous route configuration commands are:
router eigrp 20
distribute-list 2 in Serial0
The first line specifies the route protocol and EIGRP autonomous system (AS) number
involved. The second line says that for this particular EIGRP routing process, only the routes
in access list 2 from routing protocol updates over serial interface 0 will be accepted.
2.1.3 Access list wildcard masks
An optional wildcard mask can be used to include many addresses in a policy set. For
example:
access-list 3 permit 192.168.30.0 0.0.0.255
means that all the hosts on network 192.168.30.0/24 are included in our policy set, as well as
the host with IP address 192.168.33.5. The wildcard mask is interpreted as a bit mask where 1
indicates "match anything" in the corresponding bit in the IP address, and 0 means match the
IP address exactly in that bit position. Making the last octet of a mask all 1's (255) means
match anything in the final octet. Thus every host in the network 192.168.30.0/24 is included
in the policy set. If we apply the list to the virtual terminal lines:
line vty 0 5
access-class 3 in
all the hosts in the 192.168.30.0/24 network and the host at 192.168.33.5 can log into the
router. Another way to think about this is that a 1 is a wildcard for that particular bit position.
Any value, 0 or 1, in the corresponding bit position is considered a match.
2.1.4 Specifying hosts in a subnet versus specifying a subnet
It is important to distinguish between specifying a network number for inclusion in a policy
set and specifying all of the hosts in a network in a policy set. Using the previous example,
the access list entry:
includes all of the hosts in network 192.168.30.0/24 in a policy set. This is not the same as:

Page 26
This access list entry includes the single IP address 192.168.30.0 in a policy set. 192.168.30.0
could be one of two things: a host IP address (a strange one at that, since hosts typically do
not have in the last octet) or a network number. The entry does not include all of the hosts in
network 192.168.30.0/24. If we use access list 4 in an access-class statement such as:
line vty 0 4
access-class 4 in
only a host with the strange but potentially valid IP address of 192.168.30.0 would be
permitted to have login access to the router. Access list 4 would more typically be used to
build a policy set of a network addresses in a routing context:
router eigrp 100
distribute-list 4 in Serial0
Here, only the route to network 192.168.30.0 would be permitted into the routing table via the
EIGRP routing protocol.
If we were building a policy set of network addresses, the address/mask pair 192.168.30.0
0.0.0.255 would include the network 192.168.30.0/24. But it would also include networks
like 192.168.30.0/25, 192.168.30.128/25, and 192.168.30.192/26 that have different mask
lengths. In general, it is best to be as specific as possible when defining policy sets. Including
more than necessary can lead to unexpected behavior such as having unanticipated routes in a
policy set.
2.1.5 Access list wildcard masks versus network masks
One of the most commonly used access list wildcard masks specifies all the hosts in a
network or a network subnet, as we saw in the previous example. Let's define a router's
interface Ethernet on network 192.168.30.0/24 with the IP address 192.168.30.1. We use the
following statements in the router:
interface Ethernet 0
ip address 192.168.30.1 mask 255.255.255.0
The network mask (often called a subnet mask) is 255.255.255.0. The leftmost 24 bits have
a value of 1, corresponding to the first three octets of the Ethernet IP address, which define
the network number. They also correspond to the "24" used when we describe the network as
192.168.30.0/24. The remaining eight bits in this network's IP addresses identify the host. To
get all of the hosts in Network 192.168.30.0/24 into a policy set, we use the following access
list entry:
The access list wildcard mask is 0.0.0.255 (the rightmost eight bits are set to 1). This is a
wildcard mask that matches all the addresses in the network, and it has 0 in the bit positions
where the network mask has 1 and 1 where the mask has 0.
Let's look at another example of network masks and access list wildcard masks that match all
of the addresses in that network. For network 172.28.0.0/16, the network mask is
255.255.0.0. Each of the leftmost 16 bits has the value of 1. These 16 bits correspond to the

Page 27
first two octets in the IP address, which define the network number. The remaining 16 bits in
the network's IP addresses identify the host. If we need an access list address and wildcard
mask combination that include all the addresses in 172.28.0.0/16 in a policy set, we would use
172.28.0.0 0.0.255.255. The access list wildcard mask 0.0.255.255 has 1 in the 16
rightmost bits and 0 in the leftmost 16, while the network mask 255.255.0.0 has 0 in the 16
rightmost bits and 1 in the leftmost 16. Note again that the access list wildcard mask has 0 in
the bit positions where the network mask has 1 and 1 where the network mask has 0. A fairly
common mistake is to use a network's network mask when you want to match all of a
network's hosts instead of an access list wildcard mask.
Generally, for a network specified as A.B.C.D/n, the access list wildcard mask that matches
all addresses in a network will have 1's in the 32-n rightmost bits and 0 in the leftmost n bits.
For the network 192.168.32.0/26, the access list wildcard mask that matches all entries is
0.0.0.63 (six 1's in the rightmost column). The network mask on the interface is
255.255.255.192. For a supernet such as 192.168.80.0/22, the access list wildcard mask that
matched all the addresses in it would be 0.0.3.255 while the network mask on the interface
would be 255.255.252.0.
2.1.6 The implicit wildcard mask
Earlier, we saw an IP address and wildcard mask combination of:
0.0.0.0 255.255.255.255
Since each bit is a 1 in this mask, any IP address on any network will be matched. This
construct is very useful, and we'll see this address/mask combination used repeatedly in both
basic access lists and in extended access lists.
We've also seen access lists in which no mask is included. In the first example, we defined a
policy set that included the addresses 192.168.30.1 and 192.168.33.5. The access list evolved
to be the following:
As I mentioned previously, a 0 in a bit position indicates that there should be a match at
exactly that bit position. Thus, the access list could have been written as:
The lack of an explicit wildcard mask implies a default mask of 0.0.0.0.
The same applies to network numbers as well as hosts. The access list:
includes 192.168.30.0/24 and 192.168.33.0/24 (assuming a typical class C network mask). It
can also be written as:

Page 28
The implicit wildcard mask is a handy feature that saves typing. We'll be using this feature of
standard access lists repeatedly.
2.1.7 Sequential processing in access lists
You will recall from Chapter 1 that access list entries are processed sequentially in the order
in which they are entered. For each network object a router sees, it starts at the beginning of
the access list with the first entry and checks for a match. If not, it continues down the list of
entries until there is a match or no more entries. However, as soon as a match is found, no
more matches are made, which makes the order of the entries in our list a very important
consideration. Let's look at an example:
Access list 4 includes the IP address 192.168.30.70. This address is included even though
there is an explicit deny of the IP address. If the router controls a resource such as login
access with access list 4, and then a host with 192.168.30.70 requests use of that resource, the
router would see that 192.168.30.70 was in the policy set specified by access list 4 and allow
the request. No more matches are made, and the entry on the second line is never reached.
Access list 4 effectively specifies a policy set composed of all the addresses in network
192.168.30.0/24, including 192.168.30.70.
On the other hand, IP address 192.168.30.70 is not in the policy set specified by access list 5:
When the router checks 192.168.30.70 against access list 5, it matches on the first line. The
address is explicitly excluded. Although both access lists have the same entries, the entries are
in a different order. Access list 5 specifies a policy set of all the IP addresses in network
192.168.30.0/24 except 192.168.30.70.
2.1.8 Standard access lists and packet filtering
At the beginning of this section, I mentioned that standard access lists are also used to control
packets flowing through a router. Network administrators use standard access lists in this
fashion when certain hosts need total access to hosts on a particular subnet. Figure 2.2 shows
a network configuration used to protect a set of hosts that process payroll information.

Page 29
Figure 2.2. Using the standard access list for packet filtering
The router shown has two interfaces, Ethernet and Ethernet 1. Network 192.168.33.0/24,
where the payroll hosts live, is on the Ethernet 1 interface while the rest of the network is
reachable through the Ethernet interface. We wish to limit access to the payroll systems on
network 192.168.33.0/24 to the following hosts: 192.168.30.1, 172.28.38.1 (and no other host
on network 172.28.38.0/24), and any remaining host in network 172.28.0.0/16. The hosts that
can send traffic to the payroll hosts on network 192.168.33.0/24 should still be able to send
any kind of IP traffic to that network. No other hosts have any business with the payroll
systems and should have no access whatsoever.
To implement this policy, let's first define a policy set containing the hosts that can access the
payroll machines:
Policy Set #6: host with IP address 192.168.30.1
Policy Set #6: host with IP address 172.28.38.1
Policy Set #6: no other host on subnet 172.28.38.0/24 of network
172.28.0.0/16
Policy Set #6: any remaining hosts in network 172.28.0.0/16 not previously
excluded
This policy set needs to be applied to any packet going out to interface Ethernet 1 where
network 192.168.33.0/24 is attached:
Policy Set #6 translates into the following standard access list:
access-list 6 deny 172.28.38.0 0.0.0.255
The first line puts the host at IP address 192.168.30.1 into the policy set, and the second line
includes the host at 172.28.38.1. After this, we exclude all other hosts in the subnet
172.28.38.0/24. The fourth and last line includes the remaining hosts in network

Page 30
172.28.0.0/16. Note that the sequence of entries is critical. If the second and third lines switch
positions, host 172.28.38.1 is never included in the policy set. If the third and fourth lines are
switched, the hosts in subnet 172.28.38.0/24 are never excluded from the policy set.
The Cisco configuration commands to set our policy are:
interface Ethernet1
ip access-group 6 out
The first line specifies that we will modify the properties of interface Ethernet 1. The second
line says that we apply the policy set defined by standard access list 6 to all IP traffic going
out through router interface Ethernet 1 from the router.
2.1.9 Generic format of standard access lists
Now that we've seen some examples of the standard access list, we can define its format in
some detail. The generic format of the standard access list entry is:
access-list [list number] [permit | deny] [IP address] [wildcard mask
(optional)]
The arguments are:
list number
Access list number from 1 to 99.
permit | deny
Either permit or deny. permit includes a matching entry in the IP address set; deny
excludes it.
IP address
An IP address used to match and determine the IP addresses that are included in a
policy set.
wildcard mask
Optional wildcard mask that determines what bits of the IP address are significant
when matching.
The first part of the standard access list entry is the keyword access-list, which declares
the line to be an access list entry. The next part is the access list number, which identifies
what access list the entry belongs to. The standard access list for IP uses numbers between 1
and 99, which gives us 99 possible standard access lists, more than enough for typical
configurations. With Cisco routers, access list numbers specifically define an access list's type
and the network protocol it uses. Standard access lists can't use extended access list numbers,
while access lists associated with other network protocol suites (such as DECnet or IPX) can't
use standard or extended IP access list numbers.

Page 31
The argument following the list number is a keyword that determines whether an entry is
included or excluded in a policy set. permit means to include all objects matching the entry,
while deny, naturally, means to exclude all objects matching the entry. Another way to think
of this keyword is that it either permits or denies a matching entry into a policy set.
The next part of the entry is the match portion, which consists of an IP address or network
number followed by an optional wildcard mask. The mask is similar to a subnet mask,
marking which parts of a set of IP addresses are constant and which are variable. Like an IP
address, this access list wildcard mask is separated into four parts. Each part has a value from
to 255, representing a one-byte bit mask. A 0 bit in the mask indicates that this bit in an object
must match exactly the same corresponding bit in the IP address, and a 1 bit means that any
bit value matches in that position. Thus a mask of 255.255.255.255 matches all possible IP
addresses, while 0.0.0.0 specifically matches the entire IP address.
2.2 Extended access lists
I mentioned in Chapter 1 that one policy tool network administrators have at their disposal is
control over the type of packets that flow through a router. We looked at examples where it
was necessary to restrict the kinds of packets passing through a router to specific protocols
such as HTTP (web) or SSL packets. To implement this, we need to build a policy set that
includes a variety of different kinds of IP packets. We can't do this with standard access lists
because they deal with only IP addresses, sets of IP addresses, or network numbers, and not
with the nature of the packets themselves. Although we saw how to use standard access lists
to do packet filtering in the last example, there too we could only specify the hosts that are
allowed to send IP traffic through a specific interface. There was no way to narrow down the
kind of packets in a policy set to specific protocols such as TCP or UDP, specific protocol
port numbers, or specific relationships between sets of IP addresses. Standard access lists
allow all or nothing. To do packet filtering at a finer level of granularity, we need a way to
extend the standard access list to include things like protocol, port number, and destination IP
addresses.
Understanding TCP and UDP port numbers
Understanding TCP and UDP port numbers is fundamental to using extended access
lists. To understand port number usage, you have to look at how hosts function
together in networks. In a network environment, client processes on client hosts
make requests to server processes on server hosts, which service the request and
send back a response to the client process. With TCP, a connection is set up with the
request, while with UDP, there is no connection setup. Many different services, such
as Telnet or the Domain Name System (DNS), may reside on the server host. In
order for a client to specify the service it wants to use, it addresses its request to a
previously defined destination port number associated with the desired service. Ports
are specified as 16-bit numbers. For example, the standard port for Telnet service is
23, the port usually used by HTTP (the World Wide Web protocol) is 80, and the
standard port number for DNS service is 53. While there are standard port numbers,
it is important to note that these services can use nonstandard ports. A client
processes can use any of these services on other ports as long as it knows which port
to use.

Page 32
This is only half the process of servicing requests. The server needs to send back a
response to the requesting client process. It is easy to identify where to send the
response if all requests come from hosts with different IP addresses. But what if
requests come to the same service from the same host? To deal with this scenario,
the client process picks a unique source port on the client host for the destination of
a particular request. The server sends responses back to the client's source port using
the client source port as the response's destination port. The previously defined port
for the service then becomes the source port for the response. In this way, a set of
four values—source IP address, source port, destination IP address, and destination
port—uniquely identify client/server relationships and enable clients and servers to
talk to each other without confusion.
The port numbers below 1024 are called well known ports. The Internet Assigned
Number Authority (IANA) defines the standard port numbers in this range for
services such as Telnet, HTTP, and DNS (Table A.3 contains a list of the well
known ports for a variety of services). Typically, source ports for both TCP and
UDP are above 1023. This is the most common case, but there are some notable
exceptions to both of these rules of thumb. DNS requests commonly use port 53 for
UDP source and destination ports. In this case, a query ID is used to uniquely
identify service requests. As mentioned previously, services can live on nonstandard
ports as long as both client and server processes agree to use those ports.
One type of access list is designed to build policy sets for that type of control: the extended
access list. This kind of access list extends the standard access list to include the ability to
specify protocol type, protocol port, and destination in a certain direction. Of our three key
motivations for building access policies, the main motivation for using extended access lists is
security. It is often used for firewall purposes—specifying the packets that can pass through a
router between networks of various degrees of trust. Thus, we'll speak in terms of allowing or
denying packets through a router in our discussions of matching extended access lists.
Let's look at some examples to illustrate how the extended access list works. In Chapter 1, the
second example demonstrated how to create a policy that permitted only web protocols to a
web server with IP address 192.168.35.1 on an Ethernet interface of a router. Figure 2.3
shows how the web server and router connect. The web server lives on Ethernet 0. All hosts
routing in through other interfaces (not on the same segment as Ethernet 0) are permitted only
web access to the server.
Figure 2.3. Restricting packets to a web server

Page 33
To implement a policy allowing only web packets to the web server, we need to define a
policy set that includes only packets for web protocols. The policy set specification looks like
this:
Policy Set #101: HTTP packets to the host at 192.168.35.1
Policy Set #101: SSL packets to the host at 192.168.35.1
Policy Set #101: No other packets
How does this map into an extended access list? Here is the translation:
access-list 101 permit tcp 0.0.0.0 255.255.255.255 192.168.35.1 0.0.0.0 eq
80
443
access-list 101 deny ip 0.0.0.0 255.255.255.255 192.168.35.1 0.0.0.0
Extended access lists begin with the access-list keyword, followed by a list number which
must be between 100 and 199 (unlike standard access lists, which use numbers between 1 and
99). The number is followed by permit or deny, which means the same as it does for
standard lists: either permit or deny packets matching the specification given in the rest of the
line.
The next part is where things get different. After permit or deny, an extended access list
specifies the IP protocol to which the list applies. In this example, we're interested in the
HTTP and SSL protocols, which both use tcp. (The last line in this group denies access for
all packets that haven't been matched previously. To make this as general as possible, we
specify IP itself, rather than a specific IP protocol.)
Next, we have two address/mask pairs (rather than a single pair as we did with standard
access lists). The first pair defines the source address; in this example, 0.0.0.0
255.255.255.255 means "packet coming from any source address," as we'd expect.
192.168.35.1 0.0.0.0 means "packets going to the specific host 192.168.35.1." We thus
allow traffic from any host to the specific host we named.
The access list ends with another protocol specifier: this time, the port number. HTTP uses
port 80, so to allow HTTP access, we place "eq 80" at the end of the line, meaning "allow
packets with the destination port 80." Likewise, we allow SSL access with "eq 443." You can
also specify the port number for the packet source, as I will show later in this chapter. In this
case, we didn't, meaning any source port was okay.
To be accepted into our policy set, a packet must match all parts of an entry. The source IP
address, the destination address, the protocol, and any port or other IP protocol-specific
condition all must match. To use an access list once the policy set is defined, we must apply it
against a router interface. In the previous example, we applied our policy set with the
following:

Page 34
The Cisco configuration commands to do the equivalent are:
interface Ethernet 0
ip access-group 101 out
The first line specifies that we will apply a policy to interface Ethernet 0. The second line says
that we apply the policy set defined by IP access list 101 to all IP traffic going from the router
out through router interface Ethernet 0. Note that our access list applies only to the IP
protocol suite. If we had defined Ethernet to handle IPX traffic, IPX packets would not be
affected at all by access list 101. Protocols such as IPX and DECnet have their own access list
syntax, which is beyond the scope of this book.
2.2.1 Some general properties of access lists
At this point, it is useful to note the similarities and differences between the standard access
list and the extended access list. While an extended access list entry matches against two IP
addresses as opposed to one IP address for the standard access list, both match each IP
address against an IP address and wildcard masks combination in exactly the same way.
Another syntactic difference is that masks of 0.0.0.0 are not optional with extended access
lists. Remember that a router assumes a mask of 0.0.0.0, meaning to match the address
exactly if a standard access list entry leaves off a mask from an IP address. Even with the
standard access list use of an implied mask, IP address and mask matching is the same for
both kinds of lists.
Another common feature of standard and extended access lists is that both have an implicit
deny at the end. Thus we could have rewritten our access list 101 as:
80
443
The final access list entry that denied all other IP traffic to the web server is redundant.
IP address and wildcard mask matching and the implicit deny are common to all Cisco access
list structures and are important concepts in understanding access lists. Other access list
structures that we'll see later on use the same concepts.
2.2.2 Matching IP protocols
I mentioned earlier that other IP protocols can be specified in extended access lists. Here is an
extended access list entry for building a policy set for packets of IP type 47 from the host at
192.168.30.5 to the host at 192.168.33.7:
access-list 102 permit 47 192.168.30.5 0.0.0.0 192.168.33.7 0.0.0.0
IP protocol 47 is GRE, the Generic Routing Encapsulation protocol. This protocol is used for
tunneling non-IP protocols such as Novell IPX and AppleTalk through IP and by the PPTP
protocol, a virtual private network protocol. The 0.0.0.0 mask means match the IP address
exactly. Note that there are no "don't care" bit positions (1) in either the source or destination
address wildcard masks. Because tunneling has a unique set of security hazards associated

Page 35
with it, it is usually a good idea to make policy sets involving tunneling as narrowly defined
as possible. We will discuss tunneling in further detail in Chapter 7.
The following access list matches all IP packets sent from network 192.168.30.0/24 to host
192.168.33.5:
access-list 101 permit ip 192.168.30.0 0.0.0.255 192.168.33.5 0.0.0.0
The mask of 0.0.0.255 has all 1's in the last octet. This means that all IP packets from hosts
in the network 192.168.30.0 destined for host 192.168.33.5 will be in the policy set. Again,
this is similar to standard access lists except that the 0.0.0.0 wildcard mask is not optional.
Specifying all IP between sets of addresses implies total trust by the destination from the
source—any type of traffic can flow from the source to the destination.
2.2.3 More on matching protocol ports
We have created access list entries that have matched on the destination port of an UDP or
TCP packet. We can also match on the source port. This is useful for preventing fraudulent or
spoofed packets from entering. For example, the Network Time Protocol (NTP) uses UDP
packets with both the source and destination port being 123. Any packet with the destination
port of 123 and a source port of something other than 123 is likely not to be a real NTP
packet. If we want to allow NTP packets to the web server in Figure 2.3, we add the
following entry
access-list 102 permit udp 0.0.0.0 255.255.255.255 eq 123 192.168.35.1
0.0.0.0 eq 123
The source port is placed after the source IP address/mask pair.
So far, our examples have had only a single type of port operator: eq. This keyword forces
matching packets to have a port equal to some value. There are other commonly used
specifications; one of particular interest is gt. With this operator, a matching packet must
have a port greater than some value. This comes up frequently as many UDP- and TCP-based
applications use a source port greater than 1023. The following access list entry matches
packets with source ports greater than 1023 and destination ports equal to 20:
access-list 101 permit tcp 0.0.0.0 255.255.255.255 gt 1023 192.168.35.1
0.0.0.0 eq 20
It includes in a policy set any packets coming from any host (0.0.0.0 255.255.255.255)
with a source port greater than 1023 (gt 1023) going to the FTP server (192.168.35.1
0.0.0.0) with a destination port equal to 20 (eq 20). Because TCP port 20 is a well-known
port used by File Transfer Protocol (FTP), this access list is commonly used when allowing
FTP through a router.
The following access list entry matches packets that have a source port greater than 1023 and
a destination port of 53:
access-list 101 permit udp 0.0.0.0 255.255.255.255 gt 1023 192.168.35.1
0.0.0.0 eq 53

Page 36
This access list is commonly used when using the Domain Name System (DNS) protocol
through a router. We'll talk more about these two access list entries when we go into more
detail about using access lists for packet filtering in Chapter 3.
Let's look at a more complex example that demonstrates how to use extended access lists to
tightly control packet flow. For this example, we have a router and hosts in a network
configured as shown in Figure 2.4.
Figure 2.4. A more complex packet filtering example
The host with IP address 192.168.35.1 is used to control medical diagnostic equipment. For
patients' privacy and safety we wish to restrict who can access it and how it is accessed. The
host 192.168.35.1 is isolated on Ethernet 0. All other hosts have routes via Ethernet 1.
We want to restrict access to the host to only those who need it. To do that, we have to look at
what access requirements there are. In the first case, the system administrators of the
diagnostic host access it from network 192.168.30.0/24. Hosts on this network should be
trusted and should have complete TCP access to 192.168.35.1. Next, the host runs an X
Window application displayed on three different consoles. The X windows are displayed to a
host with IP address 192.168.31.1. In addition, doctors and lab technicians need to monitor
the progress of a procedure and get the final results. These doctors and lab technicians use
systems on network 192.168.32.0/24, and they use Telnet to access the host to check on
diagnostic status. Also, since time must be very accurate, the host needs NTP access to an
NTP time server. There are two time servers on the network, at 192.168.50.10 and
192.168.50.11. Finally, we allow hosts on the system administration segment to "ping"
192.168.35.1 to check whether the machine is available. Ping is a utility that uses the ICMP
protocol to send an echo request and expect a reply.
Let's implement an outbound access list that filters traffic from the router through Ethernet to
the segment where the medical diagnostic host resides. With the previously mentioned
requirements, our access looks like the following:
access-list 101 permit tcp 192.168.30.0 0.0.0.255 192.168.35.1 0.0.0.0
access-list 101 permit tcp 192.168.31.1 0.0.0.0 192.168.35.1 0.0.0.0 range
6000 6002
23

Page 37
access-list 101 permit udp 192.168.50.10 0.0.0.1 eq 123 192.168.35.1
0.0.0.0
eq 123
access-list 101 permit icmp 192.168.30.0 0.0.0.255 192.168.35.1 0.0.0.0
echo
The first line of this access list allows TCP packets from all of network 192.168.30.0/24 to the
medical diagnostic host with IP address 192.168.33.5. The absence of any port operator and
qualifer on either the source or destination IP address/mask pairs means that all TCP ports are
allowed. The second line allows packets from host 192.168.31.1 to host 192.168.35.1 with
destination ports 6000 through 6002. The diagnostic host has three consoles. For each
console, the X Window protocol uses a different destination port, starting with port 6000 and
incrementing for each console. The range option allows specification of a range of port
addresses, cutting down the number of entries we need in our access list. The third line
accepts Telnet packets from network 192.168.32.0/24. The Telnet protocol uses TCP
destination port 23. The fourth line permits NTP packets from hosts 192.168.50.10 and
192.168.50.11. The mask of 0.0.0.1 includes both NTP servers in one IP address/mask pair.
The fifth line allows ICMP echo requests from the system management network,
192.168.32.0/24, to the medical diagnostic host. ICMP doesn't have port numbers like TCP,
but it does have different types of packets, such as echo or echo-reply. Allowing echo
requests means that host 192.168.35.1 can receive ICMP echo requests and respond.
We've seen that extended access lists can be used to filter TCP packets on the basis of their
source and destination ports. The same is true for UDP, which also uses the concept of ports
(see the sidebar Understanding TCP and UDP port numbers earlier in this chapter). The
ICMP protocol, which doesn't use ports, allows you to filter based on packet type; the most
common ICMP packet types are echo and echo-reply. An example access list entry using
echo is in access list 101 described earlier.
2.2.4 Text substitutes for commonly used ports and masks
Certain configurations are so common that Cisco has developed text substitutes instead of
port numbers or address mask pairs. The IP address/mask pair:
0.0.0.0 255.255.255.255
matches any host or network address. It can be replaced with the single term any. The IP
address/wildcard mask pair of the form:
<IP address> 0.0.0.0
can be replaced with the form:
host <IP address>
These text substitutes can be used in both standard and extended access lists.
Certain service ports are well defined and commonly used. In previous examples, we learned
that the well known HTTP port is port 80, the NTP port is 123, and the Telnet port is 23. With
this information, we could have rewritten our web server example as follows:

Page 38
access-list 101 permit tcp any host 192.168.35.1 eq http
access-list 101 permit tcp any host 192.168.35.1 eq 443
Similarly, the common types of IP protocols have text values. We have already seen the
common types of TCP, UDP, and ICMP used, but other IP protocols such as GRE have text
values. We can rewrite the access list entry that allows GRE (IP protocol 47) as:
access-list 102 permit gre host 192.168.30.5 host 192.168.33.7
The more complex access list in the medical diagnostic equipment example can be rewritten
as:
access-list 101 permit tcp 192.168.30.0 0.0.0.255 host 192.168.35.1
access-list 101 permit tcp host 192.168.31.1 host 192.168.35.1 range 6000
6002
access-list 101 permit tcp 192.168.32.0 0.0.0.255 host 192.168.33.5 eq
telnet
access-list 101 permit udp 192.168.50.10 0.0.0.1 eq ntp 192.168.33.5 eq ntp
access-list 101 permit icmp 192.168.30.0 0.0.0.255 host 192.168.33.5 echo
Using these text substitutes makes for less typing and more readable access lists.
2.2.5 Generic format of extended access lists
Now that we have looked at a variety of extended access lists, let's define the generic format
of extended access lists as they are typically used. Extended access lists take the following
form:
access-list [list number] [permit | deny] [protocol] [source specification]
[destination specification]
[protocol qualification][logging]
The arguments are:
list number
Access list number from 100 to 199.
permit | deny
Either permit or deny. permit includes a matching entry in the IP address set; deny
excludes it.
protocol
Protocol of packet. This can be ip, tcp, udp, or icmp among other IP protocols, or it
can be an IP protocol number.
source specification
A specification of the form [IP address] [wildcard mask] [port number
specification (only for UDP and TCP)].

Page 39
destination specification
A specification of the form [IP address] [wildcard mask] [port number
specification (only for UDP and TCP)].
IP address
An IP address used for matching.
wildcard mask
Optional mask for determining what bits of the IP address are significant in matching.
port number specification
Optional specification determining some range of numbers for ports.
protocol qualifiers
Optional specification defining a more specific instance of the protocol.
logging
The logging keyword. If present, it turns on a log of all packet information every
time the access list entry is matched.
As with standard access lists, the list number specifies an entry's access list number. For
extended access lists, this number is from 100 to 199, allowing up to 100 IP access lists on a
router. protocol is the type of IP protocol being matched. It can also be an IP protocol
number or else one of the more common IP protocols such as icmp, tcp, udp, or ip (for all of
IP). A complete table of the possible protocol values is included in Table A.1. Source and
destination addresses and masks operate in the same way as the standard access list address
and mask: the source address and mask apply to the source IP address of packets. The
optional source port is the source TCP or UDP port of a packet matching against the list.
Obviously, this applies only to UDP or TCP packets. The destination address, mask, and port
function in the same way.
The optional protocol qualifier depends on the type of IP protocol specified. For ICMP, the
protocol qualifier can be echo, echo-reply, or any of the other ICMP packet types. UDP and
TCP typically use the port number specifications instead, but TCP has an additional qualifier
called established. The established qualifier for TCP matches all TCP packets that are
part of a TCP connection that is already set up, regardless of the source or destination port.
This is a very useful qualifier, and we'll talk more about how to use it in Chapter 3. If no
qualifier is specified, all packet types of the designated IP protocol that match the given
source and destination criteria are matched and added to the policy set. Table A.2 includes all
possible ICMP types and codes, while Table A.3 includes all port number qualifiers.
The final part of the extended access list entry is the logging keyword (you can abbreviate
this by just using log). If the logging keyword is present, then every time that the access list
entry is matched, a log entry is produced. This capability is available only with extended

Page 40
access lists. It is very useful for producing security alerts and for debugging, as we will see in
Chapter 5.
Clearly, there are many possible values for various parts of extended access lists. Appendix A
contains a number of tables that contain all the possible values for protocols and packet types
used in extended access lists.
2.3 More on matching
Proper use of matching and masks can reduce the number of access list entries that a network
administrator must write. As we discussed before, matching sets of IP addresses, whether for
networks or hosts in standard access lists or for the source and destination definitions for an
extended access list, always involves defining an IP address and a mask. Masks are bit masks
that apply to the corresponding bit of the IP address. Remember that a 1 in a access list
wildcard mask is a wildcard, meaning that the corresponding bit in the IP address is a match
no matter what the value is in the IP address being compared. A 0 indicates that the
corresponding bit must match the IP address exactly.
So far we have used only 1's in the last portion of a mask to match all the hosts in that
network, like this:
192.168.30.0 0.0.0.255
In this and all previous examples, the 1's in a mask were on the right while the 0's were on the
left, but we can mask on other portions of an IP address to consolidate access list entries, as
we'll see here. Let's include four networks in a policy set: 192.168.32.0/24, 192.168.33.0/24,
192.168.34.0/24, and 192.168.35.0/24. The following access list entries accomplish this:
We can reduce the number of entries by looking at the network numbers and asking what
these networks have in common. Clearly, the first two octets are the same: 192.168. Let's look
at bit patterns for the third octet of the address in Table 2.1.
Table 2.1. Bit patterns for 32 through 35
Third octet decimal value Binary equivalent
32 00100000
33 00100001
34 00100010
35 00100011
The first six bits are the same (001000), while the last two bit positions vary over the entire
range of possible values (00, 01, 10, and 11) for a pair of bits. Any bit pattern in the two bit
positions will match the mask. Thus we can consider those positions wildcards and use 1 in
the mask at those positions. The bit pattern for the third octet mask is 00000011. This
translates to 3 in decimal. Thus we can then write this access list as only one line:

Page 41
If we need to refer to those four networks again, either in a standard or extended access list,
we can just refer to them as 192.168.32.0 0.0.3.0, a more terse and compact representation.
Grouping networks together in this manner has other benefits as well, which we'll discuss
later in the chapter.
Since the last two bits in the third octet are wildcards, we can use any of the following access
list entries to match the four aggregated networks in addition to the previous entry:
It is best to use our original aggregated entry, with the IP address/mask of 192.168.32.0
0.0.3.0. This is the most intuitive entry, since the block of network starts with network
192.168.32.0/24 and has three more networks in the block. Using the other entries, while
valid, can create confusion and make debugging problems harder because the IP address is
not as intuitive.
Does the following access list entry create the same policy set as the previous aggregated
entry?
It seems to be equivalent. Networks 192.168.32.0/24, 192.168.33.0/24, 192.168.34.0/24, and
192.168.35.0/24 would be included in the policy set. I don't recommend using this as a mask,
though. While the four networks we want are included, wildcarding the last octet includes
other networks, like 192.168.32.128/25 and 192.168.32.64/26. In general, it is best to make
access lists as specific as possible to prevent surprises like this in the future.
Let's look at another access list example:
access-list 101 permit ip 192.168.34.0 0.0.0.255 host 192.168.33.5
This access list includes all IP packets from all the addresses in four networks going to host
192.168.33.5. As in the previous example, we have four consecutive networks. Each has a
mask that matches all of the addresses in that subnet. Can we condense these entries into a
single statement? No. To see why, let's look at Table 2.2, a mapping of the third octet to
binary.
Table 2.2. Bit patterns for 34 through 37
Third octet value Binary equivalent
34 00100010
35 00100011
36 00100100
37 00100101

Page 42
The first address/mask pair that we might try is 192.168.34.0 0.0.3.255. As we saw in the
previous example, an octet value of 3 (00000011) in the mask means that the two rightmost
bit positions in the corresponding octet are wildcards. This implies that the leftmost six bits
have a fixed value, in this case 001000. Since the two rightmost bits are wildcards, they can
take on values from to 3 (00, 01, 10, 11 in binary). Appending these bits to the unchanging
bits leaves the bit patterns 00100000, 00100001, 0010010, and 00100011. These binary
numbers, as we can see from Table 2.1, are 32, 33, 34, and 35. This address/mask pair does
not work. It includes octet values 32 and 33, which we don't want, and excludes 36 and 37,
which we do want.
Another address/mask pair that we might try is 192.168.34.0 0.0.7.255. With the third
octet value being 7, the three rightmost bits are wildcards and thus range from to 7. If we do a
similar analysis to the one we did earlier, we end up with the possible values for the third
octet being 32, 33, 34, 35, 36, 37, 38, and 39. While this includes 36 and 37, we still end up
matching 32, 33, 38, and 39.
What happened here? When the rightmost bits of a mask are wildcards, the following are
always true:
• The number of values matched is a power of 2. There are either 2, 4, 8, 16, 32, 64,
128, or 256 values that can be matched together.
• The starting address matched is a multiple of the number of values matched. If you
match 2 addresses, then the first address matched is a multiple of 2 (even). If you
match 4 addresses, then the starting address is a multiple of 4, and so on.
In the previous example, we tried to make the address/mask pair 192.168.34.0 0.0.3.255
match all the hosts in four networks: 192.168.34.0/24, 192.168.35.0/24, 192.168.36.0/24, and
192.168.37.0/24. This was an attempt to aggregate the numbers 34, 35, 36, and 37 in the third
octet. By the first rule, we have to match a power of 2, in this case 4 since we are trying to
match 4 addresses. The second rule states that the values matched start on a multiple of 4, and
34 is not a multiple of 4. Since the closest multiple of 4 less than 34 is 32, the address/mask
we used matched networks 192.168.32.0/24, 192.168.33.0/24, 192.168.34.0/24, and
192.168.35.0/24 instead of the ones we wanted. We then tried to use the address/mask pair
192.168.34.0 0.0.7.255 to aggregate the four networks. This clearly won't work, as the
three wildcard bits match eight networks instead of four because of the first rule. The second
rule says that the range of values matched must start at a multiple of 8. The nearest multiple
of 8 less than 34 is 32, so the values 32 through 39 are matched, which is more than what we
wanted.
Since 34 is not a multiple of 4, we cannot use a single set of wildcard bits to match 4
consecutive octet values. We can, however, use more than one set of wildcards. While 34 is
not divisible by 4, it is divisible by 2. That means that a mask of 1 with 34 would incorporate
both 34 and 35. The remaining two numbers, 36 and 37, can both also be matched by a mask
of 1, since there are two numbers to match and 36 is divisible by 2. The access list can only be
condensed to the following:
Here we have used a mask of 1 (00000001) as the third octet in each mask.

Page 43
We have seen that we can use a mask such as 192.168.34.0 0.0.3.255 to match all the
hosts in the networks 192.168.32.0/24, 192.168.33.0/24, 192.168.34.0/24, and
192.168.35.0/24. This mask is deceptive. At first glance, it may seem to match the hosts in
networks 192.168.34.0/24 through 192.168.37.0/24. Starting the address/mask pair with
address 192.168.32.0 is much clearer.
Even if you do start a range with an address in the middle of the range,
the router will store and display that particular access list entry with an
address that starts the range. Using the previous example, the router
would change 192.168.34.0 0.0.0.3.255 to 192.168.32.0
0.0.3.255. This property could cause confusion later when you need to
debug access list problems.
We can learn the following rules from our attempts to reduce our number of access list
entries:
• For clarity, your matching rules should always give the base address of a range,
followed by the mask. While any address within the range will work as the address, it
is much more understandable to start with the base value.
• If you want to match some number of addresses that is not a power of 2 or that doesn't
start at a multiple of a power of 2, you have to write two or more access list entries,
each covering part of the range. An alternative is to include more addresses in the
range, which, as we will see later, is often a good idea.
In general, you can condense a set of IP addresses by looking at the bit positions that would
have fixed values over the entire set of IP addresses and those that could be wildcards. This
can happen in the middle of an octet and not just those on the end. Consider the following
access lists of networks:
These can be combined into:
since the bit patterns of 217 and 221 (see Table 2.3) vary only in the sixth bit position. A 1 in
the sixth bit position corresponds to a mask value of 4.
Table 2.3. Bit patterns for 207 and 211
Third octet value Binary equivalent
217 11011001
221 11011101
It should be noted, however, that putting wildcard bits in the middle of octets does not make
for easily readable access lists. Such unintuitive masks can make debugging problems more
difficult. You should use masks like this only when your access-list lines are at a premium or
if you are very sure that the octet values you are matching change very infrequently.

Page 44
For your convenience, all possible octet values and their corresponding bit patterns is
included in Table B.1. Table B.2 lists the most commonly used access list wildcard masks and
what values they can match.
Why make access lists shorter?
Performance, stability, and ease of maintenance are the key reasons that access lists
should be as short as possible. Remember, routers process access lists sequentially
when checking to see if an IP address, network address, or packet is a member of a
policy set. On each router interface with an inbound or outbound access list, the
router needs to check each packet passing through the interface against the access
list in each direction. Long access lists that force the router to parse and compare
many entries consume the router's processing resources as the CPU costs increase
with the number of interfaces that require attention.
Access lists can grow to the extent that they threaten a router's stability. If access
lists are so large that the router's configuration no longer fits into flash configuration
memory, only a partial configuration will be used when the router reboots. If the
router crashes for any reason and reloads a partial configuration, the behavior of the
router will be unpredictable. Although using configuration compression can help in
this situation, there is still the risk of instability as a number of Cisco IOS versions
have problems with configuration compression (discussed in Chapter 5).
Long access lists are also much more difficult to maintain. For example, if there is a
problem with a 500-entry access list, a network administrator may have to examine
each of the 500 entries to find the problem. Reducing access list length early on can
save a lot of debugging work later.
In some situations, long access lists may be unavoidable. In later chapters, we'll talk
more about how to deal with long access lists—how to debug them and how to
lessen the impact of long access lists or many access lists.
2.3.1 Good numbering practices
The way that IP addresses are assigned can save a network administrator significant amounts
of time and network resources. Good numbering practices can reduce the number of access
list entries, make the addition of hosts easier, improve performance, and even lessen network
traffic. Factoring policy and access requirements into a network design at the beginning is lot
easier than retrofitting policies later.
If you are assigning IP addresses to hosts and know that they have identical access list
requirements, there are numbering practices that can reduce the number of access list entries
you may need. To begin with, use blocks of addresses or networks in powers of 2. Start
numbering at a multiple of that block size. For example, say that you are numbering four
hosts that need permission to log into a router. You should get a block of four addresses and
start numbering hosts at 4, 8, 12 or some other multiple of 4. That way, the block of IP
addresses or networks can be matched in a single access list entry, in this case, with a mask of
3 in the proper octet. Since the IP addresses of the four hosts that need to access our router are

Page 45
192.168.30.4, 192.168.30.5, 192.168.30.6, and 192.168.30.7, you could write the access list
for them as follows:
But since we numbered them as we did, we could write a single access list entry for all four
hosts:
Our numbering work here is similar to how we reduced the number of access list entries by
using masks. In this case, we allocate the numbers to create a mask that enables fewer entries
in our access list.
When you know that you will have to add hosts that function identically to hosts already in
access lists, a variation of this technique can save on future work. Let's say we have a web
server at 192.168.30.16 and know that we may need to add more web servers later. We can
create the access entry:
access-list 101 permit tcp any 192.168.30.16 0.0.0.15 eq http
and then reserve the block of addresses 192.168.30.17 through 192.168.30.31 for future web
servers. That way, when another web server needs to be added, it can be added within the
block of addresses already reserved. No access list changes required! We can add up to 15
more web servers without having to make access list changes. This can really save time,
particularly if an organization allows router changes only during certain change windows.
Although this technique does not efficiently use an address space, it is a tradeoff a network
administrator can make on a case-by-case basis.
Allocating network numbers in a smart way can also improve router performance and even
reduce network traffic. Like the example with hosts, if you have a number of networks that
function similarly and need their routes distributed in identical ways, allocate network
numbers that can be masked together easily. Let's look at a case where we need to advertise
eight routes to the Internet. We could allocate eight consecutive networks that start on a
multiple of 8, such as 192.168.24.0 through 192.168.31.0. This allows us to express the
networks in an access list with one entry instead of eight:
Some routing protocols such as BGP and EIGRP can aggregate routing information so that a
bigger aggregation of networks leads to smaller route updates and thus less network traffic.
Smaller route updates reduce the amount of memory routers need for routing tables as well as
the router CPU resources needed to manage routing updates.

Page 46
2.4 Building and maintaining access lists
So far, we have seen many examples of access lists, but I have not shown how standard and
extended access lists are entered into the router and maintained.
Access lists are part of the router's configuration; they are not some register values that we
can set from the router's command line. That being the case, we enter access lists in the top
level of configuration mode, and must have fully enabled access in order to do so. Access list
entries are appended to the existing list in the order in which they are entered. For example,
here is how to enter the access lists implementing the first example in Chapter 1 on a router
called RouterA:
RouterA# conf term
RouterA(config)# access-list 1 permit 192.168.30.1
This creates the following access list with two entries:
If we exit the router's configuration mode and then reenter and type the following access list
entries:
RouterA# conf term
RouterA(config)# access-list 1 deny 192.168.30.1
we end up with the following access list:
It is critical to understand how new access list entries affect an access list. If you want to
delete or change an individual access list entry, you have to delete the entire access list and
reenter it with the changed or deleted access list entry. Again, this is because any new access
list entries are appended to the list. In our example, we entered deny 192.168.30.1 after
permit 192.168.30.1. The deny entry does not "cancel" the permit entry; it only makes
the access list bigger. Moreover, it is never even evaluated. As I mentioned earlier in the
chapter, access lists are evaluated sequentially. The permit entry for host 192.168.30.1 is
always evaluated before the deny entry for host 192.168.30.1. Thus the deny entry is
superflous.
You should note that while access lists may be deleted, references to those access lists do not
disappear. If an access list is deleted and then rebuilt, policy settings that refer to it will use it
in the same way as before. In our first example, we used access list 1 to control login access.
We used the following configuration commands:
line vty 0 4
access-group 1 in

Page 47
If we delete access list 1 (using the no access-list 1 configuration command), the reference
to access list 1 still remains. How does a standard access list behave when it is applied to a
vty line or interface but has no entries? You might expect that since access lists have an
implicit deny at the end, an access list without entries would deny everything. In fact, the
opposite is true. The empty access list behavior is to permit everything. For standard access
lists, this becomes:
access-list 1 permit any
Similarly, an extended access list without entries permits everything:
access-list 101 permit ip any any
The easiest way to create and maintain access lists is to keep them all in a single file on a host
and read them in via Trivial File Transfer Protocol, or TFTP. (Most Unix systems have TFTP
implementations, and software to implement a TFTP service is available on operating systems
from Windows 3.1, 95, and NT to VAX/VMS.) To maintain access lists this way, precede
every access list with the statement no access-list n, which deletes list n and allows you to
create a new list from scratch. Here is an example using the access list associated with our
very first example:
no access-list 1
When this file is read into the router, access list 1 is deleted. A new access list 1 is then
constructed from the entries of access list 1 that follow. With this technique, a network
administrator can edit individual access list entries offline from the router. An entire access
list does not need to be typed in just because a few individual entries were changed. Once
access lists are ready, the configuration file can be loaded in over the network.
Note that this technique, while convenient, can have risks. Under some
versions of IOS, reusing an access list number after deleting it can result
in some or all of the same entries still being there. Test your version of
the IOS for ACL "ghosts" before using this technique.
Another benefit of maintaining access list entries in a file is the ability to insert comments. As
an access list grows in length, inserting comments can make it much easier to read, modify,
and maintain, especially if someone other than yourself needs to change it. Even if you are the
original author of an access list, you may forget why you created a particular entry. Lines in
the configuration file that have an exclamation mark (!) or hash (#) as the first character are
comments. For example, let's document our previous example:
# access list 1 - policy set of addresses allowed
# to log into router A
#
! cancel old access list
no access-list 1
! permit Ted's workstation
! permit Mary's workstation

Page 48
The comments make it easier to understand and remember the purpose of access list 1 and its
entries and are ignored by the router.
To load a configuration file over the network, the file has to be placed in an area that is
accessible via TFTP from the router. It needs to be made readable by everyone on the host.
Once the file is ready, we need to configure the router over the network. As an example, let's
configure (we have to be fully enabled) a router from a file called routera-access on a host
with IP address 192.168.30.1:
RouterA# copy tftp://192.168.30.1/routera-access system:running-config
Configure using routea-access from 192.168.30.1? [confirm] y
Loading routera-access from 192.168.30.1 (via Ethernet 0): !!!!!!!
[OK - 12052 / 128975 bytes]
RouterA#
On most implementations of TFTP, a file has to be "world readable" to be read from the
network. This makes your access lists viewable to everyone on the host and potentially
everyone on your network. This is problematic. You do not want to make a cracker's life
easier by giving him your access lists. In addition, you probably do not want to make all the
files on the host accessible to the world either. To avoid these security problems, you can do
the following. First, configure TFTP to limit read access to a specific directory. This prevents
other people on your network from reading files on your host that are not in the directory you
specify for access list configuration. It also does not allow anyone to substitute their version
of access lists into the directory and have those loaded into your routers. Second, configure
your TFTP software to allow only your router access to the configuration files. Third, delete
the configuration file or change its read permissions to not be world-readable after you are
done configuring the router.
Generally, performing the following steps every time you configure a router with TFTP will
greatly reduce security exposure:
1. Make access lists readable only by the router
2. Configure router via TFTP
3. Make access lists unreadable from the network and to other users on the TFTP server
There are many ways to implement Step 3. One of the simplest ways is to delete the access
list file from the TFTP accessible area. Other ways include changing the read permissions on
the access list file or turning off the TFTP service. Whatever you choose, performing these
steps, either through automation or manually, will reduce any potential vulnerability.
2.4.1 Risks of deleting access lists as an update technique
Our approach to maintaining access lists (using no access-list) has its drawbacks. As
mentioned earlier, if we refer to an access list and then that access list is deleted with a no
access-list command, the default behavior is to allow everything. When reading in a
configuration, there is a brief period between the time that the no access-list command is
executed and the first access list entry is accepted. During this period, there is no access list,
and everything is permitted. Once the first entry is accepted, the implicit deny takes effect and
only specifically permitted entries are accepted into a policy set. When you are updating
standard access lists, someone could use a previously restricted resource, or routing
information once controlled could leak. When you are updating extended access lists, packets

Page 49
previously stopped could get through during that small window of time. For some denial-of-
service attacks, all that is needed to crash a host is one packet.
Fortunately, the risk is small, and there are ways to mitigate this risk. To find out how, let's
look at this issue in more detail. First, the period of vulnerability is much smaller than a
second. Routing updates have a frequency of 30 seconds for routing protocols such as RIP, 90
seconds for IGRP, and as needed for protocols such as EIGRP and BGP. For any routing
information to leak inadvertently, the window of vulnerability must occur during a routing
update. Second, there are ways to configure a network so that there is always at least one
filtering barrier between potentially hostile areas and a protected area. We will talk about this
in Chapter 7 in a firewall case study.
If the risk is still unacceptable, there are maintenance techniques to eliminate it. Instead of
using no access-list at the start of the configuration file, build any new access list versions
using a different access list number. In our previous example, we build access list 2:
We then read in access list 2 via TFTP (note that we can define and maintain access lists on a
router even if they are not used). When we are ready to cut in the new access list version, we
use access list 2 as a new access group:
line vty 0 4
access-group 2 in
If you reserve two access list numbers per access list, you can switch back and forth between
access list numbers every time you update the list. This will help conserve access list numbers
in the unlikely event that you are close to running out. It does limit you to 50 different access
lists, and you have to change access list numbers every time you change access lists. Another
method is to reserve at least one access list number for transition purposes. With this
technique, you can load in a new access list with the reserved number and then use the old
access list number as the new reserved number. Also, although the example uses a standard
access list, we can configure interfaces similarly with extended access lists.
2.4.2 Displaying access lists
We have discussed building and entering access lists, but not how to examine the access lists
on a router. To see a router's access list, you can use the command show access-list. This
command shows all of the access lists in the router, both simple and extended. If you follow
the show access-list command with an access list number, you see only an individual access
list. Here is an example listing for a standard access list:
access-list 1
permit 192.168.30.1
permit 192.168.33.5
Here is example output for an extended access list:
access-list 101
permit tcp any host 192.168.30.1 eq www
permit tcp any host 192.168.35.1 eq 443

Page 50
Notice that the output of show access-list has a different syntax from the format used to create
access list entries. The output is not legal syntax for entering access list entries, so cutting and
pasting the entire output of the show access-list command into a file will not produce an
immediately usable configuration. Also, show access-list does not show any comments you
may have created in the configuration file. The router doesn't save comments in its
configuration; they are ignored when the router sees them. You don't need to be fully enabled
in order run the show access-list command.
2.4.3 Storing and saving configurations
If you have been working extensively on access lists by using the configure terminal mode
of the router, the access lists configured on the router may not be synchronized with the
access list stored offline. One way to capture the current access lists is to write them to a file
via TFTP. Here is the router command (which requires fully enabled access) to save your
configuration:
RouterA# copy system:running-confg tftp://192.168.30.1/RouterA-access
Write file RouterA-access on host 192.168.30.1? [confirm] y
Writing RouterA-access !!!!!!!!!!!! [OK]
RouterA#
In this example, we copy the configuration of RouterA to a file called RouterA-access on host
with IP address 192.168.30.1. The file now contains the entire configuration of the router
(stuff other than access lists), but the current access lists can be edited out of the file.
Older versions of the IOS use the command write network instead of
copy.
To save a configuration via TFTP, you have to make an area on your TFTP server available to
the router for writing files. This leaves a potential security vulnerability, especially if you use
the configuration file you have saved to configure this or other routers. A cracker could
potentially overwrite the router configuration with a configuration that suits the cracker's
purposes. If you are not careful about making what you leave writable, the cracker can write
malicious files and programs to the TFTP host. To reduce your risk, the steps you should take
are similar to those for configuring a router by TFTP: limit write access to a specific directory
and configure your software so that only the router can write to that specific directory. After
saving the configuration, move the file out of the directory or change its permissions to be
unwriteable and unreadable. Performing the following steps whenever you save
configurations via TFTP should greatly reduce potential security exposure:
1. Make area writeable by router
2. Save configuration via TFTP
3. Make configuration file unwriteable and unreadable from the network and to other
users on the TFTP server
As mentioned previously, Step 3 can be implemented in many ways, such as changing file
permissions on the configuration file, shutting down the TFTP service, or moving the file to
another directory.

Exploring the Variety of Random
Documents with Different Content

Shawls made in Norwich 587
Sheriffs of Norwich, complete list of 688
Shirehall, portraits in (Earl of Leicester, Lord
Wodehouse, and H. Dover, Esq.)
49, 50
Shoe Trade, Wholesale 601
Shops, Warehouses, Banks, &c 18
Sixteenth Century, Norwich in the 188
Slavery, Abolition of 368, 371, 374
Smith, Sir James Edward 312
Soap Manufacture 621
Soc, Sac, and Custom 166
Spanish Armada, supplies against 205
Springfield, T. O. 373, 588
,, first Mayor of New Corporation 403
St. Andrew, Parish of 70
,, Andrew, Parish of (Eaton) 104
,, Andrew’s Hall, description and history of 51
,, ,, dimensions of 54
,, ,, Flag of France taken by Nelson 58
,, ,, Mayor’s Feasts in 52 et passim
,, ,, Musical Festivals 53, 324, 333, 356,
403, 455
,, ,, Portraits and Pictures in 57
,, ,, Portrait of Nelson, by Beechey 56
,, ,, restored 281

,, ,, used as Corn Hall and Exchange 54, 272
,, Augustine, parish of 87
,, Bartholomew, Heigham 102
,, Benedict, parish of 74
,, Clement, parish of 91
,, Edmund, parish of 93
,, Etheldred, parish of 82
,, George Colegate, parish of 89
,, George Tombland, parish of 77
,, Giles, parish of 67
,, Giles’ Hospital (see Charitable Institutions)
,, Gregory, parish of 68
,, Helen, parish of 79
,, Helen’s Hospital (see Charitable Institutions)
,, James, parish of 93, 108
,, John Maddermarket, parish of 69
,, John Sepulchre, parish of 95
,, John Timberhill, parish of 97
,, Julian, parish of 81
,, Lawrence, parish of 73
,, Leonard’s Priory 136
,, Margaret, parish of 74
,, Mark (Lakenham) 105
,, Martin at Oak, parish of 86

,, Martin at Palace, parish of 79
,, Mary, Friars of 138
,, Mary Coslany, parish of 88
,, Matthew (Thorpe) 106
,, Michael at Coslany, parish of 85
,, Michael at Plea, parish of 77
,, Michael at Thorn, parish of 96
,, Paul, parish of 93, 108
,, Peter Hungate, parish of 78
,, Peter Mancroft, parish of 64
,, Peter per Mountergate, parish of 81
,, Peter Southgate, parish of 82
,, Philip (Heigham) 102
,, Saviour, parish of 92
,, Simon and Jude, parish of 79
,, Stephen, parish of 94
,, Swithin, parish of 73
Stanfield Hall, Murders at 416
Stanley, Bishop, Memoir of 522
Stannard, Alfred, artist 549
Stannard, Joseph, artist 548
Stannard, Mrs., artist 549
Staple Town, Norwich made a 178
Starch and Mustard manufactory (Messrs. J. and
J. Colman’s)
84, 605

Stark, James, artist 550
Stevenson, William, F.S.A. 313
Stewards of Norwich, list of 705
Stormont and Scarlett’s Election—Commission of
Enquiry
,, ,, Evidence of Bush, Henry 397
,, ,, ,, Cooper, William 397
,, ,, ,, Cozens, Mr. 397
,, ,, ,, Francis, J. 397
,, ,, ,, Hayes, John 397
,, ,, ,, Rust, Thomas 396
,, ,, ,, Turner, Alderman 397
,, ,, ,, Wortley, Mr. 397
Stracey, Sir H. J., Bart., M.P., unseated 668
Street Improvements (London and Opie Streets) 19
Streets named from Trades 121
Streets, names of, first put up 280
Surtees, Rev. Scott F., on Roman Invasion 152
Survey of the City 9
Sutton, Dr. Charles Manners 328
Swedenborgians (French Church) 114
Sweyn, landing of 118
Tabernacle Chapel 110, 256
Tanners’ Guild 74

Taylor, Dr. John 295, 313
Taylor, Professor Edward 295, 344, 350,
458, 643
,, ,, Memoir of 475
Taylor, William 313
Telegraphic Communications 16
Textile Manufactures, History of 553
,, in Eighteenth Century 569
,, in Nineteenth Century 578
Theatre Royal 61, 322, 367
Thelwall, the Republican Orator 287
Thirteenth Century, Norwich in the 173
Thorpe, Hamlet of 106
Thurlow, Edward Baron 313
Tillett, J. H., petitioned against Sir H. J. Stracey,
Bart., M.P.
668
Tobacco and Cigar Trade 617
Tombland, St. George’s 77
Towers of the Old City 124
Trade Regulations in Seventeenth Century 265
Trade Stations and Rows in Olden Times 19, 121
Trinity, Holy, Church of (Heigham) 102
Trowse Millgate 106
Turnpike Roads opened 280
Twelfth Century, Norwich in the 169

Tyler’s Wat, Rebellion 178
Unitarian Chapel (Octagon) 113
Unitarians, History of the 295
Upholsterers, Manufacturing 619
Urns, Sepulchral, of Iceni 148
Valpy, Dr., Head Master of Grammar School 45, 334
Venta Icenorum 11
,, Gurney, Hudson, on the 153
,, Woodward, B. B., on the 117
Volunteer Infantry 325, 326
Volunteer Rifle Corps 433, 738
Wales, Prince and Princess of, in Norwich 443
Walloons settled here 204
Walls and Gates, old 121
Ward Elections, cost of contests 319, 320
Water Gate to Cathedral Precincts 44
Water Works 99
Wat Tyler’s Rebellion 178
Weavers’ Co-operative Society 441
Weavers, disturbances by 373, 406, 583
Weavers, number of (in 1839–1840) 584

Wellington, Statue of 63
Wensum River, rise and course of 16
Wesley, Revs. John and Charles in Norwich 112, 257
White Friars 137
Whitlingham (Sir R. J. H. Harvey’s) 107
Wilkins, William 314
Wilks, Rev. Mark 482, 637
William, “The Boy Martyr” 174
Windham, Major General, “Hero of the Redan” 433
Windham, William 314
Wine, Spirits, and Beer Trade 615
Woodward, B. B., on Fortifications of Castle 23
,, on Venta Icenorum 117
Wool Weaving Introduced 171
Workhouse, first act for erecting a 269
Workhouse, New (built in 1859) 101
Workhouse, Old 327
Worship, Places of (see “Churches” and
“Chapels”)
Worsted Manufacture introduced 166
Wren, Bishop, and the “Book of Sports” 244
Wrench, Sir Benjamin 314
Yarn Company, first stone of factory laid 403
Young Men’s Christian Association 732

A SURVEY OF NORWICH.
Rise and Progress of the City.
In tracing the rise and progress of the city, it is necessary to inquire
respecting the physical condition of the district around it at an early
period. Before the dawn of authentic history, it is in vain to expect
full information on this point; but the natural changes that have
taken place may be traced with tolerable clearness. Geologists
inform us that the whole area of Norfolk, including Norwich, was in
remote ages under the sea; that by the slow accumulation of alluvial
matter islands were formed in this estuary; and that the waters were
divided into several channels.
We may speculate as to the causes of these changes of the level of
land and water, but we cannot doubt the fact of such changes
having taken place. When or why the great body of waters retired
to its great reservoir in the bed of the ocean is unknown; but
whatever the causes, it is certain that between the first and the
eleventh century the waters did gradually recede till the river
assumed a narrower appearance. The higher part of the city from
Ber Street up to Lakenham was probably, 2000 years ago, like an
island surrounded by water flowing up the valley of the Taas on that
side, and over the valley of the Wensum on the other side.
The existence of Norwich as a city during the Roman period from B.C.
50 till A.D. 400 or 500 is very doubtful. Camden says that its name
occurs nowhere till the Danish wars. If it did exist, it was only a
fishing station, for then a broad arm of the sea flowed up the valley

of the Yare, and covered a great part of the north side of the present
city. Indeed, for centuries after the Christian era this arm of the sea
may have flowed over the greater part of the ground on which the
north side of the city now stands. In the course of time, however,
the arm of the sea gradually silted up and left only the present
narrow river Wensum flowing into the Yare.
Tradition has handed down this couplet:
“Caister was a city when Norwich was none,
And Norwich was built of Caister stone.”
There is, however, no evidence that Caister was ever more than a
village on the banks of the Taas, where the Romans built a camp to
overawe the neighbourhood; while all the old Roman roads have
always radiated from Norwich, proving that it was a place of
importance in the Roman period. The Iceni called it Caer Gwent,
altered by the Romans into Venta, so that it was the Venta Icenorum
of the Romans, who probably threw up the mound on which a castle
was afterwards built, in the Anglo-Saxon period.
Norwich very likely took its rise after the departure of the Romans,
about A.D. 418, on account of the distracted state of the empire.
Then, the camp or station at Caister being almost deserted, the few
remaining Romans joined with the natives, and they became one
people; and the situation of Norwich being thought preferable to
that of Caister, many retired hither for the facility of fishing and the
easier communication with the country. Caister, however, though
almost deserted, kept up some reputation, till the river becoming so
shallow, cut off all intercourse with it by water and reduced it to a
place of no importance.
After the departure of the Romans, the Angles from the opposite
coast made themselves masters of this part of the island, and to
them is chiefly owing the further progress of the city and its present
name. “Northwic” signifies a northern station on a winding river, and

may have been so called because of its being situated north of the
ancient station at Caister.
Norwich Castle was probably built in the reign of Uffa, the first king
of the East Angles, soon after the year 575. About 642 it became a
royal castle, and one of the seats of Anna, king of the East Angles,
whose daughter Ethelfred, on her marriage with Tombert, a
nobleman or prince of the Girvii (a people inhabiting the fenny parts
of Norfolk), had this Castle, with the lands belonging to it, given her
by her father. About 677, this Tombert and his wife granted to the
monastery of Ely, which they had founded, certain lands held of
Norwich Castle, by Castle guard, to which service they must have
been liable before the grant, for, by the laws of the Angles, lands
granted to the church were not liable to secular service, unless they
were at first subject thereto whilst in secular hands, which proves
that this was a Royal Castle in the time of King Anna.
The Danes soon came over in such large numbers and so frequently,
that they at last got possession of the whole of East Anglia, and
became the parent-stock of the inhabitants of parts of Norfolk and
Suffolk. In 1003, Sweyn or Swaine, King of Denmark, came over
with his forces and, in revenge for the massacre of the Danes in the
previous year, burnt Norwich and its Castle, as well as many other
places. They afterwards rebuilt the city and castle, and came hither
in such large numbers, that Norwich became a Danish city, with a
Danish Castle, about 1011. After the restoration of the Anglo-Saxon
dynasty, the city entered on a new career of prosperity, and
according to the Domesday Book of Edward the Confessor, it
contained 25 churches, and 1320 burgesses, besides the serfs or
labourers. It was still the capital of East Anglia, with a few hundred
houses, but the greater part of the area round the Castle presented
only marshes and green fields. Two broad arms of the sea still
flowed up the valleys on each side of the city. The whole district all
around consisted of marsh, and moor, and woods, and yet
uncultivated land.

In 1094, Herbert de Losinga, then Bishop of Thetford, removed the
See hither, and began to build the Cathedral, from which time the
city increased yearly in wealth and trade. Domesday Book (1086)
contains an account of all the lands and estates in England, and also
of all the towns. Norwich was then next in size to York, and
contained 738 families. Thetford had at the same time 720
burgesses, and 224 houses empty. Thetford, therefore, was
decaying and Norwich was rising. In 1377, a census was taken of
several great towns in England, and Norwich was found to contain
5300 people, for a migration hither of Flemings and Walloons, who
introduced the manufacture of woollen and worstead fabrics, had
increased the population. In 1575, the muster roll of men delivered
to the government capable of bearing arms contained 2120 names,
which would be the proportion for 15,000 people. The population in
1693 amounted to 28,881 inhabitants. In 1752 it had increased to
36,241, and in 1786 to 40,051. In 1801 it had decreased to 36,832.
In 1811 the number was 37,256, and during the next ten years so
large was the increase that in 1821 the number was 50,288. In
1831, when the census was taken, Norwich contained 61,116; in
1841, 61,796; in 1851, 68,713; in 1861, 74,414.
Notwithstanding the continued succession of wars from the
revolution in 1688 to the conclusion of the peace in 1763, the city
continued to prosper, and its trade had become very great,
extending all over Europe, and Norwich manufactures were in
demand in every town on the continent. Indeed, the period of war,
from 1743 to 1763, was the most prosperous era in Norwich history.
The prosperity continued till the disputes arose between the
government and the North American colonies, which commenced in
1765 and became serious in 1774, and were not terminated till
1783, when the independence of the United States was
acknowledged. During this period, in fact, the trade of the place
was so good, that great numbers of people came from the
surrounding villages and obtained employment in the factories.
After the passing of the paving act in 1806, the new paving of the
city commenced, and proceeded very slowly. This necessary work

was interrupted at intervals from the want of money, and the
Commissioners got deep in debt. In forty years they spent
£300,000, and left Norwich the worst paved town in England. The
drainage was very defective, and the hamlets were not drained at
all. The supply of water was altogether insufficient, and in the
hamlets was obtained from wells. The Board of Health was
established in 1851, under the powers of the Public Health Acts, and
since then its provisions have been carried out. The sanitary
condition of Norwich has subsequently greatly improved and the rate
of mortality decreased, owing to the wise and judicious measures
which have been adopted of late years. A fuller description of “the
Ancient City” will be found under the head of “Norwich Antiquities.”
The Modern City.
The modern city, with all its improvements and extensions, presents
a very different aspect to what it did in former times, when it was
enclosed by high walls and gates. It stands for the most part on the
summit and sloping sides of a rising ground, running parallel with
the river Wensum on the southern side, above its confluence with
the Yare. Its greatest extent from St. Clement’s Hill (north) to
Hartford Bridges (south) is four and a quarter miles; and following
the zigzag line of boundary it is about seventeen miles in
circumference, comprising 6630 acres of land. Within its jurisdiction,
as a city and a county of itself, it includes the picturesque hamlets of
Lakenham and Bracondale on the south, of Catton on the north, of
Thorpe on the east, and of Heigham on the west, in which direction
Norwich is rapidly extending.
The city is situated in the eastern division of Norfolk, of which
county it is the capital. It is 20 miles distant from the sea at
Yarmouth, 108 miles distant from London, 42 from Lynn, 22 from
Cromer, 43 from Ipswich, 72 from Cambridge, and 99 from Lincoln;
being in latitude 52° 42′ N., and in longitude 1° 20′ E of Greenwich.
The Great Eastern Railway system places it in communication with

all the towns before named, and all the large towns of England.
There is a railway station at Thorpe for the Norfolk line from
Yarmouth to Ely, and another station at St. Stephen’s Gates for the
Suffolk line from Norwich to Ipswich. Telegraphic lines are
established along both railways, and there is also another line from
London, viâ Norwich, to Cromer, on the northern coast of the
county. Navigation is carried on by river from Norwich to Yarmouth.
The Wensum, which rises at Rudham, enters the city on the N.W.,
and leaves it on the S.E. It pursues a boldly serpentine course
through the town, first traces for a short space the western limits,
then describes a semi-circle round the left bank, then winds through
a thinly-built part of the city, and next traverses a compact eastern
side. An eminence, that may be called a hill, compared with the
flatness of the surrounding country, extends along the right bank of
the river and terminates near its last bend; and this eminence bears
on its summit and its slopes all the more ancient parts of the city,
with a large portion of its present streets and buildings. The outline
of the area within the old walls somewhat resembles the form of a
cornucopia, with the narrow end twisted round from the S. to the
S.E., and has been aptly compared to the figure of a haunch of
venison. A strong flint embattled wall, flanked with forty towers,
pierced by twelve beautiful gates, and fortified by a broad ditch,
formerly surrounded the city, except at two places, where the
Wensum formed a natural defence; but having fallen into decay, and
being considered a hindrance to the growth and improvement of the
town, it was stripped of all its gates, its ditch was filled in, and the
only portions of walls which were permitted to remain are a few
strips, here and there, of crazy ruin. The city inside the walls is
divided into thirty-five parishes, and has five more and parts of two
others within the county of the city. Altogether it contains forty
parish churches, exclusive of the Cathedral, the French and Dutch
Churches, and Christ’s Church, New Catton; and upwards of twenty
Nonconformist chapels. It formerly included about twenty other
parishes, but they have been consolidated with some of the present
parishes, and the churches either desecrated or taken down. Among
the chapels which have altogether disappeared may be mentioned

the Chapel of St. Mary in the Field, St. Catherine’s Chapel,
Hildebrand’s Chapel, Magdalen Chapel, St. Michael’s Chapel,
(Tombland), St. Nicholas’s Chapel, St. Olave’s Chapel, (near King
Street gates), and others.
The older portion of the city in most of its street arrangements is
very irregular; and its thoroughfares are narrow and winding,
following in some instances the line of the ancient walls. Some of its
houses, however, are handsome structures, and are often admired
by strangers as beautiful specimens of squared flint facings. The old
street architecture, however, is rapidly vanishing before the hand of
improvement. Many of the half-timber, lath and plaster houses,
remarkable for their grotesque gables and picturesque appearance,
have given place to plainer, but more comfortable and convenient
dwellings; some of which have handsome fronts, more especially
round the Market Place, and in the principal streets. We may,
especially, notice the warehouses and shops of Messrs. Chamberlin,
Mr. G. L. Coleman, and others in the Market Place; of Mr. Caley, Mr.
Fiske, Mr. Livock, Mr. Dixon, Mr. Sawyer, and Mr. Allen in London
Street; the offices of the National Provincial Bank in London Street;
and of the Crown Bank on the Castle Meadow.
The Market Place.
The Market Place, which occupies the centre of the city, is one of the
most spacious in England; and being overhung by the singularly
massive square tower of St. Peter’s, and presenting several
specimens of antique houses of the gable-front construction, is very
picturesque in its appearance. It was formerly the great Croft,
belonging to the Castle, on the outer ditch of which it is supposed to
have abutted. The first parts built upon were the east and west
sides and the north end. The other portions were built by virtue of
royal licenses. As already indicated, it has been within the last few
years greatly improved, by the erection of new houses and fronts;
and upon the whole it may be said to be well paved—though as

regards the paving of the city generally, there is still room for
improvement. The approaches to the Market Place, it should here
be mentioned, were formerly very narrow and difficult, and they are
not even now all that could be wished; but many improvements
have nevertheless been made at very great expense. Thus, London
Street has within the last few years been widened, at a cost of
£20,000; and Opie Street has been opened from London Street to
the Castle Hill. Of course, the principal places of business are mostly
clustered together, either in the Market Place or in the nearest
streets; but in former times, every business in Norwich had its
particular row or station. Thus, in ancient deeds, we read of the
Glover’s Row, Mercers Row, Spicer’s Row, Needler’s Row, Tawer’s
Row, Ironmonger’s Row; also of the Apothecary’s Market, the Herb
Market, the Poultry Market, the Bread Market, the Flesh Market, the
Wool and Sheep Market, the Fish Market, the Hay Market, the Wood
Market, the Cheese Market, the Leather Market, the Cloth-cutter’s
Market, the White-ware Market; all of which we find mentioned
before the reign of Richard II.; for about the latter end of the reign
of Edward III., trades began to be mingled in such a manner, that
many of these names were lost.
Norwich Castle.

High over the centre of the old city, over all its churches, and towers,
and streets, rises the Norman Castle, frowning in feudal grandeur
over the whole district. It stands on the summit of a mound or hill,
steep on all sides, which appears to be chiefly the work of nature,
with additions by human labour. The embattled quadrangular keep,
in its restored state, retaining all the details of architectural
decoration peculiar to the Norman style, presents a faithful image,
though without the grey antiquity, of its original exterior, and is a
noble striking object from whatsoever point it is seen. The common
history is, that a fortress existed here during the Saxon period, and
that Uffa, the first King of the East Angles, formed one of earth,
according to the rude method of the times. In 642, Anna, another
of the East Anglian kings, is said to have resided here; and during
the Danish wars, this fortress was often taken and retaken. Alfred is
believed to have repaired it, and to have erected the first stone
structure, which was destroyed by the Danes in 1004. Canute
probably erected another castle here about 1018, and after the
conquest it was much injured during a siege, and was rebuilt by
Roger Bigod. The plan of the fortifications has been a subject of
some controversy. According to the account commonly given of the
fortress, it consisted of a barbican or outwork to defend the

entrance; three nearly concentric lines of defence, each consisting of
a wall and ditch, and enclosing a ballium or court; and a great
central keep, as the last resort in the event of a siege. The area
comprised a space of twenty-three acres, and each ditch had a
bridge over it similar to the one now remaining. The barbican, or
outwork of the fortification, was situated beyond the outer ditch, if it
ever existed. The wall commenced at the opening called Orford
Street, and gradually extended to the end of Golden Ball Lane, the
other extremity terminating in Buff Coat Lane. The widest part is
stated to have been forty yards broad, and gradually decreasing at
the extremities, the length being about 220 yards. Part of the
original form of the wall was supposed to be traceable from the
position of the buildings erected on its site in Buff Coat Lane. The
road to the castle from Ber Street was supposed to pass through the
barbican, exactly where Golden Ball Lane recently stood. The
circuits of the outer vallum and the middle vallum are minutely
described by most of the local historians; but unfortunately there is
no sufficient evidence in support of this old theory of three ditches
round the castle—nothing but a vague traditional story, filled up by
imagination. The editors of the history published by Crouse in 1768,
say:
“This castle was defended by a wall surrounding it, built on the
brow of the hill on which it stands, and by three ditches; the
outermost of which reached on the west to the edge of the
present Market Place, on the north to London Lane, which it
took in; on the east nearly to Conisford Street, and on the south
to the Golden Ball Lane. The postern or back entrance into the
works was on the north-east, by which a communication was
had with the earl’s palace, then occupying the whole space
between the outer ditch and Tombland. The grand entrance is
on the south, from which you passed three bridges in going to
the Castle. The first hath been immemorially destroyed; the
ruins of the second remained till the ditches were filled up and
levelled thirty years since; and the third still continues and
consists of one whole arch, exceeded by very few in England.”

Mr. John Kirkpatrick, who wrote an account of the Castle in the last
century, gives quite a different description of the earth works. He
notices the present ditch, and a second entrenchment lying between
the present ditch and the Shire house, which then stood near the old
weighing house on the hill. He also refers to the Shire house ditch
as a distinct entrenchment. He describes a bridge house on the
inner side of the great southern ditch in the middle of the present
Cattle Market, and the line of the houses forming the southern limit
of the Cattle Market seems to show the limit of the outwork.
Mr. B. B. Woodward, F.S.A., in his lectures delivered here on
“Norwich in the Olden Time,” adopted this view of the earth works,
which he believed did not consist of three concentric lines of
defence. He described the Saxon fortress as probably no more than
a strong palisade carried along the inner edge of two great trenches
and the top of the steep bank of the small stream called the
“Cockey;” the buildings consisting of a great timber hall with offices
and stabling. He believed that the Normans strengthened the
outworks, cast up the great mound, dug the vast inner ditch, and
reared the noble donjon, which, before the “restoration” of its
exterior, was a fine feudal monument. After the Norman period the
earth works, Mr. Woodward thought, underwent great changes. The
horse-shoe trench on the east side disappeared and was built upon.
This horse-shoe trench enclosed the Castle Meadow. Another
smaller outwork was formed on the south side of the original great
southern trench, both of the last named being crossed by bridges.
In support of this view, Mr. Woodward referred to the account given
by Kirkpatrick, who, as we have said, described the second ditch as
lying between the great circular ditch and the Shire house, which
then stood near the old weighing house. The old way from King
Street had been disused because the growth of the city had so
greatly altered the defensive character of the fortress. In addition to
this, there were the names of two churches, one of which was St.
Martin’s, (originally called “on the Hill,”) but afterwards “at Bailey” or
“at the Castle gate;” and the other, St. John, now Timberhill, but
then “at the Castle gate.” Unless a way existed through the

outworks to the castle hill, these churches could not have been
properly called “at the Castle gate;” and as the “Bailey,” was the
space enclosed within the intrenchments of the Castle, the other
name of St. Martin would be quite inappropriate. The Buckes, in
their view of the Castle, represented a ruined building, like a bridge
house, on the inner side of the great southern ditch. Before the end
of the last century, the level of the south side of the hill was raised
to form a Cattle Market.
Mr. Harrod, some years since, at a meeting of the Archæological
Society held in the Museum, exploded the theory of three circular
ditches by showing from the city records that houses had always
stood on the sites of the supposed outer and middle ditches; the
inner vallum was the only one, and extended round the base of the
hill on which the keep is erected, and is plainly traceable at the
present time. It is planted with trees and shrubs, having a gravelled
walk in the centre, and is enclosed with an iron palisade. The area
of the upper ballium is level and comparatively high, and forms an
irregular circle on the summit of the hill, surrounded by an iron
railing. The great Keep situated within this area is a massive
quadrangular pile, 110 feet in length from east to west, 92 feet 10
inches in breadth from north to south, and 69½ feet high to the top
of the merlons of the battlements, and the walls are from 10 to 13
feet in thickness. From the basement to the top are three stories,
each strengthened by small projecting buttresses, between which
the walls are ornamented with semi-circular arches resting on small
three-quarter columns. In the upper story the backs of some of
these arcades are decorated with a kind of reticulated work, formed
by the stones being laid diagonally, so that the joints resemble the
meshes of a net. To give it greater richness of effect, each stone
had two deeply chased lines, crossing each other parallel with the
joints, so as to present the appearance of Mosaic. On the exterior of
the west side are two arches which appear to have been originally
intended as a deception to the enemy, giving an idea of weakness
externally, where in fact was the greatest strength; for the wall is
not only 13 feet in thickness in this place, but, within, it was

additionally barricaded by two oblique walls which were, long ago,
taken down. On the east side of the keep there is a projecting
tower called Bigod’s tower, which was most probably built by Hugh
Bigod, third Earl of Norfolk, who succeeded his brother as High
Constable of the Castle, early in the 12th century. This tower, which
was an open portal to the grand entrance of the Castle, is of a richer
kind of architecture, and in the genuine Norman style, and since
1824, has been entirely restored, so as now to exhibit its pristine
aspect, which is certainly different from the rest of the keep. The
interior of the keep has been so greatly altered in order to adapt it
to prison purposes, that the original arrangement of apartments
cannot be traced.
The style of architecture has been a matter of dispute, as to whether
it is Saxon, Danish, or Norman. Mr. Boid, in his history and analysis
of the principal styles of architecture, ventures to challenge any one
to prove the existence of any monument in this country of real
Saxon skill; nor has any specimen been discovered. Mr. Wilkins, of
Norwich, who has described both the ancient and modern states of
the fortress in Vol. xii. of the Archæologia, believed, however, that
the part which yet remains might have been constructed chiefly in
the reign of Canute, but that it is notwithstanding in the style of
architecture practised by the Saxons, long before England became
subject to the Danes, and is the best exterior specimen of the kind.
Other and later writers, with much better evidence, believe the
whole keep to be Norman, of the time of William Rufus; for it is
similar in style to Castle Rising, built in the reign of that king, by
Albini. The earth works and stone works are very similar. The whole
of the exterior of the keep has been refaced, the original style being
preserved. It is to be regretted that the work was not wholly
refaced with small square stones, in the Norman manner, instead of
commencing with the large massive freestone, which is coloured to
represent smaller stones. This defect, however, on being discovered
was remedied, for a great part of the exterior was finished after the
Norman fashion. The county jail stands on the east side of the keep,
and was built on the site of a previous prison in 1824–28 at a cost of

£15,000. It comprises a governor’s house and three radiating wings,
and has room for 224 male prisoners. Three bridges are, as we
have said, thought by some authorities to have crossed three
ditches, but for more than a century the present bridge has been the
only one. This bridge consists of one large semicircular arch. Mr.
Wilkins supposed that it was the original bridge built by the Saxons,
but this is only conjectural like the rest of his theory about the earth
works. At the termination of this bridge, upon the upper ballium,
are the remains of two circular towers, 14 feet in diameter, which
are supposed to have flanked the portal of the ballium wall. The
history of the castle will be given at some length in subsequent
pages. We shall now proceed to
The Cathedral.
This grand Norman pile is the great ornament to the city, but its
situation is so low that its goodly proportions can be seen only from
one point of view, namely from Mousehold Heath. From that
elevation it presents the dignity of a great work of architecture, and
the spire may be seen on a clear day, on the north, at a distance of
twenty miles. The noble tower, with its gracefully tapering spire,
second in height only to that of Salisbury, the flying buttresses, and
the circular chapels at the east end, are objects of interest to the
attentive antiquarian observer.
The cloisters on the south side, and the bishop’s palace and grounds
on the north, and other premises, shut out from public view most of
the exterior, except the west front. A fine view of the splendid
effect, produced by a series of unbroken lines, may be obtained
opposite the south transept, where the whole pile, comprising the
transept, tower, and spire, blend themselves into one harmonious
whole. The interior from the west front entrance presents a most
imposing appearance, and when surveying the vast length of the
nave, we feel that our forefathers

“Builded better than they knew,
Unconscious stones to beauty grew.”
We shall first give, in as complete a manner as our limited space will
permit, a sketch of the foundation and progress of the edifice, the
erection of which occupied a century, and then we shall describe its
different parts, exterior and interior, including the nave, the screen,
the choir, the transepts, and the cloisters.
The original structure was begun in 1096 by Herbert de Losinga, the
first bishop of the diocese. The portions he built comprise the choir,
with the aisles surrounding it, the chapels of Jesus and St. Luke, and
the central tower with the episcopal palace on the north side of the
church, and a monastery on the south. Bishop Eborard, the
successor of Herbert, added the nave and its two aisles, from the
ante-choir or rood loft, to the west end. The building, as left by
Eborard, remained till 1171, when it sustained some damage by fire,
but was repaired by Bishop John de Oxford, about 1197, who also
added some alms houses to the monastery. The Lady chapel at the
east end, which has long since been destroyed, was the next
addition to the building, and was erected by Walter de Suffield, the
tenth bishop, who filled the See from 1244 to 1257.
In the year 1271, the tower was greatly injured by lightning during
divine service, and in 1272 the whole church was damaged
considerably, in the violent warfare which was at that time carried on
between the monks and the citizens; but in 1278, having been
repaired, the church was again consecrated by William de Middleton
on the day he was enthroned Bishop of Norwich, in the presence of
King Edward I. and Eleanor his queen, the Bishops of London,
Hereford, and Waterford, and many lords and knights. We can now
form no idea of the grandeur of such a ceremony in that age.
The tower having been much injured and weakened by fire, a new
one, according to Blomefield, was begun and finished by Bishop
Ralph de Walpole; but this, says Britton, more properly applies to the
spire, the style of which, rather than of the tower, corresponds with

that period. Bishop Walpole ruled the diocese from 1289 to 1299.
Before his translation to Ely, which took place in the latter year, he
commenced the cloister at the north-east angle, and built the
chapter house. He only completed a small portion of the east
aisles. The chapter house has since been destroyed. The rest of the
cloister was built by Richarde de Uppenhall, Bishop Salmon, Henry
de Will, John de Hancock, Bishop Wakering, Jeffery, Symonds, and
others, and was completed A.D. 1430, in the 133rd year from the first
commencement of the work.
In January, 1362, the spire was blown down, and the choir thereby
much injured; but under the auspices of Bishop Percy, the present
spire was erected and the choir repaired. In 1629, the upper part of
the spire was again blown down, and in 1633, at a general chapter,
it was ordered to be repaired. In 1843, seven feet were added to its
elevation, with the present finial which formed a consistent
termination to the crockets.
In 1463, the church was much injured by fire, the wood work in the
interior of the tower having been ignited by lightning. Under Bishop
Lyhart, however, it was again repaired and ornamented. The
splendid stone roof of the nave was added, the cathedral was paved,
and a tomb was erected over the founder, which was afterwards
demolished during the great rebellion. About the year 1488, Bishop
Goldwell built the roof of the choir of similar but inferior work to that
of the nave, adding the upper windows and flying buttresses. He
also fitted up the choir and the chapels around it, and covered the
arched stone work with lead. In 1509 the transepts having been
much injured by fire, Bishop Nykke repaired them, adding stone
roofs to them in the same manner as the rest of the church.
At the dissolution of the monasteries, the cathedral suffered greatly
from the zeal of the Reformers, much curious work being destroyed;
and several obnoxious crucifixes, images, niches, tabernacles, and
paintings, were removed. In 1643, the fanatics took possession of
the church and the adjoining palace, and plundered them of all that
was valuable. The Yarmouth people being in want of a workhouse,

sent a petition to the Lord Protector, praying that “that great useless
pile, the cathedral, might be pulled down, and the stones given them
to build a workhouse.” Of course the petition was not granted.
Soon after the restoration, the church was fitted up again. In 1740,
the nave and aisles were newly paved, the tower was repaired, and
the church cleaned. In 1763, the floor of the choir was again
repaved, the stalls repaired and painted, and other improvements
made, not always in harmony with the original structure.
The edifice was extended, embellished, altered, and repaired by
many bishops and by wealthy families till it was completed about
1500. Alternate dilapidations and restorations followed. The
dilapidations were sometimes sudden, sometimes gradual, and the
restorations have continued at frequent intervals almost to the
present day. The entire pile was repaired and beautified on an
extensive scale in 1806–7. The decayed ornaments of the west front
were restored, and many improvements in other parts were effected
in 1818 and following years. The south front was renovated, and
several houses which had stood against the walls were removed in
1831. The entire fabric was again restored, on the plan of Edward
Blore, about 1840–3; and some portions were repaired, some
embellishments were added, and some interesting ancient features
were brought into view between the years 1843 and 1868.
The pile as it now stands, comprises a nave of fourteen bays with
aisles, a transept of three bays in each wing, a central tower, a
steeple, an apsidal sacristy on the north-east side, a choir of four
bays with aisles, an apsidal end, and a procession path; also three
chapels, in the south side, the north-east side, and south-east side;
and a cloister with each alley of eleven panes to the south of the
nave. The dimensions of the Cathedral as taken from actual
measurement are as follows:—
Feet. Inches.
Length of church 407 0

,, nave to choir screen 204 0
,, choir from screen 183 0
,, roof of nave 251 0
,, transept 178 0
Breadth of nave and aisles 72 0
,, choir from back of stalls 27 1
,, aisles of choir 15 0
Height of spire from ground 315 0
,, tower 140 5
,, spire from tower 174 7
,, roof of nave from pavement 69 6
,, roof of choir from pavement 83 6
The Interior.
We shall now proceed with our description of the interior, which
contains the finest specimens of Norman architecture in existence,
and admired by all men of taste. Nothing can exceed the grandeur
of the lofty nave, massive columns, and wide circular arches. The
whole pile is chiefly of the early Norman style, wherein the semi-
circular arches and massive short columns are the leading features.
These are considerably varied in size, moulding, and ornament, in
different parts of the edifice.
The Nave comprises fourteen semicircular arches, ornamented with
billet and zigzag mouldings, and supported by massive piers. The
arches of the triforium are of similar style to those below. The
magnificent roof, the work of Bishop Lyhart, the rebus of whose
name is of frequent occurrence upon the vault and corbels, is
ornamented with 328 historical figures, curiously carved, in a kind of
relievo peculiar to itself, being chiefly composed of little figures,

most exactly put together, said to be the only work of the kind in
existence, being a complete chain of sacred history, beginning at the
tower with the Creation of the World; the different days of the
creation being disposed of in the several figures in the intersections
of the arched work of the roof. The Fall of Man, Noah’s Ark, and
incidents in the lives of the patriarchs, are represented in the first
seven arches; the rest to the west end represent events narrated in
the New Testament. The interior of the nave looks much too long in
proportion to the rest of the pile, and the triforium is out of keeping
in consequence of its heavy circular arches being too high as
compared with those of the tier below, but the piers of the nave,
with the grand arches which they support, are splendid specimens of
Norman work and decoration.
The south transept is Norman work modified by a few innovations,
and is flanked by square turrets, arcaded at the top and terminating
in pinnacles. The north transept is of similar character. The side
aisles are low, and the roof of plain vaulting. The west window is of
unusually large size, and is of the same design, as regards the
tracery, with that in Westminster Hall. This window has been filled
in with gorgeously coloured glass, being designed as a memorial of
Bishop Stanley, who was buried in the middle of the nave.
In the seventh arch of the north side are the remains of a doorway,
with a stone bench, formerly leading into the monks’ preaching yard,
now part of the bishop’s garden. Even after the Reformation, and
up to the time of the great rebellion, sermons were preached here
before the Civic Authorities and the Members of the Cathedral.
Between the sixth and seventh pillars is an unpretending inscription
to the memory of the learned Dr. Prideaux, formerly Dean of
Norwich, author of the “Connection of the Old and New Testaments,”
who died November 1st, 1724. The tomb between the
corresponding pillars on the opposite side is that of Miles Spencer,
Chancellor of the Diocese in 1537. Between the seventh and eighth
pillars is the low tomb of Bishop Nykke, who died in 1535. At the

eighth pillar a pulpit formerly stood. Bishop Parkhurst’s tomb stands
in the next space, between the eighth and ninth pillars.
The Screen was originally the division between the rood-loft and the
chapel of our Lady of Pity. Bishop Lyhart erected the rood-loft, and
upon it the principal rood or cross was placed with the
representation of the Holy Trinity, to whom this church was
dedicated; together with the images of the Blessed Virgin and St.
John, and such other saints as were esteemed here. The rood or
crucifix, of full proportions, was made of wood, and in most
churches was placed in a loft constructed for the purpose over the
entrance from the church into the chancel. The nave represented
the Church Militant, and the chancel the Church Triumphant. Those,
therefore, who would pass out of the former into the latter, must go
under the loft; that is, must go under the cross and suffer affliction.
But no rood was complete without the images of the Virgin and St.
John on either side of the cross, in allusion to St. John xix. 26,
—“Jesus saw His mother and the disciple standing by, whom He
loved.”
The Choir contains sixty-two stalls according to the number of the
old foundations, namely, a prior, sub-prior, and sixty monks. They
are adorned with rich and quaint carvings and canopies, as far as
the west pillars of the tower. The “misereres” (projecting brackets
on the under side of the seats of stalls in churches), are richly
carved and present a great variety of design. Among the stalls the
Rev. R. Hart discovered upwards of sixty misereres, and he described
them very minutely. In every example that he had seen the space
under the ledge is carved in a bold relief, with an ornamented boss
on each side to balance, as it were, the centre, whatever it might
have been. As may be supposed scriptural or legendary designs are
not often found in such a position. There are, however, a few
examples.
The interior of the tower, which is raised on four massive arches,
presents three arcades, the upper and lower forming galleries, and
the former containing the lower windows of the lantern, which are

filled with painted glass. The clerestory and roof of the chancel are
the work of Bishop Goldwell. Here is an admirable specimen of
engrafting a later style upon the Norman architecture, with as little
violence to the eye as possible.
The tomb of Bishop Goldwell stands within the chapel, formerly
dedicated to St. James, and with its canopy forms a rich specimen of
ornamental sculpture and architecture. On the east side of the
fifteenth north pillar is the monument to the memory of the learned
Bishop Home, author of an excellent “Introduction to the Study of
the Bible.” In the space between the seventeenth and eighteenth
pillars was the chapel dedicated to St. Anne, and in the next space
was the seat occupied by Queen Elizabeth, when she attended
divine service during her visit to this city. The monument to the late
Bishop Bathurst now occupies the spot, a sitting statue sculptured in
white marble. Not only for its intrinsic merits is this statue of great
value, but also because it is the last finished work of Sir Francis
Chantrey, who visited Norwich for the purpose of fixing it only a few
days before his death. Opposite to this monument is the altar tomb
of Sir William Boleyn, now despoiled of its brasses. Sir Thomas
Browne tells us in his “Repertorium,” that, during the
Commonwealth, “more that a hundred” brasses were reeved in the
Cathedral alone,—a greater number than the whole county of
Norfolk could now supply. Hence our readers may easily understand
what an immense number of these interesting memorials must have
been lost, independently of the number that have been partially
despoiled by the removal of their canopies.
At the foot of the altar steps, in the middle of the chancel, is the
tomb of Bishop Herbert de Losinga, erected by the Dean and
Chapter, in 1682, in the place of one destroyed during the civil wars.
It has been levelled with the pavement and presents a long Latin
inscription from the pen of Dean Prideaux. The east windows of the
clerestory were the gift of the Bishop, the Misses Morse, and the
Dean and Chapter of the Cathedral, and were erected between 1840
and 1847. The lower one in the triforium is an obituary window to

the memory of the late Canon Thurlow, placed there by his friends.
This space had before been occupied by a window with a pointed
arch, representing the Transfiguration. The window was removed to
the south transept, and the arches of both windows have been
restored.
The bishop’s throne, ascended by three steps, was originally placed
at the east end of the church, behind the altar, and raised so high
that before the partition was made between the altar and the
entrance to Our Lady’s chapel, the bishop had an uninterrupted view
from his throne directly in a line through the whole church. The
custos, or master of the high altar, annually accounted for the
offerings made there, which produced a large sum; and at the
annual processions of the city and country clergy, on the feasts of
the Holy Trinity and St. Paul, something considerable was realized.
The stone roof of the south transept, as well as that of the north,
was raised by Bishop Nykke, about 1501. At the same time,
probably, the old Norman arch leading into the chancel aisle was
filled with the rich and numerous mullions and tracery, which
characterise the last period of pointed architecture. The adjoining
aisle leads to the chapel of our Lady the Less, otherwise called
Bawchyn’s Chapel, having been dedicated to the Virgin and all the
Saints, by William de Bawchyn, about the middle of the fourteenth
century. The founder is buried in an arched vault under the chapel.
This chapel is now used as the Consistory Court. Adjoining is St.
Luke’s Chapel, sometimes used as the parish church of St. Mary in
the Marsh, that church having been demolished. Strictly speaking,
the circular part only is the chapel dedicated to St. Luke, but the
adjoining aisle, as far as the most eastward point, is now enclosed
and fitted up for the use of the parish. It is part of Bishop Herbert’s
original foundation. The font was brought from the parish church; it
is richly carved with designs of the seven sacraments, &c. Passing
round at the back of the altar we come to the Jesus Chapel.
The north transept is similar to the south. From the east wall of it
there was a doorway leading to a chapel, said to be the ancient

Vestiary. The arch has been filled up, and the entrance is from a
small door on the outside. Over the exterior of the door leading to
the Bishop’s palace is a niche, containing a figure, said to represent
Bishop Herbert, one of the few specimens extant of a Norman
statue.
The Exterior.
The exterior of the Cathedral is not very imposing. The west front
was the work of Bishop Alnwick, in the reign of Henry VI. It is
divided into three compartments, forming the termination of the
nave and the aisles. The central division presents the grand
entrance doorway, and a large central window filled with coloured
glass, which we have already described. It rises into a gable,
formerly pierced with a small light, now a niche, flanked by two
turrets with spirelets and round-headed single panels, and
surmounted by a cross. The doorway is formed by a bold deep-
pointed arch, and is much enriched in the spandrels and side fasciæ
with mouldings, niches, pedestals, statues, and other decorations.
The central window is divided, both horizontally and vertically, into
three leading compartments, and subdivided by small mullions; and
has good decorations of perpendicular character. Each of the two
lateral divisions of the west front exhibits pure Norman work, and is
of three stories; the first pierced with the doorway; the second
pierced with four windows separated only by small columns; the
third displaying three blank arches, and flanked with a small
staircase turret. At each side of the great window, and at the
extremities of the side divisions, are Norman turrets, lately restored
and substituted for very debased cupolas. Engravings are extant
representing this front with high and slender pinnacles where the
Norman turrets now stand.
The north and south elevations of the nave show a three-storied
aisle; and a clerestory and triforium, with an embattled parapet in
each, exhibit a great height, and tiers of blank arches or arcades
with some later perpendicular windows. On the exterior of the nave

will be observed many traces of alterations in times long subsequent
to the original building. The lowest tiers of windows are of
comparatively modern insertion, and intersect the string course of a
billet moulding, all round the exterior of the edifice. Next above is
the arcade of blank arches, with semicircular mouldings, having
regular bases and capitals, and continuing round the whole
structure. Above these was the tier of original windows now closed
up, but surmounted by windows of the sixteenth century. The
exterior of the side aisles is here terminated by a plain embattled
parapet of the same date as the windows before mentioned. The
windows of the clerestory are, however, Norman, and have blank
arches on each side, and continue the same all round the upper part
of the nave and transept. They are surmounted by a parapet similar
to that of the side aisles. The exterior of the south transept has
been lately restored, and various old houses that blocked up the
entrance have been cleared away.
The tower is grandly Norman in four stages, each adorned with
arcades, columns, and tracery mouldings. It has, at the corners,
square turrets with their angles cut off, and is surmounted by
decorated battlements and crocketted pinnacles. The spire is
decorated English octangular, elegantly proportioned, enriched with
bands, and boldly crocketted in ribs running up its angles. It
terminates in a handsome finial, and is the loftiest in England except
that of Salisbury. The base of the spire is supported by projecting
buttresses at each angle, terminating in a small pinnacle.
The Cloisters.
The Cloisters, which are entered by a tasteful modern door on the
south side of the nave, form one of the most beautiful quadrangles
in England. They comprise a square of about 174 feet, and are 12
feet wide. They were commenced by Bishop Walpole about 1297,
but were not completed by succeeding prelates till 1430. The style
of architecture is the decorated, with traces of the perpendicular.
The eastern part is the most ancient, and a progressive change may

be observed in the tracery of the windows, commencing at the
north-east corner, continuing through the south and the west, and
terminating with the north sides. The roof is much admired for its
exquisitely beautiful groining, and its bold yet elegant bosses, with
their sculptured subjects and tasteful foliage. The doorway leading
from the eastern aisle of the cloisters to the nave is deserving
especial notice, being a pointed arch with four columns on each side,
having archwolt mouldings, in front of which are seven canopied
niches, with richly-sculptured crockets containing figures. Above the
door, at the south-west corner, are carved figures of “The
Temptation of our First Parents.” In the first two arches on the west
side of the door are two lavatories, where the monks used to wash
their hands before going into the refectory or common eating hall.
Over each of these are three niches, where images formerly stood.
The cloisters are surpassed by none in beauty of architecture and
solemnity of effect. They branch off from the south transept, and
enclose a square court or area. There are eleven noble windows or
arched openings on the western side, twelve on the east, eleven on
the north, and eleven on the south. All these windows are divided
into three lights by two columns, and are decorated with a variety of
beautiful tracery. They are of decorated architecture, except eight
on the north side, which have perpendicular tracery in decorated
arches. The upper portion of the tracery of all the windows appears
to have been once filled with stained glass.
The pavement of the north side of the cloisters was torn up in the
great rebellion, and relaid by William Burleigh, Esq. In this alley
Queen Elizabeth dined in public when she visited Norwich in 1578.
In memory thereof, her Majesty’s arms and those of the nobility who
attended her were painted on the wall of the church, and properly
blazoned with supporters, etc., but they were entirely effaced a
century ago.
The dormitory of the monks adjoined the cloisters on the south. At
a short distance from the cloisters are the only remains of the Priory

founded by Bishop Herbert, consisting of three massive clustered
columns, the capitals of which are curiously carved.
The Bishop’s Palace.
The Bishop’s Palace stands on the north side of the Cathedral
Church, to which there was in former times a passage from the door
of the north transept, arched over with stone similar to the cloisters.
The original palace was founded by Bishop Herbert, but has
undergone so many repairs and alterations, that but little of the first
building remains, and that part adjoins a new structure, in a similar
style of architecture. In the garden there is a fine ruin, said to be
remains of the grand entrance into the great hall, which reached to
the site of the present episcopal chapel, and was 110 feet long, and
60 broad. This chapel was restored in 1662, and in it are
monuments of Bishops Reynolds and Sparrow. The entrance to the
episcopal residence is from St. Martin’s Plain, by the palace gate,
built by Bishop Alnwyck about 1430. It has a large pointed arch of
several mouldings, and the spandrels are filled with tracery; but it
has suffered materially from injudicious repairs. Over the arch is a
series of pannelled compartments with the letter M crowned. On the
west side is a small door, on which, amongst other ornaments, are a
heart and mitre, the supposed rebus of Bishop Lyhart.
The Cathedral Precincts.
The Cathedral Precincts include the Upper and Lower Close, and a
large portion of garden ground, with good houses on the south
side. The Upper Close was formerly used as a play ground to the
Grammar School; it is now enclosed with palisades. At the south-
east corner is the Audit Room, which contains the library of the Dean
and Chapter. The Lower Close was enclosed by Dean Lloyd, in 1782,
and converted into a garden. At the extremity of the Lower Close,
near the edge of the river, still stands a double arch of black flint,
which is considered the roughest bit of picturesque in Norwich, and

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Cisco Ios Access Lists 1st Edition Jeff Sedayao

More Related Content

Similar to Cisco Ios Access Lists 1st Edition Jeff Sedayao (20)

Recently uploaded (20)

Cisco Ios Access Lists 1st Edition Jeff Sedayao