- Test - lists.nanog.org

Re: Maybe I'm misreading this but...
by Dean Anderson 14 Oct '98

14 Oct '98

The 172.16 to 172.31 block is reserved in RFC1918 for private internets. The last address 209.149.111.17 belongs to a bellsouth block. It's a safe bet that libidomax.com is a bellsouth customer, or a customer of a bellsouth customer. Probably bellsouth and alternet are peering and using a private network between themselves. --Dean At 05:11 PM 10/14/98 -0400, Barry Shein wrote: > >The following traceroute seems to indicate, according to ARIN, that >someone is running routers for spammers in the IANA Reserved netspace? > >First a traceroute: > >>world% traceroute www.libidomax.com >>traceroute to www.libidomax.com (209.149.111.17), 30 hops max, 40 byte packets >> 1 Boston-STD-F.std.com (199.172.62.80) 17 ms 4 ms 4 ms >> 2 553.Hssi2-0.GW2.BOS1.ALTER.NET (157.130.10.129) 59 ms 107 ms 69 ms >> 3 124.ATM3-0.XR1.BOS1.ALTER.NET (146.188.176.250) 77 ms 54 ms 37 ms >> 4 191.ATM2-0.TR1.NYC1.ALTER.NET (146.188.179.82) 38 ms 51 ms 51 ms >> 5 104.ATM7-0.TR1.ATL1.ALTER.NET (146.188.136.57) 80 ms 87 ms 133 ms >> 6 100.ATM7-0.XR1.ATL1.ALTER.NET (146.188.232.85) 91 ms 141 ms 63 ms >> 7 195.ATM10-0-0.GW1.JAX1.ALTER.NET (146.188.232.169) 53 ms 81 ms 107 ms >> 8 bs-jackson-gw.customer.alter.net (157.130.65.226) 107 ms 132 ms 96 ms >> 9 172.17.80.46 (172.17.80.46) 59 ms 53 ms 44 ms >>10 172.21.210.18 (172.21.210.18) 122 ms 96 ms 49 ms >>11 209.149.111.17 (209.149.111.17) 53 ms (ttl=118!) 58 ms (ttl=118!) 150 ms (ttl=118!) > > > >Ok, now let's look up the 172.* addresses: > >>world% arin 172.17.80.46 >>IANA (IANA-BBLK-RESERVED) >> Internet Assigned Numbers Authority >> Information Sciences Institute >> University of Southern California >> 4676 Admiralty Way, Suite 1001 >> Marina del Rey, CA 90292-6695 >> >> Netname: IANA-BBLK-RESERVED >> Netblock: 172.16.0.0 - 172.31.0.0 >> >> Coordinator: >> Internet Assigned Numbers Authority (IANA-ARIN) iana(a)iana.org >> (310) 822-1511 >> >> Domain System inverse mapping provided by: >> >> BLACKHOLE.ISI.EDU 128.9.64.26 >> NS2.INTERNIC.NET 198.41.0.11 > >and I get the same result of course for the other 172 address so I'll >save you the redundant cut and paste. > >What's going on here? > >-- > -Barry Shein > >Software Tool & Die | bzs(a)world.std.com | http://www.world.com >Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD >The World | Public Access Internet | Since 1989 *oo* > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Cisco security notice: CSCdk43920 command history release (fwd)
by William F. Maton 14 Oct '98

14 Oct '98

