Cisco 2960X Port blijft down en up gaan

[wicked1980]

Er gebeurt iets op 1 van mijn switches wat ik niet helemaal kan verklaren. En ja, dat ligt zeker aan onvolledige Cisco kennis

Ik heb een Cisco WS-C2960X-24TS-L, draaien op IOS Version 15.2

Op 2 poorten is een EWON Firewallbox FLX3101 aangesloten. Hierop kan een derde partij inbellen en diverse machine uitlezen.

Het vreemde is alleen dat de poorten waar deze boxen aan hangen continu Up en Down blijven gaan

Feb 20 13:11:40.820: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/2, changed state to down
Feb 20 13:11:41.824: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/2, changed state to down
Feb 20 13:11:47.780: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/2, changed state to up
Feb 20 13:11:48.783: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/2, changed state to up

Heel af en toe stopt het, zo is het op dit moment ook maar 1 poort die het doet, waar het er gisteren 2 waren. Als ik een laptop aan de poort hang, dan is er niets aan de hand. Enige wijziging die ik dan doorvoer is een ander VLAN op die poort. Maar zelfs voordat ik dat doe blijft de poort gewoon up

Config van de Poort die nu problemen geeft:

interface GigabitEthernet1/0/2
description MACHINE01
switchport access vlan 70
switchport mode access
switchport nonegotiate
speed 100
duplex full
!

Speed en Duplex zijn een test, als ik ze eruit haal blijft het probleem

Port 5 gaf gisteren dezelfde problemen, maar die config heb ik met rust gelaten. Op het moment werkt die poort wel normaal. Config:

interface GigabitEthernet1/0/5
description PRODUCTIEVLAN
switchport access vlan 70
switchport mode access
switchport nonegotiate
spanning-tree portfast edge
!

Overige config info die wellicht relevant is:

vtp mode transparent

spanning-tree mode rapid-pvst
spanning-tree extend system-id
auto qos srnd4
errdisable recovery cause bpduguard
errdisable recovery cause channel-misconfig
errdisable recovery cause link-flap
errdisable recovery interval 60


Iemand een idee/suggestie/tip/zoekrichting?

[gatlarf]

Heb ooit eens iets gelijkaardigs meegemaalkt. Interne switch in cisco-router die hetzelfde gedrag vertoonde. Het bleek de HP-switch te zijn waar ik de router mee verbond. Een firmware upgrade van de HP-switch later was het probleem opgelost. Geen idee of het hier ook zo is maar ik wil maar aangeven dat het niet noodzakelijk de switch is die het probleem is.

[MisteRMeesteR]

Kijk ook eens in de 'EWON Firewallbox FLX3101'
Probleem kan aan beide zijdes leven en/of ontstaan.

Tevens titelfix

[wicked1980]

gatlarf schreef op donderdag 20 februari 2020 @ 14:25:
Heb ooit eens iets gelijkaardigs meegemaalkt. Interne switch in cisco-router die hetzelfde gedrag vertoonde. Het bleek de HP-switch te zijn waar ik de router mee verbond. Een firmware upgrade van de HP-switch later was het probleem opgelost. Geen idee of het hier ook zo is maar ik wil maar aangeven dat het niet noodzakelijk de switch is die het probleem is.

klopt, ik neig er ook naar te stellen dat het probleem bij de Ewon Box ligt. Zeker omdat andere hardware wel normaal functioneert.

MisteRMeesteR schreef op donderdag 20 februari 2020 @ 14:28:
Kijk ook eens in de 'EWON Firewallbox FLX3101'
Probleem kan aan beide zijdes leven en/of ontstaan.

[mbr]Tevens titelfix :)[/]

Probleem is alleen dat ik zelf geen onderhoud aan die box kan/mag doen. En de communicatie met de leverancier daarvan loopt (voeglelijkwoordin)...

Vandaar mijn test met vaste Port Speed en Duplex

Daarnaast twijfel ik nog aan de Spanningtree modus op die poort, omdat die Ewon box zich wellicht als switch probeert te gedragen zou dat weer rare Bridging loops veroorzaak wellicht

[ Voor 11% gewijzigd door wicked1980 op 20-02-2020 14:40 ]

[wicked1980]

Update:

En nu doet port 2 normaal, maar port 5 weer vreemd...

Show int tijdens down:

HWL-SW-FABRIEK-01#show interface gigabitEthernet 1/0/5
GigabitEthernet1/0/5 is down, line protocol is down (notconnect)
Hardware is Gigabit Ethernet, address is 4c71.0cd9.6d85 (bia 4c71.0cd9.6d85)
Description: PRODUCTIEVLAN
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
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 0 bits/sec, 0 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
0 packets input, 20 bytes, 0 no buffer
Received 0 broadcasts (0 multicasts)
2 runts, 0 giants, 0 throttles
2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
16942 packets output, 2125406 bytes, 0 underruns
0 output errors, 170 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 145 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out


