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,
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,
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
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
On Fri, 2010-08-20 at 09:34 +0200, Mikael Abrahamsson wrote:
In case of having to force, do use speed auto / duplex full if your
equipment supports it.
And on a side note, if one needs to provide less-than-linerate speeds
(e.g. a 100 Mbps customer on a gigabit interface) it's much better to
On Fri, 20 Aug 2010, Peter Rathlev wrote:
On Fri, 2010-08-20 at 09:34 +0200, Mikael Abrahamsson wrote:
In case of having to force, do use speed auto / duplex full if your
equipment supports it.
And on a side note, if one needs to provide less-than-linerate speeds
(e.g. a 100 Mbps customer on
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
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
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
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
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
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
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
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:
Someone in the other thread mentioned that they were surprised to see
that so many people were against manually configuring speed and
duplex, so I thought I would explain why this is a bad idea most of
the time.
The Fast Ethernet standard does not mention how devices are supposed
to behave when
On 8/20/2010 10:01 AM, Gert Doering wrote:
Hi,
On Fri, Aug 20, 2010 at 07:38:20AM -0600, John Neiberger wrote:
There are two options and they picked the worst one. I can't think of
any rationale that holds up to reasoning.
They talked to their web team? We should be happy that autoneg
On Fri, Aug 20, 2010 at 4:28 PM, Keegan Holley keegan.hol...@sungard.comwrote:
I disagree completely. I have run into the behavior you mentioned and gone
back to auto, however I've had more problems with auto than with statically
setting duplex. Devices rebooting and somehow coming to the
On 20/08/2010 15:28, Keegan Holley wrote:
I disagree completely. I have run into the behavior you mentioned and gone
back to auto, however I've had more problems with auto than with statically
setting duplex. Devices rebooting and somehow coming to the wrong
conclusion about speed and duplex
Which switches in the 4900 family are you looking at. Most of them support
jumbo frames as they are targetted at Datacenter top of rack type
deployments.
The 4900M is particularly impressive.
http://www.eweek.com/c/a/IT-Infrastructure/Cisco-Catalyst-4900M-Helps-Clear-the-Way-to-10G/
I don't disagree with that point. I guess the times where I've see a
behavior 1 device and a behavior 2 device have been few and far between
though. YMMV though.
On 8/20/10 10:35 AM, John Neiberger jneiber...@gmail.com wrote:
As I mentioned, if you are connecting two behavior #1 devices
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
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
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
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
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.
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
On 8/20/10 7:44 AM, Andrew Miehs wrote:
I guess the differing opionions have to do with age and brand of hardware.
I found Auto the best running HP Procurve switches with and Supermicro and
HP Proliant DL360 G5 servers (nothing older than 2004). I had no end of
problems with old PA Risc
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
I wouldn't. I have a 2924XL-EN in service as a workstation switch; all
ports auto. It's seen all kinds of printers, homebrew x86, HP, Dell,
Apple, one SPARCstation, and other hardware I've forgotten about. The
one time I remember having to force a port (10/full) was with a CRT iMac
that
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:
Thats a very good point John!
Any thoughts why a cat5 5m non-erroring link with auto on both ends that
negotiates 100/full would sometimes (once,twice per week) drop down
(10/half) and then back up again shortly after?
Forcing both ends 'fixes' it (stops the flaps).. Seen that one before?
Cheers
On Fri, Aug 20, 2010 at 11:54 AM, Heath Jones hj1...@gmail.com wrote:
Thats a very good point John!
Any thoughts why a cat5 5m non-erroring link with auto on both ends that
negotiates 100/full would sometimes (once,twice per week) drop down
(10/half) and then back up again shortly after?
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
Hi Paul,
(I've Cc'ed the list again since other people's eyes can spot errors I
might have made.)
On Fri, 2010-08-20 at 12:51 -0400, P.A wrote:
Actually Peter, I have come to determine that even now with the
correct cos 5 mapped to the incoming priority queue, unless it’s a
trunk it will not
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
Yeah I have the same config, but don’t think that incoming packets will be
mapped to the priority queue. I think all the config below is going to do is
set the internal dscp with the policy to be used on the outgoing queue. From
what I understand from the link below all incoming packets 1st are
On Fri, 2010-08-20 at 15:39 -0400, P.A wrote:
Yeah I have the same config, but don’t think that incoming packets
will be mapped to the priority queue. I think all the config below is
going to do is set the internal dscp with the policy to be used on the
outgoing queue. From what I understand
Well thanks for all your help, at least its post on the list and maybe it can
help someone else.
-Original Message-
From: Peter Rathlev [mailto:pe...@rathlev.dk]
Sent: Friday, August 20, 2010 3:51 PM
To: P.A
Cc: 'cisco-nsp'
Subject: Re: [c-nsp] incoming queue
On Fri, 2010-08-20 at
If you are using COS-Q mapping, the frame *must*
carry COS to be prioritized on ingress. If using
DSCP-Q (available on certain 10G modules) then we
can prioritize on the ingress port based on DSCP,
which of course would always be carried in an IP packet.
An input service-policy is applied in
The 6K gigabit copper ports support speed auto 10 100.
Jim
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev
Sent: Friday, August 20, 2010 3:45 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] The myths
Well one problem with that is that a port configured to auto-negotiate
can only link up in half duplex the link partner is configured as fixed
speed. This is called parallel detection. The phy is transmitting fast
link pulses (FLP's). On the receive side it can detect FLP's, MLT3
coding for
On Fri, 2010-08-20 at 14:58 -0500, Jim Getker (getker) wrote:
The 6K gigabit copper ports support speed auto 10 100.
Hm... it actually does support speed auto 10 100, but speed auto 100
returns an error (WS-X6748-GE-TX):
Switch(config)#int gi1/1
Switch(config-if)#speed auto 100
Speed
Its an ASIC thing.
What you can configure the port to do is only negotiate at a subset of speeds
it
is capable of. I think this is actually a feature of the ASIC, not software
per
se.
I'm guessing.
From: Peter Rathlev pe...@rathlev.dk
To: Jim Getker
We just didn't see a need to support 10 and 100 individually. There is no
standard regarding this as far as I know.
Jim
-Original Message-
From: Peter Rathlev [mailto:pe...@rathlev.dk]
Sent: Friday, August 20, 2010 4:36 PM
To: Jim Getker (getker)
Cc: cisco-nsp@puck.nether.net
On Fri, 2010-08-20 at 15:54 -0500, Jim Getker (getker) wrote:
We just didn't see a need to support 10 and 100 individually. There
is no standard regarding this as far as I know.
Oh, ok. Fine by me with 10/100 vs. just 100. :-)
The more important point was about correcting this text:
Speed
On Fri, 2010-08-20 at 13:54 -0700, Derick Winkworth wrote:
Its an ASIC thing.
What you can configure the port to do is only negotiate at a subset of
speeds it is capable of. I think this is actually a feature of the
ASIC, not software per se.
But {100} is a subset of {10,100,100} is it
My years-long quest to get a pair of GEIP+ boardsets has finally come to
fruition. However, I have one question.
Does the GEIP+ support 1000BASE-T GBICs? I don't need it to be eligible
for Cisco support; I just need it to work.
Failing that, does the C4912G support 1000BASE-T GBICs?
47 matches
Mail list logo
