Re: [c-nsp] Full Duplex
On Sat, Nov 22, 2014 at 09:43:03PM +0200, Mark Tinka wrote: What is more confusing is when vendors use half-duplex bandwidth to make a line card seem faster, e.g., a 30Gbps line card is sold as a 60Gbps if traffic flows in only one direction. Well, that depends. Lets assume the linecard in question has four 10GE Ports, but the chip on the linecard driving these ports can only pump roughly 70Gbps of traffic - no matter what direction. Would you describe this as a 35Gbps linecard? Even if you can e.g. do 40G RX + 20G TX, which would be line rate if your traffic profile is heavily and deterministically biased in one direction? As long as the vendor is _clear_ what performance exactly is being claimed, I have no issues with that. In fact, this can be the more precise number. All this n Gbps per Slot stuff should go away. Vendors should clearly describe their architecture (fabric, backplane connectivity, traffic handling chips) and their specific performance characteristics. Blanket statements seldom tell the full truth. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ 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] Full Duplex
On Sunday, November 23, 2014 11:39:49 AM Daniel Roesen wrote: All this n Gbps per Slot stuff should go away. Vendors should clearly describe their architecture (fabric, backplane connectivity, traffic handling chips) and their specific performance characteristics. Blanket statements seldom tell the full truth. That's why I stopped paying attention to them anymore. I look at the overall architecture, and generally ignore the Gbps/slot schpill. Real life places different demands on the platform, and the numbers generated by the vendors are usually not in line with real life. 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] Full Duplex
On Sun, Nov 23, 2014 at 02:46:45PM +0200, Mark Tinka wrote: I look at the overall architecture, and generally ignore the Gbps/slot schpill. Real life places different demands on the platform, and the numbers generated by the vendors are usually not in line with real life. To cut them some slack, marketing requires them to put up some glossy simple numbers as probably 95% of the people they try to sell to (suitsties, lesser educated technical people) don't understand all the technical details and implications. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ 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] Full Duplex
On 11/18/2014 5:16 AM, M K wrote: Hi all , we were arguing about the full duplex FE interface and it's speedIs it true that this interface can handle 100Mbps send and 100Mbps receive at the same time? like it is 200Mbps ? Thanks This reminds me of the late 90s, when switches were becoming mainstream.Some vendors would refer to the full-duplex 100Mbps ports on their switches as 200Mbps ports right in the marketing literature and on the packaging. -jay ___ 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] Full Duplex
On 18/11/14 02:16, M K wrote: Is it true that this interface can handle 100Mbps send and 100Mbps receive at the same time? Yes. It's 100 Mbps full-duplex. like it is 200Mbps ? No. It's 100 Mbps full-duplex. It's the same as DSL: If you have a 10 Mbps download speed and a 1 Mbps upload speed, you don't call that an 11 Mbps link. If I found a vendor that did that, I would run away from it for lying. ___ 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] Full Duplex
On Saturday, November 22, 2014 02:16:23 AM Octavio Alvarez wrote: If I found a vendor that did that, I would run away from it for lying. But they all do that. What is more confusing is when vendors use half-duplex bandwidth to make a line card seem faster, e.g., a 30Gbps line card is sold as a 60Gbps if traffic flows in only one direction. 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] Full Duplex
On 11/22/2014 11:43 AM, Mark Tinka wrote: On Saturday, November 22, 2014 02:16:23 AM Octavio Alvarez wrote: If I found a vendor that did that, I would run away from it for lying. But they all do that. What is more confusing is when vendors use half-duplex bandwidth to make a line card seem faster, e.g., a 30Gbps line card is sold as a 60Gbps if traffic flows in only one direction. This is different. A line card can support 60 Gbps of *processing power* if it can handle a full-duplex 30 Gbps interface because it has to process all the data at the same time in the worst case. This is correct. And so on: consider a two full-duplex 30 Gbps port line card: it would need the necessary power to handle 120 Gbps of data if you want it to not block or oversubscribe. It's not the same as selling a full-duplex 30 Gbps link as a 60 Gbps link. This is incorrect. ___ 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] Full Duplex
On 11/22/2014 12:17 PM, Octavio Alvarez wrote: On 11/22/2014 11:43 AM, Mark Tinka wrote: On Saturday, November 22, 2014 02:16:23 AM Octavio Alvarez wrote: If I found a vendor that did that, I would run away from it for lying. But they all do that. What is more confusing is when vendors use half-duplex bandwidth to make a line card seem faster, e.g., a 30Gbps line card is sold as a 60Gbps if traffic flows in only one direction. This is different. A line card can support 60 Gbps of *processing power* if it can handle a full-duplex 30 Gbps interface because it has to process all the data at the same time in the worst case. This is correct. And so on: consider a two full-duplex 30 Gbps port line card: it would need the necessary power to handle 120 Gbps of data if you want it to not block or oversubscribe. Before anything else happens: I guess I misread your message. I get your point now. The line card itself is only 30 Gpbs, but because the traffic is not full-duplex (and it will never be) they sell it as a 60 Gbps. Yeah, that sucks too. Sorry for my confusion and the generated noise. ___ 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] Full Duplex
Another example: vendors who sell new equipment and highlight the unit's phenomenal backplane...but none of their linecards can be configured in any kind of way even use it. Frank -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Saturday, November 22, 2014 1:43 PM To: cisco-nsp@puck.nether.net Cc: M K Subject: Re: [c-nsp] Full Duplex On Saturday, November 22, 2014 02:16:23 AM Octavio Alvarez wrote: If I found a vendor that did that, I would run away from it for lying. But they all do that. What is more confusing is when vendors use half-duplex bandwidth to make a line card seem faster, e.g., a 30Gbps line card is sold as a 60Gbps if traffic flows in only one direction. 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/
Re: [c-nsp] Full Duplex
On 11/18/14, 2:16 AM, M K wrote: If you have an expressway with lanes in both directions and a speed limit of 100 MPH, you don't call it a 200 MPH expressway. (That's full-duplex). Yes, but if you view that as cars per second, which is a bit more comparable to bits per second - 100cps north and 100cps south, you could conceivably say that you had 200 cars per second traverse that highway. It's all in how you look at it and how you present your numbers. With that said, I too agree that referring to 100Mbps full duplex as 200Mbps is typically service provider market speak. ___ 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] Full Duplex
On Friday, November 21, 2014 08:36:58 PM Rick Martin wrote: With that said, I too agree that referring to 100Mbps full duplex as 200Mbps is typically service provider market speak. Vendor-speak, to be more accurate. The only time I've seen service providers hear about such talk is when customers don't understand the technology. 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] Full Duplex
Marketing folks love to use half-duplex when speaking about backplane fabric speed.. Typically they don't do that on the ports themselves, typically.. On Wed, Nov 19, 2014 at 6:05 PM, Jay Hennigan j...@west.net wrote: On 11/18/14, 2:16 AM, M K wrote: Hi all , we were arguing about the full duplex FE interface and it's speedIs it true that this interface can handle 100Mbps send and 100Mbps receive at the same time? like it is 200Mbps ? To be more precise, the throughput in either direction is limited to 100 Mbps but traffic can flow in both directions at the same time. If you have an expressway with lanes in both directions and a speed limit of 100 MPH, you don't call it a 200 MPH expressway. (That's full-duplex). If you have a single-lane road with a speed limit of 100 MPH then you can transmit at up to 100 MPH in one direction at a time. Attempting to transmit in both directions at the same time results in what is referred to as a collision. Collisions reduce throughput as the debris must be cleaned up and then retried. Salespeople have been known to refer to T-1 circuits as 3Mbits/s and 100Mbps full-duplex Ethernet as 200 Mbits/s. This is considered to be nitrogen-rich organic fertilizer by those with clue. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ 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] full duplex mismatch speed - dynamips
On 20 Aug 2010, at 17:57, christopher.mar...@usc-bt.com wrote: Regardless of what the UI appears to be doing, you can't do gigabit without autonegotiating. Yes, you can do gig without autoneg. That doesn't make it a good idea, but it certainly works. Nick ___ 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] full duplex mismatch speed - dynamips
Please elaborate. How do you manually configure which end of the link is master for clocking purposes? Sorry for top-posting. Sent from my clunky phone interface. /chris Nick Hilliard n...@foobar.org wrote: On 20 Aug 2010, at 17:57, christopher.mar...@usc-bt.com wrote: Regardless of what the UI appears to be doing, you can't do gigabit without autonegotiating. Yes, you can do gig without autoneg. That doesn't make it a good idea, but it certainly works. Nick ___ 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] full duplex mismatch speed - dynamips
Andrew said: On 20/08/2010, at 5:57 PM, christopher.mar...@usc-bt.com wrote: Two mentions of problems with manually configured gigabit operation. Is there really a problem in that scenario? Shouldn't be. Regardless of what the UI appears to be doing, you can't do gigabit without autonegotiating. It shouldn't be possible to create a duplex mismatch on a gig link. The issue is that the interfaces can usually do 10/100/1000. If one side is set to auto, and the other to 1000/Full - the side set to auto will usually drop down to 10/Half, as this is usually the lowest common denominator. Thank you for underscoring my point about additional myths. Now we have another. My original point: Duplex mismatches with equipment running at gigabit (1000/full on one end, 1000/half on the other) just don't happen. Or do they? I'm open to being corrected on this point, but only with an explanation of how the (required) negotiation has gone wrong. New myth: /Speed/ mismatches exist. They don't. You'll never see a link operating with one end at 100 or 1000 Mb/s and the other end running 10/half. That's why we call them /duplex/ mismatches, not /speed/ mismatches. Incidentally, the scenario outlined above will result in a correctly operating 1000/full linkup because both ends (even the one set for 1000/full) are negotiating. /chris (Adam's other new best friend) ___ 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] full duplex mismatch speed - dynamips
There is no such thing as gigabit half duplex, both link partners transmit on all four pairs simultaneously. So there can't be a duplex mismatch when running at gig. Auto-negotiation has to happen to link up at 1000. If you set a port to 1000 the phy is configured to not advertise 10/100 but it does auto-negotiate. Jim -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of christopher.mar...@usc-bt.com Sent: Saturday, August 21, 2010 11:37 AM To: and...@2sheds.de; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] full duplex mismatch speed - dynamips Andrew said: On 20/08/2010, at 5:57 PM, christopher.mar...@usc-bt.com wrote: Two mentions of problems with manually configured gigabit operation. Is there really a problem in that scenario? Shouldn't be. Regardless of what the UI appears to be doing, you can't do gigabit without autonegotiating. It shouldn't be possible to create a duplex mismatch on a gig link. The issue is that the interfaces can usually do 10/100/1000. If one side is set to auto, and the other to 1000/Full - the side set to auto will usually drop down to 10/Half, as this is usually the lowest common denominator. Thank you for underscoring my point about additional myths. Now we have another. My original point: Duplex mismatches with equipment running at gigabit (1000/full on one end, 1000/half on the other) just don't happen. Or do they? I'm open to being corrected on this point, but only with an explanation of how the (required) negotiation has gone wrong. New myth: /Speed/ mismatches exist. They don't. You'll never see a link operating with one end at 100 or 1000 Mb/s and the other end running 10/half. That's why we call them /duplex/ mismatches, not /speed/ mismatches. Incidentally, the scenario outlined above will result in a correctly operating 1000/full linkup because both ends (even the one set for 1000/full) are negotiating. /chris (Adam's other new best friend) ___ 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] full duplex mismatch speed - dynamips
On Sat, Aug 21, 2010 at 09:42, Jim Getker (getker) get...@cisco.com wrote: There is no such thing as gigabit half duplex Actually, the IEEE specifications allows for 1000/half (to support gigabit hubs). That I have never seen a gigabit hub is not relevant to the capabilities one must build into the device to be standards compliant. ___ 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] full duplex mismatch speed - dynamips
Hi Gary, By bad, you are correct it is in 802.3. Thanks, Jim -Original Message- From: Gary Buhrmaster [mailto:gary.buhrmas...@gmail.com] Sent: Saturday, August 21, 2010 1:08 PM To: Jim Getker (getker) Cc: christopher.mar...@usc-bt.com; and...@2sheds.de; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] full duplex mismatch speed - dynamips Importance: High On Sat, Aug 21, 2010 at 09:42, Jim Getker (getker) get...@cisco.com wrote: There is no such thing as gigabit half duplex Actually, the IEEE specifications allows for 1000/half (to support gigabit hubs). That I have never seen a gigabit hub is not relevant to the capabilities one must build into the device to be standards compliant. ___ 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] full duplex mismatch speed - dynamips
Thats an interesting point! I had that problem yesterday with a ethernet extension service CPE connecting to 2800. The CPE didn't like no auto. 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. 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. 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. It sounds like this is a matter of opinion and the opinion depends on the environment in which it is being applied, no ?? 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?? Is there someone here that has actually gone to town on this one - CRO etc?? Cheers Heath On 20 August 2010 03:52, John Neiberger jneiber...@gmail.com wrote: Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. JFTR, count me in that camp as well (and that has been discussed here on c-nsp just a few months ago as well). The PA-FE-TX is really the only thing left in our network that needs force-duplex. I, believe it or not, still have a 3640 floating around with a NM-4E set to 10/full on all interfaces. It hasn't died yet and does its intended job perfectly. I'd tried to turn up a fast ethernet with Verizon a while back and their policy was to set the ports on the overture to 100/full, no auto. But these are both fringe cases these days. Other than that it's autoneg all the way. It's not the 90's anymore. There's absolutely no reason to not use it. I think the nailing issue is still more of a problem in telcos as opposed to isps. Telcos being in general larger, slower and more fond of process and procedure which once instituted are impossible to remove :) I've worked for a telco which insisted on forcing ports both internally and customer facing. They went so far as to force 100/full on ports facing phones and printers. It took a while to remove the practice. I found challenging people to tell me when the last time they saw an issue caused by an autonegotiating port where the other side wasn't forced helped quite a lot, as no one could think of any, it was just something they'd always done, for fear of the autoneg boogeyman! adam. Even more insidious is the fact that hard-setting both sides to 100/full can actually cause a duplex mismatch. Many NIC drivers still expect to see an autonegotiating link partner even when hard set. If they don't detect a partner participating in Nway, they will--according to spec--assume they are connected to a hub and fall back to half duplex even when configured for full duplex. This is important because most Cisco switches made in the last eight years or so completely disable Nway if you hard set them. If you connect a PC/server that expects an Nway partner, you'll get a duplex mismatch. I've personally corrected this on a few hundred occasions. ___ 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] full duplex mismatch speed - dynamips
Hi, On Fri, Aug 20, 2010 at 07:33:14AM +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. If you force one end, and the other end is set to auto, what usually happens is that the auto end will not see autoneg happening - and has to assume I'm connected to a *Hub*, so I must do half-duplex now. So now you have one side full-duplex, and the other side half-duplex, which implies collision detection and avoidance. Now, the half-duplex side sends out a packet. Everything fine. The full-duplex side also wants to send out a packet, some us later - and it will just go ahead and do it, since it does not have to wait for the incoming packet to be finished (full-duplex!). Now, on the half-duplex end, the device notices oh, something comes in while I am sending a packet, so this MUST BE A COLLISION - and drops(!) both the outgoing and incoming packet. Boom, you have packet loss. And the worst thing about this is that the packet loss is fairly hard to diagnose - if the link is not carrying background traffic, diagnosing with a single ping stream will always have packet goes out, reply comes back. new packet goes out, reply comes back, but there will never be two packets on the link at the same time - no collision. So you assume everything fine, put the link into production use, and your customers complain about internet is slow. 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. Well, of course someone will still stick to the old lore... :-) 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. Huh? There is no renegotiation going on in nway autoneg. It sounds like this is a matter of opinion and the opinion depends on the environment in which it is being applied, no ?? Well. Practical experience tends to form opinion, yes. I'll be honest here, I've never truely understood the cause of speed duplex mismatches. See above. People blindly forcing one side and not ensuring that the other side is also forced (possibly because that side is configured by a different group, or whatever). Or one side of the link getting exchanged years later, and the new device defaulting to autoneg, etc. 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?? People making mistakes is the most common reason, by FAR. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpR6K7PFUMqw.pgp Description: PGP signature ___ 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] full duplex mismatch speed - dynamips
Hi Gert, You response appreciated. One fatal assumption though is me only forcing one end of the link - where did that come from? Read back over my post, keeping in mind that I force both ends to 100/full. By renegotiation I meant each end changing state. Yes I chose a bad word. Do you have a view on what causes an end (or both ends) of a link to all of a sudden change state and think the other end is not capable of 100/full? That is what I am trying to understand. I am also referring to a link that is not erroring like mad and the occurrences might be as low as once per week. Cheers Heath On 20 August 2010 09:48, Gert Doering g...@greenie.muc.de wrote: Hi, On Fri, Aug 20, 2010 at 07:33:14AM +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. If you force one end, and the other end is set to auto, what usually happens is that the auto end will not see autoneg happening - and has to assume I'm connected to a *Hub*, so I must do half-duplex now. So now you have one side full-duplex, and the other side half-duplex, which implies collision detection and avoidance. Now, the half-duplex side sends out a packet. Everything fine. The full-duplex side also wants to send out a packet, some us later - and it will just go ahead and do it, since it does not have to wait for the incoming packet to be finished (full-duplex!). Now, on the half-duplex end, the device notices oh, something comes in while I am sending a packet, so this MUST BE A COLLISION - and drops(!) both the outgoing and incoming packet. Boom, you have packet loss. And the worst thing about this is that the packet loss is fairly hard to diagnose - if the link is not carrying background traffic, diagnosing with a single ping stream will always have packet goes out, reply comes back. new packet goes out, reply comes back, but there will never be two packets on the link at the same time - no collision. So you assume everything fine, put the link into production use, and your customers complain about internet is slow. 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. Well, of course someone will still stick to the old lore... :-) 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. Huh? There is no renegotiation going on in nway autoneg. It sounds like this is a matter of opinion and the opinion depends on the environment in which it is being applied, no ?? Well. Practical experience tends to form opinion, yes. I'll be honest here, I've never truely understood the cause of speed duplex mismatches. See above. People blindly forcing one side and not ensuring that the other side is also forced (possibly because that side is configured by a different group, or whatever). Or one side of the link getting exchanged years later, and the new device defaulting to autoneg, etc. 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?? People making mistakes is the most common reason, by FAR. gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ 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] full duplex mismatch speed - dynamips
Hi, On Fri, Aug 20, 2010 at 10:03:12AM +0100, Heath Jones wrote: You response appreciated. One fatal assumption though is me only forcing one end of the link - where did that come from? Read back over my post, keeping in mind that I force both ends to 100/full. If you can ensure(!) that both ends are always force-config'ed, then there is nothing wrong with forcing 100/full (except for those devices where that doesn't really work, unfortunately, there's a number of them). The problem is that networks change. A server/router breaks down, gets exchanged in the middle of the night. Configuration can not be copy-paste'd (because it's different hardware), so duplex full gets lost. These things happen, and in my experience, if a network runs for 5 years, you have lots and lots of duplex mismatches creep into your network in various places - we took over a larger hosting business some years ago, and they had been religiously nailing manual forced full-duplex!! everywhere. I found at least 10 customer connections that had developed duplex mismatches over time... [..] Do you have a view on what causes an end (or both ends) of a link to all of a sudden change state and think the other end is not capable of 100/full? That is what I am trying to understand. I am also referring to a link that is not erroring like mad and the occurrences might be as low as once per week. Never seen that. But that could be cabling that just barely so works, and if something changes (humidity, ...) tolerance is exceeded... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ 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] full duplex mismatch speed - dynamips
Its good to get your experience Gert - Almost all of my experience to date has been with control of both ends of the link - service provider, managed hosting etc - so believe it or not, I haven't actually run into these issues of forcing only one side of a link. I'll definately keep it in mind for when that happens though! Cheers!! On 20 August 2010 10:12, Gert Doering g...@greenie.muc.de wrote: Hi, On Fri, Aug 20, 2010 at 10:03:12AM +0100, Heath Jones wrote: You response appreciated. One fatal assumption though is me only forcing one end of the link - where did that come from? Read back over my post, keeping in mind that I force both ends to 100/full. If you can ensure(!) that both ends are always force-config'ed, then there is nothing wrong with forcing 100/full (except for those devices where that doesn't really work, unfortunately, there's a number of them). The problem is that networks change. A server/router breaks down, gets exchanged in the middle of the night. Configuration can not be copy-paste'd (because it's different hardware), so duplex full gets lost. These things happen, and in my experience, if a network runs for 5 years, you have lots and lots of duplex mismatches creep into your network in various places - we took over a larger hosting business some years ago, and they had been religiously nailing manual forced full-duplex!! everywhere. I found at least 10 customer connections that had developed duplex mismatches over time... [..] Do you have a view on what causes an end (or both ends) of a link to all of a sudden change state and think the other end is not capable of 100/full? That is what I am trying to understand. I am also referring to a link that is not erroring like mad and the occurrences might be as low as once per week. Never seen that. But that could be cabling that just barely so works, and if something changes (humidity, ...) tolerance is exceeded... gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ 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] full duplex mismatch speed - dynamips
My favorite is when the sys-admin sets 10-12 prod servers to 100/1000 - full doesn't tell anyone and then comes back in a panic because the network blew up. On 8/20/10 10:36 AM, Andrew Miehs and...@2sheds.de wrote: +1 for Autonegotiation. I have had so many problems because someone forced 100/Full, 1000/Full on a switch and the servers could A) Not set duplex AND speed (some could only set one option) B) Remember what they had been set to after power off C) Admin remembers to set on the server at all! The old cisco switches/ routers convinced people to force duplex and speeds - as 15 years ago - it actually worked better by being forced. Nowerdays though, the opposite is the case, but no-one seemes to have informed the management departments yet. Cheers Andrew ___ 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/ Keegan Holley ▪ Jr. Network Architect ▪ SunGard Availability Services ▪ 401 North Broad St. Philadelphia, PA 19108 ▪ (215) 446-1242 ▪ keegan.hol...@sungard.com Keeping People and Information Connected® ▪ http://www.availability.sungard.com/ P Think before you print CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. ___ 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] full duplex mismatch speed - dynamips
My favorite is when the sys-admin sets 10-12 prod servers to 100/1000 - full doesn't tell anyone and then comes back in a panic because the network blew up. I have had so many problems because someone forced 100/Full, 1000/Full on a switch and the servers could A) Not set duplex AND speed (some could only set one option) B) Remember what they had been set to after power off C) Admin remembers to set on the server at all! Two mentions of problems with manually configured gigabit operation. Is there really a problem in that scenario? Shouldn't be. Regardless of what the UI appears to be doing, you can't do gigabit without autonegotiating. It shouldn't be possible to create a duplex mismatch on a gig link. Either I'm confused, or this should be added to the list of myths that need debunking. /chris ___ 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] full duplex mismatch speed - dynamips
On Fri, Aug 20, 2010 at 9:02 AM, Keegan Holley keegan.hol...@sungard.com wrote: My favorite is when the sys-admin sets 10-12 prod servers to 100/1000 - full doesn't tell anyone and then comes back in a panic because the network blew up. Or they just call you up and say, The network is running really slow. Did you guys change something? ___ 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] full duplex mismatch speed - dynamips
On 20/08/2010, at 5:57 PM, christopher.mar...@usc-bt.com wrote: Two mentions of problems with manually configured gigabit operation. Is there really a problem in that scenario? Shouldn't be. Regardless of what the UI appears to be doing, you can't do gigabit without autonegotiating. It shouldn't be possible to create a duplex mismatch on a gig link. The issue is that the interfaces can usually do 10/100/1000. If one side is set to auto, and the other to 1000/Full - the side set to auto will usually drop down to 10/Half, as this is usually the lowest common denominator. Cheers Andrew ___ 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] full duplex mismatch speed - dynamips
On Tue, 17 Aug 2010 19:03:44 -0700, Jeferson Guardia jefers...@gmail.com wrote: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up Force it speed and duplex. I find that preferrable over disabling CDP. -- Octavio. ___ 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] full duplex mismatch speed - dynamips
On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. 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] full duplex mismatch speed - dynamips
On Thu, Aug 19, 2010 at 10:07 AM, Adam Armstrong li...@memetic.org wrote: On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. adam. Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. ___ 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] full duplex mismatch speed - dynamips
On Thu, 19 Aug 2010, Adam Armstrong wrote: On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. For 1000baseT, yes, autoneg support is mandatory. I'll qualify my original statement. My FE experience is somewhat dated, but at that time, enabling autoneg would also often set the evil bit. It created more problems than it solved. It's been 5+ years since I had to worry about speed and duplex autoneg to any significant extent in my network infrastructure since the place I moved to was already GE over fiber when I came in and much of it has been upgraded to 10G since. The only time I worry about speed and duplex autoneg anymore is on end-user ports that don't always link up the way one would think they should, and this more often than not ends up being caused by older NICs and/or sketchy drivers. jms ___ 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] full duplex mismatch speed - dynamips
Oh, believe me, you're not alone. We have actually a cable guy with a piece of paper on the wall behind picturing a road sign - crossed red circle with the word auto inside. On Thu, Aug 19, 2010 at 6:52 PM, John Neiberger jneiber...@gmail.com wrote: On Thu, Aug 19, 2010 at 10:07 AM, Adam Armstrong li...@memetic.org wrote: On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. adam. Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. ___ 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] full duplex mismatch speed - dynamips
On 19/08/2010 17:52, John Neiberger wrote: On Thu, Aug 19, 2010 at 10:07 AM, Adam Armstrongli...@memetic.org wrote: On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. adam. Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. It's merely a case of people not changing habits they learnt in the mid 90s (and new engineers being taught habits by stubborn older engineers) It's often something I have to argue about quite strongly in a new company. I see far more duplex issues in places where they nail duplex as habit, because people often forget to do it on one side (or simply don't know how to do it on the device in question), and of course, if one side is forced and another side is auto, the result is auto side drops to half, and you get a mismatch :) There is of course the odd device which doesn't autoneg properly (like PA-FE-TX), but those are almost always old, and are something we should be working around, not something we build policy around. I'm sure there'll be similar stories in 10 years time when people are still (somehow) using classful terminology and policies with IPv6. 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] full duplex mismatch speed - dynamips
On 8/19/10 1:26 PM, Justin M. Streiner wrote: On Thu, 19 Aug 2010, Adam Armstrong wrote: On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. For 1000baseT, yes, autoneg support is mandatory. I'll qualify my original statement. My FE experience is somewhat dated, but at that time, enabling autoneg would also often set the evil bit. It created more problems than it solved. It's been 5+ years since I had to worry about speed and duplex autoneg to any significant extent in my network infrastructure since the place I And that's kind of the point the others are making: it's been well over 5 years since autoneg breakage was the norm. It USED to be good advice to hardcode speed/duplex. I used to do it religiously myself -- in 2002. But it's 2010 now. Times have changed, hardware has gotten better, then gigabit came along and made autoneg mandatory anyway. Not many people are hooking broken Tulip-based cards (like the PA-FE-TX) to 2924XL's anymore. :) ___ 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] full duplex mismatch speed - dynamips
The PA-FE-TX (at least the ones I've used) don't support auto speed/duplex, so it's not that they have problems with auto. They just don't support it. I've always had to set the device up that they're talking to using manual settings. -Vinny -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Adam Armstrong Sent: Thursday, August 19, 2010 2:35 PM To: John Neiberger Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] full duplex mismatch speed - dynamips On 19/08/2010 17:52, John Neiberger wrote: On Thu, Aug 19, 2010 at 10:07 AM, Adam Armstrongli...@memetic.org wrote: On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. adam. Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. It's merely a case of people not changing habits they learnt in the mid 90s (and new engineers being taught habits by stubborn older engineers) It's often something I have to argue about quite strongly in a new company. I see far more duplex issues in places where they nail duplex as habit, because people often forget to do it on one side (or simply don't know how to do it on the device in question), and of course, if one side is forced and another side is auto, the result is auto side drops to half, and you get a mismatch :) There is of course the odd device which doesn't autoneg properly (like PA-FE-TX), but those are almost always old, and are something we should be working around, not something we build policy around. I'm sure there'll be similar stories in 10 years time when people are still (somehow) using classful terminology and policies with IPv6. 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/ ___ 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] full duplex mismatch speed - dynamips
On 19/08/2010 18:26, Justin M. Streiner wrote: On Thu, 19 Aug 2010, Adam Armstrong wrote: On 17/08/2010 23:50, Justin M. Streiner wrote: On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. This is horribly terrible advice. Autonegotiation should always be used as default, nailing should be the fix for when things don't work, and where very old devices don't do autoneg properly. Note that for gigabit, autonegotiation is MANDATORY. For 1000baseT, yes, autoneg support is mandatory. I'll qualify my original statement. My FE experience is somewhat dated, but at that time, enabling autoneg would also often set the evil bit. It created more problems than it solved. It's been 5+ years since I had to worry about speed and duplex autoneg to any significant extent in my network infrastructure since the place I moved to was already GE over fiber when I came in and much of it has been upgraded to 10G since. The only time I worry about speed and duplex autoneg anymore is on end-user ports that don't always link up the way one would think they should, and this more often than not ends up being caused by older NICs and/or sketchy drivers. Well now you know better, so please don't go repeating that anywhere else. 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] full duplex mismatch speed - dynamips
Abello, Vinny wrote: The PA-FE-TX (at least the ones I've used) don't support auto speed/duplex, so it's not that they have problems with auto. They just don't support it. I've always had to set the device up that they're talking to using manual settings. It's especially bad when the device on the other end of the link from the PA-FE-TX is something for which you don't have administrator access, as it is in my case with my Verizon FiOS ONT. Peace... Sridhar ___ 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] full duplex mismatch speed - dynamips
Hi, On Thu, Aug 19, 2010 at 10:52:48AM -0600, John Neiberger wrote: Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. JFTR, count me in that camp as well (and that has been discussed here on c-nsp just a few months ago as well). The PA-FE-TX is really the only thing left in our network that needs force-duplex. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpd4Vu7i62Eh.pgp Description: PGP signature ___ 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] full duplex mismatch speed - dynamips
On 8/19/2010 12:26, Gert Doering wrote: Hi, On Thu, Aug 19, 2010 at 10:52:48AM -0600, John Neiberger wrote: Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. JFTR, count me in that camp as well (and that has been discussed here on c-nsp just a few months ago as well). The PA-FE-TX is really the only thing left in our network that needs force-duplex. I, believe it or not, still have a 3640 floating around with a NM-4E set to 10/full on all interfaces. It hasn't died yet and does its intended job perfectly. I'd tried to turn up a fast ethernet with Verizon a while back and their policy was to set the ports on the overture to 100/full, no auto. But these are both fringe cases these days. Other than that it's autoneg all the way. It's not the 90's anymore. There's absolutely no reason to not use it. ~Seth ___ 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] full duplex mismatch speed - dynamips
Hello, Actually it looks like a dynamips/IOS bug in the emulation of GT96100-FE - see http://7200emu.hacki.at/viewtopic.php?t=4484 or alternatively this one http://7200emu.hacki.at/viewtopic.php?t=121postdays=0postorder=ascstart=30 On the other side Gert is correct this is more a cosmetic issue, as there is no signalling emulation in dynamips, the L1 frames are simply moved between the router instances through UDP tunnels and fed directly to the interface driver of the destination driver on L1. Therefore - having duplex or even speed mismatch is totally irrelevant on dynamips as these issues only affect signalling...Also (as a corollary) there is no auto-speed negotiation when connecting 10Mb/s card to a 100Mb/s card -pavel On Wed, Aug 18, 2010 at 11:03 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Aug 18, 2010 at 10:44:37AM +0200, Andreas Sikkema wrote: Since Dynamips is an emulator (and from the looks of it, quite an old one) it could also be a bug in the emulator itself. Or even a bug in the IOS version you're using, or a combination of both. The bug in dynamips would be that it works even though there is a perceived duplex mismatch (I'd assume that it doesn't even try to implement half-duplex mode on FE). Just telling both sides to configure the interface to duplex full should be enough to silence the IOSes involved. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ 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] full duplex mismatch speed - dynamips
On 19/08/2010 21:02, Seth Mattinen wrote: On 8/19/2010 12:26, Gert Doering wrote: Hi, On Thu, Aug 19, 2010 at 10:52:48AM -0600, John Neiberger wrote: Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. JFTR, count me in that camp as well (and that has been discussed here on c-nsp just a few months ago as well). The PA-FE-TX is really the only thing left in our network that needs force-duplex. I, believe it or not, still have a 3640 floating around with a NM-4E set to 10/full on all interfaces. It hasn't died yet and does its intended job perfectly. I'd tried to turn up a fast ethernet with Verizon a while back and their policy was to set the ports on the overture to 100/full, no auto. But these are both fringe cases these days. Other than that it's autoneg all the way. It's not the 90's anymore. There's absolutely no reason to not use it. I think the nailing issue is still more of a problem in telcos as opposed to isps. Telcos being in general larger, slower and more fond of process and procedure which once instituted are impossible to remove :) I've worked for a telco which insisted on forcing ports both internally and customer facing. They went so far as to force 100/full on ports facing phones and printers. It took a while to remove the practice. I found challenging people to tell me when the last time they saw an issue caused by an autonegotiating port where the other side wasn't forced helped quite a lot, as no one could think of any, it was just something they'd always done, for fear of the autoneg boogeyman! 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] full duplex mismatch speed - dynamips
Adam, you are my new best friend. I've been saying this for the past few years and people still think I'm crazy. I flat out refuse to manually configure speed and duplex for someone unless it is demonstrated (or I can verify) that a duplex mismatch is actually happening or there is some other extenuating circumstance that requires it. JFTR, count me in that camp as well (and that has been discussed here on c-nsp just a few months ago as well). The PA-FE-TX is really the only thing left in our network that needs force-duplex. I, believe it or not, still have a 3640 floating around with a NM-4E set to 10/full on all interfaces. It hasn't died yet and does its intended job perfectly. I'd tried to turn up a fast ethernet with Verizon a while back and their policy was to set the ports on the overture to 100/full, no auto. But these are both fringe cases these days. Other than that it's autoneg all the way. It's not the 90's anymore. There's absolutely no reason to not use it. I think the nailing issue is still more of a problem in telcos as opposed to isps. Telcos being in general larger, slower and more fond of process and procedure which once instituted are impossible to remove :) I've worked for a telco which insisted on forcing ports both internally and customer facing. They went so far as to force 100/full on ports facing phones and printers. It took a while to remove the practice. I found challenging people to tell me when the last time they saw an issue caused by an autonegotiating port where the other side wasn't forced helped quite a lot, as no one could think of any, it was just something they'd always done, for fear of the autoneg boogeyman! adam. Even more insidious is the fact that hard-setting both sides to 100/full can actually cause a duplex mismatch. Many NIC drivers still expect to see an autonegotiating link partner even when hard set. If they don't detect a partner participating in Nway, they will--according to spec--assume they are connected to a hub and fall back to half duplex even when configured for full duplex. This is important because most Cisco switches made in the last eight years or so completely disable Nway if you hard set them. If you connect a PC/server that expects an Nway partner, you'll get a duplex mismatch. I've personally corrected this on a few hundred occasions. ___ 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] full duplex mismatch speed - dynamips
'no cdp log mismatch duplex' could be a better way to get rid of annoying message but still have cdp running. That is if you're sure it's a bug not inadequate configuration. On Wed, Aug 18, 2010 at 4:42 AM, Jeferson Guardia jefers...@gmail.com wrote: Guys, Thanks for all replies, googling it I came across a link at groupstudy from someone experiencing the same problem before when labbing up CCIE topologies. http://www.groupstudy.com/archives/ccielab/200701/msg01450.html I think it is a dynamips 'bug/weird behavior' , the way of getting rid of this issue is only disabling CDP, if anyone knows another way out, please let me know. rgs, 2010/8/17 Alessandro Braga sandro.u...@gmail.com Jeff, use the 'show interface FastEthernet0/0' command on this router (R3) and see a problem: 'duplex mismatch discovered on FastEthernet0/0 ''(not full duplex)'' - this interface not operate in fullduplex mode.' Att, AB 2010/8/17 Alessandro Braga sandro.u...@gmail.com: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Att, AB 2010/8/17 Jeferson Guardia jefers...@gmail.com: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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-...@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] full duplex mismatch speed - dynamips
Hi, On Tue, Aug 17, 2010 at 11:03:44PM -0300, Jeferson Guardia wrote: Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. If that's a 7200, just nail it to duplex full. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpnHpwp5cLEe.pgp Description: PGP signature ___ 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] full duplex mismatch speed - dynamips
Jeferson, why no one read the 'dynamis' word on the subject? this is a particular issue being experienced on a 3725 being used as a switch on DYNAMIPS... it just doesnt work... Since Dynamips is an emulator (and from the looks of it, quite an old one) it could also be a bug in the emulator itself. Or even a bug in the IOS version you're using, or a combination of both. -- Andreas Sikkema ___ 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] full duplex mismatch speed - dynamips
If it's any help at all, I downloaded GNS3 about 3 weeks ago and with relatively recent IOS, its working fine and I can force to 100/full. Andreas is right.. So is it possible for you to upgrade to latest dynamips? On 18 August 2010 09:44, Andreas Sikkema asikk...@office.unet.nl wrote: Jeferson, why no one read the 'dynamis' word on the subject? this is a particular issue being experienced on a 3725 being used as a switch on DYNAMIPS... it just doesnt work... Since Dynamips is an emulator (and from the looks of it, quite an old one) it could also be a bug in the emulator itself. Or even a bug in the IOS version you're using, or a combination of both. -- Andreas Sikkema ___ 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] full duplex mismatch speed - dynamips
Hi, On Wed, Aug 18, 2010 at 10:44:37AM +0200, Andreas Sikkema wrote: Since Dynamips is an emulator (and from the looks of it, quite an old one) it could also be a bug in the emulator itself. Or even a bug in the IOS version you're using, or a combination of both. The bug in dynamips would be that it works even though there is a perceived duplex mismatch (I'd assume that it doesn't even try to implement half-duplex mode on FE). Just telling both sides to configure the interface to duplex full should be enough to silence the IOSes involved. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpFSkawMKam9.pgp Description: PGP signature ___ 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] full duplex mismatch speed - dynamips
Whatever config I make, it does not work. Some people here got the point, some are still thinking I am missing stuff somewhere.. anyway, I not using GNS3 but Dynagen. I am loading up 14 devices and on gns3 this usually crashes, the only stable way I found on loading, it was using dynagen, but unfortunately I have this issue but is not a big deal. thanks for all replies 2010/8/18 Gert Doering g...@greenie.muc.de Hi, On Wed, Aug 18, 2010 at 10:44:37AM +0200, Andreas Sikkema wrote: Since Dynamips is an emulator (and from the looks of it, quite an old one) it could also be a bug in the emulator itself. Or even a bug in the IOS version you're using, or a combination of both. The bug in dynamips would be that it works even though there is a perceived duplex mismatch (I'd assume that it doesn't even try to implement half-duplex mode on FE). Just telling both sides to configure the interface to duplex full should be enough to silence the IOSes involved. gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ http://www.muc.de/%7Egert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ 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] full duplex mismatch speed - dynamips
sth...@nethelp.no writes: I would have agreed five to ten years ago. However, nowadays we use autoneg everywhere with a few well known exceptions (e.g. Cisco 7200 with Fast Ethernet PAs). Autoneg simply gives us less problems. Autoneg also has the advantage of almost always failing in an easily detectable way: The interface goes half duplex. So as soon as you see a half-duplex interface you know that something is wrong. /Benny ___ 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] full duplex mismatch speed - dynamips
On Wednesday, August 18, 2010 01:30:07 pm sth...@nethelp.no wrote: I would have agreed five to ten years ago. However, nowadays we use autoneg everywhere with a few well known exceptions (e.g. Cisco 7200 with Fast Ethernet PAs). Autoneg simply gives us less problems. +1. 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/
[c-nsp] full duplex mismatch speed - dynamips
Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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] full duplex mismatch speed - dynamips
Do you have two Cisco devices separated by a non-Cisco device? Imagine this: A B --- C A and C are Cisco devices, B is not. If B is a switch or a hub, it will pass CDP frames from A to C, which can cause these weird mismatches. It's not really a mismatch because A and C are not actually directly connected. CDP just thinks they are because B is letting them pass through transparently. Is that what's happening in your situation? On Tue, Aug 17, 2010 at 8:03 PM, Jeferson Guardia jefers...@gmail.com wrote: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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] full duplex mismatch speed - dynamips
Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Att, AB 2010/8/17 Jeferson Guardia jefers...@gmail.com: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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] full duplex mismatch speed - dynamips
Jeff, use the 'show interface FastEthernet0/0' command on this router (R3) and see a problem: 'duplex mismatch discovered on FastEthernet0/0 ''(not full duplex)'' - this interface not operate in fullduplex mode.' Att, AB 2010/8/17 Alessandro Braga sandro.u...@gmail.com: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Att, AB 2010/8/17 Jeferson Guardia jefers...@gmail.com: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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] full duplex mismatch speed - dynamips
Guys, Thanks for all replies, googling it I came across a link at groupstudy from someone experiencing the same problem before when labbing up CCIE topologies. http://www.groupstudy.com/archives/ccielab/200701/msg01450.html I think it is a dynamips 'bug/weird behavior' , the way of getting rid of this issue is only disabling CDP, if anyone knows another way out, please let me know. rgs, 2010/8/17 Alessandro Braga sandro.u...@gmail.com Jeff, use the 'show interface FastEthernet0/0' command on this router (R3) and see a problem: 'duplex mismatch discovered on FastEthernet0/0 ''(not full duplex)'' - this interface not operate in fullduplex mode.' Att, AB 2010/8/17 Alessandro Braga sandro.u...@gmail.com: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Att, AB 2010/8/17 Jeferson Guardia jefers...@gmail.com: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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] full duplex mismatch speed - dynamips
You would need to change the duplex (half or full) to solve this, not the speed. On Tue, Aug 17, 2010 at 22:03, Jeferson Guardia jefers...@gmail.com wrote: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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] full duplex mismatch speed - dynamips
On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. jms ___ 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] full duplex mismatch speed - dynamips
Jeff, probably your configurations dont are correct or the autonegotiation dont work properly, try put the shut and no shut commands on envolved interfaces. i dont remember of the any case this. Rgs, AB 2010/8/17 Jeferson Guardia jefers...@gmail.com: Guys, Thanks for all replies, googling it I came across a link at groupstudy from someone experiencing the same problem before when labbing up CCIE topologies. http://www.groupstudy.com/archives/ccielab/200701/msg01450.html I think it is a dynamips 'bug/weird behavior' , the way of getting rid of this issue is only disabling CDP, if anyone knows another way out, please let me know. rgs, 2010/8/17 Alessandro Braga sandro.u...@gmail.com Jeff, use the 'show interface FastEthernet0/0' command on this router (R3) and see a problem: 'duplex mismatch discovered on FastEthernet0/0 ''(not full duplex)'' - this interface not operate in fullduplex mode.' Att, AB 2010/8/17 Alessandro Braga sandro.u...@gmail.com: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Att, AB 2010/8/17 Jeferson Guardia jefers...@gmail.com: Guys, Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. R3# *Mar 1 00:12:08.323: %SYS-5-CONFIG_I: Configured from console by console *Mar 1 00:12:10.027: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up *Mar 1 00:12:11.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up *Mar 1 00:12:23.527: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:24.079: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:12:26.295: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). *Mar 1 00:13:10.571: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). R3# R3# *Mar 1 00:13:59.455: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on Fast Ethernet0/0 (not full duplex), with Router FastEthernet1/3 (full duplex). Rgs, ___ 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] full duplex mismatch speed - dynamips
Guys, why no one read the 'dynamis' word on the subject? this is a particular issue being experienced on a 3725 being used as a switch on DYNAMIPS... it just doesnt work... 2010/8/17 Justin M. Streiner strei...@cluebyfour.org On Tue, 17 Aug 2010, Alessandro Braga wrote: Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. jms ___ 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] full duplex mismatch speed - dynamips
Verify duplex and speed configurations on interface, the rule is: autoXauto, forcedXforced. If problem not solve, disable cdp. Also, while auto speed/duplex negotiation is fine for user workstation/PC ports in most cases, I recommend against using it on your network infrastructure if you can help it. I would have agreed five to ten years ago. However, nowadays we use autoneg everywhere with a few well known exceptions (e.g. Cisco 7200 with Fast Ethernet PAs). Autoneg simply gives us less problems. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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/
