RE: Spanning Tree Protocol [7:2564]
Unfortunately turning off appletalk isn;t as easy as it sounds. It really depends on the environment. Mac's can use IP for filesharing, however Appletalk needs to be enabled for this to work. There are printing issues that arise from disabling appletalk as well. tim I hear and I forget I see and I believe I do and I understand -Confucius Tim Medley - CCNA, CCDA VoIP Engineer 704-943-3615 - Phone 704-525-9119 - Fax 877-6-iReady - Helpdesk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chuck Larrieu Sent: Wednesday, May 02, 2001 4:59 PM To: [EMAIL PROTECTED] Subject: RE: Spanning Tree Protocol [7:2564] The other way to solve the problem would be to delete AppleTalk and use native IP on your Mac's ;-> ( can't wait for PO's response to this one! ) chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 1:39 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:2564] It took me 10 times to get the thing to allow me to create a new account (each time, it would time out when I hit Continue, and when I'd go back all the form would be blank). Anyway, from the Knowledgebase at http://www.apple.com/support/ it appears that portfast or tuning the spanning tree learning->forwarding time down would solve the problem instead of just disabling spanning tree. Also, it appears to not affect TCP/IP services at all, only AppleTalk (which does it's little song-and-dance at boot to get a unique address): http://www.info.apple.com/kbnum/n30922 TITLE Spanning Tree Protocol: AppleTalk Issues Article ID: 30922 Created: 3/10/99 Modified:3/22/01 TOPIC When the Spanning Tree Protocol is enabled on an Ethernet bridge or switch port to which a Macintosh computer is directly connected the computer may be unable to use AppleTalk services. Enable Fast Convergence Several switch manufacturers have extended the Spanning Tree Protocol to allow the convergence time to be reduced. One of the enhancements usually available is the ability to safely and quickly move the port from the blocked state (listening and learning) to the forwarding state. For example, if the bridge detects a single device attached to a port it can quickly assume that no other bridges are attached to that port and move the port to the forwarding state almost immediately. Check the manufacturer's documentation for specific information on how to configure this option for your switch. For example, Cisco has an option called 'portfast' that can be enabled on most of their switches. For additional information on this feature, see: http://www.cisco.com/warp/public/473/12.html Tune the Forward Delay Timer The Forward Delay timer can be tuned down to the minimum value. This value can usually be tuned down to a few seconds, which would give the switch enough time to move to the forwarding state before the address allocation packets were sent by the computer. If you choose to use this solution you must set these timers in the root bridge. The root bridge is the bridge that transmits these timer settings to all other designated bridges. Although you can set these timers on any bridge only the root bridge can effect the overall environment. Products affected AppleTalk services Macintosh computers ranging from the PowerBook 3400 to the latest Power Mac G4 computers. Note: TCP/IP based services are not affected. Question: Why does this only affect later Macintosh computers? Answer: Later computers start up faster causing the packets used for AppleTalk address assignment to be sent while the port is still in the blocked state. Question: Is Apple planning to change the way AppleTalk addresses are allocated to fix the problem? Answer: Apple has no plans to change the algorithms used for AppleTalk address assignment. -- Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ List email: [EMAIL PROTECTED] Homepage: http://jason.artoo.net/ ""Hire, Ejay"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > There is an Apple knowledgebase article about this issue. > > It is Doc#30922. > > Ejay Hire > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 2:01 PM > To: [EMAIL PROTECTED] > Subject: RE: Spanning Tree Protocol [7:2564] > > > Believe it or not it's true! We did some test/research on it and we had to > modify some of our login processes to allow the switch to go the STP > process for login, it appeared we were requesting to quickly for the switch. > > > -Original Message- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 1:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Spanning Tree Protocol [7:2564] > > > If it really takes 15-30 seconds
Re: Spanning Tree Protocol [7:2564]
Hey, it's fine with me. IP has finally caught up to the 1984 features of AppleTalk (dynamic addressing, service location protocol). ;-) At 06:25 PM 5/2/01, Tom Lisa wrote: >Chuck, you do like living dangerously, don't you?!! :) > >Prof. Tom Lisa, CCAI >Community College of Southern Nevada >Cisco Regional Networking Academy > >Chuck Larrieu wrote: > > > The other way to solve the problem would be to delete AppleTalk and use > > native IP on your Mac's ;-> > > > > ( can't wait for PO's response to this one! ) > > > > chuck > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 02, 2001 1:39 PM > > To: [EMAIL PROTECTED] > > Subject:Re: Spanning Tree Protocol [7:2564] > > > > It took me 10 times to get the thing to allow me to create a new account > > (each time, it would time out when I hit Continue, and when I'd go back all > > the form would be blank). Anyway, from the Knowledgebase at > > http://www.apple.com/support/ it appears that portfast or tuning the > > spanning tree learning->forwarding time down would solve the problem >instead > > of just disabling spanning tree. Also, it appears to not affect TCP/IP > > services at all, only AppleTalk (which does it's little song-and-dance at > > boot to get a unique address): > > > > http://www.info.apple.com/kbnum/n30922 > > > > TITLE > > Spanning Tree Protocol: AppleTalk Issues > > Article ID: 30922 > > Created: 3/10/99 > > Modified:3/22/01 > > > > TOPIC > > When the Spanning Tree Protocol is enabled on an Ethernet bridge or switch > > port to which a Macintosh computer is directly connected the computer may >be > > unable to use AppleTalk services. > > > > Enable Fast Convergence > > > > Several switch manufacturers have extended the Spanning Tree Protocol to > > allow the convergence time to be reduced. One of the enhancements usually > > available is the ability to safely and quickly move the port from the > > blocked state (listening and learning) to the forwarding state. For >example, > > if the bridge detects a single device attached to a port it can quickly > > assume that no other bridges are attached to that port and move the port to > > the forwarding state almost immediately. Check the manufacturer's > > documentation for specific information on how to configure this option for > > your switch. For example, Cisco has an option called 'portfast' that can be > > enabled on most of their switches. For additional information on this > > feature, see: http://www.cisco.com/warp/public/473/12.html > > > > Tune the Forward Delay Timer > > > > The Forward Delay timer can be tuned down to the minimum value. This value > > can usually be tuned down to a few seconds, which would give the switch > > enough time to move to the forwarding state before the address allocation > > packets were sent by the computer. If you choose to use this solution you > > must set these timers in the root bridge. The root bridge is the bridge >that > > transmits these timer settings to all other designated bridges. Although >you > > can set these timers on any bridge only the root bridge can effect the > > overall environment. > > > > Products affected > > > > AppleTalk services > > Macintosh computers ranging from the PowerBook 3400 to the latest Power Mac > > G4 computers. > > Note: TCP/IP based services are not affected. > > > > Question: Why does this only affect later Macintosh computers? > > > > Answer: Later computers start up faster causing the packets used for > > AppleTalk address assignment to be sent while the port is still in the > > blocked state. > > > > Question: Is Apple planning to change the way AppleTalk addresses are > > allocated to fix the problem? > > > > Answer: Apple has no plans to change the algorithms used for AppleTalk > > address assignment. > > > > -- > > Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ > > List email: [EMAIL PROTECTED] > > Homepage: http://jason.artoo.net/ > > > > ""Hire, Ejay"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > There is an Apple knowledgebase article about this issue. > > > > > > It is Doc#30922. > > > > > > Ejay Hire > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAI
Re: Spanning Tree Protocol [7:2564]
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 > > &g
Re: Spanning Tree Protocol [7:2564]
Chuck, you do like living dangerously, don't you?!! :) Prof. Tom Lisa, CCAI Community College of Southern Nevada Cisco Regional Networking Academy Chuck Larrieu wrote: > The other way to solve the problem would be to delete AppleTalk and use > native IP on your Mac's ;-> > > ( can't wait for PO's response to this one! ) > > chuck > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 1:39 PM > To: [EMAIL PROTECTED] > Subject:Re: Spanning Tree Protocol [7:2564] > > It took me 10 times to get the thing to allow me to create a new account > (each time, it would time out when I hit Continue, and when I'd go back all > the form would be blank). Anyway, from the Knowledgebase at > http://www.apple.com/support/ it appears that portfast or tuning the > spanning tree learning->forwarding time down would solve the problem instead > of just disabling spanning tree. Also, it appears to not affect TCP/IP > services at all, only AppleTalk (which does it's little song-and-dance at > boot to get a unique address): > > http://www.info.apple.com/kbnum/n30922 > > TITLE > Spanning Tree Protocol: AppleTalk Issues > Article ID: 30922 > Created: 3/10/99 > Modified:3/22/01 > > TOPIC > When the Spanning Tree Protocol is enabled on an Ethernet bridge or switch > port to which a Macintosh computer is directly connected the computer may be > unable to use AppleTalk services. > > Enable Fast Convergence > > Several switch manufacturers have extended the Spanning Tree Protocol to > allow the convergence time to be reduced. One of the enhancements usually > available is the ability to safely and quickly move the port from the > blocked state (listening and learning) to the forwarding state. For example, > if the bridge detects a single device attached to a port it can quickly > assume that no other bridges are attached to that port and move the port to > the forwarding state almost immediately. Check the manufacturer's > documentation for specific information on how to configure this option for > your switch. For example, Cisco has an option called 'portfast' that can be > enabled on most of their switches. For additional information on this > feature, see: http://www.cisco.com/warp/public/473/12.html > > Tune the Forward Delay Timer > > The Forward Delay timer can be tuned down to the minimum value. This value > can usually be tuned down to a few seconds, which would give the switch > enough time to move to the forwarding state before the address allocation > packets were sent by the computer. If you choose to use this solution you > must set these timers in the root bridge. The root bridge is the bridge that > transmits these timer settings to all other designated bridges. Although you > can set these timers on any bridge only the root bridge can effect the > overall environment. > > Products affected > > AppleTalk services > Macintosh computers ranging from the PowerBook 3400 to the latest Power Mac > G4 computers. > Note: TCP/IP based services are not affected. > > Question: Why does this only affect later Macintosh computers? > > Answer: Later computers start up faster causing the packets used for > AppleTalk address assignment to be sent while the port is still in the > blocked state. > > Question: Is Apple planning to change the way AppleTalk addresses are > allocated to fix the problem? > > Answer: Apple has no plans to change the algorithms used for AppleTalk > address assignment. > > -- > Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ > List email: [EMAIL PROTECTED] > Homepage: http://jason.artoo.net/ > > ""Hire, Ejay"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > There is an Apple knowledgebase article about this issue. > > > > It is Doc#30922. > > > > Ejay Hire > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 02, 2001 2:01 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Spanning Tree Protocol [7:2564] > > > > > > Believe it or not it's true! We did some test/research on it and we had > to > > modify some of our login processes to allow the switch to go the STP > > process for login, it appeared we were requesting to quickly for the > switch. > > > > > > -Original Message- > > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 02, 2001 1:42 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Spanning Tree Protocol [7:2564] > > &
RE: Spanning Tree Protocol [7:2564]
Seen it first hand. Similar environment. Large private school. Spanning tree on a MacIntosh Network. Seemed to hose everything nicely. Not to mention the fact that there were 600 AT nodes on the ethernet network(thats a no-no). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 9: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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2966&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
t; > >""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 > > > >
Re: Spanning Tree Protocol [7:2564]
Odd. Especially even Apple says this doesn't affect TCP/IP services, just AppleTalk. -- Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ List email: [EMAIL PROTECTED] Homepage: http://jason.artoo.net/ ""LeBrun, Tim"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I have been silently listening to this thread with interest. But after he > noted his IOS version I just had to pipe in. I have the exact same version > 12.0(5.2)XU running on a 2924XL. My Macs are also having issues. However, > my issue is slightly different since I have portfast enabled on some ports > and I have a hub on another. The macs all have the same problem of getting > poor response times (very, very, very slow) from SSL sites. However if I > move it from the Cisco switch and plug it into a Fore Systems Ethernet > switch (PS I do not advocate Fore/Marconi switches) they zoom. On the flip > side of this I have a few PCs plugged into a separate VLAN on this switch > and they Zoom. > > Tim LeBrun > CCNA, CCDA > [EMAIL PROTECTED] > > > -Original Message- > From: Jason Roysdon [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 3:16 PM > To: [EMAIL PROTECTED] > Subject: Re: Spanning Tree Protocol [7:2564] > > > 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 > d
RE: Spanning Tree Protocol [7:2564]
I have been silently listening to this thread with interest. But after he noted his IOS version I just had to pipe in. I have the exact same version 12.0(5.2)XU running on a 2924XL. My Macs are also having issues. However, my issue is slightly different since I have portfast enabled on some ports and I have a hub on another. The macs all have the same problem of getting poor response times (very, very, very slow) from SSL sites. However if I move it from the Cisco switch and plug it into a Fore Systems Ethernet switch (PS I do not advocate Fore/Marconi switches) they zoom. On the flip side of this I have a few PCs plugged into a separate VLAN on this switch and they Zoom. Tim LeBrun CCNA, CCDA [EMAIL PROTECTED] -Original Message- From: Jason Roysdon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 3:16 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:2564] 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 th
RE: Spanning Tree Protocol [7:2564]
The other way to solve the problem would be to delete AppleTalk and use native IP on your Mac's ;-> ( can't wait for PO's response to this one! ) chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 1:39 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:2564] It took me 10 times to get the thing to allow me to create a new account (each time, it would time out when I hit Continue, and when I'd go back all the form would be blank). Anyway, from the Knowledgebase at http://www.apple.com/support/ it appears that portfast or tuning the spanning tree learning->forwarding time down would solve the problem instead of just disabling spanning tree. Also, it appears to not affect TCP/IP services at all, only AppleTalk (which does it's little song-and-dance at boot to get a unique address): http://www.info.apple.com/kbnum/n30922 TITLE Spanning Tree Protocol: AppleTalk Issues Article ID: 30922 Created: 3/10/99 Modified:3/22/01 TOPIC When the Spanning Tree Protocol is enabled on an Ethernet bridge or switch port to which a Macintosh computer is directly connected the computer may be unable to use AppleTalk services. Enable Fast Convergence Several switch manufacturers have extended the Spanning Tree Protocol to allow the convergence time to be reduced. One of the enhancements usually available is the ability to safely and quickly move the port from the blocked state (listening and learning) to the forwarding state. For example, if the bridge detects a single device attached to a port it can quickly assume that no other bridges are attached to that port and move the port to the forwarding state almost immediately. Check the manufacturer's documentation for specific information on how to configure this option for your switch. For example, Cisco has an option called 'portfast' that can be enabled on most of their switches. For additional information on this feature, see: http://www.cisco.com/warp/public/473/12.html Tune the Forward Delay Timer The Forward Delay timer can be tuned down to the minimum value. This value can usually be tuned down to a few seconds, which would give the switch enough time to move to the forwarding state before the address allocation packets were sent by the computer. If you choose to use this solution you must set these timers in the root bridge. The root bridge is the bridge that transmits these timer settings to all other designated bridges. Although you can set these timers on any bridge only the root bridge can effect the overall environment. Products affected AppleTalk services Macintosh computers ranging from the PowerBook 3400 to the latest Power Mac G4 computers. Note: TCP/IP based services are not affected. Question: Why does this only affect later Macintosh computers? Answer: Later computers start up faster causing the packets used for AppleTalk address assignment to be sent while the port is still in the blocked state. Question: Is Apple planning to change the way AppleTalk addresses are allocated to fix the problem? Answer: Apple has no plans to change the algorithms used for AppleTalk address assignment. -- Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ List email: [EMAIL PROTECTED] Homepage: http://jason.artoo.net/ ""Hire, Ejay"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > There is an Apple knowledgebase article about this issue. > > It is Doc#30922. > > Ejay Hire > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 2:01 PM > To: [EMAIL PROTECTED] > Subject: RE: Spanning Tree Protocol [7:2564] > > > Believe it or not it's true! We did some test/research on it and we had to > modify some of our login processes to allow the switch to go the STP > process for login, it appeared we were requesting to quickly for the switch. > > > -Original Message----- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 1:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Spanning Tree Protocol [7:2564] > > > If it really takes 15-30 seconds for a switch to forward even when portfast > is enabled, I can see why AppleTalk nodes would hate this. An AppleTalk > node sends messages right away to make sure its own address is unique, and > to find the nearest router, and verify the network number(s) and zone > name(s) for its local network. If the switch isn't forwarding these frames, > the Mac will think it's on a non-routed single network, when it probably > isn't. Worst of all, it might end up with the same address as some other > AppleTalk device. > > However.. I find it hard to believe that even with portfast enabled a > switch takes 15-30 seconds
Re: Spanning Tree Protocol [7:2564]
It took me 10 times to get the thing to allow me to create a new account (each time, it would time out when I hit Continue, and when I'd go back all the form would be blank). Anyway, from the Knowledgebase at http://www.apple.com/support/ it appears that portfast or tuning the spanning tree learning->forwarding time down would solve the problem instead of just disabling spanning tree. Also, it appears to not affect TCP/IP services at all, only AppleTalk (which does it's little song-and-dance at boot to get a unique address): http://www.info.apple.com/kbnum/n30922 TITLE Spanning Tree Protocol: AppleTalk Issues Article ID: 30922 Created: 3/10/99 Modified:3/22/01 TOPIC When the Spanning Tree Protocol is enabled on an Ethernet bridge or switch port to which a Macintosh computer is directly connected the computer may be unable to use AppleTalk services. Enable Fast Convergence Several switch manufacturers have extended the Spanning Tree Protocol to allow the convergence time to be reduced. One of the enhancements usually available is the ability to safely and quickly move the port from the blocked state (listening and learning) to the forwarding state. For example, if the bridge detects a single device attached to a port it can quickly assume that no other bridges are attached to that port and move the port to the forwarding state almost immediately. Check the manufacturer's documentation for specific information on how to configure this option for your switch. For example, Cisco has an option called 'portfast' that can be enabled on most of their switches. For additional information on this feature, see: http://www.cisco.com/warp/public/473/12.html Tune the Forward Delay Timer The Forward Delay timer can be tuned down to the minimum value. This value can usually be tuned down to a few seconds, which would give the switch enough time to move to the forwarding state before the address allocation packets were sent by the computer. If you choose to use this solution you must set these timers in the root bridge. The root bridge is the bridge that transmits these timer settings to all other designated bridges. Although you can set these timers on any bridge only the root bridge can effect the overall environment. Products affected AppleTalk services Macintosh computers ranging from the PowerBook 3400 to the latest Power Mac G4 computers. Note: TCP/IP based services are not affected. Question: Why does this only affect later Macintosh computers? Answer: Later computers start up faster causing the packets used for AppleTalk address assignment to be sent while the port is still in the blocked state. Question: Is Apple planning to change the way AppleTalk addresses are allocated to fix the problem? Answer: Apple has no plans to change the algorithms used for AppleTalk address assignment. -- Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ List email: [EMAIL PROTECTED] Homepage: http://jason.artoo.net/ ""Hire, Ejay"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > There is an Apple knowledgebase article about this issue. > > It is Doc#30922. > > Ejay Hire > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 2:01 PM > To: [EMAIL PROTECTED] > Subject: RE: Spanning Tree Protocol [7:2564] > > > Believe it or not it's true! We did some test/research on it and we had to > modify some of our login processes to allow the switch to go the STP > process for login, it appeared we were requesting to quickly for the switch. > > > -Original Message- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 1:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Spanning Tree Protocol [7:2564] > > > If it really takes 15-30 seconds for a switch to forward even when portfast > is enabled, I can see why AppleTalk nodes would hate this. An AppleTalk > node sends messages right away to make sure its own address is unique, and > to find the nearest router, and verify the network number(s) and zone > name(s) for its local network. If the switch isn't forwarding these frames, > the Mac will think it's on a non-routed single network, when it probably > isn't. Worst of all, it might end up with the same address as some other > AppleTalk device. > > However.. I find it hard to believe that even with portfast enabled a > switch takes 15-30 seconds to forward traffic. Is that really true? > > Priscilla > > At 01:22 AM 5/2/01, Jim Gillen wrote: > >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 portf
Re: Spanning Tree Protocol [7:2564]
Leigh Anne Chisholm wrote: > > 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. > Well, this is picking nits, but the STP forwarding delay is only 30 seconds. The 50 second delay only occurs if the path to root is lost such that the root BPDU is not heard for maxage (20) seconds. A leaf user port only takes a 30-second hit. > 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. > Portfast doesn't disable STP at all. All it does is cause forwarding to occur without the conservative delay for listening and learning. The port still listens for BPDUs, will detect a topology loop, and will go into blocking to break that loop. But I definitely agree with Leigh Anne that it's a BAD idea to disable STP! But before STP ever gets a chance to do anything with a port, three other phases must complete: 1) speed/duplex auto-negotiation -- max of 3 seconds per the standard. 2) negotiation of trunking via DTP 3) negotiation of Etherchannel via PAgP The last two are typically very fast if the device on the other side is capable of negotiating. If not, then the retries for each can add up to as much as 15-20 seconds, depending on platform and code release. In CatOS, the macro "set port host" disables both of these and enables STP fast-forward/portfast. You can observe the progress by making the logging a bit more verbose: "set logging level spantree 6". And while we're at it, enable bpdu-guard so if someone does back-door and create a loop, the portfast-enabled port will be disabled. I'd love to see if that makes the Macs happy. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2949&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
What switch and OS? I'm wondering if Cisco hasn't changed some thing since you ran into this. I think on a 6500 install we had it at about 10 seconds after power-on that a PC would be up (tcp/ip stack loaded) and successfully requesting a DHCP'd address (and not have any problems once portfast was set). -- Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ List email: [EMAIL PROTECTED] Homepage: http://jason.artoo.net/ wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Believe it or not it's true! We did some test/research on it and we had to > modify some of our login processes to allow the switch to go the STP > process for login, it appeared we were requesting to quickly for the switch. > > > -Original Message- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 02, 2001 1:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Spanning Tree Protocol [7:2564] > > > If it really takes 15-30 seconds for a switch to forward even when portfast > is enabled, I can see why AppleTalk nodes would hate this. An AppleTalk > node sends messages right away to make sure its own address is unique, and > to find the nearest router, and verify the network number(s) and zone > name(s) for its local network. If the switch isn't forwarding these frames, > the Mac will think it's on a non-routed single network, when it probably > isn't. Worst of all, it might end up with the same address as some other > AppleTalk device. > > However.. I find it hard to believe that even with portfast enabled a > switch takes 15-30 seconds to forward traffic. Is that really true? > > Priscilla > > At 01:22 AM 5/2/01, Jim Gillen wrote: > >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 Spa
Re: Spanning Tree Protocol [7:2564]
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
RE: Spanning Tree Protocol [7:2564]
There is an Apple knowledgebase article about this issue. It is Doc#30922. Ejay Hire -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 2:01 PM To: [EMAIL PROTECTED] Subject: RE: Spanning Tree Protocol [7:2564] Believe it or not it's true! We did some test/research on it and we had to modify some of our login processes to allow the switch to go the STP process for login, it appeared we were requesting to quickly for the switch. -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 1:42 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:2564] If it really takes 15-30 seconds for a switch to forward even when portfast is enabled, I can see why AppleTalk nodes would hate this. An AppleTalk node sends messages right away to make sure its own address is unique, and to find the nearest router, and verify the network number(s) and zone name(s) for its local network. If the switch isn't forwarding these frames, the Mac will think it's on a non-routed single network, when it probably isn't. Worst of all, it might end up with the same address as some other AppleTalk device. However.. I find it hard to believe that even with portfast enabled a switch takes 15-30 seconds to forward traffic. Is that really true? Priscilla At 01:22 AM 5/2/01, Jim Gillen wrote: >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
Re: Spanning Tree Protocol [7:2564]
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 wr
RE: Spanning Tree Protocol [7:2564]
Believe it or not it's true! We did some test/research on it and we had to modify some of our login processes to allow the switch to go the STP process for login, it appeared we were requesting to quickly for the switch. -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 1:42 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:2564] If it really takes 15-30 seconds for a switch to forward even when portfast is enabled, I can see why AppleTalk nodes would hate this. An AppleTalk node sends messages right away to make sure its own address is unique, and to find the nearest router, and verify the network number(s) and zone name(s) for its local network. If the switch isn't forwarding these frames, the Mac will think it's on a non-routed single network, when it probably isn't. Worst of all, it might end up with the same address as some other AppleTalk device. However.. I find it hard to believe that even with portfast enabled a switch takes 15-30 seconds to forward traffic. Is that really true? Priscilla At 01:22 AM 5/2/01, Jim Gillen wrote: >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 ki
Re: Spanning Tree Protocol [7:2564]
If it really takes 15-30 seconds for a switch to forward even when portfast is enabled, I can see why AppleTalk nodes would hate this. An AppleTalk node sends messages right away to make sure its own address is unique, and to find the nearest router, and verify the network number(s) and zone name(s) for its local network. If the switch isn't forwarding these frames, the Mac will think it's on a non-routed single network, when it probably isn't. Worst of all, it might end up with the same address as some other AppleTalk device. However.. I find it hard to believe that even with portfast enabled a switch takes 15-30 seconds to forward traffic. Is that really true? Priscilla At 01:22 AM 5/2/01, Jim Gillen wrote: >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
Re: Spanning Tree Protocol [7:2564]
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 > > > >al
Re: Spanning Tree Protocol [7:2564]
On Wed, May 02, 2001 at 01:22:50AM -0400, Jim Gillen wrote: > 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. The document in question is: Using Portfast and Other Commands to Fix Workstation Startup Connectivity Delays http://www.cisco.com/warp/public/473/12.html To summarize, there are four issues that can cause switchport startup delay: 1. Spanning Tree 2. EtherChannel negotiation (PAgP) 3. Trunking negotiation (DISL/DTP) 4. Link speed and duplex negotiation The solution is to disable these negotiation processes on ports connected to end systems. The first three can be disabled with the 'set port host' macro on switches running CatOS >= 5.2. They can, of course, also be disabled individually. The last can be dealt with by explicitly specifying the port speed and duplex mode. -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2856&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Spanning Tree Protocol [7:2564]
Jason, I used to work for Apple in the Higher Ed channel. I've run into this a few times, portfast should remedy this in most cases. Also look at the speed/duplex settings by default a mac uses auto negotiation and there isn't an "Apple" way to hardcode the speed/duplex. There are a couple of freeware utilities that will allow you to hack the speed/duplex and hardcode them. If the speed/duplex isn't an issue and portfast doesn't help, you could always dangle a hub from a switch port and plug the mac's in the the hub. tim I hear and I forget I see and I believe I do and I understand -Confucius Tim Medley - CCNA, CCDA VoIP Engineer 704-943-3615 - Phone 704-525-9119 - Fax 877-6-iReady - Helpdesk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 11:30 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:2564] 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, > &
Re: Spanning Tree Protocol [7:2564]
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 > > > > &
RE: Spanning Tree Protocol [7:2564]
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 defa
Re: Spanning Tree Protocol [7:2564]
It's the same old thing. You gotta turn on portfast. P. At 09:15 PM 4/30/01, Jason Roysdon wrote: >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] Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2676&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2673&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2666&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Spanning Tree Protocol [7:2564]
Config t interface FastEthernet0/1 spanning-tree portfast Tim LeBrun CCNA, CCDA [EMAIL PROTECTED] -Original Message- From: Bob Edmonds [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 3:55 PM To: [EMAIL PROTECTED] Subject: Re: Spanning Tree Protocol [7:2564] How exactly do you configure portfast on a 2924XL-EN? Just wanna try it out! Thanks Bob Edmonds CCNA, Network+ ""John Gotti"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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] 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=2611&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
How exactly do you configure portfast on a 2924XL-EN? Just wanna try it out! Thanks Bob Edmonds CCNA, Network+ ""John Gotti"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2603&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Spanning Tree Protocol [7:2564]
A few comments. First, not being able to obtain a DHCP lease upon initial boot isn't "a problem related to Cisco's Spanning Tree Protocol" implementation. Cisco implements the IEEE 802.1D STP algorithm that specifies when a port becomes active, it must go through the blocking, listening, and learning phases before it can be switched to forwarding mode. By default, Spanning Tree Protocol to transition from the blocking phase to the forwarding phase is 50 seconds. A port is to remain in the blocking phase for 20 seconds. It then transitions to the listening phase that lasts 15 seconds. Once the listening phase has been completed, the port transitions to the learning phase, which is 15 seconds in length. It's become commonplace for many newer PCs and operating systems to send DHCP requests well in advance of 50 seconds of system boot - which creates the problem of not being able to initially obtain a DHCP lease. If a PC is not configured to bridge frames between LAN segments, the switch port to which the PC is connected can safely begin forwarding frames immediately. -- Leigh Anne Chisholm > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > John Gotti > Sent: April 30, 2001 8:44 AM > To: [EMAIL PROTECTED] > Subject: Spanning Tree Protocol [7:2564] > > > 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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2596&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
What you were told sounds correct to me. If you have a port that is only connecting to workstations or servers then turn on portfast for that port. That will prevent you from having problems with DHCP. At 08:43 AM 4/30/01, you 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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2578&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
Strongly in favour, A similar problem occurs in an IPX environment. Make sure all Servers/Clients are 'portfast' and switch/switch disable 'portfast'. 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2575&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Spanning Tree Protocol [7:2564]
This is definitely a spanning tree issue. Enabling port fast on the access ports will get rid of the problem. CM -Original Message- From: John Gotti [mailto:[EMAIL PROTECTED]] Sent: 30 April 2001 15:44 To: [EMAIL PROTECTED] Subject: Spanning Tree Protocol [7:2564] 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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2573&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
By the way, where is the DHCP server, if your DHCP is located in the other vlan, you need add ip-helper address in your router. Hope this help Vincent Chong ""John Gotti"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2568&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
Try portfast, if connecrivity issue. ""John Gotti"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2567&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]