Cisco port channel failback mislukt ivm suspended interface

[TAMW]

Situatie:
Tussen 2 panden heb ik een aantal fibers lopen met welke zijn aangesloten op gestackte Cisco CAT9200 iosxe 16.9.3 switches dmv van 10G optics

Om redundancy te krijgen zijn per pand 2 switches in stack waarop een portchannel met 2 channels gemaakt is met een interface op elke switch member.

Door omstandigheden is 1 paar glasvezels niet meer bruikbaar op 10G.
Dit gaat opgelost worden maar kost tijd en redundancy is een keiharde en noodzakelijke business requirement.

Ik heb nog wel 1 werkend paar welke op 1G draait welke ik via media converters op de switches aangesloten heb.
Nu heb ik deze aan het portchannel toegevoegd en natuurlijk komen ze in suspended mode te staan omdat er een speed mismatch is.
Met de max-bundel optie geeft ik aan dat er maar 1 channel actief mag zijn en met de lacp-priority geeft ik aan dat de 10G dit moet zijn als deze beschikbaar is.


Als mijn werkende 10G fiber uitvalt komt de 1G verbinding netjes uit suspended en vindt er een failover plaats.

Nu het probleem:
Alleen als de 10G terugkomt blijft deze in suspended staan en wordt niet actief.
Om het nog erger te maken als ik nu de 1G verbinding onderbreek(fiber pacthkabel los) stopt de hele verbinding
De 10G blijft in suspended

Om het weer werkend te krijgen moet ik op beide switches de 10G interfaces een sh en no sh geven.
Of de 1G weer werkend maken en daarna deze poorten op beide switches shutten.

Dus failover geen probleem maar failback werkt niet.

UDLD agressive op de poorten om ze in err-disable te dwingen werkt ook niet ze blijven in suspended mode
gaan.

Iemand nog ideeën?

ps: beide op 1 G draaien werkt wel maar is een nog go wegens bandbreedte gebruik >3G
In de situatie dat de huidge 10G uitvalt kunnen we hier tijdelijk omheen werken.

[mhofstra]

Automatische shut/no shut mbv EEM?

[jvanhambelgium]

TAC case open doen ? Weet je direct of het "behaviour by design" is oid ;-) want ik veronderstel altijd reproduceerbaar ?

[jvanhambelgium]

Hoelang heb je zo liggen wachten ? Ik lees dat de standaard LACP control-packets elke 30sec over de interfaces lopen. Met het commando "lacp rate fast" op de interfaces is dat naar 1 sec te brengen.

Gebruik mischien ook eens wat debugging op de Cisco, mischien zie je net dat eventje passeren dat je een hint kan geven waarom de dingen gebeuren zoals ze gebeuren.

Deze doc gelezen?

https://www.cisco.com/c/e...chapter_011.html#id_17183

[TAMW]

@mhofstra

Op zich goed idee maar:
EEM is lastig omdat je het op beide switches tegelijkertijd de sh moet "timen"
En de failback op deze manier geeft te lang downtime en heeft dus direct impact op je diensten over de verbinding..

Een standaard lacp failover van een directe verbinding (dus je op beide switches tegelijk de link down) is nauwelijks merkbaar voor je traffic.


@jvanhambelgium

Na 5 minuten wachten het ik het opgegeven.
"lacp rate fast" is alleen voor het initieel opbouwen van een lacp link.
En heeft niets met een failover/failback snelheid te maken.
In mijn situatie is de lacp verbinding al gebouwd de poort staat namelijk in de lacp status suspended

TAC is echt een last resort kost zoveel tijd en energie om de hele case te maken.

Ik zal hem in het lab eens nabouwen met good old 3750's en gewoon koper en kijken wat het gedrag daar is.

[DukeBox]

TAMW schreef op dinsdag 30 juli 2019 @ 18:59:
Situatie:
welke ik via media converters op de switches aangesloten heb.

Wat bedoel je precies met media coverter ? Meeste van die devices zijn een bridge vrijwel hetzelfde is als een ethernet switch. Een lacp trunc/ether channel gaat daar niet over werken.

[Bl@ckbird]

TAMW schreef op dinsdag 30 juli 2019 @ 22:55:

