Glas verbinding tussen HP en Cisco eindigd in err-disabled

[Red Cell]

Ok, ik beken. Ik heb hulp nodig.

Situatie; ik heb een HP 5820X (JC102B) switch stack aan een kant met een 1Gb glas SFP erin (JD118B).
De andere kant bestaat uit een cisco 3650 (WS-C3650-24PS-S) stack, met ook een 1Gb glas SFP (GLC-SX-MMD).

Zodra ik de glasvezel er tussen zet krijg ik op de cisco gelijk de volgende melding waarna de interface in err-disabled gaat

code:

%PM-4-ERR_DISABLE: link-flap error detected on Gi1/1/1, putting Gi1/1/1 in err-disable state

Het vreemde, de exact zelfde config op een UTP poort werkt onmiddellijk. Maar niet via glas.

Even de relevante config stukken
HP kant

code:

interface Bridge-Aggregation21
 description Uplink to Switch_LAN_25
 port link-type trunk
 port trunk permit vlan all
 link-aggregation mode dynamic
 mad enable

interface Ten-GigabitEthernet1/0/14
 port link-mode bridge
 description Uplink to Switch_LAN_25 1/1/1
 port link-type trunk
 port trunk permit vlan all
 port link-aggregation group 21

interface Ten-GigabitEthernet2/0/14
 port link-mode bridge
 description Uplink to Switch_LAN_25 2/1/1
 port link-type trunk
 port trunk permit vlan all
 port link-aggregation group 21

Cisco kant

code:

interface Port-channel1
 description Uplink to Switch_LAN_01
 switchport mode trunk

interface GigabitEthernet1/1/1
 description Uplink to Switch_LAN_01 1/0/14
 switchport mode trunk
 switchport nonegotiate
 channel-protocol lacp
 channel-group 1 mode active
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable

interface GigabitEthernet2/1/1
 description Uplink to Switch_LAN_01 2/0/14
 switchport mode trunk
 switchport nonegotiate
 shutdown
 channel-protocol lacp
 channel-group 1 mode active
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable

Beide GBIC's zijn supported onder de gebruikte firmware versies.
Glas vervangen (het is een dubbele verbinding dus leek me al sterk), RX-TX gechecked.
Ook aan de Cisco kant de GBIC's kunnen vervangen door een spare.

Een andere (veel oudere) cisco switch heb ik wel functionerend aan de HP hangen met het zelfde GBIC's.

GBIC's ook nagekeken op Wavelength 850, kabel op diameter (62,5um).

Ben nu al een paar dagen hierop aan het testen en zoeken maar kan niet vinden wat het nou is.

Voor hun die het opmerken; ja ik blokkeer spanning tree. Dit is vanwege een bijzondere redenen waar ik hier niet over uit kan wijden.

Dus is er een mede tweaker die me kan wijzen op wat ik nou over het hoofd zie?

[The Gamblers]

Ik meen me uit het verleden te herinnerrn hier ook eens tegenaan gelopen te zijn. Blijk uiteindelijk full/half duplex te zijn waar mijn switches niet uit kwamen.

[Bl@ckbird]

Vaak zijn dit idd. duplex issues. Zet de interface handmatig op full duplex. Mocht dit niet werken en zit er een support contract op de switch, kan je een TAC case openen.

[Red Cell]

The Gamblers schreef op donderdag 23 mei 2019 @ 13:51:
Ik meen me uit het verleden te herinnerrn hier ook eens tegenaan gelopen te zijn. Blijk uiteindelijk full/half duplex te zijn waar mijn switches niet uit kwamen.

Ik kan geen duplex of speed forceren maar wel zeggen "nonegotiate" wat lijkt te helpen.

Morgen even verder checken, want hij blijft nu wel up maar claimt dat LACP niet op de remote port aan staat.
Dus of het nu goed gaat is nog even de vraag.

[jvanhambelgium]

