Страница:
that.
Lastly, if you're not sure what debugging criteria you need, you can
try ``debug all''. BE CAREFUL! It is way useful, but only in a very
controlled environment, where you can turn off absolutely everything
you're not interested in. Saves a lot of thinking. Turning it on on
a busy box can quickly cause meltdown.
------------------------------
From: Question 10
Date: 5 July 1994
>What level of software is required for NTP support in
>a cisco router?
9.21 or above.
>Which cisco routers support NTP?
It is a software feature exclusively. Anything that supports
9.21 or 10 will run NTP (when running that s/w).
>How do I set it up?
The basic hook is:
ntp server [version n]
or
ntp peer [version n]
depending on whether you want a client/server or peer relationship.
There's a bunch of other stuff available for MD5 authentication,
broadcast, access control, etc. You can also use the
context-sensitive help feature to puzzle it out; try ``ntp ?'' in
config mode.
You'll also want to play with the SHOW NTP * router commands. Here
are two examples.
EXAMPLE 1:
router# show ntp assoc
address ref clock st when poll reach delay offset disp
+~128.9.2.129 .WWVB. 1 109 512 377 97.8 -2.69 26.7
*~132.249.16.1 .GOES. 1 309 512 357 55.4 -1.34 27.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
EXAMPLE 2:
router#show ntp stat
Clock is synchronized, stratum 2, reference is 132.249.16.1
nominal freq is 250.0000 Hz, actual freq is 249.9981 Hz, precision is 2**19
reference time is B1A8852D.B69201EE (12:36:13.713 PDT Tue Jun 14 1994)
clock offset is -1.34 msec, root delay is 55.40 msec
root dispersion is 41.29 msec, peer dispersion is 28.96 msec
For particular cisco NTP questions, feel free to ask in comp.dcom.sys.cisco.
For broader NTP info, see ftp://louie.udel.edu:pub/ntp/doc. The file
clock.txt in that directory has info about various public NTP servers.
There is also information on radio time receivers that can be
connected to an NTP server (this is handy on private networks, if you
have an entire campus to get chiming, or if you become a hard core
chimer).
The ``ntp clock-period'' command is added automagically to jump-start
the NTP frequency compensation when the box is rebooted. This is
essentially a representation of the frequency of the crystal used as
the local timebase, and may take several days to calculate otherwise.
(Do a ``write mem'' after a week or so to save a good value.)
Caveat of obsolecence: Note that the CS-500 will not be able to
achieve quite the same level of accuracy as other platforms, since its
hardware clock resolution is roughly 242Hz instead of the 1MHz
available on other platforms. In practice this shouldn't matter for
anyone other than true time geeks.
----------------------------------------------------------------------
From: Question 11
Date: 5 July 1994
You will need to substitute your own NTP peers, timezones, and GMT
offsets into the examples below, of course. Example 1 is in US Central
Time Zone, while example 3 is in US Pacific Time Zone. Both account
for normal US Daylight Savings Time practices.
EXAMPLE 1 (Charley Kline):
...
clock timezone CST -6
clock summer-time CDT recurring
ntp source eth 0
ntp peer
ntp peer
ntp peer
...
EXAMPLE 2 (Tony Li):
...
ntp source Ethernet0/0
ntp update-calendar
ntp peer
ntp peer prefer
...
EXAMPLE 3 (Dave Katz):
...
service timestamps debug datetime localtime
service timestamps log datetime localtime
clock timezone PST -8
clock summer-time PDT recurring
interface Ethernet0
ip address
ntp broadcast
ntp clock-period 17180319
ntp source Ethernet0
ntp server
ntp server
ntp server
COMMENTS ON EXAMPLE 3:
The config file is commented with date and time (and user id,
if TACACS is enabled) when the system thinks the clock is accurate.
I've enabled timestamping of debug and syslog messages. I send NTP
broadcast packets out onto the local ethernet. I'm in Pacific
Standard Time, with U.S. standard daylight saving time rules. I use
the IP address of the ethernet as the source for all NTP packets.
------------------------------
From: Question 12
Date: 5 July 1994
By default, all lines are configured to automatically try a telnet
connection if the first word in a input line is not recognized as a
valid command. You can disable this by setting ``transport preferred
none'' on every line (con, aux and vty). For instance:
sl-panix-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
line vty 0 10
transport preferred none
You can see the number of vty's currently configuered with ``show lines''
Also, you can suspend connect attempts with ^^ followed by ``x'', ie
shift-cntrl-6 x.
[It has been suggested that ``no ip ipname-lookup'' to turn off IEN116
helps. I think this is the default -jhawk ]
------------------------------
From: Question 13
Date: 31 Oct 1994
or: How do I find out which non-cisco systems on my networks generate IP-RIP
information without letting them mess up my routing tables.
Here you could work with a default administrative distance.
Administrative distance is the basis upon which the cisco prefers
routing information of one protocol over another. In this example:
router rip
network 192.125.254.0
distance 255
distance 120 192.125.254.17 ! list all valid RIP suppliers
[...]
the value 255 has the implicit meaning of not putting this information
into the routing table. Therefore, setting an administrative distance
of 255 means that all RIP suppliers are by default accepted but their
information is not put into the routing table. The administrative
distance for the router 192.125.244.17 has been reset to the default
(for RIP) of 120, causing its routes to be accepted into the routing table.
Then you can look them up with ``show ip protocols'' and restore the
original administrative distance for the ones you want to fill in the
routing table.
The same results can be acheived with an ip access-list, but with
that, ``show ip protocols'' will only show the valid ones. But often
it is more useful to see which systems were generating routing
information at all.
This trick works for other routing protocols as well, but please select
the proper adminstrative distance (rather than 120) for the protocol
you're using.
------------------------------
From: Question 14
Date: 5 July 1994
[The following is wholesale included; at some point it'll
probably be editted a bit and reformatted... -jhawk ]
Frequently Asked Questions
contributed by Howard C. Berkowitz
PSC International
hcb@world.std.com
@clark.net [probably will be my permanent
personal account]
PSC's domain is in mid-setup
Where in the router are access lists applied?
In general, Basic access lists are executed as filters on
outgoing interfaces. Newer releases of the cisco code, such as
9.21 and 10, do have increased ability to filter on incoming ports.
Certain special cases, such as broadcasts and bridged traffic,
can be filtered on incoming interfaces in earlier releases.
There are also special cases involving console access.
Rules, written as ACCESS-LIST statements, are global for the entire
cisco box; they are activated on individual outgoing interfaces by
ACCESS-GROUP subcommands of the INTERFACE major command.
Filters are applied after traffic has entered on an incoming
interface and gone through a routing process; traffic that originates in
a router (e.g., telnets from the console port) is not subject to
filtering.
+-------------------+
| GLOBAL |
| |
| Routing |
| ^ v Access |
| ^ v Lists |
+-^--v--------^---v-+
| ^ v ^ v |
| ^ v ^ v |
A----------->|-| |>>>>Access >>----------->B
|1 Group 2 |
<------------| |<-----------
| |
| |
+-------------------+
Some types of ``filter,'' using ``filter'' as a broader class than
ACCESS-LIST, can operate on incoming traffic. For example, the INPUT-
SAP-FILTER used for Novell networks is applied to Service Advertisement
Packets (SAP) seen at incoming interfaces. In general, incoming
filtering can only be done for ``system'' rather than user traffic.
Rules of thumb in defining access lists.
First, define what you want to do and in which directions. An
informal drawing is a good first step. As opposed to the usual
connectivity drawings among routers, it's often convenient to draw
unidirectional links between routers.
Second, informally write out your filtering rules. In general, it
is best to go from most specific to least specific. Modify the order of
writing things to minimize the number of rules needed.
Third, determine which rules need to be on which routers.
Explicitly consider the direction of flow, and the possible existence of
additional paths that could inadvertently bypass a filter.
Can a cisco router be a ``true'' firewall?
This depends on the definition of firewall. Some writers (e.g.,
Gene Spafford in _Practical UNIX Security_) define a firewall as a
host on which an ``inside'' and/or an ``outside'' application process run,
with application-level code linking the two. For example, a firewall
might provide FTP access to the outside world, but it would not also
provide direct FTP service to the inside world. To place a file on
the FTP external server, a designated user would explicitly log onto
the FTP server, transfer a file to the server, and log off. The
firewall prevents direct FTP connectivity between the inside and
outside networks; only indirect, application-level connectivity is
allowed.
Firewalls of this sort are complemented by chokes, which filter on
network addresses and/or port numbers. Cisco routers cannot do
application-level control with access control lists.
Other authors do not distinguish between chokes and filters. Using
the loose definition that a firewall is anything that selectively blocks
access from the inside to the outside, routers can be firewalls.
IP Specific
-----------
Can the ``operand'' field be used with a protocol keyword of IP to filter
on protocol ID?
No. Operand filtering only works for TCP and UDP port numbers.
How can I prevent traffic for a certain Internet application to flow in
one direction but not the other?
Remember that Internet applications flow from client port to server
port. Denying traffic from port 23, for example, blocks flow from the
client to the server.
+-------------------+
| |
A----------->| |----------->B
|1 2|
<------------| |<-----------
| |
+-------------------+
If we deny traffic to Port 23 of address B by placing a filter at
interface 2, we have blocked A's ability to telnet to B, but not B's
ability to telnet to A. A second filter at interface A would be needed
to block telnet in both directions.
Assume that we only have the filter at interface 2. Telnets to A
from B will not be affected because the filter at 2 does not check
incoming traffic.
-------
With the arrival of in-bound access lists in 9.21, it should be noted
that both inbound and access lists are about equally efficient, in
case any of you were wondering.
It's worth remembering that there are some kinds of problems
that packet-filtering firewalls are not best suited for. There's
reasonably good information in:
"Network (in)security through packet filtering"
ftp://ftp.greatcircle.com/pub/firewalls/pkt_filtering.ps.Z
------------------------------
From: Question 15
Date: 26 July 1994
What really happens when a cisco router boots, from boot start to live
interfaces?
First it boots the ROM os version. It reads the config. Now, it
realizes that you want to netboot. It loads the netbooted copy in on
top of itself. It then re-initializes the box and re-reads the
config. Manly, yes, but we like it too....
[[ Ummm... in particular it loads the netbooted copy in as WELL as
itself, decompresses it, if necessary, and THEN loads on top of
itself. Note that this is important because it tells you what the
memory requirements are for netbooting: RAM for ROM image (if it's a
run from RAM image), plus dynamic data structures, plus RAM for
netbooted image. ]]
The four ways to boot and what happens (sort of):
I (from bootstrap mode)
The ROM monitor is running. The I command causes the ROM monitor to
walk all of the hardware in the bus and reset it with a brute force
hammer. If the bits in the config register say to auto-boot, then
goto B
B (from bootstrap mode)
Load the OS from ROM. If a name is given, tell that image to start
silently and then load a new image. If the boot system command is
given, then start silently and load a new image.
powercycle
Does some delay stuff to let the power settle. Goto I.
reload (from the EXEC)
Goto I.
------------------------------
From: Question 16
Date: 18 July 1994
Try calling 800-553-NETS and asking for your local sales office.
That's probably the best plan.
------------------------------
From: Question 17
Date: 18 April 1995
Where and how to get new RFCs
=============================
RFCs may be obtained via EMAIL or FTP from many RFC Repositories. The
Primary Repositories will have the RFC available when it is first
announced, as will many Secondary Repositories. Some Secondary
Repositories may take a few days to make available the most recent
RFCs.
Primary Repositories:
RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET,
NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or FTP.SESQUI.NET.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Secondary Repositories:
Sweden
------
Host: sunic.sunet.se
Directory: rfc
Host: chalmers.se
Directory: rfc
Germany
-------
Site: EUnet Germany
Host: ftp.Germany.EU.net
Directory: pub/documents/rfc
France
------
Site: Institut National de la Recherche en Informatique
et Automatique (INRIA)
Address: info-server@inria.fr
Notes: RFCs are available via email to the above
address. Info Server manager is Mireille
Yamajako (yamajako@inria.fr).
Netherlands
-----------
Site: EUnet
Host: mcsun.eu.net
Directory: rfc
Notes: RFCs in compressed format.
France
------
Site: Centre d'Informatique Scientifique et Medicale
(CISM)
Contact: ftpmaint@univ-lyon1.fr
Host: ftp.univ-lyon1.fr
Directories: pub/rfc/* Classified by hundreds
pub/mirrors/rfc Mirror of Internic
Notes: Files compressed with gzip. Online
decompression done by the FTP server.
Finland
-------
Site: FUNET
Host: funet.fi
Directory: rfc
Notes: RFCs in compressed format. Also provides
email access by sending mail to
archive-server@funet.fi.
Norway
------
Host: ugle.unit.no
Directory: pub/rfc
Denmark
-------
Site: University of Copenhagen
Host: ftp.denet.dk
Directory: rfc
Australia and Pacific Rim
-------------------------
Site: munnari
Contact: Robert Elz
Host: munnari.oz.au
Directory: rfc
rfc's in compressed format rfcNNNN.Z
postscript rfc's rfcNNNN.ps.Z
United States
-------------
Site: cerfnet
Contact: help@cerf.net
Host: nic.cerf.net
Directory: netinfo/rfc
Site: NASA NAIC
Contact: rfc-updates@naic.nasa.gov
Host: naic.nasa.gov
Directory: files/rfc
Site: NIC.DDN.MIL (DOD users only)
Contact: NIC@nic.ddn.mil
Host: NIC.DDN.MIL
Directory: rfc/rfcnnnn.txt
Note: DOD users only may obtain RFC's via FTP
from NIC.DDN.MIL. Internet users should NOT
use this source due to inadequate connectivity.
Site: uunet
Contact: James Revell
Host: ftp.uu.net
Directory: inet/rfc
UUNET Archive
-------------
UUNET archive, which includes the RFC's, various IETF documents,
and other information regarding the internet, is available to the
public via anonymous ftp (to ftp.uu.net) and anonymous uucp, and
will be available via an anonymous kermit server soon. Get the
file /archive/inet/ls-lR.Z for a listing of these documents.
Any site in the US running UUCP may call +1 900 GOT SRCS and use
the login "uucp". There is no password. The phone company will
bill you at $0.50 per minute for the call. The 900 number only
works from within the US.
------------------------------
From: Question 18
Date: 22 April 1996
[This could be more fleshed out (still!)]
Kerberos and RADIUS in 11.1
RIP version 2 in 11.1 (allows VSM, etc.)
Policy-based routing (routing based on source address or interface, or just
about anything else you want) in 11.0 *released*
PPP Multilink in 11.0(3) *released*
Frame Relay payload compression in 11.0(4) *released*
IPX Per-Host load balancing in 11.1
------------------------------
From: Question 19
Date: 27 July 1994
People often ask about performance of the cisco routers and are shyed
away from answering their questions because we don't know where to send
them.
Scott Bradner keeps the results of his performance tests on the
Internet. You can find them for ftp on the system hsdndev.harvard.edu
in the /pub/ndtl. There is a README file in that directory that
explains what is available. In addition, cisco has just started
publishing a piece of literature called ``The Harvard Benchmark Test
Results: Summary of cisco Systems Performance''. The only number I
can find on the doc is Lit. #700901. Don't know if you can order it
by this number, but at least there's a title to go on.
------------------------------
From: Question 20
Date: 22 April 1996
There are 3 basic types of switching (in order of increasing performance).
process switching
fast switching
autonomous switching
Process and fast switching support inbound and outbound, simple and
extended, access lists. Of course, for fast switching, such lists only
restrict traffic on the particular fast-switched interface.
Autonomous switching is done in the switch processor, a microcoded device that
is capable of switching IP, IPX, and bridging packets in the 100kpps range.
This is known as the "SP" card on the 7000 and the CBUS controller on the AGS+.
Encapsulation support is rather limited (Ethernet, HDLC, HSSI...).
The cisco 7000 also supports:
silicon switching
Silicon switching is done in the silicon switching engine (creative, eh? ;-).
The silicon switch processor (SSP) is the board which combines both the
switch processor and a silicon switching engine.
The SSP supports simple and extended outbound access lists in 10.3 and later.
The SSP supports simple and extended inbound access lists in 11.1 and later.
The cisco 75xx series supports:
"optimal" switching (cruddy name, eh?)
"flow" switching
"distributed" switching
* "optimal" switching (cruddy name, eh?)
The 7500 platform does not have a separate SP or SSP card, rather the RISC
processor on the "integrated route/switch processor card (IRSP)" handles
switching directly, similar to the 4000 series routers. There are several
hardware and software enhancements made though to increase the throughput to
a level that is several times above what you would normally get from "fast"
switching. Everything that "fast" switching supports is supported in
"optimal" switching.
* "flow" switching
Basicly the "optimal" switching method, however things have been front-ended
with an additional small "flow" cache. This flow cache contains information
about source/destination addresses & ports which allow the router to make more
informed queueing decisions and process access lists faster. This is a win in
routers that would tend to carry a reasonably small number of flows at any one
time, such as what you would expect in a corporate network or in a smaller
internet service provider network. It's unclear if there are any advantages
in a large internet backbone.
* "distributed" switching
cisco has announced a new type of interface-processor card, called a "VIP"
available in the 7500 platform that is intelligent enough to switch packets
with no intervention on the part of the IRSP card. This once again separates
switching from routing, as in the earlier CBUS/SP/SSP design.
The first packet of every session or connection is always Process Switched.
The route table is consulted (this resides in DRAM on the CPU) and the
"result" is cached in the system memory cache. If the protocol can only be
process switched, then it will continue this way and interrupt the CPU for a
route table lookup each time. [comment: Process Switching is brutally slow
compared to other switching methods. Some features (usually new features do
this for the first few software releases) force every packet to be process
switched. If you can't avoid process-switching every packet, at least get a
router with a fast CPU, such as the 75xx, 4500, and 4700. The 4700 is
currently the fastest at process-switching packets, with the 4500 and 75xx
tied for second. The 75xx can optimum-switch, however, so it's a lot faster
than either of the 4x00s, if you can use it).
The second and subsequent packets of each session are capable of being Fast
Switched (more session types are becoming fast-switchable), and will consult
only the route-cache. This still involves a memory lookup on the board, but
the packet can be transferred from the source card directly to the
destination card without requiring full storage on the CSC [the CSC refers
to the CPU card, basically].
There are some undocumented commands that are useful for obtaining
per-interface statistics on what sort of switching was performed.
For instance:
frobozz-magic-robot>sh int atm4/0 switch
ATM4/0
Throttle count: 0
Protocol Path Pkts In Chars In Pkts Out Chars Out
IP Process 104851 7669968 116378 11180988
Cache misses 35826
Fast 0 0 0 0
Auton/SSE 0 0 0 0
frobozz-magic-robot>sh int atm4/0 stat
ATM4/0
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 105024 7679155 116422 11184108
Route cache/FIB 0 0 0 0
Distributed cache 0 0 0 0
Total 105024 7679155 116422 11184108
------------------------------
From: Question 21
Date: 31 October 1994
Buffer statistics may be obtained with:
mit2-gw.near.net>sh buffers
Buffer elements:
433 in free list (500 max allowed)
82320311 hits, 0 misses, 0 created
Small buffers, 104 bytes (total 202, permanent 120):
185 in free list (20 min, 250 max allowed)
34289219 hits, 4297 misses, 1307 trims, 1389 created
Middle buffers, 600 bytes (total 104, permanent 90):
102 in free list (10 min, 200 max allowed)
6829533 hits, 1432 misses, 483 trims, 497 created
Big buffers, 1524 bytes (total 90, permanent 90):
90 in free list (5 min, 300 max allowed)
3403884 hits, 56 misses, 1 trims, 1 created
Large buffers, 5024 bytes (total 5, permanent 5):
5 in free list (0 min, 30 max allowed)
49984 hits, 13 misses, 20 trims, 20 created
Huge buffers, 18024 bytes (total 0, permanent 0):
0 in free list (0 min, 4 max allowed)
0 hits, 0 misses, 0 trims, 0 created
5683 failures (0 no memory)
You can interpret them:
Total Number of buffers of that size that exist.
Free Number of free buffers.
Max Maximum size that the free list can grow to before we start
throwing them away.
Hit Buffer got used.
Miss Someone requested a buffer and we had to go carve it up out of
free memory. If we couldn't because we were at interrupt
level, it's also an allocation failure. If we couldn't
because we were out of memory, then it's also a ``no memory''
failure.
Trim There are more free buffers on the free list than there need
to be and we threw some away.
Create Number of buffers we created after a miss.
------------------------------
From: Question 22
Date: 22 April 1996
Many admins are concerned about unauthorized access to their routers
from malicious people on the Internet; one way to prevent this
is to restrict access to your router on the basis of IP address.
Many people do this, however it should be noted that a significant number
of network service providers allow unrestricted access to their routers
to allow others to debug, examine routes, etc. If you're comfortable doing
this, so much the better, and we thank you!
If you wish to restrict access to your router, select a free IP access
list (numbered from 1-100) -- enter ``sh access-list'' to see those
numbers in use.
yourrouter#sh access-list
Standard IP access list 5
permit 192.94.207.0, wildcard bits 0.0.0.255
Next, enter the IP addresses you wish to allow access to your router
from; remember that access lists contain an implicit "deny everything"
at the end, so there is no need to include that. In this case, 30
is free:
yourrouter#conf t
Enter configuration commands, one per line. End with CNTL/Z.
yourrouter(config)#access-list 30 permit 172.30.0.0 0.0.255.255
yourrouter(config)#^Z
(This permits all IP addreses in the network 172.30.0.0, i.e. 172.30.*.*).
Enter multiple lines for multiple addresses; be sure that you don't
restrict the address you may be telnetting to the router from.
Next, examine the output of ``sh line'' for all the vty's (Virtual ttys)
that you wish to apply the access list to. In this example, I want
lines 2 through 12:
yourrouter#sh line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns
0 CTY - - - - - 0 0 0/0
1 AUX 9600/9600 - - - - - 1 3287605 1/0
* 2 VTY 9600/9600 - - - - 7 55 0 0/0
3 VTY 9600/9600 - - - - 7 4 0 0/0
4 VTY 9600/9600 - - - - 7 0 0 0/0
5 VTY 9600/9600 - - - - 7 0 0 0/0
6 VTY 9600/9600 - - - - 7 0 0 0/0
7 VTY 9600/9600 - - - - 7 0 0 0/0
8 VTY 9600/9600 - - - - 7 0 0 0/0
9 VTY 9600/9600 - - - - 7 0 0 0/0
10 VTY 9600/9600 - - - - 7 0 0 0/0
11 VTY 9600/9600 - - - - - 0 0 0/0
12 VTY 9600/9600 - - - - - 0 0 0/0
Apply the access list to the relevant lines:
yourrouter#conf t
Enter configuration commands, one per line. End with CNTL/Z.
yourrouter(config)#line 2 12
yourrouter(config-line)# access-class 30 in
yourrouter(config-line)# ^Z
(This apply access list 30 to lines 2 through 12. It's important to
restrict access to the aux port (line 1) if you have a device (such
as a CSU/DSU) plugged into it.a)
Be sure to save your configuration with ``write mem''.
Please note that access lists for incoming telnet connections do NOT
cause your router to perform significant CPU work, unlike access lists
on interfaces.
------------------------------
From: Question 23
Date: 1 November 1994
What *is* source routing?
Soure routing is an IP option which allows the originator of a packet
to specify what path that packet will take, and what path return packets
sent back to the originator will take. Source routing is useful when the
default route that a connection will take fails or is suboptimal for some
reason, or for network diagnostic purposes. For more information on
source routing, see RFC791.
Unfortunately, source routing is often abused by malicious users on
the Internet (and elsewhere), and used to make a machine (A), think
it is talking to a different machine (B), when it is really talking to
a third machine (C). This means that C has control over B's ip address
for some purposes.
The proper way to fix this is to configure machine A to ignore
source-routed packets where appropriate. This can be done for most
unix variants by installing a package such as Wietse Venema,
,'s tcp_wrapper:
ftp://cert.org:pub/tools/tcp_wrappers
For some operating systems, a kernel patch is required to make this
work correctly (notably SunOS 4.1.3). Also, there is an unofficial
kernel patch available for SunOS 4.1.3 which turns all source routing
off; I'm not sure where this is available, but I believe it was posted
to the firewalls list by Brad Powell soimetime in mid-1994.
If disabling source routing on all your clients is not posssible, a
last resort is to disable it at your router. This will make you unable
to use ``traceroute -g'' or ``telnet @hostname1:hostname2'', both
of which use LSRR (Loose Source Record Route, 2 IP options, the first
of which is a type of source routing), but may be necessary for some.
If so, you can do this with
foo-e-0#conf t
Enter configuration commands, one per line. End with CNTL/Z.
foo-e-0(config)#no ip source-route
foo-e-0(config)#^Z
It is somewhat unfortunate that you cannot be selective about this; it
disables all forwarding of source-routed packets through the router,
for all interfaces, as well as source-routed packets to the router
(the last is unfortunate for the purposes of ``traceroute -g'').
------------------------------
From: Question 24
Date: 22 April 1996
Yes there is, however whether you wish to do so is an issue of
some debate.
You could consult:
1627 Network 10 Considered Harmful (Some Practices Shouldn't be
Codified). E. Lear, E. Fair, D. Crocker & T. Kessler. June 1994.
(Format: TXT=18823 bytes)
1918 Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996.
(Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005)
In any event, RFC 1918 documents the allocation of the following
addresses for use by ``private internets'':
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Most importantly, it is vital that nothing using these addresses
should ever connect to the global Internet, or have plans to do so.
Please read the above RFCs before considering implementing such
a policy.
As an additional note, some Internet providers provide network-management
services, statistics gathering, etc. It is unlikely (if at all possible)
that they would be willing to perform those services if you choose to
utilize private address space.
With the increasing popularity and reliability of address translation
gateways, this practice is becoming more widely accepted. Cisco has acquired
Network Translation, who manufacture such a product. It is now available as
the Cisco Private Internet Exchange. With it, you can use any addressing you
want on your private internet, and the gateway will insure that the invalid
addresses are converted before making out onto the global Internet. It also
makes a good firewall. Information on this product is available at
http://www.cisco.com/warp/public/751/pix/index.html
------------------------------
From: Question 25
Date: 18 April 1995
DHCP, the Dynamic Host Configuration Protocol (RFC1533), is essentially
a more extended and flexible version of BOOTP, which allows configuration
parameters and other control information to be carried to hosts.
Forwarding of DHCP packets (to a DHCP server elsewhere in the network) is
supported in 9.21(4) and 10.0(3), as well as later releases.
------------------------------
From: Question 26
Date: 18 April 1995
Cisco no longer distributes printed documentation with their routers;
instead, they distribute a CDROM.
Paper documentation may be purchased, however if you purchase a
support contract, documentation is free.
Cisco documentation is also available on the web -- if you have
a fast Internet conneciton this may be more useful
than the CD. Try:
http://www.cisco.com/univercd/data/doc/product.htm
------------------------------
From: Question 27
Date: 18 April 1995
The last supported release on the CSC/3 is 9.1(15). cisco
does not plan to release further software for the CSC/3.
------------------------------
From: Question 28
Date: 19 May 1995
This is a really complicated question, and a full answer
is beyond the scope of this document. Here are the beginnings
of an answer.
Note that Hello is no longer shipped with cisco routers, and that EGP has been
declared Historical (and thus obsolete) by the IETF. Don't use them.
Protocol RIP HELLO IGRP OSPF EIGRP IS-IS EGP BGP4
--------------------------------------------------------------------------
Type IGP IGP IGP IGP IGP IGP EGP EGP
Algorithm DV DV DV SPF DUAL SPF DV PV
Metrics Hopcnt Delay Speed Arb. Speed Arb. Policy Policy
Convergence Slow Unstb Mdt Fast Fast Fast Slow Fast
Standard? IETF No No IETF No ISO Hist. IETF
Complexity Simple Simple Simple Complx Complx Complx Simple Complx
Multipath? Yes Yes Yes Yes Yes Yes Yes [*]
Var-netmask? No No No Yes Yes Yes No YES
Notes
-----
IGP = interior gateway protocol, used to build routing tables within an AS.
EGP = exterior gateway protocol, used to communicate reachability
information between AS's.
Algorithms
----------
DUAL = DV with diffusing update algorithm (Garcia-Luna-Aceves et al)
DV = Distance Vector (Bellman-Ford)
PV = "Path Vector"
SPF = Shortest-path-first (Dijkstra)
Metrics
-------
A metric is how the protocol measures the network to determine the
"best" path.
"Speed" refers typically to link speed, not available bandwidth.
"Arb." indicates that the metrics are arbitrary and configurable.
HELLO tried to use available bandwidth by monitoring round-trip delay,
but was not generally successful at this.
Metrics are not directly exchangable when redistributing routing
information from one protocol to another. IGRP and EIGRP use
compatible and automatically convertable metrics.
Convergence
-----------
Qualitatively, convergence measures how fast routers using this
protocol will adapt to changes in the topology of the network.
"Unstb" indicates a protocol which in general never decided on a
stable configuration but continually oscillated between alternatives.
Complexity
----------
An observation of how complex the protocol is to implement.
Multipath
---------
Multipath indicates whether the protocol support and transport
multiple equal- or different- cost pathways across between endpoints?
[*] indicates that BGP4 supports multipath for IBGP (Internal BGP, a
full mesh of all border routers within an AS), but not for EBGP
(External BGP).
Variable netmask (Var-netmask)
------------------------------
Indicates whether the protocol allows for and transports different
masks for the subnets of a routed network.
------------------------------
From: Question 29
Date: 18 April 1995
Typing ``show version'' or ``show hardware'' yields a response like:
prospect-gw.near.net>sh version
Cisco Internetwork Operating System Software
IOS (tm) GS Software (GS7), Experimental Version 10.2(11829) [pst 113]
System-type (imagename) Version major.minor(release.interim)[who] Desc
System-type: type of system the software is designed to run on.
imagename: The name of the image. This is different (slightly) for
run-from-rom, run-from-flash, and run-from-ram images, and also
for subset images which both were and will be more common.
"Version": text changes slightly. For example, if an engineer gives you
a special version of software to try out a bug fix, this will say
experimental version.
Major: Major version number. Changes (in theory) when there have been
major feature additions and changes to the softare.
Minor: minor version number. Smaller but still signficant feature added.
(in reality, cisco is not very sure what the difference between
"major" and "minor" is, and sometimes politics gets in the way,
but either of these "incrementing" indicates feature additions.)
EXCEPT: 9.14, 9.17, and 9.1 are all somewhat similar. 9.1 is
the base, 9.14 adds specical feature for low end systems, 9.17
added special features specific the high end (cisco-7000) This
was an experiment that we are trying not to repeat.
release: increments (1 2 3 4 ...) for each maintenance release of released
software. Increments for every compile in some other places.
interim: increments on every build of the "release tree", which happens
weekly for each release, but is only made into a generically
shipping maintenance release every 7 to 8 weeks or so.
[who]: who built it. Has "fc 1" or similar for released software.
has something like [billw 101] for test software built Bill
Westfield (billw@cisco.com).
Desc: additional description.
The idea is that the image name and version number UNIQUELY identify
a set of sources and debugging information somewhere back at cisco,
should anything go wrong.
Copyright (c) 1986-1995 by cisco Systems, Inc.
Compiled Thu 09-Mar-95 23:54 by tli
Image text-base: 0x00001000, data-base: 0x00463EB0
Copyright, compilation date (and by whom), as well as the
starting address of the image.
ROM: System Bootstrap, Version 5.0(7), RELEASE SOFTWARE
ROM: GS Software (GS7), Version 10.0(7), RELEASE SOFTWARE (fc1)
The version of ROM bootstrap software, and the version of IOS
in ROM.
prospect-gw.near.net uptime is 2 weeks, 4 days, 18 hours, 38 minutes
System restarted by reload
How long the router has been up, and why it restarted.
System image file is "sse-current", booted via flash
How the router was booted.
RP (68040) processor with 16384K bytes of memory.
Type of processor.
G.703/E1 software, Version 1.0.
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
Bridging software.
ISDN software, Version 1.0.
Various software options compiled in.
1 Silicon Switch Processor.
2 EIP controllers (8 Ethernet).
2 FSIP controllers (16 Serial).
1 MIP controller (1 T1).
8 Ethernet/IEEE 802.3 interfaces.
16 Serial network interfaces.
128K bytes of non-volatile configuration memory.
4096K bytes of flash memory sized on embedded flash.
Hardware configuration.
Configuration register is 0x102
Lastly, the "configuration register", which may be set via
software in current releases...
------------------------------
From: Question 30
Date: 22 April 1996
This is covered fairly thoroughly in Product Info/Product
Bulletin/Frame Relay Broadcast Queue, Cisco Product Bulletin # 256,
available on CIO.
Via the web (requires CIO username and pasword)
http://cio.cisco.com/warp/customer/417/38.html
An excerpt:
(Virtual Interfaces)
It should be noted that in the IOS (Internetworking Operating System)
10.0 software there is a limit of 256 Virtual and physical
interfaces. Hence, if each DLCI is given its own virtual interface,
the router is limited to 256 DLCIs. This restriction is expected to be
removed in a future release.
In most scenarios, it is not necessary that each DLCI have its own
Virtual Interface. In particular, IP has the facility which allows
disabling of split-horizon routing and hence does not require Virtual
Interfaces to support partial mesh topologies.
(Appendix 1: How many DLCIs Can Cisco Support on an Interface?)
This question is similar to the question of how many PCs can you put
on an Ethernet. In general, you can put a lot more than you should
given performance and availability constraints.
When dimensioning a router in a large network, the following issues
should be considered:
DLCI Address Space: The only hard limits are the roughly 1000 DLCI
limit due to the 10 bit DLCI address space in the Frame Relay frame
header.
LMI Status Update: The LMI protocol requires that all status reports
fit into a single packet and generally limits the number of DLCIs to
less than 800.
Max DLCIs (approx) = (MTU -20)/5,
where MTU is the MTU size in bytes on the Frame Relay link.
Broadcast Replication: When sending, the router must replicate the
packet on each DLCI and this causes congestion on the access link. The
Broadcast Queue reduces this problem. In general, the network should
designed to keep the routing update load to below 20 percent of the
access lines speed. It is also important that memory requirements for
the Broadcast Queue be considered. A good technique to reduce this
restriction is the use of default route or extending the update
timers.
Broadcast Receipt: When receiving, the router must receive updates
from the network. The issue here is that the upstream switch can be
overloaded and drop packets. When routing updates are dropped, routing
instability occurs. Again, the receiving routing update load should be
kept to less than 20 percent of the access link speed and preferably
lower. Where very high speed links are used, a limit of 128 Kbit/s
worth of routing updates is recommended.
Routing Stability: When using a link state protocol to reduce the
update traffic, the dimensioning should be done assuming the periodic
update process and the worst case for Link State Updates (i.e.,
assuming link and power instability). Dimensioning should not be based
on the Hello traffic. As a rule of thumb, dimension assuming a
distance vector protocol, but assume that extra bandwidth is available
for user data.
User Data Traffic: Clearly, the number of DLCIs is dependent on the
traffic on each DLCI and the performance requirements to be met. In
general, Frame Relay accesses should be run at lower loads than
router-to-router links since the prioritisation capabilities are not
Lastly, if you're not sure what debugging criteria you need, you can
try ``debug all''. BE CAREFUL! It is way useful, but only in a very
controlled environment, where you can turn off absolutely everything
you're not interested in. Saves a lot of thinking. Turning it on on
a busy box can quickly cause meltdown.
------------------------------
From: Question 10
Date: 5 July 1994
>What level of software is required for NTP support in
>a cisco router?
9.21 or above.
>Which cisco routers support NTP?
It is a software feature exclusively. Anything that supports
9.21 or 10 will run NTP (when running that s/w).
>How do I set it up?
The basic hook is:
ntp server
or
ntp peer
depending on whether you want a client/server or peer relationship.
There's a bunch of other stuff available for MD5 authentication,
broadcast, access control, etc. You can also use the
context-sensitive help feature to puzzle it out; try ``ntp ?'' in
config mode.
You'll also want to play with the SHOW NTP * router commands. Here
are two examples.
EXAMPLE 1:
router# show ntp assoc
address ref clock st when poll reach delay offset disp
+~128.9.2.129 .WWVB. 1 109 512 377 97.8 -2.69 26.7
*~132.249.16.1 .GOES. 1 309 512 357 55.4 -1.34 27.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
EXAMPLE 2:
router#show ntp stat
Clock is synchronized, stratum 2, reference is 132.249.16.1
nominal freq is 250.0000 Hz, actual freq is 249.9981 Hz, precision is 2**19
reference time is B1A8852D.B69201EE (12:36:13.713 PDT Tue Jun 14 1994)
clock offset is -1.34 msec, root delay is 55.40 msec
root dispersion is 41.29 msec, peer dispersion is 28.96 msec
For particular cisco NTP questions, feel free to ask in comp.dcom.sys.cisco.
For broader NTP info, see ftp://louie.udel.edu:pub/ntp/doc. The file
clock.txt in that directory has info about various public NTP servers.
There is also information on radio time receivers that can be
connected to an NTP server (this is handy on private networks, if you
have an entire campus to get chiming, or if you become a hard core
chimer).
The ``ntp clock-period'' command is added automagically to jump-start
the NTP frequency compensation when the box is rebooted. This is
essentially a representation of the frequency of the crystal used as
the local timebase, and may take several days to calculate otherwise.
(Do a ``write mem'' after a week or so to save a good value.)
Caveat of obsolecence: Note that the CS-500 will not be able to
achieve quite the same level of accuracy as other platforms, since its
hardware clock resolution is roughly 242Hz instead of the 1MHz
available on other platforms. In practice this shouldn't matter for
anyone other than true time geeks.
----------------------------------------------------------------------
From: Question 11
Date: 5 July 1994
You will need to substitute your own NTP peers, timezones, and GMT
offsets into the examples below, of course. Example 1 is in US Central
Time Zone, while example 3 is in US Pacific Time Zone. Both account
for normal US Daylight Savings Time practices.
EXAMPLE 1 (Charley Kline):
...
clock timezone CST -6
clock summer-time CDT recurring
ntp source eth 0
ntp peer
ntp peer
ntp peer
...
EXAMPLE 2 (Tony Li):
...
ntp source Ethernet0/0
ntp update-calendar
ntp peer
ntp peer
...
EXAMPLE 3 (Dave Katz):
...
service timestamps debug datetime localtime
service timestamps log datetime localtime
clock timezone PST -8
clock summer-time PDT recurring
interface Ethernet0
ip address
ntp broadcast
ntp clock-period 17180319
ntp source Ethernet0
ntp server
ntp server
ntp server
COMMENTS ON EXAMPLE 3:
The config file is commented with date and time (and user id,
if TACACS is enabled) when the system thinks the clock is accurate.
I've enabled timestamping of debug and syslog messages. I send NTP
broadcast packets out onto the local ethernet. I'm in Pacific
Standard Time, with U.S. standard daylight saving time rules. I use
the IP address of the ethernet as the source for all NTP packets.
------------------------------
From: Question 12
Date: 5 July 1994
By default, all lines are configured to automatically try a telnet
connection if the first word in a input line is not recognized as a
valid command. You can disable this by setting ``transport preferred
none'' on every line (con, aux and vty). For instance:
sl-panix-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
line vty 0 10
transport preferred none
You can see the number of vty's currently configuered with ``show lines''
Also, you can suspend connect attempts with ^^ followed by ``x'', ie
shift-cntrl-6 x.
[It has been suggested that ``no ip ipname-lookup'' to turn off IEN116
helps. I think this is the default -jhawk ]
------------------------------
From: Question 13
Date: 31 Oct 1994
or: How do I find out which non-cisco systems on my networks generate IP-RIP
information without letting them mess up my routing tables.
Here you could work with a default administrative distance.
Administrative distance is the basis upon which the cisco prefers
routing information of one protocol over another. In this example:
router rip
network 192.125.254.0
distance 255
distance 120 192.125.254.17 ! list all valid RIP suppliers
[...]
the value 255 has the implicit meaning of not putting this information
into the routing table. Therefore, setting an administrative distance
of 255 means that all RIP suppliers are by default accepted but their
information is not put into the routing table. The administrative
distance for the router 192.125.244.17 has been reset to the default
(for RIP) of 120, causing its routes to be accepted into the routing table.
Then you can look them up with ``show ip protocols'' and restore the
original administrative distance for the ones you want to fill in the
routing table.
The same results can be acheived with an ip access-list, but with
that, ``show ip protocols'' will only show the valid ones. But often
it is more useful to see which systems were generating routing
information at all.
This trick works for other routing protocols as well, but please select
the proper adminstrative distance (rather than 120) for the protocol
you're using.
------------------------------
From: Question 14
Date: 5 July 1994
[The following is wholesale included; at some point it'll
probably be editted a bit and reformatted... -jhawk ]
Frequently Asked Questions
contributed by Howard C. Berkowitz
PSC International
hcb@world.std.com
@clark.net [probably will be my permanent
personal account]
PSC's domain is in mid-setup
Where in the router are access lists applied?
In general, Basic access lists are executed as filters on
outgoing interfaces. Newer releases of the cisco code, such as
9.21 and 10, do have increased ability to filter on incoming ports.
Certain special cases, such as broadcasts and bridged traffic,
can be filtered on incoming interfaces in earlier releases.
There are also special cases involving console access.
Rules, written as ACCESS-LIST statements, are global for the entire
cisco box; they are activated on individual outgoing interfaces by
ACCESS-GROUP subcommands of the INTERFACE major command.
Filters are applied after traffic has entered on an incoming
interface and gone through a routing process; traffic that originates in
a router (e.g., telnets from the console port) is not subject to
filtering.
+-------------------+
| GLOBAL |
| |
| Routing |
| ^ v Access |
| ^ v Lists |
+-^--v--------^---v-+
| ^ v ^ v |
| ^ v ^ v |
A----------->|-| |>>>>Access >>----------->B
|1 Group 2 |
<------------| |<-----------
| |
| |
+-------------------+
Some types of ``filter,'' using ``filter'' as a broader class than
ACCESS-LIST, can operate on incoming traffic. For example, the INPUT-
SAP-FILTER used for Novell networks is applied to Service Advertisement
Packets (SAP) seen at incoming interfaces. In general, incoming
filtering can only be done for ``system'' rather than user traffic.
Rules of thumb in defining access lists.
First, define what you want to do and in which directions. An
informal drawing is a good first step. As opposed to the usual
connectivity drawings among routers, it's often convenient to draw
unidirectional links between routers.
Second, informally write out your filtering rules. In general, it
is best to go from most specific to least specific. Modify the order of
writing things to minimize the number of rules needed.
Third, determine which rules need to be on which routers.
Explicitly consider the direction of flow, and the possible existence of
additional paths that could inadvertently bypass a filter.
Can a cisco router be a ``true'' firewall?
This depends on the definition of firewall. Some writers (e.g.,
Gene Spafford in _Practical UNIX Security_) define a firewall as a
host on which an ``inside'' and/or an ``outside'' application process run,
with application-level code linking the two. For example, a firewall
might provide FTP access to the outside world, but it would not also
provide direct FTP service to the inside world. To place a file on
the FTP external server, a designated user would explicitly log onto
the FTP server, transfer a file to the server, and log off. The
firewall prevents direct FTP connectivity between the inside and
outside networks; only indirect, application-level connectivity is
allowed.
Firewalls of this sort are complemented by chokes, which filter on
network addresses and/or port numbers. Cisco routers cannot do
application-level control with access control lists.
Other authors do not distinguish between chokes and filters. Using
the loose definition that a firewall is anything that selectively blocks
access from the inside to the outside, routers can be firewalls.
IP Specific
-----------
Can the ``operand'' field be used with a protocol keyword of IP to filter
on protocol ID?
No. Operand filtering only works for TCP and UDP port numbers.
How can I prevent traffic for a certain Internet application to flow in
one direction but not the other?
Remember that Internet applications flow from client port to server
port. Denying traffic from port 23, for example, blocks flow from the
client to the server.
+-------------------+
| |
A----------->| |----------->B
|1 2|
<------------| |<-----------
| |
+-------------------+
If we deny traffic to Port 23 of address B by placing a filter at
interface 2, we have blocked A's ability to telnet to B, but not B's
ability to telnet to A. A second filter at interface A would be needed
to block telnet in both directions.
Assume that we only have the filter at interface 2. Telnets to A
from B will not be affected because the filter at 2 does not check
incoming traffic.
-------
With the arrival of in-bound access lists in 9.21, it should be noted
that both inbound and access lists are about equally efficient, in
case any of you were wondering.
It's worth remembering that there are some kinds of problems
that packet-filtering firewalls are not best suited for. There's
reasonably good information in:
"Network (in)security through packet filtering"
ftp://ftp.greatcircle.com/pub/firewalls/pkt_filtering.ps.Z
------------------------------
From: Question 15
Date: 26 July 1994
What really happens when a cisco router boots, from boot start to live
interfaces?
First it boots the ROM os version. It reads the config. Now, it
realizes that you want to netboot. It loads the netbooted copy in on
top of itself. It then re-initializes the box and re-reads the
config. Manly, yes, but we like it too....
[[ Ummm... in particular it loads the netbooted copy in as WELL as
itself, decompresses it, if necessary, and THEN loads on top of
itself. Note that this is important because it tells you what the
memory requirements are for netbooting: RAM for ROM image (if it's a
run from RAM image), plus dynamic data structures, plus RAM for
netbooted image. ]]
The four ways to boot and what happens (sort of):
I (from bootstrap mode)
The ROM monitor is running. The I command causes the ROM monitor to
walk all of the hardware in the bus and reset it with a brute force
hammer. If the bits in the config register say to auto-boot, then
goto B
B (from bootstrap mode)
Load the OS from ROM. If a name is given, tell that image to start
silently and then load a new image. If the boot system command is
given, then start silently and load a new image.
powercycle
Does some delay stuff to let the power settle. Goto I.
reload (from the EXEC)
Goto I.
------------------------------
From: Question 16
Date: 18 July 1994
Try calling 800-553-NETS and asking for your local sales office.
That's probably the best plan.
------------------------------
From: Question 17
Date: 18 April 1995
Where and how to get new RFCs
=============================
RFCs may be obtained via EMAIL or FTP from many RFC Repositories. The
Primary Repositories will have the RFC available when it is first
announced, as will many Secondary Repositories. Some Secondary
Repositories may take a few days to make available the most recent
RFCs.
Primary Repositories:
RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET,
NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or FTP.SESQUI.NET.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Secondary Repositories:
Sweden
------
Host: sunic.sunet.se
Directory: rfc
Host: chalmers.se
Directory: rfc
Germany
-------
Site: EUnet Germany
Host: ftp.Germany.EU.net
Directory: pub/documents/rfc
France
------
Site: Institut National de la Recherche en Informatique
et Automatique (INRIA)
Address: info-server@inria.fr
Notes: RFCs are available via email to the above
address. Info Server manager is Mireille
Yamajako (yamajako@inria.fr).
Netherlands
-----------
Site: EUnet
Host: mcsun.eu.net
Directory: rfc
Notes: RFCs in compressed format.
France
------
Site: Centre d'Informatique Scientifique et Medicale
(CISM)
Contact: ftpmaint@univ-lyon1.fr
Host: ftp.univ-lyon1.fr
Directories: pub/rfc/* Classified by hundreds
pub/mirrors/rfc Mirror of Internic
Notes: Files compressed with gzip. Online
decompression done by the FTP server.
Finland
-------
Site: FUNET
Host: funet.fi
Directory: rfc
Notes: RFCs in compressed format. Also provides
email access by sending mail to
archive-server@funet.fi.
Norway
------
Host: ugle.unit.no
Directory: pub/rfc
Denmark
-------
Site: University of Copenhagen
Host: ftp.denet.dk
Directory: rfc
Australia and Pacific Rim
-------------------------
Site: munnari
Contact: Robert Elz
Host: munnari.oz.au
Directory: rfc
rfc's in compressed format rfcNNNN.Z
postscript rfc's rfcNNNN.ps.Z
United States
-------------
Site: cerfnet
Contact: help@cerf.net
Host: nic.cerf.net
Directory: netinfo/rfc
Site: NASA NAIC
Contact: rfc-updates@naic.nasa.gov
Host: naic.nasa.gov
Directory: files/rfc
Site: NIC.DDN.MIL (DOD users only)
Contact: NIC@nic.ddn.mil
Host: NIC.DDN.MIL
Directory: rfc/rfcnnnn.txt
Note: DOD users only may obtain RFC's via FTP
from NIC.DDN.MIL. Internet users should NOT
use this source due to inadequate connectivity.
Site: uunet
Contact: James Revell
Host: ftp.uu.net
Directory: inet/rfc
UUNET Archive
-------------
UUNET archive, which includes the RFC's, various IETF documents,
and other information regarding the internet, is available to the
public via anonymous ftp (to ftp.uu.net) and anonymous uucp, and
will be available via an anonymous kermit server soon. Get the
file /archive/inet/ls-lR.Z for a listing of these documents.
Any site in the US running UUCP may call +1 900 GOT SRCS and use
the login "uucp". There is no password. The phone company will
bill you at $0.50 per minute for the call. The 900 number only
works from within the US.
------------------------------
From: Question 18
Date: 22 April 1996
[This could be more fleshed out (still!)]
Kerberos and RADIUS in 11.1
RIP version 2 in 11.1 (allows VSM, etc.)
Policy-based routing (routing based on source address or interface, or just
about anything else you want) in 11.0 *released*
PPP Multilink in 11.0(3) *released*
Frame Relay payload compression in 11.0(4) *released*
IPX Per-Host load balancing in 11.1
------------------------------
From: Question 19
Date: 27 July 1994
People often ask about performance of the cisco routers and are shyed
away from answering their questions because we don't know where to send
them.
Scott Bradner keeps the results of his performance tests on the
Internet. You can find them for ftp on the system hsdndev.harvard.edu
in the /pub/ndtl. There is a README file in that directory that
explains what is available. In addition, cisco has just started
publishing a piece of literature called ``The Harvard Benchmark Test
Results: Summary of cisco Systems Performance''. The only number I
can find on the doc is Lit. #700901. Don't know if you can order it
by this number, but at least there's a title to go on.
------------------------------
From: Question 20
Date: 22 April 1996
There are 3 basic types of switching (in order of increasing performance).
process switching
fast switching
autonomous switching
Process and fast switching support inbound and outbound, simple and
extended, access lists. Of course, for fast switching, such lists only
restrict traffic on the particular fast-switched interface.
Autonomous switching is done in the switch processor, a microcoded device that
is capable of switching IP, IPX, and bridging packets in the 100kpps range.
This is known as the "SP" card on the 7000 and the CBUS controller on the AGS+.
Encapsulation support is rather limited (Ethernet, HDLC, HSSI...).
The cisco 7000 also supports:
silicon switching
Silicon switching is done in the silicon switching engine (creative, eh? ;-).
The silicon switch processor (SSP) is the board which combines both the
switch processor and a silicon switching engine.
The SSP supports simple and extended outbound access lists in 10.3 and later.
The SSP supports simple and extended inbound access lists in 11.1 and later.
The cisco 75xx series supports:
"optimal" switching (cruddy name, eh?)
"flow" switching
"distributed" switching
* "optimal" switching (cruddy name, eh?)
The 7500 platform does not have a separate SP or SSP card, rather the RISC
processor on the "integrated route/switch processor card (IRSP)" handles
switching directly, similar to the 4000 series routers. There are several
hardware and software enhancements made though to increase the throughput to
a level that is several times above what you would normally get from "fast"
switching. Everything that "fast" switching supports is supported in
"optimal" switching.
* "flow" switching
Basicly the "optimal" switching method, however things have been front-ended
with an additional small "flow" cache. This flow cache contains information
about source/destination addresses & ports which allow the router to make more
informed queueing decisions and process access lists faster. This is a win in
routers that would tend to carry a reasonably small number of flows at any one
time, such as what you would expect in a corporate network or in a smaller
internet service provider network. It's unclear if there are any advantages
in a large internet backbone.
* "distributed" switching
cisco has announced a new type of interface-processor card, called a "VIP"
available in the 7500 platform that is intelligent enough to switch packets
with no intervention on the part of the IRSP card. This once again separates
switching from routing, as in the earlier CBUS/SP/SSP design.
The first packet of every session or connection is always Process Switched.
The route table is consulted (this resides in DRAM on the CPU) and the
"result" is cached in the system memory cache. If the protocol can only be
process switched, then it will continue this way and interrupt the CPU for a
route table lookup each time. [comment: Process Switching is brutally slow
compared to other switching methods. Some features (usually new features do
this for the first few software releases) force every packet to be process
switched. If you can't avoid process-switching every packet, at least get a
router with a fast CPU, such as the 75xx, 4500, and 4700. The 4700 is
currently the fastest at process-switching packets, with the 4500 and 75xx
tied for second. The 75xx can optimum-switch, however, so it's a lot faster
than either of the 4x00s, if you can use it).
The second and subsequent packets of each session are capable of being Fast
Switched (more session types are becoming fast-switchable), and will consult
only the route-cache. This still involves a memory lookup on the board, but
the packet can be transferred from the source card directly to the
destination card without requiring full storage on the CSC [the CSC refers
to the CPU card, basically].
There are some undocumented commands that are useful for obtaining
per-interface statistics on what sort of switching was performed.
For instance:
frobozz-magic-robot>sh int atm4/0 switch
ATM4/0
Throttle count: 0
Protocol Path Pkts In Chars In Pkts Out Chars Out
IP Process 104851 7669968 116378 11180988
Cache misses 35826
Fast 0 0 0 0
Auton/SSE 0 0 0 0
frobozz-magic-robot>sh int atm4/0 stat
ATM4/0
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 105024 7679155 116422 11184108
Route cache/FIB 0 0 0 0
Distributed cache 0 0 0 0
Total 105024 7679155 116422 11184108
------------------------------
From: Question 21
Date: 31 October 1994
Buffer statistics may be obtained with:
mit2-gw.near.net>sh buffers
Buffer elements:
433 in free list (500 max allowed)
82320311 hits, 0 misses, 0 created
Small buffers, 104 bytes (total 202, permanent 120):
185 in free list (20 min, 250 max allowed)
34289219 hits, 4297 misses, 1307 trims, 1389 created
Middle buffers, 600 bytes (total 104, permanent 90):
102 in free list (10 min, 200 max allowed)
6829533 hits, 1432 misses, 483 trims, 497 created
Big buffers, 1524 bytes (total 90, permanent 90):
90 in free list (5 min, 300 max allowed)
3403884 hits, 56 misses, 1 trims, 1 created
Large buffers, 5024 bytes (total 5, permanent 5):
5 in free list (0 min, 30 max allowed)
49984 hits, 13 misses, 20 trims, 20 created
Huge buffers, 18024 bytes (total 0, permanent 0):
0 in free list (0 min, 4 max allowed)
0 hits, 0 misses, 0 trims, 0 created
5683 failures (0 no memory)
You can interpret them:
Total Number of buffers of that size that exist.
Free Number of free buffers.
Max Maximum size that the free list can grow to before we start
throwing them away.
Hit Buffer got used.
Miss Someone requested a buffer and we had to go carve it up out of
free memory. If we couldn't because we were at interrupt
level, it's also an allocation failure. If we couldn't
because we were out of memory, then it's also a ``no memory''
failure.
Trim There are more free buffers on the free list than there need
to be and we threw some away.
Create Number of buffers we created after a miss.
------------------------------
From: Question 22
Date: 22 April 1996
Many admins are concerned about unauthorized access to their routers
from malicious people on the Internet; one way to prevent this
is to restrict access to your router on the basis of IP address.
Many people do this, however it should be noted that a significant number
of network service providers allow unrestricted access to their routers
to allow others to debug, examine routes, etc. If you're comfortable doing
this, so much the better, and we thank you!
If you wish to restrict access to your router, select a free IP access
list (numbered from 1-100) -- enter ``sh access-list'' to see those
numbers in use.
yourrouter#sh access-list
Standard IP access list 5
permit 192.94.207.0, wildcard bits 0.0.0.255
Next, enter the IP addresses you wish to allow access to your router
from; remember that access lists contain an implicit "deny everything"
at the end, so there is no need to include that. In this case, 30
is free:
yourrouter#conf t
Enter configuration commands, one per line. End with CNTL/Z.
yourrouter(config)#access-list 30 permit 172.30.0.0 0.0.255.255
yourrouter(config)#^Z
(This permits all IP addreses in the network 172.30.0.0, i.e. 172.30.*.*).
Enter multiple lines for multiple addresses; be sure that you don't
restrict the address you may be telnetting to the router from.
Next, examine the output of ``sh line'' for all the vty's (Virtual ttys)
that you wish to apply the access list to. In this example, I want
lines 2 through 12:
yourrouter#sh line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns
0 CTY - - - - - 0 0 0/0
1 AUX 9600/9600 - - - - - 1 3287605 1/0
* 2 VTY 9600/9600 - - - - 7 55 0 0/0
3 VTY 9600/9600 - - - - 7 4 0 0/0
4 VTY 9600/9600 - - - - 7 0 0 0/0
5 VTY 9600/9600 - - - - 7 0 0 0/0
6 VTY 9600/9600 - - - - 7 0 0 0/0
7 VTY 9600/9600 - - - - 7 0 0 0/0
8 VTY 9600/9600 - - - - 7 0 0 0/0
9 VTY 9600/9600 - - - - 7 0 0 0/0
10 VTY 9600/9600 - - - - 7 0 0 0/0
11 VTY 9600/9600 - - - - - 0 0 0/0
12 VTY 9600/9600 - - - - - 0 0 0/0
Apply the access list to the relevant lines:
yourrouter#conf t
Enter configuration commands, one per line. End with CNTL/Z.
yourrouter(config)#line 2 12
yourrouter(config-line)# access-class 30 in
yourrouter(config-line)# ^Z
(This apply access list 30 to lines 2 through 12. It's important to
restrict access to the aux port (line 1) if you have a device (such
as a CSU/DSU) plugged into it.a)
Be sure to save your configuration with ``write mem''.
Please note that access lists for incoming telnet connections do NOT
cause your router to perform significant CPU work, unlike access lists
on interfaces.
------------------------------
From: Question 23
Date: 1 November 1994
What *is* source routing?
Soure routing is an IP option which allows the originator of a packet
to specify what path that packet will take, and what path return packets
sent back to the originator will take. Source routing is useful when the
default route that a connection will take fails or is suboptimal for some
reason, or for network diagnostic purposes. For more information on
source routing, see RFC791.
Unfortunately, source routing is often abused by malicious users on
the Internet (and elsewhere), and used to make a machine (A), think
it is talking to a different machine (B), when it is really talking to
a third machine (C). This means that C has control over B's ip address
for some purposes.
The proper way to fix this is to configure machine A to ignore
source-routed packets where appropriate. This can be done for most
unix variants by installing a package such as Wietse Venema,
ftp://cert.org:pub/tools/tcp_wrappers
For some operating systems, a kernel patch is required to make this
work correctly (notably SunOS 4.1.3). Also, there is an unofficial
kernel patch available for SunOS 4.1.3 which turns all source routing
off; I'm not sure where this is available, but I believe it was posted
to the firewalls list by Brad Powell soimetime in mid-1994.
If disabling source routing on all your clients is not posssible, a
last resort is to disable it at your router. This will make you unable
to use ``traceroute -g'' or ``telnet @hostname1:hostname2'', both
of which use LSRR (Loose Source Record Route, 2 IP options, the first
of which is a type of source routing), but may be necessary for some.
If so, you can do this with
foo-e-0#conf t
Enter configuration commands, one per line. End with CNTL/Z.
foo-e-0(config)#no ip source-route
foo-e-0(config)#^Z
It is somewhat unfortunate that you cannot be selective about this; it
disables all forwarding of source-routed packets through the router,
for all interfaces, as well as source-routed packets to the router
(the last is unfortunate for the purposes of ``traceroute -g'').
------------------------------
From: Question 24
Date: 22 April 1996
Yes there is, however whether you wish to do so is an issue of
some debate.
You could consult:
1627 Network 10 Considered Harmful (Some Practices Shouldn't be
Codified). E. Lear, E. Fair, D. Crocker & T. Kessler. June 1994.
(Format: TXT=18823 bytes)
1918 Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996.
(Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005)
In any event, RFC 1918 documents the allocation of the following
addresses for use by ``private internets'':
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Most importantly, it is vital that nothing using these addresses
should ever connect to the global Internet, or have plans to do so.
Please read the above RFCs before considering implementing such
a policy.
As an additional note, some Internet providers provide network-management
services, statistics gathering, etc. It is unlikely (if at all possible)
that they would be willing to perform those services if you choose to
utilize private address space.
With the increasing popularity and reliability of address translation
gateways, this practice is becoming more widely accepted. Cisco has acquired
Network Translation, who manufacture such a product. It is now available as
the Cisco Private Internet Exchange. With it, you can use any addressing you
want on your private internet, and the gateway will insure that the invalid
addresses are converted before making out onto the global Internet. It also
makes a good firewall. Information on this product is available at
http://www.cisco.com/warp/public/751/pix/index.html
------------------------------
From: Question 25
Date: 18 April 1995
DHCP, the Dynamic Host Configuration Protocol (RFC1533), is essentially
a more extended and flexible version of BOOTP, which allows configuration
parameters and other control information to be carried to hosts.
Forwarding of DHCP packets (to a DHCP server elsewhere in the network) is
supported in 9.21(4) and 10.0(3), as well as later releases.
------------------------------
From: Question 26
Date: 18 April 1995
Cisco no longer distributes printed documentation with their routers;
instead, they distribute a CDROM.
Paper documentation may be purchased, however if you purchase a
support contract, documentation is free.
Cisco documentation is also available on the web -- if you have
a fast Internet conneciton this may be more useful
than the CD. Try:
http://www.cisco.com/univercd/data/doc/product.htm
------------------------------
From: Question 27
Date: 18 April 1995
The last supported release on the CSC/3 is 9.1(15). cisco
does not plan to release further software for the CSC/3.
------------------------------
From: Question 28
Date: 19 May 1995
This is a really complicated question, and a full answer
is beyond the scope of this document. Here are the beginnings
of an answer.
Note that Hello is no longer shipped with cisco routers, and that EGP has been
declared Historical (and thus obsolete) by the IETF. Don't use them.
Protocol RIP HELLO IGRP OSPF EIGRP IS-IS EGP BGP4
--------------------------------------------------------------------------
Type IGP IGP IGP IGP IGP IGP EGP EGP
Algorithm DV DV DV SPF DUAL SPF DV PV
Metrics Hopcnt Delay Speed Arb. Speed Arb. Policy Policy
Convergence Slow Unstb Mdt Fast Fast Fast Slow Fast
Standard? IETF No No IETF No ISO Hist. IETF
Complexity Simple Simple Simple Complx Complx Complx Simple Complx
Multipath? Yes Yes Yes Yes Yes Yes Yes [*]
Var-netmask? No No No Yes Yes Yes No YES
Notes
-----
IGP = interior gateway protocol, used to build routing tables within an AS.
EGP = exterior gateway protocol, used to communicate reachability
information between AS's.
Algorithms
----------
DUAL = DV with diffusing update algorithm (Garcia-Luna-Aceves et al)
DV = Distance Vector (Bellman-Ford)
PV = "Path Vector"
SPF = Shortest-path-first (Dijkstra)
Metrics
-------
A metric is how the protocol measures the network to determine the
"best" path.
"Speed" refers typically to link speed, not available bandwidth.
"Arb." indicates that the metrics are arbitrary and configurable.
HELLO tried to use available bandwidth by monitoring round-trip delay,
but was not generally successful at this.
Metrics are not directly exchangable when redistributing routing
information from one protocol to another. IGRP and EIGRP use
compatible and automatically convertable metrics.
Convergence
-----------
Qualitatively, convergence measures how fast routers using this
protocol will adapt to changes in the topology of the network.
"Unstb" indicates a protocol which in general never decided on a
stable configuration but continually oscillated between alternatives.
Complexity
----------
An observation of how complex the protocol is to implement.
Multipath
---------
Multipath indicates whether the protocol support and transport
multiple equal- or different- cost pathways across between endpoints?
[*] indicates that BGP4 supports multipath for IBGP (Internal BGP, a
full mesh of all border routers within an AS), but not for EBGP
(External BGP).
Variable netmask (Var-netmask)
------------------------------
Indicates whether the protocol allows for and transports different
masks for the subnets of a routed network.
------------------------------
From: Question 29
Date: 18 April 1995
Typing ``show version'' or ``show hardware'' yields a response like:
prospect-gw.near.net>sh version
Cisco Internetwork Operating System Software
IOS (tm) GS Software (GS7), Experimental Version 10.2(11829) [pst 113]
System-type (imagename) Version major.minor(release.interim)[who] Desc
System-type: type of system the software is designed to run on.
imagename: The name of the image. This is different (slightly) for
run-from-rom, run-from-flash, and run-from-ram images, and also
for subset images which both were and will be more common.
"Version": text changes slightly. For example, if an engineer gives you
a special version of software to try out a bug fix, this will say
experimental version.
Major: Major version number. Changes (in theory) when there have been
major feature additions and changes to the softare.
Minor: minor version number. Smaller but still signficant feature added.
(in reality, cisco is not very sure what the difference between
"major" and "minor" is, and sometimes politics gets in the way,
but either of these "incrementing" indicates feature additions.)
EXCEPT: 9.14, 9.17, and 9.1 are all somewhat similar. 9.1 is
the base, 9.14 adds specical feature for low end systems, 9.17
added special features specific the high end (cisco-7000) This
was an experiment that we are trying not to repeat.
release: increments (1 2 3 4 ...) for each maintenance release of released
software. Increments for every compile in some other places.
interim: increments on every build of the "release tree", which happens
weekly for each release, but is only made into a generically
shipping maintenance release every 7 to 8 weeks or so.
[who]: who built it. Has "fc 1" or similar for released software.
has something like [billw 101] for test software built Bill
Westfield (billw@cisco.com).
Desc: additional description.
The idea is that the image name and version number UNIQUELY identify
a set of sources and debugging information somewhere back at cisco,
should anything go wrong.
Copyright (c) 1986-1995 by cisco Systems, Inc.
Compiled Thu 09-Mar-95 23:54 by tli
Image text-base: 0x00001000, data-base: 0x00463EB0
Copyright, compilation date (and by whom), as well as the
starting address of the image.
ROM: System Bootstrap, Version 5.0(7), RELEASE SOFTWARE
ROM: GS Software (GS7), Version 10.0(7), RELEASE SOFTWARE (fc1)
The version of ROM bootstrap software, and the version of IOS
in ROM.
prospect-gw.near.net uptime is 2 weeks, 4 days, 18 hours, 38 minutes
System restarted by reload
How long the router has been up, and why it restarted.
System image file is "sse-current", booted via flash
How the router was booted.
RP (68040) processor with 16384K bytes of memory.
Type of processor.
G.703/E1 software, Version 1.0.
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
Bridging software.
ISDN software, Version 1.0.
Various software options compiled in.
1 Silicon Switch Processor.
2 EIP controllers (8 Ethernet).
2 FSIP controllers (16 Serial).
1 MIP controller (1 T1).
8 Ethernet/IEEE 802.3 interfaces.
16 Serial network interfaces.
128K bytes of non-volatile configuration memory.
4096K bytes of flash memory sized on embedded flash.
Hardware configuration.
Configuration register is 0x102
Lastly, the "configuration register", which may be set via
software in current releases...
------------------------------
From: Question 30
Date: 22 April 1996
This is covered fairly thoroughly in Product Info/Product
Bulletin/Frame Relay Broadcast Queue, Cisco Product Bulletin # 256,
available on CIO.
Via the web (requires CIO username and pasword)
http://cio.cisco.com/warp/customer/417/38.html
An excerpt:
(Virtual Interfaces)
It should be noted that in the IOS (Internetworking Operating System)
10.0 software there is a limit of 256 Virtual and physical
interfaces. Hence, if each DLCI is given its own virtual interface,
the router is limited to 256 DLCIs. This restriction is expected to be
removed in a future release.
In most scenarios, it is not necessary that each DLCI have its own
Virtual Interface. In particular, IP has the facility which allows
disabling of split-horizon routing and hence does not require Virtual
Interfaces to support partial mesh topologies.
(Appendix 1: How many DLCIs Can Cisco Support on an Interface?)
This question is similar to the question of how many PCs can you put
on an Ethernet. In general, you can put a lot more than you should
given performance and availability constraints.
When dimensioning a router in a large network, the following issues
should be considered:
DLCI Address Space: The only hard limits are the roughly 1000 DLCI
limit due to the 10 bit DLCI address space in the Frame Relay frame
header.
LMI Status Update: The LMI protocol requires that all status reports
fit into a single packet and generally limits the number of DLCIs to
less than 800.
Max DLCIs (approx) = (MTU -20)/5,
where MTU is the MTU size in bytes on the Frame Relay link.
Broadcast Replication: When sending, the router must replicate the
packet on each DLCI and this causes congestion on the access link. The
Broadcast Queue reduces this problem. In general, the network should
designed to keep the routing update load to below 20 percent of the
access lines speed. It is also important that memory requirements for
the Broadcast Queue be considered. A good technique to reduce this
restriction is the use of default route or extending the update
timers.
Broadcast Receipt: When receiving, the router must receive updates
from the network. The issue here is that the upstream switch can be
overloaded and drop packets. When routing updates are dropped, routing
instability occurs. Again, the receiving routing update load should be
kept to less than 20 percent of the access link speed and preferably
lower. Where very high speed links are used, a limit of 128 Kbit/s
worth of routing updates is recommended.
Routing Stability: When using a link state protocol to reduce the
update traffic, the dimensioning should be done assuming the periodic
update process and the worst case for Link State Updates (i.e.,
assuming link and power instability). Dimensioning should not be based
on the Hello traffic. As a rule of thumb, dimension assuming a
distance vector protocol, but assume that extra bandwidth is available
for user data.
User Data Traffic: Clearly, the number of DLCIs is dependent on the
traffic on each DLCI and the performance requirements to be met. In
general, Frame Relay accesses should be run at lower loads than
router-to-router links since the prioritisation capabilities are not