TAC is echt een last resort kost zoveel tijd en energie om de hele case te maken.

Ik zal hem in het lab eens nabouwen met good old 3750's en gewoon koper en kijken wat het gedrag daar is.

Dat zie ik vaker bij techneuten die dingen zelf willen oplossen. Maar nabouwen kost ook een hoop tijd en kan TAC ook voor je doen.

Hier staan wat tips in:
https://www.cisco.com/en/...rview0900aecd8039b86e.pdf

Als je niet tevreden bent hoe je case loopt: bellen en vragen naar de duty manager.

[ Voor 6% gewijzigd door Bl@ckbird op 31-07-2019 09:46 ]

[SniperGuy]

DukeBox schreef op dinsdag 30 juli 2019 @ 23:06:
[...]

Wat bedoel je precies met media coverter ? Meeste van die devices zijn een bridge vrijwel hetzelfde is als een ethernet switch. Een lacp trunc/ether channel gaat daar niet over werken.

Zou gewoon moeten werken een aan convertor eigenlijk een "2 poort full duplex hub" is waarbij er niets aan de inhoud van de paketten wordt gedaan en PDU, errors etc. er ook gewoon overheen verstuurd worden.

[DukeBox]

SniperGuy schreef op woensdag 31 juli 2019 @ 09:50:
Zou gewoon moeten werken een aan convertor eigenlijk een "2 poort full duplex hub" is.

Vandaar ook mijn vraag welke converter. Veel die ik tegenkom zijn toch op basis van store and forward (dus eigenlijk een switch) en als deze netjes 802.1D compliant zijn dan wordt het LLDP frame gewoon weggelaten of aangepast naar de TLV van de converter. Ik wil niet zeggen dat dat hier het geval is maar kom regelmatig dit soort issues tegen met mijn werk.

[ Voor 10% gewijzigd door DukeBox op 31-07-2019 10:52 ]

[TAMW]

DukeBox schreef op dinsdag 30 juli 2019 @ 23:06:
[...]

Wat bedoel je precies met media converter ? Meeste van die devices zijn een bridge vrijwel hetzelfde is als een ethernet switch. Een lacp trunc/ether channel gaat daar niet over werken.

Met Media converter bedoel ik in dit geval deze: https://www.fs.com/de-en/products/17237.html

Zoals in de openingpost staat dat de LACP link gewoon opkomt en via de converter ook werkt.
De mediaconverter poorten worden netjes in de bundel opgenomen.
Hier zit niet het probleem in, ik weet ook uit ervaring dat niet elke media converter werkt.

Bl@ckbird schreef op woensdag 31 juli 2019 @ 09:22:
[...]


Dat zie ik vaker bij techneuten die dingen zelf willen oplossen. Maar nabouwen kost ook een hoop tijd en kan TAC ook voor je doen.

Hier staan wat tips in:
https://www.cisco.com/en/...rview0900aecd8039b86e.pdf

Als je niet tevreden bent hoe je case loopt: bellen en vragen naar de duty manager.

Zoveel tijd zit er nog niet in hoor ongeveer 2 uur,
En mijn werk is dingen zoveel mogelijk zelf oplossen

TAC gaat dit niet nabouwen omdat de mediaconverters niet van cisco zijn.

[Swifty88]

Een labje bouwen met andere hardware lijkt me een goed plan. Wie weet wat voor gekkigheid er in de software zit.

Het is wel een lelijke oplossing maar is spanning tree misschien een optie? Dus de 1Gb link uit de channel halen en deze aansluiten. Spanning tree zou dan de link moeten blokkeren. Failover is misschien wel ietsje langer dan met LACP.

[TAMW]

We hebben wat legacy business critical apps die niet tegen korte hikjes is het netwerkverkeer kunnen
LACP failover (dmv linkdown) lukt net.

RSTP convergentie duurt soms net te lang.

We gebruiken dit al met alle tweaks om de convergentie te versnellen om onze datacenters aan de kantoren te koppelen (10G DWDM)

Maar mischien toch beter als niets

[ Voor 6% gewijzigd door TAMW op 31-07-2019 21:47 ]

[ik222]

Ik denk dat RTSP toch je enige optie is in dit geval, er van uitgaande dat dingen naar laag 3 trekken geen optie is.

