CC-TLD .af
Hello all, does anybody knows the NIC for Afghanistan ? I have to register a domain in the com.af, but I couldn't find any registrar who can help. I did try to contact [EMAIL PROTECTED], that is listed as the sponsor for the CC-TLD .af, but I don't get any reply. Any information regarding CC-TLD .af will be greatly appreciated. thanks, Muljawan
Re: CC-TLD .af
On Tuesday 7 January 2003, at 16 h 40, Hendrianto Muljawan [EMAIL PROTECTED] wrote: I have to register a domain in the com.af, but I couldn't find any registrar who can help. Giving the situation in Afghanistan, I wish you good luck. I did try to contact [EMAIL PROTECTED], that is listed as the sponsor for the CC-TLD .af, but I don't get any reply. And the administrative contact? Of course, because of the incredible amount of time it takes for ICANN to update its database, it is probably outdated but did you try?
Re: CC-TLD .af
On Tue, Jan 07, 2003 at 09:51:21AM +0100, Stephane Bortzmeyer wrote: I have to register a domain in the com.af, but I couldn't find any registrar who can help. Giving the situation in Afghanistan, I wish you good luck. ;; QUESTION SECTION: ;af.IN SOA ;; ANSWER SECTION: af. 28800 IN SOA ns1.nic.af. hostmaster.nic.af. 8597 86400 7200 2592000 21600 ;; AUTHORITY SECTION: af. 28800 IN NS ns1.nic.af. af. 28800 IN NS ns2.nic.af. ns1.nic.af is hosted by netbenefit.co.uk maybe its worth dropping their hostmaster an email ? -Subhi -- Subhi S Hashwa *** [EMAIL PROTECTED] --- When everything's coming your way, you're in the wrong lane.
Re: COM/NET informational message
At 17:00 07/01/2003 +, 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
Re: COM/NET informational message
At 17:40 07/01/2003 +, Steve Dyer wrote: This is to inform you that Characterisation GmbH (www.characterisation.de) has patents pending Ref PCT/DE02/00632 filed 28th February 2001. CentralNic have actually been working with this system for around 12 months now, and it's pretty cool. It works with a lot more browsers than the VGRS one, and requires no client or server-side plugins or patches :) It's really rather good at providing a seamless end-to-end IDN solution for web browsers; granted there are problems with Squid and such, but any IDN solution will have problems with things which filter. Personally I think it's a good transition for IDNs - but then again I've said that before ;) BR j -- Joel Rowbottom, http://www.centralnic.com - CTO and self-confessed Unix geek t +44 (0)20 7751 9000 f +44 (0)20 7736 9253 e [EMAIL PROTECTED] # Note: Contents may not necessarily represent the opinions of CentralNic.
Re: COM/NET informational message
CentralNic have actually been working with this system for around 12 months now, and it's pretty cool. It works with a lot more browsers than the VGRS one, and requires no client or server-side plugins or patches :) It's really rather good at providing a seamless end-to-end IDN solution for web browsers; granted there are problems with Squid and such, but any IDN solution will have problems with things which filter. Personally I think it's a good transition for IDNs - but then again I've said that before ;) Have you looked at RFC 2026?
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
Re: Weird networking issue.
Hi there, no that is not normal. How long is the cat5 between the two? Also, with a hub you should normally see collisions but not crc errors. On Tue, 7 Jan 2003, Drew Weaver wrote: 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
RE: Weird networking issue.
Check your duplex settigs you may also want to test with another cable. Thanks, Mario Puras SoluNet Technical Support Mailto: [EMAIL PROTECTED] Direct: (321) 309-1410 888.449.5766 (USA) / 888.SOLUNET (Canada) -Original Message- From: Drew Weaver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:19 PM To: '[EMAIL PROTECTED]' 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
RE: Weird networking issue.
Title: RE: Weird networking issue. 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:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:08 PM To: Drew Weaver Cc: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
Co-location at MAE WEST
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
RE: Weird networking issue.
Sun's hme cards won't go full duplex even though they advertise it to remote switch, causing immense headaches to anyone with Sun gear... http://www.eng.auburn.edu/~rayh/solaris/solaris2-faq.html#q4.13 -alex On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: Heh. Tell that to my Catalyst 3548's and the E250's at the other end. ;) Lab testing showed serious throughput issues though (expected) in duplex-mismatched links, and large increases in runt and mutli-collision counters. CRC errors and FCS errors also rose in proportion to relative link saturation in a more simplistic 6500 -7509- 3548 test environment. Besides, misconfigured duplex will not cause CRC errors. C. -Original Message- From: David G. Andersen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:08 PM To: Drew Weaver Cc: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
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. [...] I'd like to thank Cisco for this piece of advice, as the only company incapable of manufacturing Ethernet equipment capable of autonegotiation. At least until 1999 or so. Yeah, there're a few others, all of which seemed to follow Cisco's lead. Nutty. Peter E. Fry
RE: Weird networking issue.
On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: Sun's hme cards won't go full duplex even though they advertise it to remote switch, causing immense headaches to anyone with Sun gear... That is just not true. I've had several Sun boxes with hme interfaces properly autoneg into 100/full with misc equipment, including 3548:s, and working properly. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Weird networking issue.
On Tue, 7 Jan 2003, Charles Youse wrote: Besides, misconfigured duplex will not cause CRC errors. Yes it will. It will cause CRC errors/RX underflows/RX frags/RX align on one end and late collissions on the other end depending on which one is running half duplex and which one is running full duplex. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Weird networking issue.
### On Tue, 7 Jan 2003 22:32:15 +0100 (CET), Mikael Abrahamsson ### [EMAIL PROTECTED] casually decided to expound upon '[EMAIL PROTECTED]' ### [EMAIL PROTECTED] the following thoughts about RE: Weird networking ### issue.: MA On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: MA MA Sun's hme cards won't go full duplex even though they advertise it to MA remote switch, causing immense headaches to anyone with Sun gear... MA MA That is just not true. I've had several Sun boxes with hme interfaces MA properly autoneg into 100/full with misc equipment, including 3548:s, and MA working properly. Ditto. I'm currently sitting at my workstation (Sun Ultra2) and its hme0 autonegotiates fine with my Cisco 3524XL each and every time. I don't even have to pin any of the interfaces to 100/full. Admittedly I have had problems in the past, namely a bunch of E4500s to some 5000-series switches. Since they were in remote datacenters, I did pin the interfaces on both ends. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Weird networking issue.
On Tue, 7 Jan 2003, Jake Khuon wrote: problems in the past, namely a bunch of E4500s to some 5000-series switches. Since they were in remote datacenters, I did pin the interfaces on both ends. I've seen problems with 3548:s and Sun le-interfaces though, sometimes the link would only see packets going one way on the link, also the behaviour was different on the lower and upper row of ports on the 3548. I have never seen any of these problems with other brands of switches. We solved it by putting a dumb 10megabit hub between the Sun le-interface and the cisco switch. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Weird networking issue.
At 10:32 PM 1/7/2003 +0100, Mikael Abrahamsson wrote: On Tue, 7 Jan 2003 [EMAIL PROTECTED] wrote: Sun's hme cards won't go full duplex even though they advertise it to remote switch, causing immense headaches to anyone with Sun gear... That is just not true. I've had several Sun boxes with hme interfaces properly autoneg into 100/full with misc equipment, including 3548:s, and working properly. -- Mikael Abrahamssonemail: [EMAIL PROTECTED] The behavior I've seen in the past is Sun gear negotiating properly when plugged into Cisco gear that is already running. If you power cycle the switch with the servers already attached the port will not negotiate correctly... usually to half duplex. Also I've seen duplex problems in the past week that caused, runts, giants, collisions, CRCs, errors of all sorts, kernel module reloads, vlan tagging failure, and depletion of the ozone layer. Or maybe is was reality tv that caused that ozone thing... Ramin
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 root cause of the errors on your 3660, look at the speed and duplex settings for each device connecting to the etherstack hub. If one of those is miss-configured or possibly has a failing NIC, bad packets will be transmitted out all ports on the hub and will show up in the show int f0/0 output on your router. Mike Braun -Original Message- From: Peter E. Fry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 1:18 PM To: [EMAIL PROTECTED] 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. [...] I'd like to thank Cisco for this piece of advice, as the only company incapable of manufacturing Ethernet equipment capable of autonegotiation. At least until 1999 or so. Yeah, there're a few others, all of which seemed to follow Cisco's lead. Nutty. Peter E. Fry MMS firstam.com made the following annotations on 01/07/03 14:22:30 -- 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. ==
Scaled Back Cybersecuruty
This may be of interst: AP: Bush Expected to Sign Scaled Back Internet Security Plan Washington, DC -- A new Bush administration plan aimed at improving the security of key U.S. computer networks will not be as ambitious as previously indicated, the Associated Press reported on Tuesday. The plan is being closely watched by network security firms in the DC area. A draft of the proposal, called the National Strategy to Secure Cyberspace, obtained by the AP contains only 49 of the 86 initiatives of an earlier version, eliminating such mandates as regular consultations with privacy experts about civil liberties and a call for corporations to improve cybersecurity. Instead, it focuses on the security of federal agencies; it also makes clear that the Defense Department can engage in cyber warfare should the U.S. be attacked. The job of improving Internet security, however, would be handled by the new Homeland Security Department, which would launch test attacks against various agencies and seek to improve automated systems that operate water, chemical and electrical networks. Bush is expected to sign the plan in the coming weeks. http://www.washingtonpost.com/wp-dyn/articles/A18662-2003Jan6.html
RE: Weird networking issue.
On Tue, 7 Jan 2003, Braun, Mike wrote: 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. 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. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Weird networking issue.
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:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 5:22 PM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 1:18 PM To: [EMAIL PROTECTED] 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
Re: Weird networking issue.
Peter E. Fry wrote: [...] the only [...] Yeah, *that* is a nutty statement. I could re-phrase, but I think most here get the intent. Peter E. Fry
Re: COM/NET informational message
At 18:07 07/01/2003 +, Neil J. McRae wrote: CentralNic have actually been working with this system for around 12 months Have you looked at RFC 2026? Yes, and I'd be interested to find out where in my email you read the word Standard. BR j x -- Joel Rowbottom, http://www.centralnic.com - CTO and self-confessed Unix geek t +44 (0)20 7751 9000 f +44 (0)20 7736 9253 e [EMAIL PROTECTED] # Note: Contents may not necessarily represent the opinions of CentralNic.
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 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. ==
RE: Weird networking issue.
At 05:36 PM 1/7/2003, Mikael Abrahamsson wrote: On Tue, 7 Jan 2003, Braun, Mike wrote: 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. 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. Of all the gear I've worked with, from a wide variety of vendors, Cisco is the clear leader in gear that is incapable of successfully doing autonegotiation. I do hope they've improved this in newer products. The all time low point for them has to have been the 2924 switch. Putting a crossover cable between two 2924's yielded invariably BAD results. Now I can forgive engineers for not testing against every brand of router or host out there, but at LEAST test against another copy of the same box you're building. Not even something to blame on a QA engineer... this should have been tested before the box left the engineering benches. Connections to desktop computers and even servers are often better left set for autonegotiation. As people repatch connections to switches, it's easy to forget to reconfigure the switch. All that said, it's been my experience that when Cisco routers are involved, you really do have to force the interface settings or tempt fate.
Re: CC-TLD .af
Hendrianto Muljawan wrote: Hello all, does anybody knows the NIC for Afghanistan ? Your request seemed to indicate that you'd been here already, but just in case I thought I'd point out that I've found the page at http://www.iana.org/cctld/cctld-whois.htm to be generally pretty accurate. At least, the entry for .af gives you a few more e-mail addresses to try, and some phone numbers. Also, if you find that the information there is not up to date, [EMAIL PROTECTED] is generally appreciative of your feedback. Hope this helps. -- Doug Barton, Yahoo! DNS Administration and Development
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 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. So thats human error not a problem with using forced settings, eliminate the human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your networks folks!) 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. Heh. I dont want to look at examples or find out what your experience is but in mine across a wide range of vendors its prone to problems. 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. Have you looked at what autoneg is.. its horrible, a hack to help out the above incompetent engineers who dont know how to force duplex. .. well thats my opinion on the matter anyhow :) Steve
Re: CC-TLD .af
yes, I did try contact [EMAIL PROTECTED] as well, but no luck yet. Muljawan On Tue, Jan 07, 2003 at 09:51:21AM +0100, Stephane Bortzmeyer wrote: On Tuesday 7 January 2003, at 16 h 40, Hendrianto Muljawan [EMAIL PROTECTED] wrote: I have to register a domain in the com.af, but I couldn't find any registrar who can help. Giving the situation in Afghanistan, I wish you good luck. I did try to contact [EMAIL PROTECTED], that is listed as the sponsor for the CC-TLD .af, but I don't get any reply. And the administrative contact? Of course, because of the incredible amount of time it takes for ICANN to update its database, it is probably outdated but did you try?
Re: Weird networking issue.
At 03:17 PM 07-01-03 -0600, Peter E. Fry wrote: 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. [...] I'd like to thank Cisco for this piece of advice, as the only company incapable of manufacturing Ethernet equipment capable of autonegotiation. At least until 1999 or so. Yeah, there're a few others, all of which seemed to follow Cisco's lead. Nutty. Everything Cisco has to say on the subject: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml -Hank [Thanks Yaron :-)] Peter E. Fry
RE: Weird networking issue.
On Wed, 8 Jan 2003, Stephen J. Wilcox wrote: So thats human error not a problem with using forced settings, eliminate the human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your networks folks!) Problem with autoneg is that you always have to have manageble equipment and you always have to check both ends after changing anything. In an ISP environment that is generally not a problem luckily, apart from the equipment you connect to on the customer side, some customers insist on using cheapo stuff. Autoneg does add good things, especially on GigE. Autoneg on a GigE yields the most desireable effect of link loss return, ie if you lose fiber link one way the link goes down at both ends. Have you looked at what autoneg is.. its horrible, a hack to help out the above incompetent engineers who dont know how to force duplex. Hmm, I might draw the same conclusion regarding automatic gear boxes on cars but I think I should not considering the situation in the US regarding that perticular issue :) Personally I think the idea with autoneg is really a good thing, why shouldnt two units advertise their capabilities and then act accordingly to what they both can do? We do the same on SMTP (EHLO) and so on. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