In case none of you are on BUGTRAQ.... wfms ---------- Forwarded message ---------- Date: Wed, 14 Oct 1998 15:26:38 -0000 From: security-alert(a)cisco.com Reply-To: psirt(a)cisco.com To: BUGTRAQ(a)netspace.org Subject: Cisco security notice: CSCdk43920 command history release -----BEGIN PGP SIGNED MESSAGE----- Field Notice: Cisco IOS Command History Release at Login Prompt ==================================================================== Revision 1.0 For release 08:00 AM US/Pacific, Wednesday, October 14, 1998 Summary ======= An error in Cisco IOS software makes it possible for untrusted, unauthenticated users who can gain access to the login prompt of a router or other Cisco IOS device, via any means, to obtain fragments of text entered by prior interactive users of the device. This text may contain sensitive information, possibly including passwords. This vulnerability exposes only text entered at prompts issued by the IOS device itself; the contents of data packets forwarded by IOS devices are not exposed, nor are data entered as part of outgoing interactive connections, such as TELNET connections, from the IOS device to other network nodes. This applies only to devices running classic Cisco IOS software, including most, but not all, Cisco router products. The easiest way to determine whether your device is running classic Cisco IOS software is to use the show version command as detailed under "Who Is Affected " below. Although the conditions under which it can be exploited are similar, this vulnerability is not related to the remote crash vulnerability announced in August, 1998. Who Is Affected =============== All users of classic Cisco IOS software, versions 9.1 and later, but earlier than the repaired versions listed in the "Details" section of this notice, whose devices can be connected to interactively by untrusted users, are affected by this vulnerability. Note that all of the repaired versions are quite recent as of the date of this notice, and that it is unlikely that most Cisco users have installed them. The vulnerability affects the vast majority of systems running Cisco IOS software as of this date. The vulnerability can be exploited using direct console or asynchronous serial connections (including dialup connections), TELNET connections, UNIX "r" command connections, local-area transport (LAT) connections, Maintenance Operation Protocol (MOP) connections, X.29 connections, V.120 connections, and possibly others. Except in extraordinary security environments, administrators are strongly encouraged to assume that hostile users can find ways to make interactive connections to their Cisco IOS devices. It is not necessary to be able to actually log in to exploit this vulnerability; simply establishing a terminal connection is sufficient. Affected Devices - -------------- It is impossible to list all Cisco products in this notice; the lists below included only the most commonly used or most asked-about products. If you are unsure whether your device is running classic Cisco IOS software, log into the device and issue the command show version. Classic Cisco IOS software will identify itself simply as "IOS" or "Internetwork Operating System Software". Other Cisco devices either will not have the show version command, or will give different output. Cisco devices that run classic Cisco IOS software include: * Cisco routers in the AGS/MGS/CGS/AGS+, IGS, RSM, 8xx, 1xxx, 25xx, 26xx, 30xx, 36xx, 40xx, 45xx, 47xx, AS52xx, AS53xx, 70xx, 72xx (including the ubr72xx), 75xx, and 12xxx series * Most recent versions of the LS1010 ATM switch * Some versions of the Catalyst 2900XL LAN switch. * The Cisco DistributedDirector If you are not running classic Cisco IOS software, then you are not affected by this vulnerability. Cisco devices which do not run classic Cisco IOS software, and are not affected by this vulnerability, include the following: * 7xx dialup routers (750, 760, and 770 series) are not affected. * Catalyst 19xx, 28xx, 29xx, 3xxx, and 5xxx LAN switches are not affected, except for some versions of the Catalyst 2900XL. However, optional router modules running Cisco IOS software in switch backplanes, such as the RSM module for the Catalyst 5000 and 5500, are affected. * WAN switching products in the IGX and BPX lines are not affected. * The MGX (formerly known as the AXIS shelf) is not affected. * No host-based software is affected. * The Cisco PIX Firewall is not affected. * The Cisco LocalDirector is not affected. * The Cisco Cache Engine is not affected. Impact ====== If attackers know the details of the Cisco IOS software error, they will be able to obtain fragments of the last few lines of text entered in response to IOS prompts on the physical or virtual TTYs to which they are connected. The exact amount of recoverable text varies, and will be split among fragments of various lines. Nearly complete lines, and fragments tens of characters long, can sometimes be obtained. If the previous session was brief, the available information may include part or all of the password that a previous user used to log into the router or to enable privileged mode. If a previous user changed a system password, such as the enable password, and logged out shortly thereafter, it may be possible to recover the new password by reading the configuration command used to make the change. This vulnerability does not expose anything entered as part of an outgoing session from the IOS device to another node. For example, if a user logs into an IOS router, and then makes a TELNET connection to a remote host, none of the data in the TELNET connection itself can be recovered. Details ======= If you are a registered CCO user and you have logged in, you can view these bug details. This vulnerability has been assigned Cisco bug ID CSCdk43920. Affected and Repaired Software Versions - ------------------------------------- This vulnerability affects all releases of Classic Cisco IOS software, including special, interim, and beta software, from 9.1 up to, but not including, the following corrected releases: Earliest Regular Releases Earliest Interim Releases ----------- ----------- 11.0(22) 11.0(21.2) 11.1(22), 11.1(22)CA, 11.1(21)CC1, 11.1(22), 11.1(21.2)CA, 11.1(22)CE 11.1(21)CC1, 11.1(21.1)CE 11.2(16), 11.2(16)P, 11.2(15.4), 11.2(15.4)P, 11.2(16)BC,11.2(8)SA4 11.2(15.4)BC, 11.2(8)SA4 11.3(6), 11.3(6)T, 11.3(6)AA, 11.3(1)MA6, 11.3(5.6), 11.3(5.6)T, 11.3(6)NA, 11.3(9)WA4 11.3(5.6)AA, 11.3(1)MA54, 11.3(5.6)NA 12.0(1), 12.0(1)T, 12.0(1)S, other 12.0 Will be integrated in initial 12.0(1)x releases It is not necessary to run the specific versions listed above; the fix is present in all subsequent versions of the same releases as well. For example, 11.2(16)P is fixed, so 11.2(17)P will also be fixed. The fix is available in all regular releases as of the date of this notice. However, the fix has not yet been released for all "two-letter" early deployment software. Integration is under way for the unreleased "two-letter" versions. Some releases of Cisco IOS software have been obsoleted or have reached end of maintenance. The upgrade paths for the users of these releases are as follows: Obsolete Release Upgrade To ---------- ---------- 1.x - 8.x, 9.1, 9.14, 9.17, 9.21, 11.0 (be especially careful to check 10.1, 10.2, 10.3 (all variants) hardware compatibility) 11.0BT 11.1 11.1AA 11.2(16)P 11.2(4)XA, 11.2(9)XA 11.2(16)P 11.3(2)XA 11.3(3) 11.2F 11.3(6) Getting Fixed Software - -------------------- Cisco is offering free software upgrades to remedy this vulnerability for all vulnerable customers, regardless of contract status. Customers with service contracts may upgrade to any Cisco IOS software version. Customers without contracts may upgrade to the latest versions of the releases and feature sets that they are already running (for example, from 11.2(2) to 11.2(16), but not from 11.2(2) to 11.3(6)). Customers without contracts who are running obsolete software will receive free upgrades to the fixed versions listed in the table above. Furthermore, if there is no immediately available fix for software being run by a customer without a contract, then that customer will immediately be given the most appropriate available fixed software, even if a release or feature upgrade is involved. Customers with contracts should obtain upgraded software through their regular update channels (generally via Cisco's Worldwide Web site). Customers without contracts should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows: * +1 800 553 2447 (toll-free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact either "psirt(a)cisco.com" or "security-alert(a)cisco.com" for software upgrades. As with any software upgrade, you should check to make sure that your hardware can support the new software before upgrading. The most common problem is inadequate RAM. Assistance is available on Cisco's Worldwide Web site at http://www.cisco.com. Workarounds - --------- There are two major workarounds for this vulnerability: 1. Prevent untrusted users from having interactive access to the Cisco IOS device. If only IP-based interactive access is of concern, access can be restricted by using the ip access-class line configuration command to apply an access list to all virtual terminals in the system. However, it is important to remember that non-IP-based means of making interactive connections to Cisco IOS devices do exist, and to eliminate those means as possible routes of attack. The transport input command is particularly useful in controlling the protocols that can be used to get interactive access. Interactive access can be prevented completely by applying the configuration command no exec to any asynchronous line, or the command transport input none to any virtual terminal line, that may be accessible to untrusted users. 2. Overwrite any potentially sensitive information before logging out of any interactive session on an IOS device. This can be done by entering repeated spaces at an IOS command prompt until the command interpreter will accept no more input on the line, then pressing the "return" key. Follow this by entering a printing character, such as "q", repeatedly until no more input is accepted, then pressing control-A, followed by control-K, then "return" again. This procedure vastly reduces the probability of information leakage, but has not been verified to completely eliminate the possibility in all affected versions of Cisco IOS software. Cisco recommends installing upgraded software in preference to using either of these workarounds. The first workaround should be part of normal security configuration in any Cisco IOS device, but cannot usually be used to eliminate all possible risk, since some interactive access must be available for system management. The second workaround is prone to human error, and, although it greatly reduces the probability of an attacker's finding anything sensitive, it does not completely eliminate that possibility. Exploitation and Public Announcements ===================================== Cisco knows of no public announcements or discussion of the details of this vulnerability prior to the date of this notice. An inadvertant preannouncement was made to certain Cisco customers during the week of October 5, but the only information given to those customers consisted of the bug ID and the bug headline, which was "Security Problem". In other words, they were told that a security problem existed in a version of Cisco IOS software, but were given absolutely no details. A later message to those same customers informed them that the vulnerability had been found by a trusted customer, that Cisco knew of no exploitation of the vulnerability, and that a formal notice would be forthcoming. Extreme care was taken to avoid giving information that could be used to localize the vulnerability to any particular part of the Cisco IOS software, or other information that might be useful in finding the details. Cisco knows of no malicious exploitation of this vulnerability. This vulnerability was found by a Cisco customer during laboratory testing. Status of This Notice ===================== This is a final field notice. Although Cisco cannot guarantee the accuracy of all statements in this notice, all the facts have been checked to the best of our ability. Cisco does not anticipate issuing updated versions of this notice unless there is some material change in the facts. Should there be a significant change in the facts, Cisco may update this notice. Distribution - ---------- This notice will be posted on Cisco's Worldwide Web site at http://www.cisco.com/warp/public/770/ioshist-pub.shtml . In addition to Worldwide Web posting, the initial version of this notice is being sent to the following e-mail and Usenet news recipients: * cust-security-announce(a)cisco.com * bugtraq(a)netspace.org * first-teams(a)first.org (includes CERT/CC) * cisco(a)spot.colorado.edu * comp.dcom.sys.cisco * first-info(a)first.org * fib-beta(a)external.cisco.com * Various internal Cisco mailing lists Future updates of this notice, if any, will be placed on Cisco's Worldwide Web server, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the URL given above for any updates. Revision History - -------------- Revision 1.0, 8:00 US/Pacific, Initial released version 14-OCT-1998 Cisco Security Procedures ========================= Please report security issues with Cisco products, and/or sensitive security intrusion emergencies involving Cisco products, to security-alert(a)cisco.com . Reports may be encrypted using PGP; public RSA and DSS keys for "security-alert(a)cisco.com" are on the public PGP keyservers. The alias "security-alert(a)cisco.com" is used only for reports incoming to Cisco. Mail sent to the list goes only to a very small group of users within Cisco. Neither outside users nor unauthorized Cisco employees may subscribe to "security-alert(a)cisco.com". Please do not use "security-alert(a)cisco.com" for configuration questions, for security intrusions that you do not consider to be sensitive emergencies, or for general, non-security-related support requests. We do not have the capacity to handle such requests through this channel, and will refer them to the TAC, delaying response to your questions. We advise contacting the TAC directly with these requests. TAC contact numbers are as follows: * +1 800 553 2447 (toll-free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com All formal public security notices generated by Cisco are sent to the public mailing list "cust-security-announce(a)cisco.com". For information on subscribing to this mailing list, send a message containing the single line "info cust-security-announce" to "majordomo(a)cisco.com". An analogous list, "cust-security-discuss(a)cisco.com" is available for public discussion of the notices and of other Cisco security issues. ================================================================== This notice is copyright 1998 by Cisco Systems, Inc. This notice may be redistributed freely after the release date given at the top of the text, provided that redistributed copies are complete and unmodified, including all date and version information. ================================================================== -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNiTBTHLSeEveylnrAQE2eAf/ZS6Q/01tU+TCZSK+jzD+GNDhllW4AvIs pI/Ke02s4x3c8HtHo9YfhneAWD1Twj5e4BJPHT/Mh+54xAQ6IMxS3vA7D8XJ+0B8 xmfjrb8LBvpG+64nxGHVzHuXhoxdofUQOgE3mNQBoTj9FoBbKNVBQb0yifXjeVHs ftUfRUKH23QsT3y/tBFFNSmYXBphWXEHzb2ILuhReo2ZCh3ZB+gzp3FWPJ9MXy7s JGtVocEARykfTZsxMJkaqzITNX8gXOd9bkHQhQQN2w4pkETBDaQGo0ilVnipbhgD X/HfRRATT2NYEtBGeBJf/EdKsZOJIilFngqV1XrP3WUG1L/vJw9QAw== =JZHQ -----END PGP SIGNATURE-----

1 0

Re: IGPs in use
by Tony Li 14 Oct '98

14 Oct '98

xxvaf(a)WR.BBNPLANET.COM (Vince Fuller) writes: > There are some drawbacks to IS-IS: ... > > IS-IS uses an underlying traffic exchange which is based on OSI/CLNS. This > introduces requirements for OSI addressing and CLNS implementation which are > otherwise useless in an IP-centric network. IMHO, this represents a > substantial bit of operational complexity (obtaining CLNS addresses, teaching > operations/engineering staff how to use them and interpret them while > debugging, etc., etc...) While it does require OSI addressing, it does not require CLNP forwarding. As to the engineering and operations aspects, the additional complexity can, with a reasonable implementation, be almost completely hidden. For example: > show isis adjacency IS-IS adjacency database: Interface System L State Hold (secs) SNPA fxp0.0 lab5 2 Up 16 0:0:c0:cc:a0:bf fxp0.0 lab2 2 Up 25 0:0:c0:e8:69:db fxp0.0 lab10 1 Up 22 0:a0:c9:36:b3:a6 > On a pragmatic note, though, the relative successes of IS-IS and OSPF in the > large provider marketplace probably has more to do with the relative competence > of the cisco's original OSPF and IS-IS implementors than anything else > (only someone else who suffered through OSPF's growing pains way back in > the 9.0-9.1 days can really appreciate this comment...) Very true, tho those of us who had ringside seats do sympathize. ;-) Tony

