- Test - lists.nanog.org

Cisco Security Notice: Cisco IOS Syslog Crash
by security-alert＠cisco.com 11 Jan '99

11 Jan '99

-----BEGIN PGP SIGNED MESSAGE----- Field Notice: Cisco IOS Syslog Crash ================================================================== Revision 1.1 For release 08:00 US/Pacific, Monday, January 11, 1999 For Cisco internal use only until release date Summary ======= Certain versions of Cisco IOS software may crash or hang when they receive invalid user datagram protocol (UDP) packets sent to their "syslog" ports (port 514). At least one commonly-used Internet scanning tool generates packets which can cause such crashes and hangs. This fact has been announced on public Internet mailing lists which are widely read both by security professionals and by security "crackers", and should be considered public information. This vulnerability affects devices running Cisco IOS software version 11.3AA, version 11.3DB, or any 12.0-based version (including 12.0 mainline, 12.0S, 12.0T, and any other regular released version whose number starts with "12.0"). The vulnerability has been corrected in certain special releases, and will be corrected in maintenance and interim releases which will be issued in the future; see the section on "Software Versions and Fixes" for details on which versions are affected, and on which versions are, or will be, fixed. Cisco intends to provide fixes for all affected IOS variants. There is a configuration workaround for this vulnerability. Who is Affected =============== All Cisco devices which are running classic Cisco IOS software with any of the versions listed as affected under "Software Versions and Fixes" are vulnerable to attack. This includes 11.3AA, 11.3DB, and all 12.0 versions, up to the repaired releases listed in the table. No particular configuration is needed to make a Cisco IOS device vulnerable. It is possible to filter out the attack traffic using access lists; see "Workarounds" in this document. However, except at Internet firewalls, the appropriate filters are not common in customer configurations. You should carefully evaluate your configuration before assuming that any filtering you have already configured protects you against this attack. Affected Devices - -------------- It is impossible to list all Cisco products in this notice; the lists below include 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, ubr9xx, 1xxx, 25xx, 26xx, 30xx, 36xx, 38xx, 40xx, 45xx, 47xx, AS52xx, AS53xx, AS58xx, 64xx, 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. The affected software versions are relatively new, and are not necessarily available on every device listed above. 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 ====== Attackers can cause Cisco IOS devices to crash and reload. Furthermore, an attacker can repeat the process at will. By striking continuously, an attacker might be able to completely disable a Cisco IOS device until that device was reconfigured by its administrator. Some Cisco IOS devices have been observed to hang instead of crashing when attacked. These devices do not recover until manually restarted by reset or power cycle. This means that it might be necessary for an administrator to physically visit an attacked device in order to recover from the attack, even if the attacker is no longer actively sending any traffic. Some devices have crashed without providing stack traces; devices crashed using this vulnerability may indicate that they were "restarted by power-on", even when that is not actually the case. Workarounds =========== You can work around this vulnerability by preventing any affected Cisco IOS device from receiving or processing UDP datagrams addressed to its port 514. This can be done either using packet filtering on surrounding devices, or by using input access list filtering on the affected IOS device itself. If you use an input access list, that list should be applied to all interfaces to which attackers may be able to send datagrams. This includes not only physical LAN and WAN interfaces, but virtual subinterfaces of those physical interfaces, as well as virtual interfaces and/or interface templates corresponding to GRE, L2TP, L2F, and other tunnelling protocols. The input access list must block traffic destined for UDP port 514 at any of the Cisco IOS device's own IP addresses, as well as at any broadcast or multicast addresses on which the Cisco IOS device may be listening. It's important to remember to block old-style "all-zeroes" broadcasts as well as new-style "all-ones" broadcasts. It is not necessary to block traffic being forwarded to other hosts; only traffic actually addressed to the Cisco IOS device is of interest. There is no single input access list that will work in all configurations. It is very important that you understand the effect of your access list in your specific configuration before you activate the list. The following example shows a possible access list for a three-interface router, along with the configuration commands needed to apply that access list. The example assumes that there is no need for input filtering other than as a workaround for this vulnerability. ! Deny all multicasts, and all unspecified-net broadcasts, to port 514 access-list 101 deny udp any 224.0.0.0 31.255.255.255 eq 514 ! Deny old-style unspecified-net broadcasts access-list 101 deny udp any host 0.0.0.0 eq 514 ! Deny network-specific broadcasts. This example assumes that all of ! the local interfaces are on the class B network 172.16.0.0, subnetted ! everywhere with mask 255.255.255.0. This will differ from network ! to network. Note that we block both new-style and old-style broadcasts. access-list 101 deny udp any 172.16.0.255 0.0.255.0 eq 514 access-list 101 deny udp any 172.16.0.0 0.0.255.0 eq 514 ! Deny packets sent to the addresses of our own network interfaces. access-list 101 deny udp any host 172.16.1.1 eq 514 access-list 101 deny udp any host 172.16.2.1 eq 514 access-list 101 deny udp any host 172.16.3.3 eq 514 ! Permit all other traffic (default would be to deny) access-list 101 permit ip any any ! Apply the access list to the input side of each interface interface ethernet 0 ip address 172.16.1.1 255.255.255.0 ip access-group 101 in interface ethernet 2 ip address 172.16.2.1 255.255.255.0 ip access-group 101 in interface ethernet 3 ip address 172.16.3.3 255.255.255.0 ip access-group 101 in It can be complicated to list all possible addresses, and especially all possible broadcast addresses, to which attack packets might be sent. If you do not expect to need to forward any legitimate syslog traffic received on an interface, you may wish to simply block all syslog traffic arriving on that interface. Remember that this will affect traffic routed through the Cisco IOS device as well as traffic destined to the device; if the IOS device is expected to forward syslog packets, you will have to do the detailed filtering. Input access lists have an impact on system performance, and should be installed with a degree of caution, especially on systems that are running very near their capacity limits. Software Versions and Fixes =========================== This vulnerability has Cisco bug ID CSCdk77426. Many Cisco software images have been or will be specially reissued to correct this vulnerability. For example, regular released version 12.0(2) is vulnerable, as are interim versions 12.0(2.1) through 12.0(2.3) The first fixed interim version of 12.0 mainline software is 12.0(2.4). However, a special release, 12.0(2a), contains only the fix for this vulnerability, and does not include any of the other bug fixes from later 12.0 interim releases. If you were running 12.0(2), and wanted to upgrade to fix this problem, without taking the risk of instability presented by installing the 12.0(2.4) interim release, you could upgrade to 12.0(2a). 12.0(2a) represents a "code branch" from the 12.0(2) base, which merges back into the 12.0 mainline at 12.0(2.4). In every case, these special releases are one-time spot fixes, and will not be maintained. The upgrade path from, say, 12.0(2a), is to 12.0(3). See the following table for information about affected and repaired software versions. All dates in the table are tentative and subject to change. +----------+-------------+---------------+---------------+-----------------+ | | | Special | First fixed | | | | | one-time spot | interim | First fixed | | Cisco IOS| | fix release; | release** (fix| regular | | Major | Description | most stable | will carry | maintenance | | Release | | immediate | forward into |release (or other| | | | upgrade path | all later |long term upgrade| | | | (see above) | versions) | path) | +----------+-------------+---------------+---------------+-----------------+ | Unaffected releases | +----------+-------------+---------------+---------------+-----------------+ |11.2 and |Unaffected | | | | |earlier, |early | | | | |all |releases (no |Unaffected |Unaffected |Unaffected | |variants |syslog | | | | | |server) | | | | +----------+-------------+---------------+---------------+-----------------+ |11.3, | | | | | |11.3T, | | | | | |11.3DA, |11.3 releases| | | | |11.3MA, |without |Unaffected |Unaffected |Unaffected | |11.3NA, |syslog | | | | |11.3WA, |servers | | | | |11.3(2)XA | | | | | | | | | | | +----------+-------------+---------------+---------------+-----------------+ | 11.3-based releases | +----------+-------------+---------------+---------------+-----------------+ | |11.3 early | | | | |11.3AA |deployment |11.3(7)AA2, |11.3(7.2)AA |11.3(8)AA, | | |for AS58xx |8-JAN-1999* | |15-FEB-1999* | +----------+-------------+---------------+---------------+-----------------+ | |11.3 for | | | | | |Cisco NRP | | | | |11.3DB |routing blade| - | - |11.3(7)DB2, | | |in Cisco 6400| | |18-JAN-1999* | | |xDSL DSLAM | | | | +----------+-------------+---------------+---------------+-----------------+ | 12.0-based releases | +----------+-------------+---------------+---------------+-----------------+ |12.0 |12.0 mainline|12.0(2a), |12.0(2.4) |12.0(3), | | | |8-JAN-1999* | |1-FEB-1999* | +----------+-------------+---------------+---------------+-----------------+ | |12.0 new | | | | |12.0T |technology |12.0(2a)T1, |12.0(2.4)T |12.0(3)T, | | |early |11-JAN-1999* | |15-FEB-1999* | | |deployment | | | | +----------+-------------+---------------+---------------+-----------------+ | |ISP support: | | | | |12.0S |7200, RSP, | - |12.0(2.3)S |12.0(2)S***, | | |GSR | |27-DEC-1998 |18-JAN-1999* | +----------+-------------+---------------+---------------+-----------------+ | |12.0 for | | | | | |Cisco 6400 | | | | | |universal | | | | |12.0DB |access | - | - |12.0(2)DB, | | |concentrator | | |18-JAN-1999* | | |node switch | | | | | |processor | | | | | |(lab use) | | | | +----------+-------------+---------------+---------------+-----------------+ | | |12.0(1)W5(5a) | |12.0(1)W5(6) | | |12.0 for |and | |(platform support| |12.0(1)W |Catalyst 8500|12.0(1a)W5(5b) |12.0(1)W5(5.15)|for Catalyst | | |and LS1010 |(LS1010 | |8540M will be in | | | |platform only) | |12.0(1)W5(7)) | +----------+-------------+---------------+---------------+-----------------+ | |One-time | | | | | |early | | | | | |deployment | | |Unaffected; | | |for CH-OC12 |Unaffected; | |general upgrade | |12.0(0.6) |in Catalyst |one-time |Unaffected |path is via | |W5 |8500 series |release | |12.0(1)W5 | | |switches | | |releases. | | | | | | | | | | | | | +----------+-------------+---------------+---------------+-----------------+ | |Short-life | | | | | |release; | | |Upgrade to | |12.0(1)XA3|merged to |Obsolete |Merged |12.0(2a)T1and/or | | |12.0T at | | |to 12.0(3)T | | |12.0(2)T | | | | +----------+-------------+---------------+---------------+-----------------+ | |Short-life | | | | | |release for | | | | | |Cisco 800 | | | | |12.0(1)XB |series; |12.0(1)XB1 |Merged |Upgrade to | | |merged to | | |12.0(3)T | | |12.0T at | | | | | |12.0(3)T | | | | +----------+-------------+---------------+---------------+-----------------+ | |Short-life | | | | | |release for | | | | | |new features | | | | | |in Cisco | | | | | |2600, Cisco | | | | |12.0(2)XC |3600, |12.0(2)XC1, |Merged |Upgrade to | | |ubr7200, |7-JAN-1999* | |12.0(3)T | | |ubr900 | | | | | |series; | | | | | |merged to | | | | | |12.0T at | | | | | |12.0(3)T | | | | +----------+-------------+---------------+---------------+-----------------+ | |Short-life | | | | | |release for | | | | | |ISDN voice | | | | |12.0(2)XD |features; |12.0(2)XD1, |Merged |Upgrade to | | |merged to |18-JAN-1999* | |12.0(3)T | | |12.0T at | | | | | |12.0(3)T. | | | | +----------+-------------+---------------+---------------+-----------------+ |12.0(1)XE |Short-life |12.0(2)XE, |Merged |Upgrade to | | |release |18-JAN-1999* | |12.0(3)T | +----------+-------------+---------------+---------------+-----------------+ * All projected dates are estimates, and are subject to change ** Interim releases are subjected to less rigorous testing than regular maintenance releases, and may have serious bugs. *** The vulnerability is fixed in 12.0(2)S. The 12.0(2.3)S interim release is available to the field before the 12.0(2)S regular release because of internal process considerations. This entry is not a misprint. Getting Fixed Software - -------------------- Cisco is offering free software updates to correct this vulnerability for all vulnerable customers, regardless of contract status. Note, however, that because information about this vulnerability has been disseminated by third parties, Cisco has been forced to release this notice before updates are available for all software versions. The projected fix dates in the table above are subject to change, but represent Cisco's best estimate of the dates on which fixes will be available. As with any software change, you should check to make sure that your hardware can support the new software before installing it. The most common problem is inadequate RAM. While this is seldom a problem when upgrading within a major release (say, from 11.2(11)P to 11.2(17)P), it is often an issue when upgrading between major releases (say, from 11.2P to 11.3T). Because fixes will be made available for all affected releases, this vulnerability will rarely, if ever, require an upgrade to a new major release. Cisco recommends very careful planning for any upgrade between major releases. When upgrading between major releases, you must be especially careful to make certain that no known bugs will prevent the new software from working properly in your environment. Further upgrade planning assistance is available on Cisco's Worldwide Web site at http://www.cisco.com. Customers with service contracts should obtain new software through their regular update channels (generally via Cisco's Worldwide Web site). Customers with service contracts may upgrade to any software release, but must, as always, remain within the boundaries of the feature sets they have purchased.. Customers without service contracts may upgrade only to obtain the bug fixes; they are not offered upgrades to versions newer than required to resolve the defects. In general, customers without service contracts will be restricted to upgrading within a single row of the table above, except when no upgrade within the same row is available in a timely manner. Customers without service contracts should get their updates by contacting the Cisco 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) * tac(a)cisco.com Give the URL of this notice as evidence of your entitlement to a free update. Free updates 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 updates. Exploitation and Public Announcements ===================================== A third party announced this vulnerability on the "bugtraq(a)netspace.org" electronic mailing list on December 22, 1998. The third party's announcement included sufficient information to allow any computer-literate person with a moderate interest in security to exploit the vulnerability. On that same day, Cisco sent an informal acknowledgement and a description of the workaround both to the "bugtraq" list and to some other Internet discussion forums, as well as to all Cisco customers who had requested security updates by subscribing to the "cust-security-announce(a)cisco.com" mailing list. Cisco has seen the information from "bugtraq" reposted on several Worldwide Web sites catering to those interested in computer security. All of the Worldwide Web sites in question, and all of the discussion forums, including the "bugtraq" mailing list, are open to the public, and many of them are widely read by people interested in computer and network security. Customers should assume that any potential attacker is likely to know that this vulnerability exists, and furthermore is likely to know how to exploit the vulnerability. This vulnerability can be exploited using tools available to the public on the Internet; an attacker would not need to write any software to exploit the vulnerability. Minimal skill is required. No special equipment is required. Despite specifically inviting such reports, Cisco has received no actual reports of malicious exploitation of this vulnerability. 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/iossyslog-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) * first-info(a)first.org * cisco(a)spot.colorado.edu * comp.dcom.sys.cisco * nanog(a)merit.edu * 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, First release candidate version. 22:00 US/Pacific, 9-JAN-1999 Revision 1.1, Correct upgrade path for 12.0XE 09:45 US/Pacific, 10-JAN-1999 Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's Worlwide Web site at http://www.cisco.com/warp/public/791/sec_incident_response.shtml. This includes instructions for press inquiries regarding Cisco security notices. ================================================================== This notice is copyright 1999 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 this copyright notice and all date and version information. ================================================================== -----BEGIN PGP SIGNATURE----- Version: 1234567 iQEVAwUBNpjoBnLSeEveylnrAQE+qAf7BAR2F5l7mwXDZ58pisEMx+HoLd3ukCI3 p6I80G1B04EU0u484HNvD+ryrLRiwpfaxvrPm7zSqVyOsjaipt+fytONy3IpfQAr NK5yQ/VAzbW4dDzDKcaujiHHRNxq/ho9mMrbwpCMgq1agLaukDz+VbwH/5bAienI ARgfKkqrFUJBTCMMjxrv9IAGvF9aCgRZuI7rFWzGlYtxm0fayNpW4R1GXO0hQUz8 wV+LYydobOS1ZI3ADmk8oIyKOF9Mrcw5rE+j/aLaVik4ZBeG3TF+yhfqYuXiXg2G /TjoOLLgBDPsH29r+dCLp3oTYjjMpbg2YIWR2/dFeAMRqOnX1toKQQ== =k4vu -----END PGP SIGNATURE-----