Je bent al vlot in de debugging gedoken op de Cisco kant ? Mischien heeft die "link-flap" error een diepere/andere oorzaak ? In principe wil dat zeggen dat je link meer als 5x op 10sec transities heeft.
Debug eens op tal van interface-paramters, STP-zaken etc.
SOMS kan je daar plots het licht zien...figuurlijk dan ;-)

[Swifty88]

Lijkt me een fysiek probleempje met de glas kabel of connector...maar als hij nu up is dan is dat in ieder geval voor elkaar.

Ik heb een beetje mijn twijfels over over de stukje volgende configuratie

code:

channel-protocol lacp
 channel-group 1 mode active
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable

Het lijkt met dat je het commando channel-protocol lacp niet nodig hebt aangezien hij al in active staat en dus al lacp onderhandeld. Verder zou ik geen bpdufilter of bpduguard gebruiken op een verbinding naar een andere switch. Hiermee saboteer je eigenlijk je spanning tree.

Ben eigenlijk wel benieuwd hoe de switch reageert met deze twee commando's tegelijk. Het filter zegt eigenlijk verstuur of ontvange geen BPDU en de guard zegt blokkeer de poort als er een BPDU binnenkomt.

Ik ben niet zo thuis in HP switches maar volgens mij moet je inderdaad lacp aanzetten op een interface. Iets van zoals het volgende:

code:

HP Switch(config) int c1-c4 lacp active

Hier is er ook wat informatie over te vinden.

[ Voor 9% gewijzigd door Swifty88 op 23-05-2019 17:55 ]

[silvans]

Eventueel zou je op de Cisco nog errdisable recovery cause link-flap aan kunnen zetten.
Dan komt de poort op na de errdisable timeout zolang je verbinding op laag 1 (fysiek) maar stabiel is.

Er kan van alles mis gaan met aansluiten (wel / niet voldoende licht) waardoor je makkelijk een link flap te pakken hebt.

[Red Cell]

Swifty88 schreef op donderdag 23 mei 2019 @ 17:48:
Het lijkt met dat je het commando channel-protocol lacp niet nodig hebt aangezien hij al in active staat en dus al lacp onderhandeld.

Even geëxperimenteerd, maar als ik dat weg laat wil hij graag (zoals zo vaak met Cisco) Cisco's eigen pagp protocol gebruiken i.p.v. de industriestandaard. Plus zolang de channel mode op active of passive staat mag ik van de software het geen eens uitschakelen.

Swifty88 schreef op donderdag 23 mei 2019 @ 17:48:
Verder zou ik geen bpdufilter of bpduguard gebruiken op een verbinding naar een andere switch. Hiermee saboteer je eigenlijk je spanning tree.

Zoals ik stelde ik "saboteer" bewust spanning tree. Ik snap het risico, maar ik kan mij ook het risico van een spanning tree recalculate niet veroorloven in deze omgeving.

Swifty88 schreef op donderdag 23 mei 2019 @ 17:48:
Ik ben niet zo thuis in HP switches maar volgens mij moet je inderdaad lacp aanzetten op een interface. Iets van zoals het volgende: *snip*
Hier is er ook wat informatie over te vinden.

In dit type switch (voormalig H3c eigenlijk) staat die dynamic voor LACP.

jvanhambelgium schreef op donderdag 23 mei 2019 @ 17:28:
Je bent al vlot in de debugging gedoken op de Cisco kant ? Mischien heeft die "link-flap" error een diepere/andere oorzaak ? In principe wil dat zeggen dat je link meer als 5x op 10sec transities heeft.
Debug eens op tal van interface-paramters, STP-zaken etc.
SOMS kan je daar plots het licht zien...figuurlijk dan ;-)

Het vreemde blijft dat de zelfde config op een UTP poort gewoon werkt.
Ik kan het eens testen, maar ik vermoed dat als ik het test tegen een andere cisco spare dat ik onmiddellijk verbinding heb.

Maar het "speed nonegotiate" zorgt dat de link up blijft, maar nu is de switch van mening dat

