True about that being a long time, but I think that's just a matter of how
fast did I plug it in, and how long did it take for my NIC to see it (and
which is a good 1 second delay from when I plug it in and when the NIC LED
goes green).
The one thing I forgot to test was without spanning tree enabled. I tested
the switch with 'no spanning-tree' for 10 times, and 10 times with it
optimally configured with spanning tree on (portfast, full duplex, 100mbit,
power inline never). The hardest thing to test is that Win2k will generate
"Destination host unreachable." when no TCP/IP interfaces are up. It seemed
that if instead of letting a constant ping run and watch pagefulls of those
messages go by, I would instead hit enter as soon as I saw the NIC LED go
green. This definately produces faster results (since the stack isn't being
accessed, perhaps it initilizes faster?).
Anyway, at first I forgot I had DHCP running and was wondering why it was
taking so long (5-7 seconds). It acted the same with spanning tree
disabled, and optimized as stated above. When I configured a static
address, it dropped to 3-4 seconds for both, just as before.
Of course, this isn't scientific, and Win2k doesn't really let you test the
way you could with Win9x or even NT4 (where you could leave it pinging, and
it would just sit there and respond with normal timeouts). Oh, growl, I
just remembered I have Win98SE on this laptop. I'll save this post and go
try it out.
Ok, so I just rebooted to Win98. I must say, it handles lose of
connectivity much better than Win2k, IMHO. I guess it all depends on what
you want it to do: If it's a server/router, then you want the IP stack to
know right away when there is a lost connection and drop it; if it's a
desktop, you don't want to concern the user too fast (so long as the NIC
gets plugged back in rather fast, or they're not generating IP traffic, no
big deal).
What I dislike on Win2k is that the second you lose your connection, you
lose your DHCP lease (it remembers it and will try to renegotiate for it,
but that IP/NIC is gone from the stack). With Win98, you still have it, so
no need to re-negotiate for it when your connection comes back. That
explains why DHCP was taking 2 extra seconds with Win2k (my DHCP server
pings twice to make sure it's not in use before giving it back out). Win98
never checks the DHCP lease due to cable loss, so long as the lease is still
valid.
Anyway, the results seemed to show no discernable different between
optimized spanning tree, and diabled spanning tree. I also tested with
using 'shutdown' and 'no shutdown' instead of physically removing the cable.
Much easier, but the results were the same (my NIC couldn't tell the
difference). 3-4 seconds after bringing the the switch interface up,
pinging would start. The biggest thing I ran into with Win98 is that I
couldn't shut/no shut or unplug/plug too fast, or it would never bring the
stack back up no matter how long I left it (even though the NIC LED was on).
I needed to let it have a good 1-2 seconds of disconnect for it to work.
Perhaps Apple can tell the difference, but 3-4 seconds seemed constant with
or without spanning tree. Perhaps some of the other Cisco switches or OS
bases do things differently, but I don't have access to anything else at the
moment. Anyone else want to post some results with other gear? I was using
'debug spanning events' and 'debug interface f0/6' to see the original
content I was posting.
--
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]...
> Thanks for the testing! I have bad news for you. ;-) Three or 4 seconds is
> a lot of time.
>
> An AppleTalk device sends its AARP frame to see if its address is unique
10
> times, with only 1/5 of a second between tries. Then it sends a
> ZIPGetNetInfo. It tries that 3 times, I think with the same timeout. This
> could happen before the switch is forwarding, even with portfast enabled
it
> seems. (These timeout values may be dated. I haven't looked at AppleTalk
in
> a while! But I bet it's still really fast, perhaps even faster on a G4?
;-)
>
> My guess is that IPX and DHCP are really fast too. ARGH.
>
> Priscilla
>
> At 03:15 PM 5/2/01, Jason Roysdon wrote:
> >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]
> >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]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=2964&t=2564
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
