I wonder what switch and software version you were running at the time? I'm
trying this on a Catalyst 3524 XL Inline Power running 12.0(5.2)XU (I
haven't upgraded it, so that's whatever it shipped with).
I did a number of tests (but not enough samples to make it 100% accurate on
the timing, but a general idea +/- 2 seconds). The digits "00:16:47," are
time since boot, while the dated timestamps are accurate GMT. For each of
my tests, I would attempt to physically plug in the patch cable at :00
seconds based on the clock on my laptop, and both the laptop and switch are
accurate from ntp (the log is not timestamped at :00 seconds, but just for
your reference).
The first with the port in the "out of the box" state with it left at
defaults:
00:16:54: ST: FastEthernet0/6 vlan 1 -> listening
May 2 11:33:02.985 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed
state to up
May 2 11:33:03.986 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/6,
changed state to up
00:17:09: ST: FastEthernet0/6 vlan 1 -> learning
00:17:24: ST: sent Topology Change Notice on Port Group 1 vlan 1
00:17:24: ST: FastEthernet0/6 vlan 1 -> forwarding
! 32 seconds
At 32 seconds I had ping replies at my desktop (using a static address, as
DHCP wouldn't be accurate to see how fast it comes up).
Next, I wanted to see if the inline power slowed bringing the power up. It
doesn't appear to (of course, thinking about it, the only time it applies
power is if it sees a certain loop/load between a pair of wires, the details
I don't recall):
Cat3524(config-if)#power inline never
00:18:54: ST: FastEthernet0/6 vlan 1 -> listening
May 2 11:35:02.497 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed
state to up
May 2 11:35:03.498 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/6,
changed state to up
00:19:09: ST: FastEthernet0/6 vlan 1 -> learning
00:19:24: ST: sent Topology Change Notice on Port Group 1 vlan 1
00:19:24: ST: FastEthernet0/6 vlan 1 -> forwarding
!32 seconds
Again, 32 seconds with spanning tree left to the defaults. 30 seconds as
far as the switch was concerned.
Now lets enable portfast:
Cat3524(config-if)#span portfast
00:20:54: ST: FastEthernet0/6 vlan 1 ->jump to forwarding from blocking
May 2 11:37:02.483 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed
state to up
May 2 11:37:03.485 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/6,
changed state to up
! 3 seconds
In 3 seconds my PC was pinging with portfast set.
My final test, I wanted to see if locking to speed and duplex would increase
the time at all:
interface FastEthernet0/6
duplex full
speed 100
power inline never
spanning-tree portfast
Cat3524#
00:22:54: ST: FastEthernet0/6 vlan 1 ->jump to forwarding from blocking
May 2 11:39:03.165 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed
state to up
May 2 11:39:04.166 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/6,
changed state to up
May 2 11:39:06.622 PDT: %RTD-1-LINK_FLAP: FastEthernet0/6 link down/up 5
times per minsh
int
Oops, the switch doesn't like all the flapping of my tests and left it in an
down/up state (good thing to know though!).
Ok, give it a moment without the cable connected and try again:
Cat3524#
00:26:54: ST: FastEthernet0/6 vlan 1 ->jump to forwarding from blocking
May 2 11:43:03.200 PDT: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed
state to up
May 2 11:43:04.201 PDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/6,
changed state to up
!4 seconds
I think this time I was a little slow getting the cable in, but basically
the same results, 3-4 seconds and the port is up and pinging from my
connected laptop. That shouldn't be a problem for any network devices, I
wouldn't think. The only way I could see it affecting is if during boot the
NIC is not activated until the drivers load, and then within 1-2 seconds the
protocol stack gets access to the NIC before the switch takes the port
up/up, but I don't think this would be any different with or without
spanning-tree enabled.
--
Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
List email: [EMAIL PROTECTED]
Homepage: http://jason.artoo.net/
""Jim Gillen"" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I have had plenty of experience with this problem when I updated a token
ring
> network to a fully switched ethernet network.
>
> CISCO has a document on spanning tree and these types of problems.
>
> Enabling portfast still means that it takes 15-30sec for the port on a
switch
> to come up. If you workstation needs to attach to a server (as with the
> Novell
> Client) by sending GetNearestServer (or the like packets) and it needs a
> reply
> to attach during that 15 - 30 sec then it will fail to connect. There may
be
> other problems with the Mac's -???
>
> I would read the document on the CISCO site and then if that doesn't help
let
> us know what is the nature of the problem.
>
>
>
>
>
> >>> "Jason Roysdon" 2/05/01 13:30:21 >>>
> This message has been scanned by MAILSweeper.
> ************************************************************
>
> The customer claims that even with portfast enabled the Macs won't
function
> due to Spanning tree. Has anyone else heard any such rumors about this?
My
> guess, as you suggested, is that portfast would solve it, but supposedly
it
> was tried before disabling spanning tree.
>
> --
> Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
> List email: [EMAIL PROTECTED]
> Homepage: http://jason.artoo.net/
>
>
>
> ""Leigh Anne Chisholm"" wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > It's a symptom of the problem I wrote about earlier in this thread.
When
> a
> > MAC becomes active on the network, the computer isn't able to
communicate
> for
> > the first 50 seconds the port detects the end-system is active. The
port
> > begins in blocking mode, then transitions to listening, then learning.
> > Finally, once STP determines that a looped topology hasn't occurred, the
> port
> > is set to forwarding mode. This creates havoc with any end-system that
> > expects to receive over-the-network information within the first 50
> seconds.
> > IP, IPX, AppleTalk - all face the same issue.
> >
> > The simple solution isn't to kill Spanning Tree on all switches - that's
> the
> > "I don't understand the problem so I'll do whatever works and create a
> bigger
> > problem" solution. The real solution is to enable portfast on all
switch
> > ports that have end-systems directly connected. The caveat to this is
to
> > ensure none of the end-systems are capable as acting as a bridge,
> forwarding
> > packets between LAN segments. Enabling portfast essentially disables
> > Spanning
> > Tree on a port - and Spanning Tree is used to ensure a loop-free
> environment.
> >
> >
> > -- Leigh Anne
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: April 30, 2001 7:15 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Spanning Tree Protocol [7:2564]
> > >
> > >
> > > Oh, speaking of AppleTalk. We've got a customer (not mine, but one of
> the
> > > engineers working the account bounced this off me): They claim their
> new
> > > Macs can't access the network if Spanning Tree is enabled. Supposedly
> this
> > > has been verified by Apple and TAC (but we've never had a customer lie
> to
> > > us, so that must be gospel, right. Heh, not). I don't know what
> exactly
> > > the details are, but basically it just doesn't function. The simple
> > > solution is to kill spanning-tree on all the switches, but this is at
a
> > > number of public schools, and I can't wait to hear about a kid
bringing
> in
> > > his Linksys 8 port 10/100 switch and melting their network.
> > >
> > > Anyone else hear such rumors?
> > >
> > > --
> > > Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
> > > List email: [EMAIL PROTECTED]
> > > Homepage: http://jason.artoo.net/
> > >
> > >
> > >
> > > ""Priscilla Oppenheimer"" wrote in message
> > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > > At 11:08 AM 4/30/01, Phil Barker wrote:
> > > > >Strongly in favour,
> > > > >
> > > > >A similar problem occurs in an IPX environment.
> > > > >Make sure all Servers/Clients are 'portfast' and
> > > > >switch/switch disable 'portfast'.
> > > >
> > > > A similar problem happens with AppleTalk too. That's what we get for
> > > > expecting switches to replace hubs in a topology. ;-) They were
> designed
> > > as
> > > > bridges and to talk to other bridges. Despite switches being the
> > > > new-fangled thing (well, sort of new), a lot of their functionality
is
> > > > vintage 1980s.
> > > >
> > > > Priscilla
> > > >
> > > >
> > > > >Regards,
> > > > >
> > > > >Phil.
> > > > >--- John Gotti wrote: > Hey
> > > > >all...we are having a problem where workstations
> > > > > > sporatically will not
> > > > > > be able to obtain an IP address from our DHCP
> > > > > > server. After about 4 minutes,
> > > > > > you can perform a manual renew from WINIPCFG and you
> > > > > > get your IP address.
> > > > > > This has baffled me for quite some time and I have
> > > > > > recently been told it is
> > > > > > our Cisco 2924 Switch to blame. The story I was told
> > > > > > is below. I welcome any
> > > > > > comments for or against this opinion. Thank you for
> > > > > > your time.
> > > > > >
> > > > > >
> > > > > > "It appears the problem is connected to the
> > > > > > spanning tree algorithm used
> > > > > > by the CISCO switches. By default, ports on the
> > > > > > switch block as they are
> > > > > > initialised; during this phase the port is in its
> > > > > > spanning tree algorithm
> > > > > > learning and listening state - it is not
> > > > > > forwarding. This is specifically
> > > > > > aimed at ports that will be used to connect to other
> > > > > > switches/routers in a
> > > > > > stack. After a default time (4 mins?) they switch to
> > > > > > the standard forwarding
> > > > > > mode and everything seems normal, the problem is
> > > > > > that you have missed all
> > > > > > the important DHCP broadcast and acknowledgment from
> > > > > > client to DHCP server
> > > > > > during this period.
> > > > > >
> > > > > > You can change this default state by changing the
> > > > > > PORT-FAST setting on
> > > > > > each port. The port is then immediately in the
> > > > > > FORWARDING mode as it is
> > > > > > initialised. By default this setting is DISABLED,
> > > > > > I have ENABLED all
> > > > > > ports except the ports doing the linking to other
> > > > > > switches"
> > > > > >
> > > > >_________________________________________________________________
> > > > > > Get your FREE download of MSN Explorer at
> > > > > > http://explorer.msn.com
> > > > > > FAQ, list archives, and subscription info:
> > > > > > http://www.groupstudy.com/list/cisco.html
> > > > > > Report misconduct and Nondisclosure violations to
> > > > >[EMAIL PROTECTED]
> > > > >
> > > > >
> > > > >____________________________________________________________
> > > > >Do You Yahoo!?
> > > > >Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> > > > >or your free @yahoo.ie address at http://mail.yahoo.ie
> > > > >FAQ, list archives, and subscription info:
> > > > >http://www.groupstudy.com/list/cisco.html
> > > > >Report misconduct and Nondisclosure violations to
> [EMAIL PROTECTED]
> > > >
> > > >
> > > > ________________________
> > > >
> > > > Priscilla Oppenheimer
> > > > http://www.priscilla.com
> > > > FAQ, list archives, and subscription info:
> > > http://www.groupstudy.com/list/cisco.html
> > > > Report misconduct and Nondisclosure violations to
[EMAIL PROTECTED]
> > > FAQ, list archives, and subscription info:
> > > http://www.groupstudy.com/list/cisco.html
> > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> > FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=2931&t=2564
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
