cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4691
Views
95
Helpful
35
Replies

urgent

ney25
Level 2
Level 2

Hi NetPros,

anyone can help ?

Aug 20 17:19:44.160: %RTD-1-ADDR_FLAP: GigabitEthernet0/2 relearning 5 addrs per min

Aug 20 17:20:44.175: %RTD-1-ADDR_FLAP: GigabitEthernet0/1 relearning 6 addrs per min

switch>sh spann int gi 0/1

Interface Gi0/1 (port 40) in Spanning tree 1 is FORWARDING

Port path cost 4, Port priority 128

Designated root has priority 32768, address 0003.e35c.2580

Designated bridge has priority 32768, address 0003.e35c.2580

Designated port is 40, path cost 0

Timers: message age 0, forward delay 0, hold 0

BPDU: sent 1690479, received 1352

switch>sh spann int gi 0/2

Interface Gi0/2 (port 48) in Spanning tree 1 is FORWARDING

Port path cost 4, Port priority 128

Designated root has priority 32768, address 0003.e35c.2580

Designated bridge has priority 32768, address 0003.e35c.2580

Designated port is 48, path cost 0

Timers: message age 0, forward delay 0, hold 0

BPDU: sent 1703077, received 13968

regards,

kitten

35 Replies 35

Hi Jorgenolla,

attached with show spanning-tree for all switches, kindly have a look.

your reply will be highly appreciated.

Ok I believe the problem relies on your Trunk Ports and not on STP. The only STP discrepancy which really should not affect your topology; is found on 51.214.

Gi 0/1 should have been chosen as the Root port, and Gi 0/2 should have been blocked.

Reason being, they both have a total path cost of 8, but the Port id is lower on Gi 0/1 being 128.49, and 128.50 on Gi 0/2. But still since once is blocked, STP should not have any loops.

If you are using 2900XL/3500XL series switches, they do not support DTP, and I believe this is where the problem lies, and not on STP.

One of the text files you had sent earlier, confirmed that the not all port that are on p2p between switches, were actually trunked.

The following switches must be configured manually to switchport mode trunk on it's p2p interfaces with other switches:

51.210

51.211

51.212

51.213

51.214

51.215

51.216

So basically all of your switches, at this moment are running in switchport access mode, and not in Trunk mode.

The only link that is actually Trunked in your topology is the link:

51.216 Gi 0/2 To 51.211 Gi 0/6

After you have set all the rest of the links to switchporrt mode trunk, you should have no further problems with the address flapping that you had before.

Here is an article, that has some information on this problem:

http://www.cisco.com/warp/public/473/131.html

Please let me know how it goes after you enable trunking on those ports.

Best Regards

Hi bro,

so, you mean all uplink port configure as Trunk (dot1q) the problem will be resolved ?

because, i noticed some pple connect the one of the switch port (i.e fa 0/23) to some hub (unmanaged hub), so could this cause the loop as well ? because, currently all ports have no any configuration like switchport mode access, so do you think i should put all ports as switchport mode access ?

thanks.

When you a link is from a switch to a switch that link should be configured to switchport mode trunk. All ports are configure as switchport mode access by default.

A hub is layer one device; which is totally different thing; and not part of the topology diagram you posted.

Hi Jorgenolla,

yes, that's no in my diagram . because, i just noticed when i trace all switch ports , i noticed some port which consist 3 MAC addresses .. so, when i called them to verify .. they told me that's some limitation for the switch usage that's why they cascade for hub for some installation work for desktop PC.

so, my point is even they cascade a Hub in between , does this will cause the loop ?

should i configure this port to "switchport mode access" also ?

thanks

kitten/ney25

you should give jorgenolla some points for all the help you are receiving.

Do you have smartnet on any of these switches?

If so, call the TAC.

If not, set the center switch to ROOT BRIDGE that was recommended days ago.