January 2003 - Test - lists.nanog.org

Weird networking issue.
by Drew Weaver 08 Jan '03

08 Jan '03

Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver

5 5

RE: Weird networking issue.
by Braun, Mike 07 Jan '03

07 Jan '03

>> I think we all agree that autonegotiation is evil, and should be avoided >> whenever possible. When you are looking for the root cause of the errors on >I don't agree. I have seen more problems generated by incompetence in >trying to fix duplex/speed, than I have seen problems generated by autoneg >not working properly. >I am always amazed by the fact that very few people out there know that >you have to lock duplex at BOTH ENDS of any given link for it to work >properly. >Generally, in a LAN environment with good quality switches and good >network cards, autoneg works just fine. Yes, with 10/100 meg >fiber/converters converters you should definately lock duplex, but in most >other cases I recommend to leave the duplex setting to auto. I agree that with quality switches and network cards (ones supported by the manufacturer of the switch), you should be OK using autonegotiate in a desktop environment, but not in a sever environment or when interconnecting networking equipment. I've seen servers that initially autonegotiate fine, only to renegotiate later to a different speed or duplex setting; and in a production environment, that ends up costing money. The problems between Cisco and SUN have already been addressed in this thread. I have also seem problems between Cisco and Bay equipment. The bottom line is that if you need to take the guess work out of a connection, then lock up both ends. >Yes, cisco routers are notoriously bad at doing autoneg, but I blame that >on cisco and not on autoneg. The el cheapo $50 desktop switches seem to >hack autoneg just fine. I think that this stems from the folks at Cisco believing that they can dictate the standard for the IEEE 802.3u autonegotiation protocol (aka, their faith that isl will become the trunking standard of the future). "MMS <firstam.com>" made the following annotations on 01/07/03 15:33:08 ------------------------------------------------------------------------------ "THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM." ==============================================================================

1 0

RE: Weird networking issue.
by Jeffrey Wheat 07 Jan '03

07 Jan '03

Even Cisco states in some of their documentation that it is best to pin the interfaces to match both ends. I have had many a strange issue with auto negotiation depending on which side was up first. Additionally, TAC usually says to never trust auto negotiation. Regards, Jeff > -----Original Message----- > From: Braun, Mike [mailto:MBraun@firstam.com] > Sent: Tuesday, January 07, 2003 5:22 PM > To: nanog(a)merit.edu > Subject: RE: Weird networking issue. > > I think we all agree that autonegotiation is evil, and should > be avoided whenever possible. When you are looking for the > > -----Original Message----- > From: Peter E. Fry [mailto:pfry@swbell.net] > Sent: Tuesday, January 07, 2003 1:18 PM > To: nanog(a)merit.edu > Subject: Re: Weird networking issue. > > "David G. Andersen" wrote: > > > > Rule number 1 with any ethernet: Check to make sure you have the > > duplex and rate statically configured, and configured > identically on > > both ends of the connection. [...] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.435 / Virus Database: 244 - Release Date: 12/30/2002

1 0

RE: Weird networking issue.
by Charles Youse 07 Jan '03

07 Jan '03

By nature, a hub is half-duplex - it's a repeater. Besides, misconfigured duplex will not cause CRC errors. C. -----Original Message----- From: David G. Andersen [mailto:dga@lcs.mit.edu] Sent: Tuesday, January 07, 2003 2:08 PM To: Drew Weaver Cc: 'nanog(a)merit.edu' Subject: Re: Weird networking issue. Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. I'd wager you've got half duplex set on one side, and full on the other... -Dave On Tue, Jan 07, 2003 at 02:19:10PM -0500, Drew Weaver mooed: > > Hi, this is kind of a newbie question but this doesn't make a whole lot of > sense :P > > I have an etherstack hub connected to a FastEthernet port on a cisco 3660 > router, these are the stats when I do a show int fast0/0: > > 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored > > Whats weird is I just cleared the counters 12 minutes ago, and already there > are almost 6000 CRC errors. This connected via a standard Cat5 ethernet > cable, I have tried replacing the cable to noavail. > > Is this a fairly normal situation, If so that's great, but it seemed rather > ridiculous to me, and if it is not a normal situation, what would cause > this? > > Any ideas are appreciated. > Thanks, > -Drew Weaver -- work: dga(a)lcs.mit.edu me: dga(a)pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.

