Cisco ERR_DISABLE: loopback error

[relaxteb]

Onderstaande situatie is bij ons actief :

2 Cisco switches verbonden met 1 crosslink

SWITCH_A<<straight cable>>interconnectie paneel<<crosscable>>SWITCH_B----------------->

Nu valt om de haverklap de verbinding uit.
Bij onderzoek bleek dat poort 3 op switch_A in error disable state stond.
Na het bekijken van de log kwam deze melding :

%ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on FastEthernet0/3.
%PM-4-ERR_DISABLE: loopback error detected on Fa0/3, putting Fa0/3 in err-disable state

Het vreemde is dat er maar 1 kabel van Switch_A naar Switch_B loopt, dus een loopback zou hier niet thuishoren.

Wat hebben we gedaan :
- de straight kabel vervangen
- de cross kabel vervangen
- een andere interconnectie kabel gebruikt
- straight en cross omgewisseld (dus cross bij switch A en straight bij switch

Niets hiervan helpt. Het enige wat we kunnen doen om het disablen van de poort tegen te gaan is het commando "no errdisable detect cause loopback".

Het is 100% zeker dat er geen loop door een fysieke 2e kabel veroorzaakt wordt, er is namelijk maar 1 kabel aangesloten tussen de 2 switches.

We hebben al van allerlei spanningtree en bpdu commando's gebruikt maar het lijkt toch echt iets anders te zijn.

Heeft IEMAND een idee hoe te achterhalen wat er nou werkelijk fout is of hoe we dit op kunnen lossen ??

[Die Bruine]

Welke softwareversie draai je? Check eerst bij Cisco zelf of er iets over bekend is. Heb je spanning-tree portfast aan staan? Niet doen.

Ik heb de meldingen ook wel eens voorbij zien komen icm spanning-tree portfast bpduguard. Dan willen ze ook wel eens in error disable gaan. Zegt je log nog iets anders? Of alleen dit?

[relaxteb]

We draaien versie c2950-i6q4l2-mz.121-19.EA1c op switch A.
Nadat we eerst nog versie c2950-i6q4l2-mz.121-22.EA5 hadden geïnstalleerd en dit niet hielp hebben we zelfs de switch zelf nog gewisseld.
Op de Cisco site en forums kon ik er weinig over vinden. We hebben hier al flink lopen zoeken.
Ook heb ik een aantal Cisco beheerders benaderd maar zij konden ook niets meer bedenken.

Portfast staat aan, echter zou dit niet uit moeten maken omdat we maar 1 link gebruiken ?
Ook het commando "spanning-tree bpdufilter enable" hebben we gebruikt zonder resultaat.

In de log staat niets anders dan "loop back detected".

<edit>
Ik heb maar even op de poort zelf portfast disabled op jou advies.
</edit>

[ Voor 9% gewijzigd door relaxteb op 08-09-2005 16:42 ]

[TrailBlazer]

als je dat commando gebruikt is de verbinding dan wel stabiel dus geen crc fouten overruns collisions dat soort dingen

[Die Bruine]

Als je portfast aan hebt staan en bpduguard aan hebt staan zal hij de port disablen! Het is overigens nooit de bedoeling dat je twee switches (ook al heb je geen loop) koppelt over een spanning-tree portfast poort. Heb je overigens ook al een andere poort geprobeerd? Cisco is heer en koning in vreemde gevallen

[relaxteb]

FastEthernet0/3 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is**************** (bia **************)
Description: ******************
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 10Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:02, output hang never
Last clearing of "show interface" counters 1d02h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 48000 bits/sec, 8 packets/sec
5 minute output rate 23000 bits/sec, 7 packets/sec
1042041 packets input, 766356612 bytes, 0 no buffer
Received 78533 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 58697 multicast, 0 pause input
0 input packets with dribble condition detected
842640 packets output, 201362487 bytes, 0 underruns
0 output errors, 0 collisions, 6 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

---

Geen errors, dus verbinding lijkt me in dat opzicht redelijk stabiel

[relaxteb]

Biposto schreef op donderdag 08 september 2005 @ 16:49:
Als je portfast aan hebt staan en bpduguard aan hebt staan zal hij de port disablen! Het is overigens nooit de bedoeling dat je twee switches (ook al heb je geen loop) koppelt over een spanning-tree portfast poort. Heb je overigens ook al een andere poort geprobeerd? Cisco is heer en koning in vreemde gevallen

Jeps, andere poort al gebruikt.
Overigens zijn we deze commandos gaan gebruiken omdat er problemen ontstonden.
Portfast staat dus nu uit voor de interface.

[Verwijderd]

en als je loopback nu eens op beide interfaces disabeled ?

[relaxteb]

De loopback is niet ingesteld op de interface.
Of bedoel je de loopback detectie ? Want die kan volgens mij alleen voor alle poorten uitgezet worden.

[Verwijderd]

relaxteb schreef op vrijdag 09 september 2005 @ 11:19:
De loopback is niet ingesteld op de interface.
Of bedoel je de loopback detectie ? Want die kan volgens mij alleen voor alle poorten uitgezet worden.

Loopback is default en zie je niet in je config. of bedoel je dat er al een "no loopback" onder de interface geconfigureerd is ?

My bad, loopback bestaat niet op switches. wel op routers.

[ Voor 10% gewijzigd door Verwijderd op 09-09-2005 11:25 ]

[Verwijderd]

Zou het kunnen dat iemand aan de gebruikerszijde een switch heeft geinstalleerd. en deze misschien met 2 kabels heeft verbonden met je netwerk? (wellicht tijdelijk)?

[Verwijderd]

Verwijderd schreef op vrijdag 09 september 2005 @ 11:20:
Zou het kunnen dat iemand aan de gebruikerszijde een switch heeft geinstalleerd. en deze misschien met 2 kabels heeft verbonden met je netwerk? (wellicht tijdelijk)?

dat zie je snel genoeg als je "sh mac-adress" doet.

Alle poorten waar meer als 1 mac op zit is een mogenlijke switch / hub gebruiker.

Loop back wil zeggen dat de switch een pakket detecteerd wat reeds eerder verstuurd is.

Gebuiken jullie baluns of zo ?

[ Voor 15% gewijzigd door Verwijderd op 09-09-2005 11:26 ]

[relaxteb]

Verwijderd schreef op vrijdag 09 september 2005 @ 11:22:
[...]

Nee dat is niet mogelijk. Het is maar een kleine omgeving dus dat zou ons direct opvallen.

dat zie je snel genoeg als je "sh mac-adress" doet.
Alle poorten waar meer als 1 mac op zit is een mogenlijke switch / hub gebruiker.
Loop back wil zeggen dat de switch een pakket detecteerd wat reeds eerder verstuurd is.
Gebuiken jullie baluns of zo ?

We gebruiken geen baluns
We hebben een 2 tal poorten met meerdere mac addressen :
poort 24 dit is een uplink naar een 2e lan switch, deze geeft geen problemen
poort 3 dit is de uplink naar een andere switch met een vlan wat op een asr uitkomt.
Deze poort geeft problemen, maar zoals al vermeld is dit maar 1 uplink.

Ik heb uplink fast vanochtend uitgeschakeld en nog geen verstoring gehad.
Echter is het optreden van die verstoring ook niet continue en onvoorspelbaar.
Het is dus nog even afwachten of iemand moet nog een andere tip hebben ?

[Kabouterplop01]

Loop back wil zeggen dat de switch een pakket detecteerd wat reeds eerder verstuurd is

Ik denk dat het een retransmit (tcp-ip) pakketje is. Het apparaat welk dat veroorzaakt is dan denk ik ook de boosdoener. (weet niet hoeveel machines op die switch zitten gepatched, maar anders zou ik zeggen: Even op hubje patchen en sniffen)

[TrailBlazer]

een switch houdt volgens mij niet bij wat voor pakketjes hij al heeft verstuurd. Zou dat ding veel te veel geheugen voor moeten hebbem

[relaxteb]

Even een update : Het ziet er naar uit dat het probleem niet meer voorkomt, maar we moeten het nog even aankijken.

[Die Bruine]

Kwas al benieuwd hoe het was afgelopen. Maar ik wacht nog maar effe met juichen

[relaxteb]

het probleem is schijnbaar opgelost omdat we geen verstoringen meer hebben gehad.
Ik vind het nog steeds vreemd maar dat ligt dan denk ik aan mijn cisco kennis.

bedankt