1 0

Re: Fwd: Mailing List (1999)
by Dean Anderson 11 Jan '99

11 Jan '99

Not to jump too hard, but a whole lot of people agreed that spam was not usually a topic of interest on NANOG. So if you won't post spam to Nanog, I won't point out how flawed the anti-spam methods are, nor will I be tempted to explain why anti-spam methods eventually backfire on network operators. --Dean At 10:28 PM 1/10/1999 -0500, Alan Spicer wrote: >Has anyone else received email similar to this? I haven't got the headers >yet because this was forwarded to me by management. megasuccess.net isn't >listed in InterNIC but there are similar domain names. I don't want to >contact or complain about the wrong organization or people. Replies to >me only by email, unless this is some massive UCE campaign, please. > >Maybe they have already been shutdown by their provider? > >> >>>From: web(a)megasuccess.net >>>X-Sender: web(a)megasuccess.net >>>Date: 1/9/99 5:27:27 AM Pacific Daylight Time >>>Reply-To: web(a)megasuccess.net >>>To: web(a)megasuccess.net >>>Subject: Mailing List (1999) >>> >>>Hello, >>> >>>Please forgive the intrusion. >>> >>>Your email address is on a list that we purchased. >>> >>>Realizing that these lists are often compiled without your knowledge this >>is our attempt to clean this list before we begin mailing. It is not an >>attempt to verify that your email address is valid. We use an automated >>mail system that deletes undeliverable email (invalid addresses). >>>Since you are reading this email we already know your address is valid. >>> >>>If you DO NOT want to receive mail reply with "REMOVE" in the subject line. >>>Please make sure remove is in subject line or mail software will delete >>your reply. >>>Mail is not read so yelling, screaming or sending threats will not get you >>on remove list. >>>Only the word "REMOVE" will work. >>> >>>You will be placed on our remove list and not receive any email from us >>again. >>> >>>We DO NOT want anybody on our list to receive email that does not want to >>be there. >>> >>>If you are one of the small group of people who believe that you have the >>right to decide what email everyone on the internet should receive, and are >>going to email every organization you can find to request that you not >>receive any more email from us, then please remember to include us in your >>mailing with "REMOVE" in the subject. Otherwise you will have wasted a lot >>of people's time and still receive email from us. >>> >>>Thank you all for understanding. >>> >>>Sincerely, >>> >>>Bob Beaudoin >>>Webmaster MegaSuccess >>> >>> ___________________________________________________________ >>>This Message was Composed by a user of Automated E- Mail Software. If >>>you wish to be removed from this advertiser's future mailings, please reply >>>with the subject "Remove" and this software will automatically block you >>>from their future mailings. >>> >>Ebiznet...when results are more important than pretty web pages! >> >/------------------------------------------------\ >| Alan Spicer (tech(a)ebiznet.com) NIC:AGS14 | >|------------------------------------------------| >| www.ebiznet.com | www.websgreatesthits.com | >| www.trafficdirector.com | >| (OTC BB: BIZN). | >\------------------------------------------------/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Fwd: Mailing List (1999)
by Alan Spicer 11 Jan '99