Verschillende link speeds in een port-channel wordt niet ondersteunt schrijven ze overal dus de kans dat TAC hier iets mee gaat doen lijkt me ook minimaal.

Waarom kan je die mediaconverters er niet tussenuit halen en dan 10G over die fibers doen eigenlijk?

[TAMW]

1 Paar is fysiek beschadigd tijdens bouwwerkzaamheden.(zijn eigen fibers op eigen terein, deze worden hersteld maar hier gaat wat tijd overheen)

Het paar waar de mediaconverters opzitten zijn hele oude OM1 fibers.
Hier heb ik met LRM optics en mode conditioning patchkabels 10G overheen proberen te doen maar krijg heel veel CRC errors en flapping. 1G is wel betrouwbaar.

[3DDude]

als je cisco naar cisco doet waarom lacp?
ik zou gewoon pagp doen.

En dan maak je toch gewoon 2 channel groups ?
een voor de gig uplinks en een voor de 10gb
afhankelijk wat je wilt gebruiken shut je een int portchannel.

[TAMW]

Alles moet juist automatisch gaan, dat is het hele punt
Met handmatig shutten werkt het nu ook al.

[DukeBox]

Hoe groot is de kans dat de 10G er uitknalt ? Is het niet een aannemelijk risico om het (totdat de kapotte fiber gerepareerd is) zolang met een handmatige failover te werken ? Stabiliteit moet het uitgangspunt zijn, failover moet niet het doel opzich worden.

Van je defecte paar, zijn beide fibers beschadigd ? Je zou anders een 'single strain' connectie kunnen maken over de nog werkende fiber. Dat kan je natuurlijk ook met je nog werkende 10G doen (daar dus 2 single strains van maken). Met een WDM coupler kan je ook over een FD verbinding behouden.

[ Voor 37% gewijzigd door DukeBox op 01-08-2019 12:26 ]

[Anoniem: 450810]

Bl@ckbird schreef op woensdag 31 juli 2019 @ 09:22:
[...]


Dat zie ik vaker bij techneuten die dingen zelf willen oplossen. Maar nabouwen kost ook een hoop tijd en kan TAC ook voor je doen.

Hier staan wat tips in:
https://www.cisco.com/en/...rview0900aecd8039b86e.pdf

Als je niet tevreden bent hoe je case loopt: bellen en vragen naar de duty manager.

Daar ben ik het niet mee eens. In het lab heb ik de topologie een stuk sneller nagebouwd dan een TAC dat heeft. Mocht het dan toch tot een case komen (een software bug) kan ik de oplossing direct testen zonder de productieomgeving te hoeven upgraden. Als er de mogelijkheid is om zo zelf te testen zou dat altijd stap één moeten zijn. Daarnaast gaat TAC niet direct nabouwen maar eerst analyseren en dat kost ook een hoop tijd.

[Freeaqingme]

Anoniem: 450810 schreef op donderdag 1 augustus 2019 @ 15:08:
[...]


Daar ben ik het niet mee eens. In het lab heb ik de topologie een stuk sneller nagebouwd dan een TAC dat heeft. Mocht het dan toch tot een case komen (een software bug) kan ik de oplossing direct testen zonder de productieomgeving te hoeven upgraden. Als er de mogelijkheid is om zo zelf te testen zou dat altijd stap één moeten zijn. Daarnaast gaat TAC niet direct nabouwen maar eerst analyseren en dat kost ook een hoop tijd.

Dan ga je er al van uit dat de hardware beschikbaar is om een representatieve lab setup in te richten. Partijen die enkel 1 relatief kleine deployment hebben zullen dat niet altijd hebben. Verder ben ik het met je eens dat qua doorlooptijd het zelf reproduceren/fixen vaak sneller zal gaan. Echter, zo'n lab opbouwen etc kost ook allemaal tijd.

Als het meezit dan heb je slechts een handvol mailtjes nodig om het TAC z'n ding te kunnen laten doen, terwijl jij zelf andere dingen in die tijd kan doen. Dan is de doorlooptijd weliswaar iets hoger, maar heb je in die tijd wel meer gedaan kunnen krijgen.

[Anoniem: 450810]

