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. ------------------------------ Where can I get cisco hardware? 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. ------------------------------ Where can I get IETF documents (RFCs, STDs, etc.)? 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. ------------------------------ Future features in cisco software 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 ------------------------------ How do cisco routers rate performance-wise? 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. ------------------------------ How are packets switched? 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 ------------------------------ How does one interpret buffer statistics? 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. ------------------------------ How should I restrict access to my router? 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. ------------------------------ What can I do about source routing? 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''). ------------------------------ Is there a block of private IP addresses I can use? 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 ------------------------------ Is DHCP supported? 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. ------------------------------ Where can I get cisco documentation? 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 ------------------------------ What's the latest software for the CSC/3? 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. ------------------------------ What IP routing protocol should I use? 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. ------------------------------ How do I interpret the output of ``show version''? 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... ------------------------------ What is the maximum number of Frame Relay PVCs? 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 as strong in many cases and in general the marginal costs of increasing access link speed are lower than with dedicated lines. Many of the issues covered here are included in the Internet Design Guide manual that Cisco provides. Update: The limit of 256 PVCs goes away in IOS 11.1. I think the number is now something like 1024 per router or some even more ludicrous number. There are still lots of reasons you never want to do that. ;-) The limit of 256 PVCs goes away in IOS 11.1. I think the number is now something like 1024 per router or some even more ludicrous number. There are still lots of reasons you never want to do that. ;-) ------------------------------ How much memory is necessary to telnet to a cisco router? From: Question 31 Date: 18 April 1995 In order to login to a cisco router, it needs to have at least 64k of contiguous free memory. ------------------------------ Where can I purchase flash RAM? From: Question 32 Date: 18 April 1995 There are two varieties: MEM-1X8F 8meg MEM-2X8F 16meg ******************************************************************************* ******************************* 2500 ******************************** ******************************* 8M Flash ******************************** ******************************************************************************* PRODUCT# QTY -------- --- MEM-1X8F 1 MEM-2X8F 2 Part Number: 16-0975-01 Description: IC,FEPROM, 2Mx32,100ns,SIM80 SC: P REV: A0 S/UM: EA P/UM: EA ------------------------------------------------------------------------------- VENDOR ITM MANUFACTURER'S PART CODE MANUFACTURER'S NAME --- -------------------- ---------- ------------------------------ 1- 1 SM732C2000B-10 KITTING01 SMART MODULE Smart Modular is located in Freemont, California. For small orders, Smart Modular recommends you contact: PC Complete 800-849-4622. They carry both Flash RAM and DRAM. ------------------------------ When are static routes redistributed? From: Question 32 Date: 19 May 1995 In the simple case, any static route *in the routing table* is redistributed if the ``redistribute static'' command is used, and some filter (set with either ``route-map'' or ``distribute-list out'') doesn't filter it out. Whether the static route gets into routing table depends on: Whether the next hop address is reachable (if you use static route pointing to a next hop) OR Whether the interface is up (if you use static route pointing to an interface). If one of these is true, an attempt is made to add the route to the routing table; whether that succeeds depends on the administrative distance of the route -- a lower administrative distance (the route is "closer") than a preexisting route will cause the preexisting route to be overwritten. ------------------------------ When is the next hop of a route considered ``reachable''? From: Question 33 Date: 19 May 1995 When a static route is added, or during an important event (eg: interface up/down transition), the next hop for a route is looked up from the routing table (i.e. recursive routing). As a consequence, if a route which is depended upon for evaluation of the next hop of a static route goes away, a mechanism is required to remove that (now-invalid) static route. Scanning all static routes each time the routing table changes is too expensive, so instead, a period timer is used. One a minute, static routes are added and removed from the routing table based on the routes they depend upon. It should be noted that a particular static route will be reevaluated when its interface transitions up or down. ------------------------------ How do name and phone number of ``dialer map'' interfere? From: Question 35 Date: 22 April 1996 How do name and phone number of `dialer map' interfere? We use the telephone number first actually. If the caller id matches the telephone number to call, then you don't need the 'name' parameter with a phone number. I realized that the above is ambiguous, so let's do this. You have: dialer map ip x.x.x.x name is used for incoming authentication. It can be either the hostname, for PAP and CHAP, or it can be a number as returned by caller id. If this is not there, and it is an imcoming call, and there is caller id, we will compare against to see if that matches. Not sure I've been clear here. ------------------------------ What's the purpose of the network command? From: Question 36 Date: 22 April 1996 >* what is the real purpose of the network subcommand of > router commands? When do I not want to include a network > I know about? The real purpose of the 'network' sub-command of the router commands is to indicate what networks that this router is connected to are to be advertised in the indicated routing protocol or protocol domain. For example, if OSPF and EIGRP are configured, some subnets may be advertised in one and some in the other. The network command enables one to do this. An example of such a case is a secure subnet. Imagine the case where a set of subnets are permitted to communicate within a campus, but one of the buildings is intended to be inaccessible from the outside. By placing the secure subnet in its own network number and not advertising the number, the subnet is enabled to communicate with other subnets on the same router, but is unreachable from any other router, barring static routes. This can be extended by using a different routing protocol or routing protocol domain for the secure network; subnets on the various routers within the secure domain are mutually reachable, and routes from the non-secure domain may be leaked into the secure domain, but the secure domain is invisible to the outside world. ------------------------------ What is VLSM?  From: Question 37 Date: 22 April 1996 A Variable Length Subnet Mask (VLSM) is a means of allocating IP addressing resources to subnets according to their individual need rather than some general network-wide rule. Of the IP routing protocols supported by Cisco, OSPF, Dual IS-IS, BGP-4, and EIGRP support "classless" or VLSM routes. Historically, EGP depended on the IP address class definitions, and actually exchanged network numbers (8, 16, or 24 bit fields) rather than IP addresses (32 bit numbers); RIP and IGRP exchanged network and subnet numbers in 32 bit fields, the distinction between network number, subnet number, and host number being a matter of convention and not exchanged in the routing protocols. More recent protocols (see VLSM) carry either a prefix length (number of contiguous bits in the address) or subnet mask with each address, indicating what portion of the 32 bit field is the address being routed on. A simple example of a network using variable length subnet masks is found in Cisco engineering. There are several switches in the engineering buildings, configured with FDDI and Ethernet interfaces and numbered in order to support 62 hosts on each switched subnet; in actuality, perhaps 15-30 hosts (printers, workstations, disk servers) are physically attached to each. However, many engineers also have ISDN or Frame Relay links to home, and a small subnet there. These home offices typically have a router or two and an X terminal or workstation; they may have a PC or Macintosh as well. As such, they are usually configured to support 6 hosts, and a few are configured for 14. The point to point links are generally unnumbered. Using "one size fits all" addressing schemes, such as are found in RIP or IGRP, the home offices would have to be configured to support 62 hosts each; using numbers on the point to point links would further compound the address bloat. One configures the router for Variable Length Subnet Masking by configuring the router to use a protocol (such as OSPF or EIGRP) that supports this, and configuring the subnet masks of the various interfaces in the 'ip address' interface sub-command. To use supernets, one must further configure the use of 'ip classless' routes. ------------------------------