Testing Fastport on a 2950.. and having problems

pogue

I enabled Fastport on a non-trunked link, as a method of testing my grasp of the concept.

This port is directly connected to my USB-Ethernet adapter on my laptop. This adapter is configured with a static ip address...

I start a continuous ping from myy laptop to the switch. While consoled into the router, I pull the CAT5 out of my USB-Ethernet device. Port goes down on the switch. Ping begins timing out.

Now, with Fastport enabled on this port, am I not correct that when I plug the cable back in, it should come up immediately? And my ping should come up almost immediately?

The link light on my USB-Ethernet adapter comes back up immediately, but the ping fails for approximately another full minute. I thought it might take a certain time period for the adapter to come up fully, so I monitored the link status, which comes up approx. 15-20 seconds after reconnection.

To me, this seems like STP is actively stopping the forwarding of traffic until the hold down timers expire.

Is there something I am missing here? The time for the ping to resume is very consistent, at right around 1 minute.

Russ

gojericho0

are you able to post a copy of your config? You don't have your NIC trying to get a DHCP address do you?

pogue

Fa0/1 is the port in question...

Thanks,

Russ


New_Switch#sho run
Building configuration...

Current configuration : 3236 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname New_Switch
!
enable secret 5 $1$J0QK$neMxsRbyQ.Z4joycto7Ry.
!
ip subnet-zero
!
spanning-tree mode pvst
spanning-tree portfast default
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
!
!
interface FastEthernet0/1
switchport mode access
switchport nonegotiate
no ip address
spanning-tree portfast
!
(Deleted)

interface FastEthernet0/10
switchport mode trunk
no ip address
!
interface FastEthernet0/11
switchport mode access
switchport nonegotiate
no ip address
!
interface FastEthernet0/12
switchport mode access
switchport nonegotiate
no ip address
!

(Deleted)


interface GigabitEthernet0/1
no ip address
!
interface GigabitEthernet0/2
no ip address
!
interface Vlan1
ip address 172.16.5.5 255.255.255.0
no ip route-cache
!
interface Vlan2
description RUSS
ip address 172.16.6.1 255.255.255.0
no ip route-cache
shutdown
!
interface Vlan7
description BALLYHOO
ip address 172.16.7.1 255.255.255.0
no ip route-cache
shutdown
!
interface Vlan8
ip address 172.16.8.1 255.255.255.0
no ip route-cache
shutdown
!
ip http server
!
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password 7 070C285F4D06
login
line vty 5 15
password 7 00071A150754
login
!
end

/usr

I apologize if I looked over this in your config, but have you configured RSTP on the switch?

You're assumption is correct, the port should come back up in around a second with portfast enabled on the edge port, assuming you're using RSTP.

If you're using plain old STP, convergence time should be around 50 seconds, which is about how long you're saying it's taking to come up.

To confirm, do a "show spanning-tree".

luke_bibby

Nup hes got plain old stp enabled:

spanning-tree mode pvst

But yeah the port should go to Forwarding pretty much straight away with portfast enabled

rakem

/usr wrote: »

I apologize if I looked over this in your config, but have you configured RSTP on the switch?

You're assumption is correct, the port should come back up in around a second with portfast enabled on the edge port, assuming you're using RSTP.

If you're using plain old STP, convergence time should be around 50 seconds, which is about how long you're saying it's taking to come up.

To confirm, do a "show spanning-tree".

It doesn't matter if he is using RSTP or PVST or not, if a port is portfast it will transition to the forwarding state straight away.

pogue

I spent a little more time troubleshooting the issue, and I am pretty sure it is the USB-Ethernet adapter that I am currently using because my onboard 10/100 card is shot in this laptop.

While monitoring the continuous ping from the laptop, I also pulled up the network connection info specific to this adapter and monitored it as well. The adapter is not even sending out packets for the first 50 seconds or so once the link is reconnected.

When the CAT5 is pulled and reconnected, I guess the logical part of the adapter goes down, but not the physical part, as the port comes right back to an up/up status on the switch. Even with the continuous ping going in DOS, looking right at the connection, nothing is being sent by the adapter..

Wierd.

I guess I have to try another PC. The one I am on is also Vista, so funky drivers may be the problem instead of the adapter...

Russ

/usr

It doesn't matter if he is using RSTP or PVST or not, if a port is portfast it will transition to the forwarding state straight away

If you say so...but Cisco seems to have a different opinion.

From the Catalyst 2950 documentation found here...

Catalyst 2950 Desktop Switch Software Configuration Guide, 12.1(9)EA1 - Configuring RSTP and MSTP [Cisco Catalyst 2950 Series Switches] - Cisco Systems

The RSTP provides for rapid recovery of connectivity following the failure of switch, a switch port, or a LAN. It provides rapid convergence for edge ports, new root ports, and ports connected through point-to-point links as follows:
•Edge ports—If you configure a port as an edge port on an RSTP switch by using the spanning-tree portfast interface configuration command, the edge port immediately transitions to the forwarding state. An edge port is the same as a Port Fast-enabled port, and you should enable it only on ports that connect to a single end station.