En tijdens up:

GigabitEthernet1/0/5 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 4c71.0cd9.6d85 (bia 4c71.0cd9.6d85)
Description: PRODUCTIEVLAN
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
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 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 20 bytes, 0 no buffer
Received 0 broadcasts (0 multicasts)
2 runts, 0 giants, 0 throttles
2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
16987 packets output, 2134179 bytes, 0 underruns
0 output errors, 170 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 146 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out


Valt me nu op dat hij 10Mb Half Duplex pakt
Gaat toch niet aan de bekabeling liggen dit...

Port 2 die eerder vandaag dezelfde problemen gaf draait nu goed, op 100mb Full Duplex (via Auto, niet manual ingesteld)

[ Voor 96% gewijzigd door wicked1980 op 20-02-2020 15:05 ]

[htn02]

als je dit soort issues ziet op een switch, is het 9/10 keer de bekabeling in mijn ervaring. heb je een (goede) kabeltester?

[wicked1980]

htn02 schreef op donderdag 20 februari 2020 @ 15:12:
als je dit soort issues ziet op een switch, is het 9/10 keer de bekabeling in mijn ervaring. heb je een (goede) kabeltester?

Begin er ook aan te twijfelen ja...

Heb alleen een tester die aderparen test helaas, maar goed, dat is een begin

[mindwarper]

Inderdaad even bij Layer 1 beginnen;
vervang als "test" de kabels even voor nieuwere Cat 6A S/FTP exemplaren…

Dan is de volgende kandidaat inderdaad duplex mode etc...
ik zou ook de port even als test ook niet in portfast zetten als test.
de port config zo plain mogelijk houden om mee te beginnen en dan stapje voor stapje gaan zoeken…

Ja I know it is a PITA

[Ascension]

Heb wel eens vergelijkbare vreemde issues gezien die door energy efficient ethernet kwamen, het remote device kon daar niet mee omgaan en zodra er maar een beetje verkeer over de poort ging klapte die eruit. EEE uitgezet op die poort en het probleem was opgelost. Misschien het proberen waard. "no power efficient-ethernet auto" op de poort zou het uit moeten schakelen.

[wicked1980]

Ascension schreef op donderdag 20 februari 2020 @ 16:32:
Heb wel eens vergelijkbare vreemde issues gezien die door energy efficient ethernet kwamen, het remote device kon daar niet mee omgaan en zodra er maar een beetje verkeer over de poort ging klapte die eruit. EEE uitgezet op die poort en het probleem was opgelost. Misschien het proberen waard. "no power efficient-ethernet auto" op de poort zou het uit moeten schakelen.

Helaas...

Ben nu de port config aan het uitkleden en stap voor stap weer opbouwen, kijken of dat iets doet. ben straks ook nog even op locatie, dan kan ik de kabel doorpiepen op gebroken aders.

[Kabouterplop01]

htn02 schreef op donderdag 20 februari 2020 @ 15:12:
als je dit soort issues ziet op een switch, is het 9/10 keer de bekabeling in mijn ervaring. heb je een (goede) kabeltester?

Ik heb juist heel andere ervaringen; als er een port op fixed speed staat en de andere op auto, dat je dit ziet.
Dit is een laag 1 dingetje.

Waarschijnlijk kunnen die firewall boxen niet meer dan 100MB FD aan. Eigenlijk zou je dat moeten kortsluiten met de 3rd party.

[ChaserBoZ_]

Je kabels uitsluiten, je poorten uitsluiten. Is er een best practices document beschikbaar voor die combinatie ?

[Jan-man]

Kabouterplop01 schreef op zondag 23 februari 2020 @ 08:35:
[...]


Ik heb juist heel andere ervaringen; als er een port op fixed speed staat en de andere op auto, dat je dit ziet.
Dit is een laag 1 dingetje.

Waarschijnlijk kunnen die firewall boxen niet meer dan 100MB FD aan. Eigenlijk zou je dat moeten kortsluiten met de 3rd party.

Kan ik 100% beamen dat heb ik een tijdje terug ook gehad. Leuke was toen dan down de volle snelheid wel gehaald werd maar dat UP nog geen 10% .

Bleek dat dat de glas switch op fixed 100 stond en de cisco op auto negotiation. Uiteindelijke fix was een switch er tussen met 1 fixed poort en 1 auto negotiation poort omdat geen van beide partijen hun config wouden of konden aanpassen