code:

 %EC-5-L3DONTBNDL2: Gi1/1/1 suspended: LACP currently not enabled on the remote port.

Nou las ik net dat iemand last had van een bug die de zelfde error veroorzaakte.
Dat bleek een bug te zijn, maar een update naar de laatste SW versie haalt niks uit.

We graven verder...

[Kabouterplop01]

wat voor errors zie je eigenlijk in de sh int ?

[Red Cell]

Kabouterplop01 schreef op vrijdag 24 mei 2019 @ 10:30:
wat voor errors zie je eigenlijk in de sh int ?

Weinig bijzonders

code:

GigabitEthernet1/1/1 is up, line protocol is down (suspended)
  Hardware is Gigabit Ethernet, address is f80b.cb15.6a99 (bia f80b.cb15.6a99)
  Description: Uplink to Switch_LAN_01 1/0/14
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 1000Mb/s, link type is force-up, media type is 1000BaseSX SFP
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/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, 0 bytes, 0 no buffer
     Received 0 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     75 packets output, 9370 bytes, 0 underruns
     0 output errors, 0 collisions, 6 interface resets
     0 unknown protocol drops
     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

De errors komen nog van voor de nonegotiate, counter nog niet gereset.

[Kabouterplop01]

Dat betekent geen laag 2 en 3 errors! Kun je eens proberen die HP port(s) op 1G /Full Dup te forceren? Aangezien dat een 10G interface lijkt.
(en hoe ziet die interface statistics eruit?)

[Red Cell]

Kabouterplop01 schreef op vrijdag 24 mei 2019 @ 10:40:
Dat betekent geen laag 2 en 3 errors! Kun je eens proberen die HP port(s) op 1G /Full Dup te forceren? Aangezien dat een 10G interface lijkt.
(en hoe ziet die interface statistics eruit?)

Ja dat is het laatste puzzel stukje.

Het is niet zo zeer die 10G interface (zit 1Gb GBIC in en de switch past het netjes automatisch aan).

Het is de combinatie.
De cisco krijgt het (zoals vaker gebeurt tussen Cisco en andere merk switches) niet voor elkaar netjes speed en duplex automatisch af te stemmen tussen de twee switches.

Dus om de verbinding niet in err-disabled te laten vallen door dat hij op de glas GBIC het niet snapt moet je op de glas interface "speed nonegotiate" zetten aan de Cisco kant. (Je kan op de GBIC geen speed of duplex configureren)
Maar omdat de interface dan niet negotiated word moet je aan de HP kant de duplex en speed forceren.
Stom eigenlijk dat ik daar niet aan gedacht heb.
Je word alleen snel op de verkeerde voet gezet doordat hij meld dat LACP het niet doet.
Wel vaag dat (veel) oudere Cisco's die ik op de zelfde manier er aan heb hangen dit probleem niet hebben.

Nou les is weer geleerd, doe of Cisco of HP en probeer maximaal een mix van deze twee te vermijden.

[ Voor 3% gewijzigd door Red Cell op 24-05-2019 11:04 ]

[ThomVis]

In het verleden hadden we ook problemen met Cisco switches naar H3C switches (na een firmware upgrade van de H3C switch). In het oude configuratiedocument (voor de Cisco) vond ik:

code:

errdisable flap-setting cause link-flap max-flaps 10 time 10

[Red Cell]

ThomVis schreef op vrijdag 24 mei 2019 @ 11:05:
In het verleden hadden we ook problemen met Cisco switches naar H3C switches (na een firmware upgrade van de H3C switch). In het oude configuratiedocument (voor de Cisco) vond ik:

code:

errdisable flap-setting cause link-flap max-flaps 10 time 10

Voor toekomstige mensen die dit topic lezen; dit had ik ook inderdaad geprobeerd, maar haalde niks uit.

[Red Cell]

Nou omdat ik maar 1 antwoord kan aanwijzen dan via deze kant; @Kabouterplop01 @The Gamblers @Bl@ckbird jullie hadden gelijk. Dank jullie voor de hulp en meedenken.