Regardless of whether or not I'm right, I am still interested in seeing whether or not enabling RSTP fixes this issue because I have a sneaking suspicion that it will, but then again, I've been wrong before.

/usr

Try enabling RSTP, if for no other reason than to ease my curiosity.

Your NIC should not be "bad" if the only issue is that it's taking a minute to come up. If it's working properly AFTER coming up, doesn't periodically go down, and works fine with all other applications, then my guess is that it's fine.

pogue

/usr wrote: »

Try enabling RSTP, if for no other reason than to ease my curiosity.

Your NIC should not be "bad" if the only issue is that it's taking a minute to come up. If it's working properly AFTER coming up, doesn't periodically go down, and works fine with all other applications, then my guess is that it's fine.

New config, same issue. I'm not saying the NIC is "bad" per se, just that it does not allow me to properly test STP vs. RSTP, because of the lag time with the adapter coming up.

Basically, to have any idea whether STP or RSTP are having a pronounced impact, I need a NIC that grabs the connection within seconds.

Russ

New_Switch#sho conf
Using 3244 out of 32768 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname New_Switch
!
enable secret 5 $1$J0QK$neMxsRbyQ.Z4joycto7Ry.
!
ip subnet-zero
!
!
spanning-tree mode rapid-pvst
spanning-tree portfast default
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id

/usr

Apparently I stand corrected, but I would still like someone else to confirm whether or not an edge port, with portfast enabled, will immediately come back up if only plain STP is enabled.

My next question is...what in the hell kind of laptop are you using that doesn't have an onboard ethernet port?

pogue

/usr wrote: »

Apparently I stand corrected, but I would still like someone else to confirm whether or not an edge port, with portfast enabled, will immediately come back up if only plain STP is enabled.

My next question is...what in the hell kind of laptop are you using that doesn't have an onboard ethernet port?

It does have one, but I think HP made it with an ever so slightly undersized RJ45 receptacle, as every single CAT5 I tried to connect to it was an EXTREMELY tight fit.

Did not matter if it had professional type rubber coating, or just an RJ45 connector clamped onto the end of a cable..I had a very hard time inserting a cable into this receptacle. When I got it in, it worked fine, but having to force the cable, and having to pull hard to get it back out, eventually a pin got bent, and that, as they say, was that.

The funny thing is, I was going to take it back to Best Buy and force some sort of exchange after I got the cable out the last time. [After having a nice technician "demonstrate" how easy it was to insert a sable, lol] And the last time is when the connector was damaged, pretty much destroying any chance I had of a return..

I am gonna try another way to test STP/RSTP.. I have 2 2924's (non RSTP, I think), and one 2950 connected to each other, no redundant links..

Gonna ping from switch3 (2950, with RSTP) to switch1..And then connect SW1 to SW3 on another port. This should temporarily drop the ping whilst RSTP blocks all ports during the negotiation phase....

Should be down 1-2 seconds....

If that works, I will disable RSTP, and see how STP handles the same thing..

Gotta go check the two ports I am gonna connect for configuration..I'll be right back with results...

Russ

rakem

/usr wrote: »

Apparently I stand corrected, but I would still like someone else to confirm whether or not an edge port, with portfast enabled, will immediately come back up if only plain STP is enabled.

Trust me dude, it does. That quote you posted from the cisco site doesn't mention PVST....

I have a 2960 on my desk and tested it and it does.

/usr

What does PVST have to do with STP versus RSTP convergence times?

PVST simply means that a separate instance of spanning tree can be ran on each VLAN, correct?

rakem

/usr wrote: »

What does PVST have to do with STP versus RSTP convergence times?

PVST simply means that a separate instance of spanning tree can be ran on each VLAN, correct?

Yes. But the command to enable normal or old STP on a switch is 'spanning-tree mode pvst'

So normal spanning tree is sometimes refered to as PVST.....

Edit: On new switches ieee STP is not supported anymore, so the command 'spanning-tree mode ieee' is not support. PVST is the default these days

pogue

I tried the experiment as listed above, and the 3rd switch cannot communicate with either of the others, even though the other two are both forwarding on both of their connected ports..

I am quite perplexed, actually. I have three switches set up in a triangle type configurqtion for redundancy.. Two of the switches have both ports forwarding, and the third has one port forwarding, as expected... But the third switch cannot ping either of the other two.

I disconnected the redundant link..and now all can communicate freely..

I reconnect it again, and now the SECOND switch is unreachable, though both other switches are in a forwarding state on the connected links.

?????

Russ

rakem

post your configs from all the switches....

pogue

rakem wrote: »

post your configs from all the switches....

I will after this post if you still want them..

I changed the link between SW1 and SW3 to be a trunk, and that stopped the connectivity problems.

Only thing is now.. Spanning Tree converges WAY too fast..

In SW3, I have

spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id

trunk to SW1

interface FastEthernet0/9
switchport mode trunk
switchport nonegotiate
no ip address

Trunk to SW2

interface FastEthernet0/10
switchport mode trunk
no ip address