11 Jan '99

Has anyone else received email similar to this? I haven't got the headers yet because this was forwarded to me by management. megasuccess.net isn't listed in InterNIC but there are similar domain names. I don't want to contact or complain about the wrong organization or people. Replies to me only by email, unless this is some massive UCE campaign, please. Maybe they have already been shutdown by their provider? > >>From: web(a)megasuccess.net >>X-Sender: web(a)megasuccess.net >>Date: 1/9/99 5:27:27 AM Pacific Daylight Time >>Reply-To: web(a)megasuccess.net >>To: web(a)megasuccess.net >>Subject: Mailing List (1999) >> >>Hello, >> >>Please forgive the intrusion. >> >>Your email address is on a list that we purchased. >> >>Realizing that these lists are often compiled without your knowledge this >is our attempt to clean this list before we begin mailing. It is not an >attempt to verify that your email address is valid. We use an automated >mail system that deletes undeliverable email (invalid addresses). >>Since you are reading this email we already know your address is valid. >> >>If you DO NOT want to receive mail reply with "REMOVE" in the subject line. >>Please make sure remove is in subject line or mail software will delete >your reply. >>Mail is not read so yelling, screaming or sending threats will not get you >on remove list. >>Only the word "REMOVE" will work. >> >>You will be placed on our remove list and not receive any email from us >again. >> >>We DO NOT want anybody on our list to receive email that does not want to >be there. >> >>If you are one of the small group of people who believe that you have the >right to decide what email everyone on the internet should receive, and are >going to email every organization you can find to request that you not >receive any more email from us, then please remember to include us in your >mailing with "REMOVE" in the subject. Otherwise you will have wasted a lot >of people's time and still receive email from us. >> >>Thank you all for understanding. >> >>Sincerely, >> >>Bob Beaudoin >>Webmaster MegaSuccess >> >> ___________________________________________________________ >>This Message was Composed by a user of Automated E- Mail Software. If >>you wish to be removed from this advertiser's future mailings, please reply >>with the subject "Remove" and this software will automatically block you >>from their future mailings. >> >Ebiznet...when results are more important than pretty web pages! > /------------------------------------------------\ | Alan Spicer (tech(a)ebiznet.com) NIC:AGS14 | |------------------------------------------------| | www.ebiznet.com | www.websgreatesthits.com | | www.trafficdirector.com | | (OTC BB: BIZN). | \------------------------------------------------/