6 7

Co-location at MAE WEST
by Andrew Staples 07 Jan '03

07 Jan '03

I have an available cabinet at 55 Market Street 11th floor co-locate. If anyone is interested in space there, please let me know. It currently has a private 100mb fddi to the switch. Andrew Staples www.nwnetcom.com I am not a vegetarian because I love animals; I am a vegetarian because I hate plants. -- A. Whitney Brown

1 0

Re: Weird networking issue.
by Spencer.Wood＠dot.state.oh.us 07 Jan '03

07 Jan '03

Check the duplex setting for your FastEthernet Port on the Router and that on your Switch/Hub. Sounds like you might have a duplexing issue.. Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 ************************************************************* Drew Weaver <drew.weaver(a)thenap.com> Sent by: owner-nanog(a)merit.edu 01/07/2003 02:19 PM To: "'nanog(a)merit.edu'" <nanog(a)merit.edu> cc: Subject: Weird networking issue. Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver

1 0

RE: Weird networking issue.
by MPuras＠solunet.com 07 Jan '03

07 Jan '03

Check your duplex settigs you may also want to test with another cable. Thanks, Mario Puras SoluNet Technical Support Mailto: mpuras(a)solunet.com Direct: (321) 309-1410 888.449.5766 (USA) / 888.SOLUNET (Canada) -----Original Message----- From: Drew Weaver [mailto:drew.weaver@thenap.com] Sent: Tuesday, January 07, 2003 2:19 PM To: 'nanog(a)merit.edu' Subject: Weird networking issue. Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver

1 0

Re: COM/NET informational message
by Steve Dyer 07 Jan '03

07 Jan '03

