Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
We have EoSDH equipment (by NSN) which is indeed not able to auto-negotiate. The strange thing is that older cards supported auto-negotiation, while newer ones do not -- Tassos Mark Tinka wrote on 20/08/2010 11:20: On Friday, August 20, 2010 03:34:24 pm Mikael Abrahamsson wrote: +1 on the "use autoneg unless you really have to force duplex". We have a customer that connects to us over Gig-E, but their end is an EoSDH implementation. As it were, that SDH box either won't auto-neg (which I can't believe), or they're too scared to make it so. They're just about the only customer we're hard-coding for, and less than 1% of our customers don't connect to us via Ethernet. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
On Fri, 2010-08-20 at 07:33 +0100, Heath Jones wrote: I'm really curious as to why there are many people here saying forcing ports is a bad thing though. I was pretty surprised to be reading that actually, its good to have another perspective on the idea. IMO forcing ports isn't bad per se, but it's error prone and complicates the network. Sometimes you need this manual configuration, most times you don't. I've seen countless issues where inter switch links, inter router links and also links between servers and switches have cause so many issues. On almost all of these occasions, forcing will solve the problem. If these are Gigabit links, then you should return the equipment to the manufacturer. It doesn't follow 802.3 correctly and thus isn't Gigabit Ethernet. The link is actually going down while the renegotiation happens. This causes a L2 topology change, so frames will be dropped. In a service provider environment, there will be a L3 topology change - IGP does its thing and this may take some time (especially on a heavily loaded router). The end result is customers start calling wondering where their traffic went. If auto-negotiation gives problems like that (and we're talking a modern network) you would just be hiding the problem by disabling auto-neg, not solving it. Actually 802.3 auto-neg can sometimes help to discover bad cabling. It sounds like this is a matter of opinion and the opinion depends on the environment in which it is being applied, no ?? Technically I guess every argument is based on opinion. But as a funny man once could have said: I'll advise all my competitors against using auto-negotiation. :-) I'll be honest here, I've never truely understood the cause of speed duplex mismatches. Noise would be the obvious one, but does noise actually play a big part on relatively short cat5 links? Dodgy connectors? Problems with the PLL decoder getting out of sync (noise again?)? Faulty clock?? Someone jumping on the cable?? The duplex thing is about Ethernet legacy; you don't have the problem on fiber links, since these can't be simplex (AFAIK, please correct me if I'm wrong). But any copper port _might_ be connected to a hub from 1993 some day, and the standard tries to make that work. -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
On Fri, 20 Aug 2010, Peter Rathlev wrote: The duplex thing is about Ethernet legacy; you don't have the problem on fiber links, since these can't be simplex (AFAIK, please correct me if I'm wrong). But any copper port _might_ be connected to a hub from 1993 some day, and the standard tries to make that work. I've used AUI-transceivers with 10BASE-FL (fiber) that by definition were half duplex, but this was in the mid 90:ties so it's doesn't really apply anymore. It emulated collissions over the fiber layer as far as I could discern. +1 on the use autoneg unless you really have to force duplex. In case of having to force, do use speed auto / duplex full if your equipment supports it. If you connect something that is auto / auto to it then autoneg still succeeds, if you connect something that is 10/full or 100/full to it, then you still get something that works. If you force half duplex or connect it to a hub then you'll get a duplex mismatch, but at least you have a much higher chance of it working even if you do something wrong. Duplex seems to be a big mystery in most organizations, I've heard so many misconceptions about it it's scary, I'd say it's one of the biggest causes of bad performance in modern networking, at least in equipment which humans can actually configure. The simple L2 switches with no configuration is more likely to work. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
Cheers Peter! I agree for sure that forcing should be a temporary workaround and that there could still be underlying issues. Disabling certainly isnt the long term solution!! I started reading wikipedia about autoneg and the best I could come up with is that there is sufficient attenuation and then noise so the receiver doesnt see the fast link pulses (not sure how many it must miss to change state though), either that or there is something causing enough delay / temporary phase shift that the pll at the receiver is out of whack and doesn't decode the capability correctly on occasion. That's the thing that gets me - the links where it only happens very occasionally. If it happens all the time or not at all, its obvious. Older fibre still does autoneg, anything 1G doesn't as far as I'm aware.. On 20 August 2010 08:12, Peter Rathlev pe...@rathlev.dk wrote: On Fri, 2010-08-20 at 07:33 +0100, Heath Jones wrote: I'm really curious as to why there are many people here saying forcing ports is a bad thing though. I was pretty surprised to be reading that actually, its good to have another perspective on the idea. IMO forcing ports isn't bad per se, but it's error prone and complicates the network. Sometimes you need this manual configuration, most times you don't. I've seen countless issues where inter switch links, inter router links and also links between servers and switches have cause so many issues. On almost all of these occasions, forcing will solve the problem. If these are Gigabit links, then you should return the equipment to the manufacturer. It doesn't follow 802.3 correctly and thus isn't Gigabit Ethernet. The link is actually going down while the renegotiation happens. This causes a L2 topology change, so frames will be dropped. In a service provider environment, there will be a L3 topology change - IGP does its thing and this may take some time (especially on a heavily loaded router). The end result is customers start calling wondering where their traffic went. If auto-negotiation gives problems like that (and we're talking a modern network) you would just be hiding the problem by disabling auto-neg, not solving it. Actually 802.3 auto-neg can sometimes help to discover bad cabling. It sounds like this is a matter of opinion and the opinion depends on the environment in which it is being applied, no ?? Technically I guess every argument is based on opinion. But as a funny man once could have said: I'll advise all my competitors against using auto-negotiation. :-) I'll be honest here, I've never truely understood the cause of speed duplex mismatches. Noise would be the obvious one, but does noise actually play a big part on relatively short cat5 links? Dodgy connectors? Problems with the PLL decoder getting out of sync (noise again?)? Faulty clock?? Someone jumping on the cable?? The duplex thing is about Ethernet legacy; you don't have the problem on fiber links, since these can't be simplex (AFAIK, please correct me if I'm wrong). But any copper port _might_ be connected to a hub from 1993 some day, and the standard tries to make that work. -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
On Friday, August 20, 2010 03:34:24 pm Mikael Abrahamsson wrote: +1 on the use autoneg unless you really have to force duplex. We have a customer that connects to us over Gig-E, but their end is an EoSDH implementation. As it were, that SDH box either won't auto-neg (which I can't believe), or they're too scared to make it so. They're just about the only customer we're hard-coding for, and less than 1% of our customers don't connect to us via Ethernet. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
I started to believe after your post that it could be true as we have the same hand over from our EoSDH. That is on fiber and having speed nonegotiate on those ports annoys the hell out of me. Another case - multispeed media-converters which are rare guest by ISPs I guess. The lack of optical sockets on old ISRs forced many people to use them and having autoneg there isn't the best thing one could do. On Fri, Aug 20, 2010 at 10:20 AM, Mark Tinka mti...@globaltransit.net wrote: On Friday, August 20, 2010 03:34:24 pm Mikael Abrahamsson wrote: +1 on the use autoneg unless you really have to force duplex. We have a customer that connects to us over Gig-E, but their end is an EoSDH implementation. As it were, that SDH box either won't auto-neg (which I can't believe), or they're too scared to make it so. They're just about the only customer we're hard-coding for, and less than 1% of our customers don't connect to us via Ethernet. Mark. ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
On Fri, Aug 20, 2010 at 10:20, Mark Tinka mti...@globaltransit.net wrote: On Friday, August 20, 2010 03:34:24 pm Mikael Abrahamsson wrote: +1 on the use autoneg unless you really have to force duplex. We have a customer that connects to us over Gig-E, but their end is an EoSDH implementation. As it were, that SDH box either won't auto-neg (which I can't believe), or they're too scared to make it so. I've worked with some SDH equipment and we had some problems with auto-negotiate on 1G links, on some cisco equipment it would work flawlessly and with some it had to be disabled for link to come up. Is it a problem with SDH equipment vendor of with Cisco I don't know. (there were no problems with links that went to some extreme BD-s though) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
On Fri, 20 Aug 2010, Mikael Abrahamsson wrote:
Duplex seems to be a big mystery in most organizations, I've heard so many
misconceptions about it it's scary, I'd say it's one of the biggest causes of
bad performance in modern networking,
Network Performance Problem Solution Guide:
http://tinyurl.com/32ol9sf
-
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[]= { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
On Friday, August 20, 2010 07:18:29 pm Danijel wrote: I've worked with some SDH equipment and we had some problems with auto-negotiate on 1G links, on some cisco equipment it would work flawlessly and with some it had to be disabled for link to come up. Is it a problem with SDH equipment vendor of with Cisco I don't know. (there were no problems with links that went to some extreme BD-s though) Our end is talking to a 5-port Gig-E SPA on an ASR1002. This link will be moved to an MX480 in a few weeks. I don't expect the situation to change, as I don't think the issue is Cisco-related. But if it does, I'll surely let the list know. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
While we're on the autoneg subject... Has anyone else run into cases of newer computers that support a powersave and/or wake-on-lan state where in that instance the interface goes into a 10Mb/full connection? Drives us nuts with the growing green initiatives... Computers that do that go into some sort of zombie state that doesn't quite autoneg properly, our switches (Cisco and Procurve) go to 10/full, but the device doesn't seem to quite be full, and the ports will generate lots of up/downs and errors while in that state. If you're doing any sort of monitoring that involves trapping mac-address changes or linkup/linkdowns, they'll drive your monitors crazy too... When they're working they'll do gig/full, but when in this zombie state, they autoneg down to 10/full Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
We have EoSDH equipment (by NSN) which is indeed not able to auto-negotiate. The strange thing is that older cards supported auto-negotiation, while newer ones do not -- Tassos Andriy Bilous wrote on 20/08/2010 13:45: I started to believe after your post that it could be true as we have the same hand over from our EoSDH. That is on fiber and having speed nonegotiate on those ports annoys the hell out of me. Another case - multispeed media-converters which are rare guest by ISPs I guess. The lack of optical sockets on old ISRs forced many people to use them and having autoneg there isn't the best thing one could do. On Fri, Aug 20, 2010 at 10:20 AM, Mark Tinkamti...@globaltransit.net wrote: On Friday, August 20, 2010 03:34:24 pm Mikael Abrahamsson wrote: +1 on the use autoneg unless you really have to force duplex. We have a customer that connects to us over Gig-E, but their end is an EoSDH implementation. As it were, that SDH box either won't auto-neg (which I can't believe), or they're too scared to make it so. They're just about the only customer we're hard-coding for, and less than 1% of our customers don't connect to us via Ethernet. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
This could lead to some frustration when connecting to devices with auto-mdi... as auto-neg is required for auto-mdi to work... From: Tassos Chatzithomaoglou ach...@forthnet.gr To: cisco-nsp@puck.nether.net Sent: Fri, August 20, 2010 11:38:34 AM Subject: Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips) We have EoSDH equipment (by NSN) which is indeed not able to auto-negotiate. The strange thing is that older cards supported auto-negotiation, while newer ones do not -- Tassos Andriy Bilous wrote on 20/08/2010 13:45: I started to believe after your post that it could be true as we have the same hand over from our EoSDH. That is on fiber and having speed nonegotiate on those ports annoys the hell out of me. Another case - multispeed media-converters which are rare guest by ISPs I guess. The lack of optical sockets on old ISRs forced many people to use them and having autoneg there isn't the best thing one could do. On Fri, Aug 20, 2010 at 10:20 AM, Mark Tinkamti...@globaltransit.net wrote: On Friday, August 20, 2010 03:34:24 pm Mikael Abrahamsson wrote: +1 on the use autoneg unless you really have to force duplex. We have a customer that connects to us over Gig-E, but their end is an EoSDH implementation. As it were, that SDH box either won't auto-neg (which I can't believe), or they're too scared to make it so. They're just about the only customer we're hard-coding for, and less than 1% of our customers don't connect to us via Ethernet. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
On 20/08/2010 17:38, Tassos Chatzithomaoglou wrote: We have EoSDH equipment (by NSN) which is indeed not able to auto-negotiate. The strange thing is that older cards supported auto-negotiation, while newer ones do not I suspect this is related to the telco-land obsession with forcing speed/duplex on ports. adam. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
Yes. We recently rolled out new switches in a couple sites (4507-R with Sup6E and 10/100 blades) and were checking to see if any clients came up wrong. We panicked when we saw tons of clients coming up 10/full, 10/half, and 100/half. All over the map. Turns out all the workstations were powered off during the install, and it was just the WoL drivers that were wonky. Once booted everything auto'ed up properly. -Geoff On Fri, Aug 20, 2010 at 11:28 AM, Jeff Kell jeff-k...@utc.edu wrote: While we're on the autoneg subject... Has anyone else run into cases of newer computers that support a powersave and/or wake-on-lan state where in that instance the interface goes into a 10Mb/full connection? Drives us nuts with the growing green initiatives... Computers that do that go into some sort of zombie state that doesn't quite autoneg properly, our switches (Cisco and Procurve) go to 10/full, but the device doesn't seem to quite be full, and the ports will generate lots of up/downs and errors while in that state. If you're doing any sort of monitoring that involves trapping mac-address changes or linkup/linkdowns, they'll drive your monitors crazy too... When they're working they'll do gig/full, but when in this zombie state, they autoneg down to 10/full Jeff ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