Freeaqingme schreef op donderdag 1 augustus 2019 @ 15:29:
[...]


Dan ga je er al van uit dat de hardware beschikbaar is om een representatieve lab setup in te richten. Partijen die enkel 1 relatief kleine deployment hebben zullen dat niet altijd hebben. Verder ben ik het met je eens dat qua doorlooptijd het zelf reproduceren/fixen vaak sneller zal gaan. Echter, zo'n lab opbouwen etc kost ook allemaal tijd.

Als het meezit dan heb je slechts een handvol mailtjes nodig om het TAC z'n ding te kunnen laten doen, terwijl jij zelf andere dingen in die tijd kan doen. Dan is de doorlooptijd weliswaar iets hoger, maar heb je in die tijd wel meer gedaan kunnen krijgen.

Ja dat is waar als er geen hardware beschikbaar is dan is een TAC-lab een goede oplossing. Ik merk dat ik in onze lab setup alle cases in 1 tot 2 uur na bouw. Dat vind ik een acceptabele tijd om een probleem te onderzoeken. Daarnaast deel ik dan alleen lab informatie met de externe partij en geen informatie uit onze productieomgeving.

[Sebas1337]

TAMW schreef op dinsdag 30 juli 2019 @ 22:55:
@mhofstra

Op zich goed idee maar:
EEM is lastig omdat je het op beide switches tegelijkertijd de sh moet "timen"
En de failback op deze manier geeft te lang downtime en heeft dus direct impact op je diensten over de verbinding..

Haal de links los van elkaar, dus niet bij elkaar in een channel, en zet de 1G link aan een kant shut. Dan kan je in geval van link failiure hem toch via EEM opbrengen?

[muppet99]

Ik was in deze eerder gedaan voor mst. Wij hebben 3 glasvezels en 1 utp uplink tussen edge en core. We splitsen de vlans door middel van mst over de 4 aansluitingen. Wanneer ik een verbinding eruit trek, zie ik geen hikje voorbij komen. Wellicht zou je die ook eens kunnen testen in je lab.

[Uberprutser]

En als je "port-channel min-link 1" op je po toevoegd, heb je dan nog steeds het probleem wanneer je de backup link eruit trekt?

[Bl@ckbird]

TAMW schreef op woensdag 31 juli 2019 @ 20:16:
[...]

Zoveel tijd zit er nog niet in hoor ongeveer 2 uur,
En mijn werk is dingen zoveel mogelijk zelf oplossen

TAC gaat dit niet nabouwen omdat de mediaconverters niet van cisco zijn.

Ja dat is waar.. Aan de andere kant: Waarschijnlijk is er betaald voor supportcontracten, dus dan kan je er net zo goed gebruik van maken.

Je kan ook vragen of de TAC Engineer even mee kijkt via een WebEx sessie. Scheelt vaak wat mailtjes heen-en-weer.

Een andere tip als je een belangrijke deployment hebt, is om alvast een TAC case aan te maken op prio 4. (Inclusief alle info, serienummers, show run's, topologie, tijd/datum van de implementatie / service window, etc.) Als je dan tijdens de deployment problemen tegen komt, hoef je alleen maar te bellen om de prio omhoog te schoppen naar prio 2 of 1.

Verder is het handig om te communiceren over de business impact. Als je mensen naar huis moet sturen omdat het netwerk down is, is dat een prio 2 of 1 case. Dat kan je zelf bepalen. Maar weet wel dat diezelfde TAC engineer misschien aan een netwerk van een ziekenhuis zit te troubleshooten.

[jvanhambelgium]

TAMW schreef op woensdag 31 juli 2019 @ 23:10:
Alles moet juist automatisch gaan, dat is het hele punt
Met handmatig shutten werkt het nu ook al.

Je hebt al de nodige debugging gedaan om mogelijks iets te spotten ? Mischien zie je wel een stack-trace'je voorbij vliegen op de moment dat je iets van interface eruit trekt ofzo...who knows...

[TAMW]

Defecte Fiber is gerepareerd, dus de 1 Gb link is weer overbodig geworden.
Had er ook geen tijd meer ingestoken omdat het toch maar voor relatief korte duur zou zijn.

[ Voor 38% gewijzigd door TAMW op 05-09-2019 14:57 ]