By my estimates, with this configuration, when I disconnect/reconnect fa0/9 to break/reform the redundant link, it should take almost a minute to converge, with no fastport or rapid spanning tree configured..

Doing an extended ping from SW3 to SW1, I don't even drop a packet when I disconnect/reconnect the trunk between them.

????

This Spanning Tree stuff is kicking my arse.

Russ

rakem

perhaps they were already in blocking state, so when you disconnect, there is nothing to converge.... same as when you reconnet.

post the output from show spanning-tree

pogue

rakem wrote: »

perhaps they were already in blocking state, so when you disconnect, there is nothing to converge.... same as when you reconnet.

post the output from show spanning-tree

I ended up blowing away the config on all three switches and starting from scratch..

No trunks this time, and the switches behave as normal, one blocking port in the whole configuration..

Regular STP took about 45-55 seconds to converge, and RSTP took about 10-15 to converge, from the perspective of a customer ping,

In my setup, only 1 of the 3 switches is capable of RSTP, so that might account for the slower RSTP convergence..

Russ

Santucci4

Are the 2950G switches capable of running the RSTP?

pogue

Santucci4 wrote: »

Are the 2950G switches capable of running the RSTP?

Yes, I have it enabled on both my 2950s right now..

Russ

APA

pogue wrote: »

I ended up blowing away the config on all three switches and starting from scratch..

No trunks this time, and the switches behave as normal, one blocking port in the whole configuration..

Regular STP took about 45-55 seconds to converge, and RSTP took about 10-15 to converge, from the perspective of a customer ping,

In my setup, only 1 of the 3 switches is capable of RSTP, so that might account for the slower RSTP convergence..

Russ

Are you talking about dropping the customer link... or dropping one of the trunk links for spanning-tree to reconverge...

If your talking about reconverging then the time you got for RSTP is damn good.... RSTP is suppose to take a minimum of 20 secs to reconverge.... remember it's removing the usual spanning-tree initial 30 sec delay (forwarding delay + listening delay) - resulting in a 20 second delay for listening + learning & forwarding which the port needs to do to be able to forward!....

If you have a a chance to play around with PVST - play around with the features they brought across from RSTP - such as uplinkfast, backbonefast etc... these all allow the plain old pvst to minimise convergence time - however if you have the opportunity to run RSTP you may as well use it....

luke_bibby

Santucci4 wrote: »

Are the 2950G switches capable of running the RSTP?

The 2950G switches run an enhanced image IOS which supports RSTP

petedude

/usr wrote: »

My next question is...what in the hell kind of laptop are you using that doesn't have an onboard ethernet port?

A very old kind, possibly. Remember back a bit. . . integrated NICs have not been around forever. There are old Compaq, Toshiba and NEC laptops that have CardBus but no integrated NIC. You could still run some sort of antiquated OS with a TCP/IP stack that would let you study for CCNA if you had to (e.g. Winblows95, Windows NT).

If you really wanted to be a masochist about it, you could drag out some ancient 386 laptop, connect up a parallel-to-Ethernet adapter of the likes that used to be made by SMC et al, and run Windows for Workgroups 3.11.

(Scary part is, I'm showing how long I've been in IT.)

mikej412

petedude wrote: »

If you really wanted to be a masochist

Um... how about an old IBM PC clone with an 8088 processor, 640K memory, and dual 5.25 inch 360K floppy drives -- running DOS 3.3 and Procomm Plus? I think those usually had the multifunction serial and parallel port ISA cards.

pogue

petedude wrote: »

If you really wanted to be a masochist about it, you could drag out some ancient 386 laptop, connect up a parallel-to-Ethernet adapter of the likes that used to be made by SMC et al, and run Windows for Workgroups 3.11.

(Scary part is, I'm showing how long I've been in IT.)

Bah. Imagine being a tech in a sysadmin shop for an enterprise that has nothing but XP clients and 2003 Servers, and someone brings you the Accounting office's WFW 3.11 machine that has a financial database on it.. In some archaic versions of Access.. The computer was the same one used for the last 10-11 years...

Oh yeah... No NIC, BTW. And the accounting shop NEEDS that database off the machine TODAY. And working on an XP box! The file is not really THAT big (300Meg), but WAY too big to transferred by floppy, even IF the shop had an external 5 1/4" drive that we could find XP drivers for.

All the other admins are scratching their heads and have no ideas.

I say, "Wait for a second.. I got an idea.."

I go to the storage closet where we were storing all the old software that was soon to be DRMO'ed, and what do I find? An old copy of LapLink Pro!

I hunt for a few more minutes, and find a parallel cable that will connect the parallel ports on the two machines..

I don't really remember how long the transfer took, but it worked like a charm, and the version of Access on the XP machine was able to integrate the database using a some sort of legacy file update feature.

I too started out in IT when very few PCs had NICs, and I used Laplink Pro quite frequently, actually..

Russ

APA

this thread has gone way off topic.... but I love it....

Normally when a thread goes off topic it's because someone is having a cry about something.... but the last three posters have managed to keep a sane conversation going.... off topic sane, but sane nonetheless....