1 0

Cisco config checker
by Pete Kruckenberg 10 Jan '99

10 Jan '99

Is there such a thing as a Cisco config checker, to allow off-line editing of Cisco configs and check them before they're uploaded to the router? Preferrably something that could be used in a Web/Unix environment as a filter. If not, does anyone know of a source for a complete definition of Cisco configuration language, in some kind of standardized format, so I could possibly generate a config-checker myself? Thanks. Pete.

9 11

Huge smurf attack
by Brandon Ross 09 Jan '99

09 Jan '99

We are currently seeing a smurf attack larger than any one we've ever seen before... it looks like it's causing us over 200Mb/s of incoming echo-reply traffic to 207.69.200.132 (our IRC server, imagine that). Please check your networks and see if you can help us trace this attack to the perpetrator, we'd love to prosecute if we can find them. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

1 2

Re: IGP Comparison (Summary of Responses)
by Ehab Hadi 09 Jan '99

09 Jan '99

And not only that. Each ISP has it's own applications, requirement, and traffic patterns. Deploying various IGP might add values. --Ehab >Date: Fri, 08 Jan 1999 14:06:51 -0500 >To: Antoni Przygienda <prz(a)dnrc.bell-labs.com> >From: Scott Brim <swb(a)newbridge.com> >Subject: Re: IGP Comparison (Summary of Responses) >Cc: nanog(a)merit.edu > >At 12:46 PM 1/8/99 -0500, Antoni Przygienda wrote: >ISPs are customers here and until the world converges >>on one >>protocol (if it ever will), their needs should be met. > >If we do see pressure for convergence, it will be evidence that we've >lost our hold on the multi-tier model. If we like the multi-tier model >(and so far it's been useful) then we want to continue to make the IGP >you run in a given domain a local matter. If it weren't we never would >have seen OSPF or ISIS deployed widely in the first place. > > >Cordiali saluti ... Scott > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Test-Disregard This
by Martin, Christian 09 Jan '99

09 Jan '99

Test

1 0

agenda topics so far
by Susan R. Harris 08 Jan '99

08 Jan '99

Greetings - here are agenda topics we've come up with so far for the Denver NANOG meeting (Jan. 31 - Feb. 2). Let us know what else you'd like to hear about by sending e-mail to nanog-support(a)nanog.org, and watch for further details at: http://www.nanog.org/mtg-9901 Hope you can join us! ---------- - MPLS: Progress in the IETF from an ISP Perspective (Curtis Villamizar, ANS; other speakers TBA) - Deploying Inter-Domain Multicast Routing (Dino Farinacci, Cisco) - Academic NGI Networking: What's the Difference Between Internet2, Abilene, and the vBNS? (Paul Love, Internet2; Guy Almes, Advanced Network & Services; John Jamison, MCI; other speakers TBA) - ARIN Update (Kim Hubbard, ARIN) - Cflowd Update (includes BOF covering configuration details) (Daniel McRobb, Cooperative Association for Internet Data Analysis) (CAIDA) - IRcache Web Proxy Bake-Off (Duane Wessels, University of California, San Diego) - Internet Engineering Curriculum (Evie Nemeth, CAIDA) ------------------- BOFs - Switch Migration and Renumbering at the Chicago NAP (Andrew Schmidt, AADS) - Managing Filters and Traffic Shaping in Complex Networks (Pete Kruckenberg, inQuo) ------------------------------------------------------------------------- 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

The Cidr Report
by Tony Bates 08 Jan '99

08 Jan '99

This is an auto-generated mail on Fri Jan 8 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 08Jan99 0) General Status Table History ------------- Date Prefixes 010199 55011 020199 55001 030199 54615 040199 54770 050199 54954 060199 54958 070199 55003 080199 54976 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4389 Number of ASes announcing only one prefix: 2167 (1158 cidr, 1009 classful) Largest number of cidr routes: 351 announced by AS3561 Largest number of classful routes: 1010 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 391 145 246 62.9% UNKNOWN AS3749 231 71 160 69.3% UNKNOWN AS701 1010 861 149 14.8% UNKNOWN AS2493 326 179 147 45.1% UNKNOWN AS174 669 546 123 18.4% UNKNOWN AS5668 131 35 96 73.3% UNKNOWN AS4200 188 97 91 48.4% UNKNOWN AS4755 150 68 82 54.7% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4293 207 135 72 34.8% UNKNOWN AS549 220 154 66 30.0% UNKNOWN AS4740 393 329 64 16.3% UNKNOWN AS8517 133 74 59 44.4% UNKNOWN AS1221 381 323 58 15.2% UNKNOWN AS7046 251 195 56 22.3% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS7657 140 89 51 36.4% UNKNOWN AS3493 248 197 51 20.6% UNKNOWN AS7545 114 64 50 43.9% UNKNOWN AS1239 530 483 47 8.9% UNKNOWN AS10928 95 48 47 49.5% UNKNOWN AS7496 74 28 46 62.2% UNKNOWN AS577 205 160 45 22.0% UNKNOWN AS852 175 133 42 24.0% UNKNOWN AS719 452 410 42 9.3% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 71 35 36 50.7% UNKNOWN AS7122 109 75 34 31.2% UNKNOWN AS1 503 470 33 6.6% UNKNOWN AS6897 46 14 32 69.6% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