At 17:00 07/01/2003 +0000, Verd, Brad wrote: >>This message explains an upcoming change in certain behavior of the >>com and net authoritative name servers related to internationalized >>domain names (IDNs). Hi, This is to inform you that Characterisation GmbH (www.characterisation.de) has patents pending Ref PCT/DE02/00632 filed 28th February 2001. It appears that the method of resolution used by VGRS in the announcement below uses this process. Characterisation GmbH is willing to discuss licence agreements. Best regards Stephen Dyer Geschäftsführender Gesellschafter Characterisation GmbH >>VeriSign Global Registry Services (VGRS) has been a longtime advocate >>of IDNs. Our IDN Test Bed has been active for over two years and we >>have followed and supported IETF developments in the IDN area. The >>protocol for IDNs developed by the IETF's IDN Working Group has been >>approved by the IESG and we anticipate that RFCs will be published >>soon. That protocol, Internationalizing Domain Names in Applications >>(IDNA), calls for changes to individual applications to support IDNs. >>VGRS has developed a plug-in, called i-Nav, for Microsoft's Internet >>Explorer browser to support IDNs in a manner consistent with IDNA. >>i-Nav is free and more information about it is available at >><<http://www.idnnow.com>>. >> >>Before IDNA, some application developers had developed proprietary >>mechanisms designed to support IDNs. The Internet Explorer browser, >>for example, sends a DNS query in UTF-8 or another, local encoding >>when a user types a domain name with characters other than letters, >>digits and the hypen in the address bar. These efforts, however, were >>not entirely successful. For example, if such a domain name ends in >>com or net these queries reach the com/net name servers and fail. >> >>Our research indicates that the average user expects IDNs to work but >>does not understand the need for additional software to support this >>functionality. Such users attempt to enter IDNs in their browsers, >>but when the queries fail, they become frustrated and do not know >>what action to take to enable IDNs. They are unaware that downloading >>a browser plug-in such as i-Nav would enable IDN resolution. >>To improve this user experience and to encourage the adoption of an >>application that supports IDNA, VGRS is announcing a measure intended >>to stimulate widespread distribution of the i-Nav plug-in. Starting >>on January 3, 2003, some queries to the com/net name servers that >>previously failed with a DNS Name Error (NXDOMAIN) response will >>instead return an address (A) record. Any queries for A records with >>at least one octet greater than decimal 127 in the second-level label >>will trigger this A record response. For example, a query for the A >>record for "foo?.com", where "?" represents an octet with a value >>greater than 127, would return an A record rather than NXDOMAIN >>response. The goal is to match unrecognized domain names generated by >>browsers attempting to resolve IDNs. Since browsers construct DNS >>queries for such IDNs using UTF-8 or a local encoding, and since >>these encodings use octets with all possible values (i.e., from 0 >>through 255), the presence of octets with values greater than 127 as >>described above can indicate a web browser's failed IDN resolution >>attempt. >> >>The A record that will be returned by VGRS points to a farm of web >>servers that will attempt to resolve the query. The browser that sent >>the original DNS query will connect to one of these web servers and >>its HTTP request will contain a Host header with the representation >>of the IDN originally entered by the user in the address bar. The web >>servers will attempt to interpret the contents of the Host header. If >>the Host header corresponds to an IDN registered in VeriSign's IDN >>Test Bed, the web server will return a page that gives the user an >>opportunity to download the free i-Nav plug-in. The page will also >>allow the user to navigate to the corresponding IDN web site via an >>HTTP redirect. If the contents of the Host header cannot be matched >>to an IDN registered in the Testbed, the web server will return an >>HTTP 404 response. >> >>If a user downloads and installs the i-Nav plug-in, his or her >>browser will convert any IDNs entered to ASCII compatible encoding >>(ACE) format, according to the method described in IDNA. As a result, >>subsequent DNS queries will use ASCII characters only. >>The user experience for web browsing will change only slightly from >>the current experience if the contents of the Host header cannot be >>interpreted. If the web farm cannot match the Host header to an IDN, >>the user will see an error page resulting from the HTTP 404 error >>returned, rather than an error page resulting from a DNS NXDOMAIN >>response. The web servers refuse connections on all other UDP and TCP >>ports, so other network services are minimally affected. >> >>The overriding goal is to improve Internet navigation by encouraging >>widespread adoption of software supporting the emerging IETF >>standards for IDNs. These measures allow distribution of such >>software. >> >>- -------- >>Brad Verd >>Resolution Systems Operations Manager >>VeriSign Global Registry Services >><<http://www.verisign-grs.com>> >>Email: bverd(a)verisign.com >>- -------- >> >> >>-----BEGIN PGP SIGNATURE----- >>Version: PGP 7.1 >> >>iQEVAwUBPhXOL/Al8hAO5uPhAQFASQgAuu9y0LF5/2SuddtdRNDbyUd9ccNkPwnw >>fip2bSh1EW7+b2jykw2tDxIAl2iejg2GVwhXmMiGOdm+FBOyBPtbQaM/DMCXHJ3r >>JlaEmKgqKwjyVHVxxEmNYHQ0uU5V8khskWorhsobjDb+l5bPumkUaGsVnRvTMFGR >>CZTrHdn1bo1Q0IvfD1IBCq5qUugRimLc47TZdibYccCty8TmdtL/8jz4r6W90JPL >>KxXdjMpk6SOQj1SqErV/S6ypd5TFpXi1fEv6QEIrsqVoMCdELjFRZbmDTAMObvcR >>MpS75jUWbNmO7KENJCyacWzLTkh951+dszszwYig9jGIIXEpmrYGFA== >>=g2df >>-----END PGP SIGNATURE----- > > >-- >Joel Rowbottom BSc.(Hons) - vaguely human and mostly harmless >Self-confessed was-kid, Unix geek & Net addict since 1991 >Personal: http://www.joel.co.uk | Pics: http://photos.jml.net >

1 0

RE: AT&T oddities tonight?
by Bulger, Tim 07 Jan '03

07 Jan '03