1 0

Sunday evening NANOG tutorials
by Susan R. Harris 14 Oct '98

14 Oct '98

We're pleased to announce two tutorials for Sunday evening, November 8, in Atlanta: 7:15 - 8:45 "Good ISPs Have No Class - Addressing Nuances and Nuisances" Presented by Howard Berkowitz A review of some of the more subtle points of CIDR, aggregation, and renumbering. Included are tricks and techniques that the newer ISP might need, including pure address administration and procedures for submitting address space justifications. Hank Nussbacher's CIDR FAQ is a prerequisite for the session: http://www.ibm.net.il/~hank/cidr.html 8:45 - 10:45 "External Route Selection: Tips and Techniques for ISPs" Presented by Avi Freedman, Net Access Tips for ISPs on external route selection, including the BGP MED and LOCAL_PREF attributes, peering at multiple locations; backup transit; and how to mix transit, public, and private peering. We've also added several other presentations to the Mon. - Tues. schedule: http://www.nanog.org/mtg-9811/topics.html ------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 734.936.2100 srh(a)merit.edu Senior Science Writer Fax: 734.647.3185 -------------------------------------------------------------------------

1 0

Re: IGPs in use
by Vince Fuller 14 Oct '98

14 Oct '98

Not to nit-pick, but one correction and a few comments: Let's start with OSPF: ... Timers must be consistent among all neighbours, so if you want to make a change to your hello/dead timers to deal with delays somewhere (in links or routers), then you have to configure your entire network all at once. This isn't true. Timers must be consistant between adjacent routers, not across the entire network. This means, for example, that you must change both ends of a point-to-point link at the same time or must change all of the routers on a common multi-access network at the same time. ... The "scaling" feature of multicasting on a multicast-capable subnet saves you only 1/2 of your traffic, and LSA traffic still grows as your neighbour count grows. This is thanks to the unicast ACKs. The ACKs should be smaller than the distributed LSA's, so the savings should be a bit better than 1/2... ... The means of repairing a level-2 (backbone area) parition is, to put it politely, completely fucked in the head. I'm not sufficiently familiar with how IS-IS works to know how it solves this problem. But I wouldn't describe the OSPF virtual link mechanism as "completely fucked in the head"; think of a virtual link as a tunnel used only by the routing system... ... There are some drawbacks to IS-IS: ... IS-IS uses an underlying traffic exchange which is based on OSI/CLNS. This introduces requirements for OSI addressing and CLNS implementation which are otherwise useless in an IP-centric network. IMHO, this represents a substantial bit of operational complexity (obtaining CLNS addresses, teaching operations/engineering staff how to use them and interpret them while debugging, etc., etc...) On a pragmatic note, though, the relative successes of IS-IS and OSPF in the large provider marketplace probably has more to do with the relative competence of the cisco's original OSPF and IS-IS implementors than anything else (only someone else who suffered through OSPF's growing pains way back in the 9.0-9.1 days can really appreciate this comment...) --Vince

1 0

Re: IGPs in use
by Tony Li 14 Oct '98

14 Oct '98

scharf(a)vix.com (Jerry Scharf) writes: > One thing about IS-IS that is quite different from OSPF and all the other > IGPs is that the neighbor traffic is not in IP but instead is done at > layer 2. Some say this is a good thing. I have never run into a case > where I couldn't get it to do what I wanted, but always suspected there > would be. Would this force ATM links to move to the less efficient SNAP > based encoding (if so, there's 4% of your bandwidth)? Yes, however, let's be accurate here: the problem is NOT that IS-IS runs over the link layer. The problem is that it doesn't run over IP. Even if it ran over another network layer protocol, you'd still require an additional demux layer. One might point out that SNAP is perhaps not the most efficient of all encapsulations anyhow. Nor is ATM. Tony