IGP Comparison (Summary of Responses)
by Dan Rabb 08 Jan '99

08 Jan '99

In the process of selecting an IGP to run on a large scale nationwide IP Network, I received many responses to my NANOG request for information on IS-IS versus OSPF protocols. Most of the resources mentioned in the responses, however, were bias towards OSPF. There was not much information on IS-IS to be found, although obviously some individuals are satisfied enough with this protocol that is it still in place in large networks. Thank you to everyone who responded to my request. Rather than responding to each of you individually, I have summarized the information I received below (although admittedly one-sided). General: "The two are really pretty much equivalent, other than that IS-IS is intended for OSI networks while OSPF is for IP networks. Then there's "Integrated IS-IS" that handles both." Politics: "In fact, a number of members in the OSPF working group feared that IS-IS would be preferred for "political" reasons, as part of a grand plan to convert the Internet to OSI correctness, even if that meant a complete disruption of the service."(1) "There were also non-technical considerations. Many people felt that it was better that the IETF have complete control over the OSPF protocol design rather than depend on an ISO committee whose goals, namely to produce a routing protocol for the OSI protocol stack, were somewhat different."(2) Technical Issues: The following are excerpt from John Moy's book discusses the reasons that the IETF went ahead with the development of OSPF even though IS-IS was already being developed: "First, IS-IS ran directly over the link layer, which we thought was the wrong choice for a TCP/IP routing protocol..." "IS-IS had an area routing scheme, but one that did not allow any shortcuts between areas that we thought were necessary for an Internet routing protocol." "Also, IS-IS made no attempt to align fields in their packet formats, making life more difficult for protocol implementers." "It is possible to run IS-IS on an IP-only network, but, even if one does not want to forward CLNP datagarms, one will have to install in the routers the low-level code that demultiplexes CLNP and IS-IS packets. The "area" model of IS-IS is designed for CLNP where the rigidity and connectivity requirements are somewhat compensated by the possibility to perform automatic address assignment; when one uses IS-IS for IP, the rigidity remains, but the advantages disappear. IS-IS suffers from at least two other problems; a tiny metric and a limit to what a router can advertise. Having only 6 bits to express a link's metric is not really a good idea. It may make some messages shorter, but it certainly diminishes the routing's precision. Then, using the 8-bit link state record number to identify the link state record's will limit to 256 the number of records that a given router can advertise. As the size of each record is limited to the maximum packet size supported by the network, this can prove to be a severe constraint."(1) Dr. Huitema goes on to state some advantages of OSPF over IS-IS: * Support of a backup designated router * Coexistence with RIP through "not-so-stubby-areas" [Okay, this ones a little dated] * OSPF is "change controlled" by the IETF, evolution of OSI Protocols was much slower and that it responded to many other forces besides user needs. Ron Johnson wrote: OSPF: Uses a multicast address and standard IP transport to carry it's packets. IS-IS: Uses it own transport method to carry it's packets. OSPF: Scales well when the Backbone/area/stub model is correctly implemented, otherwise with many routers in a single area, it can have a definite performance impact on routing convergence times. IS-IS: Is less sensitive to growth problems then OSPF. OSPF: Is easier to implement and understand. It is more widely used, and supported amongst many vendors. IS-IS: Is more arcane. Harder to implement and understand it's operation and behavior, and may not be supported on every router. So, the bottom line, for me is; Use OSPF V2, if you are building a network where you can create a "backbone" area and then other logical areas attached to the backbone. Then aggregate and summarize your route announcements in your areas and announce the summarized routes into the backbone area. You will end up with less routes in your IGP. Which in turn means lower OSPF recalculation times, better performance and a more stable IGP. References: (1)"Routing and the Internet" By: Christian Huitema (ISBN: 0131321927) (2)"OSPF Anatomy of an Internet Routing Protocol" By: John Moy (ISBN: 0201634724) "Routing TCP/IP Volume I" By: Jeff Doyle, CCIE (ISBN:1578700418) RFC2178 "OSPF Version 2" (http://www.faqs.org/rfcs/rfc2178.html) RFC1195 "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments" (http://www.faqs.org/rfcs/rfc1195.html) RFC1371 "Choosing a "Common IGP" for the IP Internet (The IESG's Recommendation to the IAB)" (http://www.faqs.org/rfcs/rfc1370.html) Previous NANOG Discussions on this topic: http://www.cctec.com/maillists/nanog/historical/9810/threads.html#00484 Other References I have yet to review: "Interconnections: Bridges and Routers" By: Radia Perlman (ISBN: 0201563320) "The Great IGP Debate--Part One:IS-IS and Integrated Routing." By: R. Perlman and R. Callon (ConneXions 5, no. 10, October 1991) "The Great IGP Debate--Part Two:The Open Shortest Path First (OSPF) Routing Protocol." (ConneXions 5, no. 10, October 1991) Dan Rabb Network digital broadcast network dan(a)dbn.net

5 4