- Test - lists.nanog.org

Multi-Homed Swamp Space (was: Your class 'B' address space)
by William Allen Simpson 01 Oct '98

01 Oct '98

Catching up on NANOG, I could not resist responding here: > Date: Tue, 29 Sep 1998 10:08:34 -0700 (PDT) > From: Michael Dillon <michael(a)memra.com> > If the registries would start allocating address space that has been > recovered from the swamp to this sort of company, then the problem would > be solved. If a company needs multihoming capability but will never use > more than a /23 then what is wrong with reusing swamp space? > I just tried 2 weeks ago to reuse one of my own old swamp blocks (192.138.173.0) that had been out of production for a number of years. Upstreams are MCI and eSpire. Got it in the RR via MCI. Seems to have propagated into many other nets by the following day. But for some odd reason, SprintLink had problems and AOL never worked. After calling them, SprintLink began to route it, but it went away again the next morning. Access to AOL servers from dial-in equipment in that /24 block never completed a TCP handshake, despite that a traceroute seems to work (although it's hard to tell, as the AOL servers didn't respond on the last hop). After a few days, had to move into another MCI /24 block. Customers seem to want to talk to AOL, and vice versa.... :-( Anyway, looks like using swamp space for multi-homed nets and servers doesn't work. Too much hand configuration. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

Re: Is the .to (Tonga) domain completely rogue and should be removed?
by Dean Anderson 01 Oct '98

01 Oct '98

At 03:08 PM 9/30/98 -0500, Sam Hayes Merritt, III wrote: >On Wed, 30 Sep 1998, Barry Shein wrote: > >> We've been having increasing problems with one or more porn sites in >> the .to domain promoting itself by massive spamming of AOL customers >> using one of our domains in their From: header thus causing both >> complaints to us and thousands of bounces from AOL due to bad AOL >> addresses in their spam lists. About a year ago, I asked Vixie if he would RBL porn sites. I might have supported the RBL if there were a moral high ground. He said no. --Dean P.S. Barry, I do feel sorry for you. Perhaps you should just refuse spam complaints, and try to get them to stop using your domains. Instead of stealing a domain, all the spammers need to do is change their addresses to uucp style addresses, and their mail will likely be accepted, and bounces shouldn't leave the system. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Re: Is the .to (Tonga) domain completely rogue and should be removed?
by Steven J. Sobol 01 Oct '98

01 Oct '98

[ In reply to a private message from Jeremy Porter. ] > Maybe you should post a clarification that you do not feel RBL is > the same a terriorism. That is certainly the appearance you gave. > In all the messages in the thread posted to nanog my was the only > replace that suggested solutions, and it was on topic. Done. Yes, when I mentioned the T-word, I was not refering to the RBL. The RBL is voluntary and allows people to deny others access to THEIR OWN machines. It has nothing to do with people trying to deny others access to machines the perpetrators do NOT own - that is what I take issue with. > Your accusations of terrorism, stupidity and your pity are not > needed on Nanog, perhaps on other mailing lists such comments are > reasonable. I see absolutely no call for you to be advocating denial of service attacks anywhere - and ESPECIALLY not on NANOG, where everyone *knows better anyhow*. The knife cuts both ways. I hope no one using an nstc.com account, or an account at my upstream, ever even comes close to getting you upset because it sounds like in a situation like that, you would advocate a DoS attack against the network involved. I'm sorry, but I am not retracting my statement that that IS terrorism, and there is absolutely no call for it, and if you commit a DoS attack you deserve whatever sanctions you get hit with, either by your upstream or the law. Period. -- Anyone who spams me will be subject to torture by Jake, my killer attack hedgehog, and/or Lizzy and Junior, my man-eating iguanas.

2 2

Re: Is the .to (Tonga) domain completely rogue and should be removed?
by Dean Anderson 01 Oct '98

01 Oct '98

>The simple question here is: who are you to tell a sovereign country what >it can and what it cannot do? hahhahshhahahhaha!! Well put. Anti-spammers make up whatever laws or exemptions to laws they have to. Thats all they need. Thats why they can't be trusted. Fire your anti-spammers before they do something you'll regret... Anyway, I'm laughing too hard (rolling in my chair, knocked the keyboard on the floor) to contribute anything more without endangering safety or equipment... --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

InterNIC modification
by william＠pacific.net.ph 01 Oct '98

01 Oct '98

Hi all! Is it Internic becoming slower in their modifications? We have sent a modification request twice and until now - nothing has happened.... William ---------- Forwarded message ---------- Date: Thu, 24 Sep 1998 20:24:48 -0400 (EDT) From: Domain Registration Role Account <domreg(a)internic.net> To: armand(a)shell.egis.net Subject: Re: [NIC-980924.46494] Re: MODIFY DOMAIN dwrt.com Your request NIC-980924.46494 for [NIC-980924.46494] Re: MODIFY DOMAIN dwrt.com. could not be automatically processed. The request has been queued for manual processing. It will be processed within 5 business days. InterNIC Registration Services email hostmaster(a)internic.net voice (703) 742-4777 ============================================================ >From armand(a)shell.egis.net Thu Sep 24 16:48:22 1998 >Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) > by mail-hub.internic.net (8.9.1/8.9.1) with ESMTP id QAA04873 > for <hostmaster(a)mail-hub.internic.net>; Thu, 24 Sep 1998 16:48:21 -0400 (EDT) >Received: from biprrs3.lb (biprrs3.lb.internic.net [192.168.120.41]) > by opsmail.internic.net (8.9.1/8.9.1) with SMTP id QAA16745 > for <hostmaster(a)internic.net>; Thu, 24 Sep 1998 16:47:54 -0400 (EDT) >Received: (qmail 23915 invoked from network); 24 Sep 1998 05:58:06 -0000 >Received: from unknown (HELO shell.egis.net) (202.163.235.6) > by 192.168.119.41 with SMTP; 24 Sep 1998 05:58:06 -0000 >Received: by shell.egis.net (Smail3.1.29.1 #57) > id m0zMFSJ-001SlLC; Thu, 24 Sep 98 13:45 EDT >Date: Thu, 24 Sep 1998 13:45:27 -0400 (EDT) >From: Armand Hernandez <armand(a)shell.egis.net> >To: hostmaster(a)internic.net >Subject: [NIC-980924.46494] Re: MODIFY DOMAIN dwrt.com >In-Reply-To: <199809240552.BAA17662(a)rrs2.lb.internic.net> >Message-ID: <Pine.LNX.3.90.980924134523.9387A-100000(a)shell.egis.net> >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >X-MTS-Ticket: 980924.46494 >X-MTS-Type: Domain >X-MTS-Mode: Modify >X-MTS-Priority: Normal >X-MTS-Status: Open >X-MTS-Timestamp: 980924164822 > > > > >On Thu, 24 Sep 1998 hostmaster(a)internic.net wrote: > >> ---------------------------------------------------- >> This is the Domain Name Registration Agreement you >> recently created. >> In order to complete this modification, >> >> YOU MUST E-MAIL THIS FORM TO: hostmaster(a)internic.net >> >> After you e-mail this form, you should receive an auto-reply >> with a tracking number. You must use that number in the >> Subject of any future messages you send regarding >> this registration action. >> Once this registration action is completed you will receive >> a notification via e-mail. >> >> [ URL http://rs.internic.net/cgi-bin/domain ] [ 03/98 ] >> [ URL ftp://rs.internic.net/templates/domain-template.txt ] [ 03/98 ] >> >> ******* Please DO NOT REMOVE Version Number or Sections A-Q ******** >> >> Domain Version Number: 4.0 >> >> ******* Email completed agreement to hostmaster(a)internic.net ******* >> >> NETWORK SOLUTIONS, INC. >> >> DOMAIN NAME REGISTRATION AGREEMENT >> >> >> A. Introduction. This domain name registration agreement >> ("Registration Agreement") is submitted to NETWORK SOLUTIONS, INC. >> ("NSI") for the purpose of applying for and registering a domain name >> on the Internet. If this Registration Agreement is accepted by NSI, >> and a domain name is registered in NSI's domain name database and >> assigned to the Registrant, Registrant ("Registrant") agrees to be >> bound by the terms of this Registration Agreement and the terms of >> NSI's Domain Name Dispute Policy ("Dispute Policy") which is >> incorporated herein by reference and made a part of this Registration >> Agreement. This Registration Agreement shall be accepted at the >> offices of NSI. >> >> B. Fees and Payments. >> >> 1) Registration or renewal (re-registration) date through March 31, 1998: >> Registrant agrees to pay a registration fee of One Hundred United States >> Dollars (US) as consideration for the registration of each new domain >> name or Fifty United States Dollars (US) to renew (re-register) an >> existing registration. >> 2) Registration or renewal date on and after April 1, 1998: Registrant >> agrees to pay a registration fee of Seventy United States Dollars (US) >> as consideration for the registration of each new domain name or the >> applicable renewal (re-registration) fee (currently Thirty-Five United >> States Dollars (US)) at the time of renewal (re-registration). >> 3) Period of Service: The non-refundable fee covers a period of two (2) >> years for each new registration, and one (1) year for each renewal, >> and includes any permitted modification(s) to the domain name record >> during the covered period. >> 4) Payment: Payment is due to Network Solutions within thirty (30) >> days from the date of the invoice. >> >> C. Dispute Policy. Registrant agrees, as a condition to >> submitting this Registration Agreement, and if the Registration >> Agreement is accepted by NSI, that the Registrant shall be bound by >> NSI's current Dispute Policy. The current version of the Dispute >> Policy may be found at the InterNIC Registration Services web site: >> "http://www.netsol.com/rs/dispute-policy.html". >> >> D. Dispute Policy Changes or Modifications. Registrant agrees >> that NSI, in its sole discretion, may change or modify the Dispute >> Policy, incorporated by reference herein, at any time. Registrant >> agrees that Registrant's maintaining the registration of a domain name >> after changes or modifications to the Dispute Policy become effective >> constitutes Registrant's continued acceptance of these changes or >> modifications. Registrant agrees that if Registrant considers any such >> changes or modifications to be unacceptable, Registrant may request >> that the domain name be deleted from the domain name database. >> >> E. Disputes. Registrant agrees that, if the registration of its >> domain name is challenged by any third party, the Registrant will be >> subject to the provisions specified in the Dispute Policy. >> >> F. Agents. Registrant agrees that if this Registration Agreement >> is completed by an agent for the Registrant, such as an ISP or >> Administrative Contact/Agent, the Registrant is nonetheless bound as a >> principal by all terms and conditions herein, including the Dispute >> Policy. >> >> G. Limitation of Liability. Registrant agrees that NSI shall have >> no liability to the Registrant for any loss Registrant may incur in >> connection with NSI's processing of this Registration Agreement, in >> connection with NSI's processing of any authorized modification to the >> domain name's record during the covered period, as a result of the >> Registrant's ISP's failure to pay either the initial registration fee >> or renewal fee, or as a result of the application of the provisions of >> the Dispute Policy. Registrant agrees that in no event shall the >> maximum liability of NSI under this Agreement for any matter exceed >> Five Hundred United States Dollars (US). >> >> H. Indemnity. Registrant agrees, in the event the Registration >> Agreement is accepted by NSI and a subsequent dispute arises with any >> third party, to indemnify and hold NSI harmless pursuant to the terms >> and conditions contained in the Dispute Policy. >> >> I. Breach. Registrant agrees that failure to abide by any >> provision of this Registration Agreement or the Dispute Policy may be >> considered by NSI to be a material breach and that NSI may provide a >> written notice, describing the breach, to the Registrant. If, within >> thirty (30) days of the date of mailing such notice, the Registrant >> fails to provide evidence, which is reasonably satisfactory to NSI, >> that it has not breached its obligations, then NSI may delete >> Registrant's registration of the domain name. Any such breach by a >> Registrant shall not be deemed to be excused simply because NSI did >> not act earlier in response to that, or any other, breach by the >> Registrant. >> >> J. No Guaranty. Registrant agrees that, by registration of a >> domain name, such registration does not confer immunity from objection >> to either the registration or use of the domain name. >> >> K. Warranty. Registrant warrants by submitting this Registration >> Agreement that, to the best of Registrant's knowledge and belief, the >> information submitted herein is true and correct, and that any future >> changes to this information will be provided to NSI in a timely manner >> according to the domain name modification procedures in place at that >> time. Breach of this warranty will constitute a material breach. >> >> L. Revocation. Registrant agrees that NSI may delete a >> Registrant's domain name if this Registration Agreement, or subsequent >> modification(s) thereto, contains false or misleading information, or >> conceals or omits any information NSI would likely consider material >> to its decision to approve this Registration Agreement. >> >> M. Right of Refusal. NSI, in its sole discretion, reserves the >> right to refuse to approve the Registration Agreement for any >> Registrant. Registrant agrees that the submission of this Registration >> Agreement does not obligate NSI to accept this Registration Agreement. >> Registrant agrees that NSI shall not be liable for loss or damages >> that may result from NSI's refusal to accept this Registration >> Agreement. >> >> N. Severability. Registrant agrees that the terms of this >> Registration Agreement are severable. If any term or provision is >> declared invalid, it shall not affect the remaining terms or >> provisions which shall continue to be binding. >> >> O. Entirety. Registrant agrees that this Registration Agreement >> and the Dispute Policy is the complete and exclusive agreement between >> Registrant and NSI regarding the registration of Registrant's domain >> name. This Registration Agreement and the Dispute Policy supersede all >> prior agreements and understandings, whether established by custom, >> practice, policy, or precedent. >> >> P. Governing Law. Registrant agrees that this Registration >> Agreement shall be governed in all respects by and construed in >> accordance with the laws of the Commonwealth of Virginia, United >> States of America. By submitting this Registration Agreement, >> Registrant consents to the exclusive jurisdiction and venue of the >> United States District Court for the Eastern District of Virginia, >> Alexandria Division. If there is no jurisdiction in the United States >> District Court for the Eastern District of Virginia, Alexandria >> Division, then jurisdiction shall be in the Circuit Court of Fairfax >> County, Fairfax, Virginia. >> >> Q. This is Domain Name Registration Agreement Version >> Number 4.0. This Registration Agreement is only for registrations >> under top-level domains: COM, ORG, NET, and EDU. By completing >> and submitting this Registration Agreement for consideration and >> acceptance by NSI, the Registrant agrees that he/she has read and >> agrees to be bound by A through P above. >> >> Authorization >> 0a. (N)ew (M)odify (D)elete.........: M >> 0b. Auth Scheme.....................: >> 0c. Auth Info.......................: >> >> 1. Comments........................: >> >> 2. Complete Domain Name............: dwrt.com >> >> Organization Using Domain Name >> 3a. Organization Name................: 99.5 RT >> 3b. Street Address..................: 14/F JAKA (Royal Match) Bldg., 6780 Ayala Avenue >> 3c. City............................: Makati >> 3d. State...........................: MM >> 3e. Postal Code.....................: 1200 >> 3f. Country.........................: PH >> >> Administrative Contact >> 4a. NIC Handle (if known)...........: JRL17 >> 4b. (I)ndividual (R)ole?............: Individual >> 4c. Name (Last, First)..............: >> 4d. Organization Name...............: >> 4e. Street Address..................: >> 4f. City............................: >> 4g. State...........................: >> 4h. Postal Code.....................: >> 4i. Country.........................: >> 4j. Phone Number....................: >> 4k. Fax Number......................: >> 4l. E-Mailbox.......................: >> >> Technical Contact >> 5a. NIC Handle (if known)...........: JRL17 >> 5b. (I)ndividual (R)ole?............: Individual >> 5c. Name(Last, First)...............: >> 5d. Organization Name...............: >> 5e. Street Address..................: >> 5f. City............................: >> 5g. State...........................: >> 5h. Postal Code.....................: >> 5i. Country.........................: >> 5j. Phone Number....................: >> 5k. Fax Number......................: >> 5l. E-Mailbox.......................: >> >> Billing Contact >> 6a. NIC Handle (if known)...........: JRL17 >> 6b. (I)ndividual (R)ole?............: Individual >> 6c. Name (Last, First)..............: >> 6d. Organization Name...............: >> 6e. Street Address..................: >> 6f. City............................: >> 6g. State...........................: >> 6h. Postal Code.....................: >> 6i. Country.........................: >> 6j. Phone Number....................: >> 6k. Fax Number......................: >> 6l. E-Mailbox.......................: >> >> Prime Name Server >> 7a. Primary Server Hostname.........: NS1.PACIFIC.NET.PH >> 7b. Primary Server Netaddress.......: 210.23.234.33 >> >> Secondary Name Server(s) >> 8a. Secondary Server Hostname.......: NS2.PACIFIC.NET.PH >> 8b. Secondary Server Netaddress.....: 210.23.234.65 >> >> >> END OF AGREEMENT >> >> >> For instructions, please refer to: >> "http://rs.internic.net/help/instructions.txt" >> >>

7 9

.cc domain spam
by Jon Lewis 30 Sep '98

30 Sep '98

Are others being spammed on their NIC contact addresses by domainspace.com trying to sell .cc domains? Received: from domainspace.com ([209.203.244.14]) by yoda.fdt.net with ESMTP id UAA01623 for <jlewis(a)FDT.NET>; Fri, 25 Sep 1998 20:19:03 -0400 ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

14 20

Fiber outage for BBN 29 Sep
by Andy McConnell 30 Sep '98

30 Sep '98

Curious - no one seemed to mention BBN Planet's "major" fiber cut yesterday. Their trouble system "shortcutted" calls to an automated message saying there were two major cuts in the Texas and Washington DC area. their ticket was #273439. As a BBN customer, we had trouble getting out of BBN all morning, and by early afternoon things were fine. Did anyone on the list see this sort of trouble? -Andy -- Andy McConnell アンディマッコネル Network Architect, NTT Multimedia Communications Laboratories Freedom means that, in time of war, good men and women will be asked to risk their lives because we think it better to die free than to live as slaves.

2 1

1997 Fiber Deployment Update Report Available
by Simon Leinen 30 Sep '98

30 Sep '98

FYI, I just noticed that this had been put on the FCC Web server earlier this month, see http://www.fcc.gov/Bureaus/Common_Carrier/Reports/FCC-State_Link/infra.html -- Simon.

1 0

Re: UDP packet/DNS server
by Roeland M.J. Meyer 30 Sep '98

30 Sep '98

Yeah, and if you do then sendmail will be broken, according to the v8.9.1 dox. It's called a wild-card MX record and is specifically not recommended, more than once, in the sendmail dox. I actually had NetCom tech support recommend it once, then I found out why it's not recommended, the hard way. When it comes to DNS, you're *much* better off by being specific, even if it means being verbose. At 10:39 AM 9/30/98 +0900, Tatsuya Kawasaki wrote: >Eric, > >thank for your reply. Though I did not agree with RFC I understand >what you are saying. >Do you think it is about time to change RFC? > >BTW, according to NDS and BIND 2nd Ed. by O'Reilly, it is okay for >MX record too. :-) > >TIA, >Tatsuya > >$B$+$o$5$-(B >TK3197 > >= = = = = = >Business Network Telecom (BNT) >$B%S%8%M%9%M%C%H%o!<%/%F%l%3%`3t<02q<R(B >$B")(B111-0053$B!!El5~ETBfEl6h@uAp66(B3-8-5 >31$B;35~%S%k(B6$B3,(B >TEL 03-5687-3945 FAX 03-5687-6009 >http://www.giganet.net > >On Tue, 29 Sep 1998, Eric Sobocinski wrote: > >> But it's perfectly ok for PTR records, though perhaps your example is less >> than ideal. The objection to the use of "*" was specific to NS records. >> An NS record should exist for a domain only if that domain exists. Since >> "*" matches any subdomain whether the domain exists or not, an NS record >> will be returned for non-existent subdomains and that violates the rule. >> Some records of other types are incompatible with "*" for similar reasons. >> The major point here is that any DNS record should reference either a valid >> response or another record that will lead to a response, and an NS record >> pointing to a zone file that doesn't exist is neither. >> >> Some folks will contend that the use of "*" in PTR records is bad form even >> though it is legal. That's a religious war, not a technical one. (I >> happen to like the use of "*", though I also believe that one should first >> apply specific host names whenever a static mapping allows). >> >> >> On Monday, 28 Sep 1998 at 21:02 EDT, Eric Germann wrote: >> > >> >you have to admit, it does save one hell of a lot of typing for the 1918 >> >IN-ADDR.ARPA delegations. >> > >> >rfc1918.db >> >---------- >> > >> >@ IN SOA ns1.xxx.net. hostmaster.xxx.net. ( >> > 1997101001 ; serial >> > 300 ; refresh >> > 300 ; retry >> > 604800 ; expire >> > 600) ; minimum >> > >> > IN NS ns1.xxx.net. >> > IN NS ns2.xxx.net. >> > >> > >> >* IN PTR rfc1918.xxx.net. >> >----------- >> > >> >then in named.bt >> > >> >primary 16.172.in-addr.arpa RFC1918.DB >> >primary 17.172.in-addr.arpa RFC1918.DB >> >primary 18.172.in-addr.arpa RFC1918.DB >> >primary 19.172.in-addr.arpa RFC1918.DB >> >primary 20.172.in-addr.arpa RFC1918.DB >> >primary 21.172.in-addr.arpa RFC1918.DB >> >primary 22.172.in-addr.arpa RFC1918.DB >> >primary 23.172.in-addr.arpa RFC1918.DB >> >primary 24.172.in-addr.arpa RFC1918.DB >> >primary 25.172.in-addr.arpa RFC1918.DB >> >primary 26.172.in-addr.arpa RFC1918.DB >> >primary 27.172.in-addr.arpa RFC1918.DB >> >primary 28.172.in-addr.arpa RFC1918.DB >> >primary 29.172.in-addr.arpa RFC1918.DB >> >primary 30.172.in-addr.arpa RFC1918.DB >> >primary 31.172.in-addr.arpa RFC1918.DB >> > >> >repeat for 10.x.x.x and 192.168 space >> > >> >To reiterate the question posed by the original poster, (donning asbestos), >> >why is this bad? >> > >> >Eric >> > >> > >> >At 08:31 AM 9/28/98 -0500, you wrote: >> >>Tatsuya Kawasaki wrote: >> >>>xyz.com. IN NS that.host >> >>>*.xyz.com In NS that.host >> >> >> >>Gah!! >> >> >> >>Illegal! >> >> >> >>Never use "*" in DNS! Just makes /bad things/ happen. >> >> >> >>@ IN SOA xyz.com. hostmaster.xyz.com. ( >> >> 1998092801 3600 1800 3600000 7200) >> >> >> >> ns ns1.xyz.com. >> >> ns ns2.xyz.com. >> >> >> >> mx 0 mail.xyz.com. >> >> >> >>mail a 1.2.3.4 >> >> mx 0 mail >> >> >> >>. etc .. >> >> >> >>-- >> >>jamie rishaw (efnet:gavroche) American Information Systems, >> >Inc. >> >> Tel:312.425.7140, FAX:312.425.7240 >> >> Help stop spam! router(config)#no ip routing >> >> thirty thousand feet above the earth..youre a beautiful thing.. >> >> >> > >> >========================================================================== >> > Eric Germann CCTec >> > ekgermann(a)cctec.com Van Wert, OH 45891 >> > http://www.cctec.com Ph: 419 968 2640 >> > Fax: 419 968 2641 >> > Network Design, Connectivity & System Integration Services >> > A Microsoft Solution Provider >> > >> > ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ I bet the human brain is a kludge. -- Marvin Minsky

1 0

Re: Thanks WAS: any cisco experienced...
by barton＠cent.net 30 Sep '98

30 Sep '98

Sorry if this is the wrong topic for NANOG but some mis-information needs to be fixed before it spreads any further. >I appreciate the assistance several of you provided. As it turns out the >image that was installed on the flash was a compressed image only for the >1605, and not for the 1601-1604 routers. It looks like someone at RMA >inadvertantly loaded the wrong software to flash, and it ended up throwing >most off guard. I knew it had to be something simple. WRONG, WRONG, WRONG. NOT just for 1605. It is a perfectly fine image and one I would routinely recommend for any 1601-1604 user, but you *MUST* understand the implications of running it. You don't mind running about 35% faster, I would assume, as that is what you can now do. You have loaded an image that has to load into DRAM and then self decompresses. Multiple 3rd party toolkits do this routinely for 25xx routers if someone needs more squeeze that an Unix .Z image provides to wedge a recent IOS into FLASH. Sadly the 1601's bootstrap has a **BUG** that precludes running mere .Z images, but then cisco came out with the 1605 and with it came cisco provided -mz images - to everyone's joy. The 1601-1604 have only 2 meg soldered in, so adding a 16 meg non-parity simm ($15 or so these days) only gets you to 18 meg. Not enough for the monster largest images and still leave enough for buffers and tables. Marketing decided to not let the customers only needing some smaller image know you can just as well run from DRAM. Usual cisco arrogance. "keep them stupid - they still pay $1000 for 16 meg DRAM which proves it" So they made the 1605 with 8 meg soldered in. That with a 16meg SIMM is enough to run any image in DRAM and still leave enough for other things. BUY A $15 (or $25 if someone is ripping you off, or $1000 if you are being "ciscoed") 16 meg DRAM simm and your box with the -mz image will not only boot but will run 35% faster than running from FLASH. And, with FLASH left (READ/WRITE), updates are trivial on a running router. This has been rehashed repeatedly on c.d.s.c. Check an archive. >For the record in the 1600-series world.. images with c1600-mz* are >compressed and will only work on the 1605 model. NO NO! - only will work in a 16xx router with adequate DRAM, but since you can MAX that box for a $15 16 meg DRAM SIMM, this is hardly a problem. >Images with c1600-l* are for the 1601-1604 models and are not compressed. Unless someone uses one of the available toolkits to make a -mz. Using a unix compressed .Z image ***SHOULD*** be ok but there is a good old fashioned *BUG* is their boot code. The TAC says so, too (I can probably dig out an old case number if really pressed). Now that cisco ships the -mz images for 1605s, every 16xx should be running them. Many many 25xx users run .Z or -mz images and cisco's code says "wrong image type" which everyone doing this simply ignores.

1 0