1 0

Re: IGPs in use
by Tony Li 14 Oct '98

14 Oct '98

smd(a)clock.org (Sean M. Doran) writes: > There are some drawbacks to IS-IS: its per-link metrics are not > rich as currently defined, the LSP space is limited (but can be > hacked at), and you are stuck with no more than 255 pseudonodes. > All of these are likely to be hacked at and some seem pretty > fixable by locking Henk and Tony (and probably Dave Katz, who did > a good public analysis of IGP scaling at NANOG in Phoenix and who > has done even better private analyses and gripefests --:) ) in a > room for a few hours. In fact, I believe that it is not necessary to lock us in a room. A preferable alternative is if you lock others out, and throw in bandwidth, cycles, pizza, Scotch, diet Coke, and cash. ;-) ;-) ;-) > Frankly, though, I'm hoping that rather than locking themselves > in the room to "improve" IS-IS, the Obvious People lock themselves > into a room and build something else instead (which they might simply > call IS-IS, even if it isn't. Been there, done that, called it BGP). It's not clear that locking these people in a room would produce something fundamentally different than IS-IS anyway... so.... I believe that a more accurate modus operandi will be to extend IS-IS as much as possible within the bounds of the existing protocol. Then, when pressing problems drive us beyond those borders, to do more major work on the protocol. Whether that final result is called IS-IS or not (or even OSPF ;-) is largely a political question, not a technical one. Tony