Thanks all for the replies.. Found out we were talking to the wrong NOC. It appears some maintenance they were doing has created nasty problems. Ticket number is 12537770. -----Original Message----- From: Bulger, Tim Sent: Monday, January 06, 2003 11:13 PM To: nanog(a)merit.edu Subject: AT&T oddities tonight? Has anyone else noticed any ususal oddities in AS7018 over the last half hour or so? I saw BGP advertisements flap en masse and we are still experiencing strange connectivity issues that reek of inconsistent CEF tables.. Their NOC claims there are no problems. Tracing the route to 159.153.226.19 1 12.119.156.21 [AS 7018] 0 msec 0 msec 0 msec 2 gbr1-p30.auttx.ip.att.net (12.123.133.54) [AS 7018] 4 msec 0 msec 0 msec 3 * * * 4 tbr2-p013701.sl9mo.ip.att.net (12.122.10.90) [AS 7018] 20 msec 20 msec 20 msec 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * Tracing the route to 159.153.226.20 1 12.119.156.21 [AS 7018] 0 msec 0 msec 4 msec 2 gbr1-p30.auttx.ip.att.net (12.123.133.54) [AS 7018] 0 msec 0 msec 4 msec 3 * * * 4 tbr2-p013701.sl9mo.ip.att.net (12.122.10.90) [AS 7018] 20 msec 20 msec 20 msec 5 tbr1-p012401.sl9mo.ip.att.net (12.122.9.141) [AS 7018] 20 msec 20 msec 20 msec 6 tbr1-p012401.wswdc.ip.att.net (12.122.10.65) [AS 7018] 36 msec 36 msec 36 msec 7 gbr5-p10.wswdc.ip.att.net (12.122.11.170) [AS 7018] 36 msec 36 msec 36 msec 8 gar3-p360.wswdc.ip.att.net (12.123.9.65) [AS 7018] 36 msec 36 msec 36 msec 9 gar1-p371.abnva.ip.att.net (12.123.217.2) [AS 7018] 40 msec 40 msec 36 msec 10 12.119.141.58 [AS 7018] 40 msec 36 msec 40 msec 11 159.153.224.218 [AS 7018] 36 msec 36 msec 36 msec Regards, Tim Bulger Senior Network Engineer Electronic Arts

1 0

Re: AT&T oddities tonight?
by Hank Nussbacher 07 Jan '03

07 Jan '03

At 11:13 PM 06-01-03 -0800, Bulger, Tim wrote: I suggest showing them the results of "sho ip bgp damp damp | incl 7018" from route-views.oregon-ix.net (or even from route-server.ip.att.net) I get close to 800 prefixes as being suppressed (some for up to an hour). More details can be seen via: "sho ip bgp damp flap reg 7018" -Hank >Has anyone else noticed any ususal oddities in AS7018 over the last half >hour or so? I saw BGP advertisements flap en masse and we are still >experiencing strange connectivity issues that reek of inconsistent CEF >tables.. Their NOC claims there are no problems. > > >Tracing the route to 159.153.226.19 > > 1 12.119.156.21 [AS 7018] 0 msec 0 msec 0 msec > 2 gbr1-p30.auttx.ip.att.net (12.123.133.54) [AS 7018] 4 msec 0 msec 0 msec > 3 * * * > 4 tbr2-p013701.sl9mo.ip.att.net (12.122.10.90) [AS 7018] 20 msec 20 > msec 20 msec > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * >Tracing the route to 159.153.226.20 > > 1 12.119.156.21 [AS 7018] 0 msec 0 msec 4 msec > 2 gbr1-p30.auttx.ip.att.net (12.123.133.54) [AS 7018] 0 msec 0 msec 4 msec > 3 * * * > 4 tbr2-p013701.sl9mo.ip.att.net (12.122.10.90) [AS 7018] 20 msec 20 > msec 20 msec > 5 tbr1-p012401.sl9mo.ip.att.net (12.122.9.141) [AS 7018] 20 msec 20 > msec 20 msec > 6 tbr1-p012401.wswdc.ip.att.net (12.122.10.65) [AS 7018] 36 msec 36 > msec 36 msec > 7 gbr5-p10.wswdc.ip.att.net (12.122.11.170) [AS 7018] 36 msec 36 msec > 36 msec > 8 gar3-p360.wswdc.ip.att.net (12.123.9.65) [AS 7018] 36 msec 36 msec 36 > msec > 9 gar1-p371.abnva.ip.att.net (12.123.217.2) [AS 7018] 40 msec 40 msec > 36 msec > 10 12.119.141.58 [AS 7018] 40 msec 36 msec 40 msec > 11 159.153.224.218 [AS 7018] 36 msec 36 msec 36 msec > > >Regards, >Tim Bulger >Senior Network Engineer >Electronic Arts

1 0