Switches, Hubs, and Modems
1748280 Members
3826 Online
108761 Solutions
New Discussion юеВ

Re: Starved BPDU's

 
Frootbat
New Member

Starved BPDU's

I have a 5406 zl ON k.12.05 with 3 ZL modules in, I have 3 trunks configured on these, and i am running MSTP

I am getting periodically the error

I 10/02/08 21:45:46 00842 stp: CIST starved for a BPDU Rx on port Trk3 from
0:0001e6-f9f600

always on trunks 3, this causes MSTP to close the trunk and enable another, i beleive the trunk is in useas at the same time this happens 2 data servers failover from primary nic's to secondary and then back to primary

fairly new to networking so would appreciate some input to possible causes/solutions

any info you need please let me know (i have attached MSTP/trunk details)

Thanks
5 REPLIES 5
RicN
Valued Contributor

Re: Starved BPDU's


I noticed from your output that the topology change counter seems very high, around 90000. Since your edge ports should not introduce a topology change (I think) this looks like your infrastructure links are changing a lot.

Could you please include your spanning tree configuration commands?

What is on the opposite side of the Trk2-link?
Matt Hobbs
Honored Contributor

Re: Starved BPDU's

Update the firmware first and foremost, many many STP issues fixed since then.
Frootbat
New Member

Re: Starved BPDU's

other end of trunk 2 is a 5308xl running RSTP
RicN
Valued Contributor

Re: Starved BPDU's


I saw in your attached output that Trk2 was blocked, but I see now that in your original post it was Trk3 that was the problem, so what is on the opposite side of that? :)
Frootbat
New Member

Re: Starved BPDU's

there are 3 trunks configured and all with priority of 64, trunks 1 and 2 go directly to master switches and trunk 3 to anther switch

trunks 3 seems to be giving the problms and high topology change count

can i alter the priority to 65 for trunk 3 so that in theory trunk 1 and 2 would be used to see if this would reduce the problem?

i have no time to schedule firmware upgrades and major work is happening on the data servers that means data restores will run over night for the next few nights, and if this happens and the NIC's failover all connections are lost and the data restore will fail! just want to stabalise for the next few nights and then i will update firmwares after