1 0

Re: IGPs in use
by Tony Li 14 Oct '98

14 Oct '98

smd(a)clock.org (Sean M. Doran) writes: > BGP is fundamentally rate-limited by virtue of running on TCP. While that's necessary, it turns out to not be sufficient. A competent implementation must also meter out the changes that it sends to a peer in some sensical fashion. IOS, for example, had a hack in it so that if it was blowing out memory, it would rate limit the number of updates that it would send to a peer. > By contrast, IGPs are *not* fundamentally rate-limited -- > retransmissions are not congestion avoiding in any IGP that > I know of. In addition to the specifications that Henk has noted, it's become very clear that an IGP implementation that does NOT rate limit itself is very likely to become unstable. Tony

1 0

Re: IGPs in use
by Sean M. Doran 14 Oct '98

14 Oct '98

| > most large nsps use is-is, but usually only to carry the routes of the bgp | > speaking interfaces. | | Really?? Not that I desire to express any prejudices, but I honestly | thought nobody used it. Everywhere that Peter went... It wouldn't surprise me to learn that everywhere that Andrew went does it too. | Does it just work better for very large networks? "Better" is difficult to nail down. It works acceptably. Few people have the experience of switching from one to the other with networks the size that they are today, and probably only they are in a position to make that kind of qualitative judgement. While IS-IS and OSPF are really similar, and Dr Li was right that on a theoretical level they both ought to scale the same way, since they are both two-level IGPs, there are some fundamental differences which may hurt during failures and may hurt going into the future. Let's start with OSPF: The per-neighbour state in OSPF is large. The lifetime field counts upwards (I have heard this decision was made just because IS-IS counts downwards). This turns out to be dumb: you can't increase the refresh interval, so dumping a full routing table into OSPF means you have to refresh one LSA every 30ish milliseconds around the clock, assuming you don't have any other instabilities, and before considering adding extra data (like AS paths) and the multiplicative effects of flooding across NBMAs and the like. Since we count upwards, we cannot reduce the refresh load. Timers must be consistent among all neighbours, so if you want to make a change to your hello/dead timers to deal with delays somewhere (in links or routers), then you have to configure your entire network all at once. The "scaling" feature of multicasting on a multicast-capable subnet saves you only 1/2 of your traffic, and LSA traffic still grows as your neighbour count grows. This is thanks to the unicast ACKs. The means of repairing a level-2 (backbone area) parition is, to put it politely, completely fucked in the head. Because OSPF was designed to be "really fast" on machines with 32-bit register operations, everything is beautifully 32-bit, which is not the greatest in terms of granularity. One of the sacrifices were fields that might let one extend the protocol, other than adding new LSA types. Whee! IS-IS on the other hand is considerably more extensible. The existence of integrated IS-IS for IP is a pleasant demonstration; the work by Henk Smit of Cisco also underlines how IS-IS can be brought forwards towards the future. Unlike in OSPF, IS-IS LSP traffic is constant independent of neighbour count. The LSP refresh timer is down-counting, and so you can make the refresh interval as long as 18 hours. This is good, because when you have a stable network, you might not want to fill it with unnecessary LSPs. The hello and dead timers are independent of each other -- you can tune them in parts of your network, rather than needing to tune them everywhere in your network all at once. The per-neighbour state in IS-IS is quite small. There are some drawbacks to IS-IS: its per-link metrics are not rich as currently defined, the LSP space is limited (but can be hacked at), and you are stuck with no more than 255 pseudonodes. All of these are likely to be hacked at and some seem pretty fixable by locking Henk and Tony (and probably Dave Katz, who did a good public analysis of IGP scaling at NANOG in Phoenix and who has done even better private analyses and gripefests --:) ) in a room for a few hours. Of course, as the number of vendors developing IS-IS grows, it too may develop fun change control issues, but it's unlikely that many changes will be made that will lead to a lack of interoperability with previous (or other) implementations. Doing it in the IETF (as with BGP) is probably not so bad an idea, either. Frankly, though, I'm hoping that rather than locking themselves in the room to "improve" IS-IS, the Obvious People lock themselves into a room and build something else instead (which they might simply call IS-IS, even if it isn't. Been there, done that, called it BGP). None of the current IGPs is free of bad scaling problems and building one that is will be hard, so don't get ready to throw out your iBGP hacks yet. Sean.

3 2

Re: IGPs in use
by Tony Li 14 Oct '98

14 Oct '98

hcb(a)clark.net (Howard C. Berkowitz) writes: > When I gave my OSPF tutorial at NANOG in June, I stressed OSPF shouldn't be > thought of purely as a 2-level hierarchy with a routing domain consisting > of an area 0 and a set of nonzero areas. Some of the OSPF scaling > problems I see, and these are probably equally likely in IS-IS, come from > people trying to put everything into a single OSPF routing domain. Aside > from performance issues, this can become a network administration nightmare. > > Splitting the interior network into several IGP routing domains, and > linking these with a backbone-of-backbones, helps both performance and > administration. The backbone group doesn't need to be concerned with LAN > installations in a POP or customer site. Depending on the particular > network, you might link IGP routing domains with: > > -- static routes > -- iBGP, putting all IGPs in a single AS > -- iBGP and eBGP in a confederation > -- Hybrid layer 2/3 techniques, such as linking IGP-routed domains > to internal layer 2 "superhubs" > > How much IGP support you need will depend on your network. A large > enterprise, or a provider of both connectivity and content, will probably > need more IGP stuff than a pure connectivity provider. Howard, Yes, those sound like a list of administrative nightmares. ;-) Wouldn't it be much easier to make use of a three or four level hierarchical IGP? Tony

2 1