- NANOG - lists.nanog.org

Re: BGP as an IGP (Was Re: IGPs in use)
by Sean M. Doran 15 Oct '98

15 Oct '98

Chrisy Luke wrote: | Paul G. Donner wrote (on Oct 13): | > If BGP rides on TCP, how are the TCP sessions built if BGP itself is used | > as the IGP? | | Same way as it does when you take next-hops from any other IGP. The fact | that one already has a route to ones' directly attached networks. In other words, the interior routing protocol is either static or a combination of statically configured routes and the likes of ARP/ES-IS/other neighbour discovery protocols. The key point is that, in a router talking iBGP, the route to the NEXT_HOP received by an iBGP neighbour *MUST* be known through means other than BGP. This is not to say that the route need be dynamic -- a static default route would do just fine. Sean.

4 4

Need help with registering Maintainer info with CW.NET
by miguel a.l. paraz 15 Oct '98

15 Oct '98

Hi, This maybe off-topic here but I hope someone can help. I need to get BGP up and running with Cable & Wireless (ex-MCI) really soon. But, my submission for the Maintainer Object to the Routing Registry, which is manually approved, isn't being acknowledged. Without this I can't register my routes. I've e-mailed the supposed account rep for the Philippines (where I am), but I've received no response either. Anyone from Cable & Wireless here? Thanks, -- Miguel A.L. Paraz +63-2-750-2288 CTO, IPhil Communications www.iphil.net

1 0

Updated exchange point cross-matrix
by Sean Donelan 15 Oct '98

15 Oct '98

I have updated my exchange point cross-matrix. I didn't bother to update the ASN/name index because I thought it would be faster just to let you send in corrections. I have no idea which ASN or name some people are going to use pre/post merger. http://dranet.dra.com/exchangematrix.html -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

RE: Maybe I'm misreading this but...
by Martin, Christian 15 Oct '98

15 Oct '98

Also note that these IPs may sit on interfacs accompanied by 'routable' IPs, such as the 'secondary' keyword is used in Cisco-Speak (maybe others as well, I dunno). I've seen cases where customer's use RFC 1918 addreses as the primary and their real addresses as secondaries, so as to make it difficult to attack the router. TTL exceeded messages then get returned with the primary IP.... -Chris > -----Original Message----- > From: Tim Wolfe [mailto:tim@clipper.net] > Sent: Wednesday, October 14, 1998 7:16 PM > To: Dean Anderson > Cc: Barry Shein; nanog(a)merit.edu > Subject: Re: Maybe I'm misreading this but... > > > On Wed, 14 Oct 1998, Dean Anderson wrote: > > > 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 > > Or Bellsouth is using Alter.Net for their transit provider > just as US West > is in the Pacific NW... > > Tim > > ---------------------------------------------------- > Timothy M. Wolfe | Why surf when you can Sail? > tim(a)clipper.net | Join Oregon's Premier > Sr. Network Engineer | Wireless Internet Provider! > ClipperNet Corporation | http://www.clipper.net/ > ---------------------------------------------------- > >

1 0

Re: MAE NY?
by Sean Donelan 15 Oct '98

15 Oct '98

SEAN(a)dra.COM (Sean Donelan) writes: >Of course, WCOM wins for having the hottest POPs. Sorry to followup on my own posting. I should mention that after peaking at 37C (98F) in June, WorldCom has finally gotten their Washington DC co-locate down to a comfortable 19C (66F). So WCOM no longer has the hottest POPs (within my measurement domain). This message has been brought to you by the Absence of Malice Lawyer Avoidance System (AMLAS). -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

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