Inleiding

Dit document beschrijft een casestudy van een complexe, grootschalige migratie van een vast draadloos netwerk van Cisco CNC 4.1 naar 7.1 via lift-and-shift.

samenvatten

In dit artikel wordt een gedetailleerde casestudy gepresenteerd van de migratie van een grootschalig vast draadloos netwerk van Cisco Crosswork Network Controller (CNC) versie 4.1 naar versie 7.1. Vanwege het ontbreken van een in-place upgrademechanisme vereiste de overgang een volledige implementatie van lift-and-shift, waardoor een aanzienlijke architecturale, operationele en integratiecomplexiteit werd geïntroduceerd op meer dan 2.000 netwerkapparaten en meerdere onderling afhankelijke systemen. In de studie worden de uitdagingen onderzocht die op meerdere gebieden zijn ondervonden.

Een belangrijk resultaat benadrukt de essentiële rol van automatisering bij het waarborgen van schaalbaarheid, nauwkeurigheid en operationeel determinisme, met name voor workflows met een hoog volume. De resultaten tonen verder aan dat productieomgevingen aanzienlijk afwijken van gecontroleerde laboratoriumomstandigheden, waardoor adaptieve probleemoplossing, iteratieve validatie en aanhoudende betrokkenheid met TAC- en Business Unit-engineeringteams noodzakelijk zijn. Dit werk draagt praktische inzichten, gevalideerde methodologieën en aanbevolen best practices bij die dienen als referentieblauwdruk voor toekomstige CNC-upgrades en grootschalige orkestratieplatformovergangen.

Achtergrond

De proliferatie van 5G-netwerken, de snelle adoptie van verbonden apparaten en de digitalisering van bedrijfs- en consumentenomgevingen hebben geleid tot een aanzienlijke toename van het verkeersvolume en de diversiteit aan diensten die veilig en betrouwbaar op schaal moeten worden geleverd. Communications Service Providers (CSP's) exploiteren nu zeer dynamische netwerken waar traditionele, geïsoleerde operationele tools vaak complexiteit creëren, de gebruikerservaring verslechteren en hogere operationele kosten (OpEx) veroorzaken.

Om concurrerend te blijven, nemen operators steeds meer gemoderniseerde operationele modellen over die zijn gebaseerd op automatisering, virtualisatie, SDN-principes en analysegestuurde, zelfoptimaliserende netwerken.

Cisco Crosswork Network Controller (CNC) is ontworpen om deze transformatie te ondersteunen door operationele workflows te vereenvoudigen, de totale eigendomskosten te verlagen en op opzet gebaseerde automatisering mogelijk te maken in transportnetwerken van meerdere leveranciers. CNC biedt een uniform platform voor service provisioning, monitoring van de netwerkgezondheid en realtime optimalisatie, en biedt operators één venster om grootschalige IP-netwerken proactiever en efficiënter te beheren.

De onderliggende kruiswerkinfrastructuur biedt een veerkrachtig, schaalbaar clusterframework waarop alle CNC-toepassingen worden uitgevoerd. Voor CNC 7.1 omvat dit modules zoals Optimization Engine, Active Topology, Change Automation, Health Insights, Element Management Functions (EMF), Service Health en Crosswork Workflow Manager (CWM), die elk bijdragen aan end-to-end orkestratie en zekerheid.

Het upgraden van CNC biedt echter unieke uitdagingen. CNC ondersteunt geen in-place upgrades, waardoor een volledige lift-and-shift-implementatie nodig is waarbij de nieuwe omgeving parallel aan de bestaande wordt gebouwd en alle gegevens en services naar de nieuwe versie worden gemigreerd. Deze case study onderzoekt een grootschalige upgrade van CNC 4.1 naar CNC 7.1 voor een belangrijke Australische service aggregator die backbone-service voor alle andere serviceproviders ondersteunt.

De migratie was vooral complex vanwege meerdere aangepaste Change Automation-playbooks, aangepaste Health Insight-KPI's, L2/L3 VPN-serviceverzoeningsvereisten en de behoefte aan veilige ZTP.

De grote versiesprong zorgde voor extra onzekerheid, gezien interne architecturale en gedragsveranderingen die het moeilijk maakten om te voorspellen hoe bestaande use cases zich zouden gedragen in de nieuwe release. Dit vereiste uitgebreide validatie en afstemming tussen alle use cases.

Er is veel planning geïnvesteerd in het bepalen van de optimale toewijzing van middelen, waaronder het aantal hybride/werknemersknooppunten, CDG-distributie en PCE-dimensionering, en of uw bestaande grondstofvoetafdruk kan worden behouden.

De eerste CNC 7.1-implementatie en -validatie werden uitgevoerd in een intern CALO-lab en boden een veilige omgeving om te experimenteren, configuraties te verfijnen en vertrouwen op te bouwen. Dit werd gevolgd door implementatie in de interne testomgeving, die de productie nauw weerspiegelt. De laatste fase betrof het implementeren van CNC 7.1 in de productie, het toepassen van configuratiewijzigingen op apparaatniveau en het uitvoeren van een gefaseerde migratie van alle apparaten en bijbehorende services naar de nieuwe controller.

productienetwerk

Het air-gapped productienetwerk is verspreid over grote delen van Australië. Met de aanwezigheid van 2K + -apparaten, variërend van NCS tot ASR9Ks, beheerde CNC al deze apparaten door een live topologische weergave te bieden. Ongeveer 2K-apparaten waren NCS540s lokaal bekend als SWR (Small Wireless Router) met IOS-XR 24.3.2 en 30 waren ASR-9Ks (versie 7.5.2) lokaal bekend als LWR's (Large Wireless Router).

De Crosswork-opstelling bestond uit 3 hybride knooppunten en 2 werkknooppunten. Er waren in totaal 5 CDG's voor de apparaten met 4 actief en 1 de standby-node. Dit bood beperkte bescherming omdat de pool slechts 1 standby-CDG had. Maar gezien uw eisen, werd dit gegeven het groene licht. Het feit dat alle VM's op één datacenter zouden staan, maakte het ook gemakkelijker om met slechts 1 standby te werken.

De CDG is het onderdeel dat de gegevensverzameling van apparaten afhandelt via verschillende protocollen zoals SNMP, CLI en GNMI. De door CDG verzamelde gegevens worden via de interne kafka blootgesteld aan kruiswerk. Een apparaat aan boord van Crosswork moet worden aangesloten op een CDG, waarmee de datagateway verbinding kan maken met het apparaat en de apparaatgegevens kan ophalen.

Ook over de apparaatverdeling voor de CDG’s is veel nagedacht. De eerdere inzet had de apparaten willekeurig verdeeld over de CDG's. Dit leidde tot een zeer scheve verdeling waarbij sommige CDG's meer apparaten vervoerden terwijl er 1-2 CDG's waren met zeer minder apparaten. Dit leidde tot overconsumptie en overbelasting van sommige CDG's, terwijl andere te weinig voorzieningen hadden.

Het denkproces hier in de upgrade was om 700 SWR's elk te distribueren naar de 4 actieve CDG's. Dit was goed voor 2100 SWR's die werden ondergebracht in de eerste drie CDG's.  LWRs die zeer zwaar waren op de interface voorzijde waren allemaal gereserveerd voor de vierde CDG. Hoewel ze een zeer klein aantal waren met een telling van 30, zorgde deze toewijzing ervoor dat, zelfs als er meer inzamelingen werden gedaan van deze apparaten, er geen zware belasting op de CDG zou zijn. Elke daaropvolgende onboarding van SWR's zou ook naar de 4^e CDG gaan. Dit zorgde voor een uniforme verdeling in de eerste drie CDG's met meer ruimte beschikbaar in de 4^e om nieuwe apparaten in te nemen.

SR-PCE werd geïmplementeerd in 2 paren, wat betekent dat 4 VM's op verschillende hostmachines werden gedistribueerd. Het ene paar beheert 7 POI-sites en het andere beheert de resterende 8 POI-sites. De topologie updates op CNC GUI worden gedaan door het gebruik van SR-PCE. Het leert de topologie van het netwerk door middel van BGP-LS peering met andere LWR routers. Deze component wordt ook gebruikt voor alle verkeerskundige use cases waarbij het de rol van de controller speelt om het verkeer naar verschillende paden te sturen.

Om alle serviceprovisioning en apparaatconfiguratieuse-cases te verwerken, moet NSO worden gebruikt in combinatie met de CNC. Voor het productienetwerk werden twee NSO's met versie 6.4.1.1 ingezet om samen te werken in de hoge beschikbaarheidsmodus. SR-PCE (Segment Routing Path Computation Element) is het onderdeel dat nodig is voor het leveren van de topologie-updates aan CNC en ook voor het afhandelen van de real-time verkeerskunde use cases. Vier SR-PCE's met versie 25.2.1 werden hier ingezet waarbij elke PCE werd vergeleken met twee verschillende LWR's.

Migratieworkflow van CNC 4.1 naar CNC 7.1

Voor de CNC-implementatie was de voorkeurskeuze om door te gaan met de docker-gebaseerde. Maar omdat de client de installatie van de docker op hun locatie niet goedkeurde, was er geen andere optie dan door te gaan met handmatige implementatie met vCenter. Dit kost meer tijd om te implementeren in vergelijking met het script dat is gebaseerd op een omdat het ons vereist om meerdere keren invoer in de vCenter GUI te leveren.

Nadat de CNC-implementatie was voltooid, werden alle vereiste toepassingen geïmplementeerd met het BU-meegeleverde automatische actie-installatiebestand dat de toepassingen in één keer uploadt en activeert, waardoor de tijd die nodig is om het handmatig te doen, wordt verminderd. De belangrijkste laag is geïmplementeerd met Crosswork Optimization Engine, Active Topology, Service Health, Element Management Functions en Crosswork Workflow Manager. Samen met dit, de add-on pakketten werden ook ingesteld die Change Automation en Health Insight omvat.

CWM en SH hadden geen use cases. Maar ze werden toch ingezet omdat ze geïnteresseerd waren in enkele van de use cases die deze applicaties in de volgende versie boden.

Toen de applicaties eenmaal waren ingesteld, was de volgende stap het migreren van de gegevens van de oude versie van CNC. Dit omvat voornamelijk de aanmeldingsprofielen, providers, tags, aangepaste playbooks, aangepaste KPI's, rollen, sZTP-vouchers en andere gegevens. CNC biedt de exportoptie voor al deze die kunnen worden gebruikt en vervolgens kunnen worden geïmporteerd naar de nieuwe CNC.

Zodra deze zijn ingesteld, is het verstandig om de apparaatmigratie te starten. In het geval van upgrades, als de nieuwe CNC wordt geïmplementeerd in een nieuw subnet in vergelijking met de oudere, is er een vereiste om ACL-wijzigingen op apparaten uit te voeren om bereikbaarheid met de nieuwe CNC te bieden. Dit is een tijdrovend proces, omdat het vereist dat men handmatig inlogt op elk apparaat en de configuratie wijzigt.

Zodra deze ACL-wijzigingen zijn voltooid, is de volgende stap om de apparaten te importeren naar nieuwe CNC en ze aan de CDG's te koppelen. Als de bereikbaarheid goed is en de SSH- en SNMP-referenties correct zijn, worden de apparaten weergegeven als bereikbaar op CNC en worden ze ook aan boord van de NSO (Network Services Orchestrator).

Op het NSO-front moeten alle vereiste pakketten operationeel aanwezig zijn om ervoor te zorgen dat CNC met NSO kan praten en vice versa. Om bijvoorbeeld de apparaten automatisch van CNC naar NSO te sturen, is het DLM-functiepakket verplicht. Evenzo, als er een vereiste is voor NSO om MDT-sensorpaden op het apparaat te configureren, moet het TM-TC-pakket op NSO worden geïmplementeerd. De kern is dat, afhankelijk van de use case, het relevante pakket moet worden ingezet op NSO.

In plaats van de handmatige aanpak om deze vereiste pakketten te implementeren, met name de Transport-SDN-pakketten, werd een geautomatiseerd script ontwikkeld voor provisioning. Met de CNC 7.1-upgrade zijn updates geïntroduceerd in de TSDN-pakketten. Deze bijgewerkte pakketten zijn bedoeld voor implementatie op de NSO-server om continue ondersteuning voor L2/L3-provisioning in de geüpgradede omgeving te garanderen. Het script automatiseert de installatie van de bijgewerkte TSDN-pakketten en laadt de nodige metagegevens in NSO, waardoor het de vereiste services kan leveren.

Eén exemplaar van Cisco Smart Software Manager (SSM)-licentieserver en drie exemplaren van Cisco Prime Network Registrar (CPNR) kunnen ook op verschillende hosts worden geïmplementeerd.

CNC-architectuur en integratie met andere componenten

CNC biedt één platform voor provisioning, optimalisatie en visualisatie van geïmplementeerde services via een uniforme gebruikersinterface. Hier is een korte samenvatting van de interne CNC-componenten die zich in de CNC-platformsuite bevinden en de use-cases.

• Kruiswerkactieve topologie (CAT):
• Toepassing voor interne componenten verdeeld over CNC VM-knooppunten
• Biedt real-time end-to-end zichtbaarheid van de aangesloten inventaris
• Integreert voorraadinformatie uit meerdere gegevensbronnen in één scherm
• Berekening van het transportnetwerkpad
• Topologiedetectie

• Crosswork optimization engine (COE):
• Toepassing voor interne componenten verdeeld over CNC VM-knooppunten
• Real-time netwerkoptimalisatie
• Real-time topologievisualisatie
• SR-TE visualisaties en provisioning
• RSVP-TE visualisatie en provisioning
• Bandbreedte op aanvraag
• Kruiswerkgezondheidsinzicht (CHI):
• Toepassing voor interne componenten verdeeld over CNC VM-knooppunten
• KPI-bewaking
• Waarschuwingsdashboard 
• Crosswork change automation (CCA):
• Toepassing voor interne componenten verdeeld over CNC VM-knooppunten
• Dev-ops tool met out-of-box speelboeken
• Planningsmogelijkheid om spelen op het gewenste moment uit te voeren
• HI KPI's waarschuwen voor stikken naar voorgestelde toneelstukken als remediëring

architectuurdiagram

Netwerkdiagram

CNC 4.1 → 7.1 Gedetailleerde migratieworkflow

End-to-end gefaseerde migratie van bestaande CNC 4.1 naar CNC 7.1 (dezelfde stroom kan worden gevolgd voor elke CNC-upgrade, ongeacht de versies)

plannen

›

lab

›

Customer Lab

›

Gereed voor PROD

›

Productiestroom

›

weektijd

›

overdracht

›

uit bedrijf nemen

	FASE 1 1 Plan en bereid je voor BEREIK EN PLANNING · Definitie reikwijdte · Capaciteitsplanning PLANNING · Vensteridentificatie wijzigen · Afstemming van belanghebbenden
▼
	FASE 2 2 Interne labvalidatie INFRASTRUCTUUR · CNC 7.1 bouwen (hybride/werknemers) · Apps installeren · NSO implementeren met HA · SR-PCE-paren implementeren VALIDERING · Alle use cases valideren · Functionele aftekening
▼
	FASE 3 3 Validatie van Customer Lab INFRASTRUCTUURBOUW · CNC 7.1 bouwen (hybride/werknemers) · Apps installeren · NSO implementeren met HA · SR-PCE-paren implementeren GEGEVENSMIGRATIE · CNC 4.1-artefacten exporteren · Apparaatgroepen opnieuw maken · Invoer in CNC 7.1 · NSO-pakketten implementeren BEREIKBAARHEID VAN HULPMIDDEL · ACL-updates · Apparaat importeren en CDG-bijlage SERVICES EN WAARNEEMBAARHEID · Serviceconciliatie en synchronisatie · KPI-enablement en verzameltaken · BNM-script inschakelen · HI/Grafana observeerbaarheid · Straalintegratie · Splunk-integratie · OneFM-integratie · CNC-back-ups inschakelen
	✓ ATP uitvoeren in Lab en afmelden
▼
	FASE 4 4 Gereedheid voor productie BEVEILIGING EN TOEGANG · Beveiligingscontrole · Instellen toegangscontroles INFRASTRUCTUUR · Grootte en installatie van productie-VM's · Netwerkvalidatie
▼
	FASE 5 5 Productieomslag ↻ Herhaalt alle stappen uit fase 3 — in de productieomgeving INFRASTRUCTUURBOUW · CNC 7.1 bouwen (hybride/werknemers) · Apps installeren · NSO implementeren met HA · SR-PCE-paren implementeren GEGEVENSMIGRATIE · CNC 4.1-artefacten exporteren (providers, inlogprofielen, afspeelboeken, tags) · Apparaatgroepen opnieuw maken · Invoer in CNC 7.1 · NSO-pakketten implementeren BEREIKBAARHEID VAN HULPMIDDEL · ACL-updates · Apparaat importeren en CDG-bijlage SERVICES EN WAARNEEMBAARHEID · Serviceconciliatie en synchronisatie · KPI-enablement en verzameltaken · Inschakelen van BNM-playbook · HI/Grafana, Splunk, OneFM · CNC-back-ups inschakelen
	✓ Uitrol van de productie
▼
	FASE 6 6 Weken CONTROLE · Stabiliteitsbewaking · Basislijn prestaties PROBLEEMBEHEER · Problemen opsporen en oplossen · Escalatieproces
▼
	FASE 7 7 Documentatie en overdracht DOCUMENTATIE · MOP's, ontwerpdocumenten en operationele documenten · Architectuurdiagrammen OVERDRACHT · Sessies voor kennisoverdracht · Aftekening overdracht
▼
	FASE 8 8 Legacy CNC uit bedrijf nemen 4.1 OPSCHONEN · Alle apparaten loskoppelen van CDG · MDT-items verwijderen die verwijzen naar 4.1 CDG-VM's · Productie-VM's verwijderen ARCHIVEREN · Alle CNC 4.1 export archiveren · Eindcontrole en aftekening

Use cases 

L2VPN (EVPN-gebaseerde) serviceprovisioning

De L2VPN-service biedt Layer2 Ethernet-connectiviteit voor meerdere SWR's, waarbij sommige services op LWR's zijn verankerd. CNC Active Topology wordt gebruikt voor de levering van services, terwijl alle omgevingsspecifieke logica wordt geïmplementeerd via aangepaste sjablonen voor NSO's.

L2VPN-provisioning wordt behandeld als een Day2-configuratieactiviteit en vereist door de operator geleverde servicekenmerken.

Aangepaste NSO-sjablonen

Er zijn verschillende aangepaste sjablonen gemaakt om deze af te stemmen op omgevingsspecifieke naamgevingsconventies en interfacegedrag:

• CT-l2vpn‑swr‑hub‑and‑lwr
  Omgaat naamgevingsverschillen aan de hubzijde van f‑of bridge ‑group en bridge ‑domain op SWR-hubs en LWR’s.
• CT‑l2vpn‑swr‑nonhub‑100/101/102/105
  Hiermee verwijdert u de ZTP-uplinkinterface van de standaard EVPN-bruggroep en het brugdomein voor elke VLAN-specifieke EVI.

Deze sjablonen zorgen voor een consistente EVPN-configuratie in het netwerk en verwijderen verschillen op hardwareniveau.

L3VPN (VRF-gebaseerde) serviceprovisioning

De L3VPN-use case maakt Layer‑3-servicelevering via meerdere SWR's als eindpunt mogelijk. Provisioning wordt uitgevoerd via CNC Active Topology, waarbij omgevingsspecifieke vereisten worden geïmplementeerd met behulp van een aangepaste NSO-sjabloon.

Net als bij de L2VPN is dit een configuratieactie op dag 2, waarbij invoer van de operator is vereist.

Aangepaste NSO-sjabloon

• CT‑l3vpn‑swr
  Verzamelt VRF-specifieke parameters (AS-nummer, VRF-naam, voorvoegselset, naam van route-beleid, route-onderscheidingsteken) en bouwt het benodigde BGP-import-/exportbeleid op, inclusief herverdeling van verbonden routes met een door de gebruiker gedefinieerd route-beleid.

Traffic engineering

De toepassing Crosswork Optimization Engine (COE) van de CNC-suite helpt bij het regelen van verkeersstromen in het netwerk op basis van de gewenste intentie.

Er zijn twee soorten verkeer die verschillende intenties vereisen (SLA-statistieken):

• TC1 Traffic – Latency Sensitive SLA om ervoor te zorgen dat het verkeer zich op het laagste latentiepad bevindt.
• TC4-verkeer – Minimale SLA voor bandbreedte om ervoor te zorgen dat toegewezen bandbreedte altijd beschikbaar is voor TC4-verkeer

TC1-verkeer (laagste latentie)

Om ervoor te zorgen dat TC1-verkeer altijd op het laagste latentiepad wordt genomen, moet een Segment Routing (SR) -beleid zijn gemaakt op SWR-koptekst met padberekeningscriteria als latentie.

Dit wordt bereikt door de On Demand Next Hop (ODN)-configuratie op elke SWR-headend voor specifieke kleur 1001 te definiëren door CNC te gebruiken om het maken van SR-beleid te vergemakkelijken.

TC4-verkeer (vastgelegde bandbreedte)

Om ervoor te zorgen dat TC4-verkeer altijd op het pad wordt genomen met toegewezen bandbreedte, moet er een SR-beleid zijn gemaakt op SWR-koptekst met padberekeningscriteria als bandbreedte.

Dit wordt bereikt door:

• Bandwidth on Demand (BoD) functiepakket op CNC
• De On Demand Next Hop (ODN)-configuratie definiëren voor elke SWR-hoofdeinde voor specifieke kleur 1004 met behulp van CNC SR-beleidscreatie met deze configuraties

BoD function pack wordt gebruikt om het pad te berekenen voor SR-beleid dat bandbreedte heeft als criteria voor padberekening. Het houdt de bandbreedte bij die aan een beleid is toegewezen en houdt het huidige pad van het beleid tijdens de levenscyclus ervan in de gaten. 

Op elk moment, als de huidige patch van BWOD-beleid is niet over voldoende capaciteit beschikbaar om te voldoen aan de vastgelegde bandbreedte, herberekent het BWOD-beleidspad en herroutering van het beleid naar een nieuw pad. Deze herroutering van het BWOD-beleid is een continu proces en vereist geen handmatige interventie.

In zekere zin doet BWOD optimalisatie on the fly voor bandbreedte op dezelfde manier als SR-PCE doet voor latentie.

Apparaat inschakelen met sZTP

In het verleden vereiste het proces van het opzetten van een nieuw apparaat een bepaald niveau van expertise door de installateur om de implementatie van een nieuw onderdeel te installeren, te configureren en problemen op te lossen. Er kan ook een lang proces van pre-staging van de apparatuur op een offsite locatie, ondersteund door veel mensen die werken aan verschillende delen van de oplossing.

Voor nieuwe SWR-apparaten die gepland zijn om in uw omgeving te worden geïmplementeerd, wordt dit proces van het inschakelen van apparaten geautomatiseerd met de beveiligde ZTP-toepassing (Zero Touch Provisioning) van CNC.

De ZTP-workflow wordt geactiveerd wanneer het apparaat voor het eerst wordt opgestart en het zou de geplande platformimage en de initiële configuratie downloaden die moet worden toegepast zonder enige handmatige interventie.

Het apparaat is ook automatisch aan boord van CNC voor verdere orkestratie.

Dit diagram toont de workflow van het beveiligde ZTP-proces bij het inschakelen van het apparaat:

Post-ZTP-orkestratie (automatiseringsgestuurd)

Een Python-automatisering op de Utility Host orkestreert en controleert het end-to-end proces met behulp van een gestructureerde Excel-invoer (per keten):

• Genereert en uploadt dag-1- en postconfig-artefacten naar CNC.
• Hiermee maakt u CPNR-reserveringen (DHCP-items gebonden aan SWR-serieel).
• Voegt apparaat toe in EPNM (voor zichtbaarheid/zekerheid).
• Post-ZTP huishouden in CNC:
• Wijs SWR's toe aan CDG's (telemetriebestemming)
• Bevestigt aan apparaatgroepen en -tags
• Updates latitude/longitude voor topologievisualisatie
• Maakt BNM KPI-profiel aan om telemetriestreaming in te schakelen

Bandbreedte Berichten Bericht (BNM) Verwerking in CNC

De SWR kan BNM ontvangen van de co-locatie MiniLink switch die overeenkomt met de bandbreedte van de WAN-poorten. Deze meldingen zijn standaard CFM-berichten die de huidige lopende opgenomen bandbreedte (RBW) en de maximale geconfigureerde bandbreedte, ook wel bekend als nominale bandbreedte (NBW) zou omvatten.

De huidige bandbreedte is de werkelijke bandbreedte van de microgolf WAN-link, gebaseerd op de geaggregeerde bandbreedten van de individuele microgolf-links en hun lopende QAM-niveaus. De nominale bandbreedte is de geconfigureerde maximaal mogelijke WAN-bandbreedte, gebaseerd op de geaggregeerde bandbreedten van de maximaal geconfigureerde QAM op elk van de afzonderlijke microgolfkoppelingen.

Bandbreedte optimalisatie wordt uitgevoerd op basis van dit scenario:

Tijdelijke (vluchtige gebeurtenissen) wijziging

• Wanneer er een tijdelijke degradatie of uitval is in het netwerk/de verbinding die is gelokaliseerd op SWR (bijvoorbeeld als gevolg van een ongunstige weersomstandigheden die vervaging van het microgolfradiopad en vermindering van de beschikbare bandbreedte veroorzaakt als gevolg van veranderingen in modulatieschema's), vindt de correctie van de verkeersvorming plaats bij de lokale SWR op de getroffen netwerkinterface.
• Dit zorgt ervoor dat er minimaal pakketverlies optreedt over het beïnvloede transmissiepad.

Wanneer een SWR is ingeschakeld met BNM KPI in CNC als onderdeel van post-sZTP-activiteiten, drukt CNC telemetrieconfiguraties in SWR.

BNM MDT

door een telemetriemodel aangedreven

 bestemmingsgroep <DGName>

  vrf VRF-OMSWR-<AreaCode>1

  adresfamilie ipv4 <CDG IPv4Address> poort 9010

   zelfbeschrijvend coderen-GPB

   Protocol TCP

  Ja!

 Ja!

 sensorgroep <GroupName>

  sensor-pad Cisco-IOS-XR-ethernet-cfm-oper: cfm/nodes/node/bandbreedte-notificaties/bandbreedte-notificatie

 Ja!

CNC verwerkt deze BNM-berichten die via telemetrie worden ontvangen en neemt indien nodig herstelmaatregelen. Hier zijn de 2 componenten die betrokken zijn bij CNC: 

• Gezondheidsinzicht (HI): CNC-applicatie wordt gebruikt om BNM-meldingen in te nemen door aangepaste KPI die specifiek sensorpad voor BNM-berichten bewaakt. Health Insight is in staat om waarschuwingen te verhogen in het geval dat veranderingen in de bandbreedte significant zijn om op te treden.
• Change automation (CA): CNC-applicatie wordt gebruikt om te reageren op het streamen van BNM-berichten die HI-waarschuwingen hebben veroorzaakt. 2 Aangepaste afspeelboeken worden geïmplementeerd om deze wijzigingen aan te brengen op de beïnvloede interface:
  • QoS-vormer instellen op nieuwe RBW
  • Interfacecapaciteit instellen op nieuwe RBW-waarde.

Een aangepast Python-script is ontwikkeld om aangepaste logica uit te voeren en de CA-afspeelboeken automatisch uit te voeren wanneer HI KPI's worden geschonden. 

Het draaiboek van het draaiboek werkt op basis van dit algoritme:

In deze tabel worden de aangepaste waarschuwingsniveaus uitgelegd die zijn ingesteld op graden van bandbreedtedegradatie: 

Gerapporteerde bandbreedte = RBW 

Nominale bandbreedte = NBW 

Waarde van waarschuwingsintervallen	Meldingsniveau
(RBW/NBW)*100 >=70	info
(RBW/NBW)*100 <70 en >60	WAARSCHUWING
(RBW/NBW)*100 <=60	Critical (Kritiek)

Dit sensorpad wordt bewaakt door CNC: 

Cisco-IOS-XR-ethernet-cfm-oper: cfm/nodes/node/bandbreedte-meldingen/bandbreedte-melding

In CNC wordt een aangepaste KPI gemaakt om het pad van de BNM-sensor te bewaken. Deze KPI wordt toegevoegd aan een KPI-profiel dat is geconfigureerd met een cadans van 120 seconden en waarschuwingsdrempels. Als u SWR's aan dit profiel koppelt, wordt de vereiste telemetrieconfiguratie automatisch naar de apparaten doorgestuurd via NSO.

Zodra deze functie is ingeschakeld, streamen apparaten RBW/NBW-gegevens naar de toegewezen CDG's met het geconfigureerde interval. Health Insight (HI) berekent de RBW-NBW-ratio en verhoogt waarschuwingen wanneer drempelwaarden worden overschreden; operators kunnen deze gebeurtenissen in HI en via Grafana-dashboards volgen.

Een alertprovider in CNC stuurt deze alerts door naar het hybride knooppunt dat de Python-automatisering host. Het script ontleden apparaat/interface/RBW/NBW details en triggert de juiste Change Automation playbooks: scherpere aanpassing, bandbreedte update, of beide op basis van de gedefinieerde beslissingslogica.

Dit zijn de 2 playbooks die gebruikt worden in de workflow:

1. Playbook om de vormgevingswaarde te wijzigen  

2. Playbook om de interfacebandbreedte te wijzigen

Zoals eerder vermeld, draait het script een webserver om als provider te fungeren om met CNC te communiceren met behulp van REST API. Elke reactie die we krijgen voor een POST-verzoek wordt hier vastgelegd. De waarschuwingen worden vastgelegd in het formulier op JSON en vervolgens geconverteerd naar het woordenboek om de nodige parameters eruit te halen. 

Standaardiseer dag 2-netwerkbewerkingen via aangepaste automatiseringsplaybooks

Custom Change Automation (CA)-playbooks zijn ontwikkeld om kritieke Day-2-activiteiten in de hele levenscyclus van het netwerk te stroomlijnen en te standaardiseren. Deze omvatten bundel-ether-provisioning, updates van de beschrijving van de beheerinterface, CFM-orkestratie van de daisy-chain, naadloze uitbreiding van de linkcapaciteit, eNodeB-ontmanteling en efficiënte Mini-Link-onboarding. Door operationele best practices te integreren in herbruikbare workflows, verbeteren deze playbooks de consistentie van de uitvoering aanzienlijk, minimaliseren ze het risico op menselijke fouten en verminderen ze de afhankelijkheid van handmatige interventies. In het kader van een Cisco CNC-upgrade speelt dit automatiseringskader een cruciale rol bij het versnellen van de operationele doorlooptijd, het waarborgen van de continuïteit van de service en het mogelijk maken van schaalbare, herhaalbare processen die zijn afgestemd op moderne netwerktransformatiedoelstellingen.

Integratiecontinuïteit van TACACS+ in Cisco CNC 7.1-upgrade

Als onderdeel van de Cisco CNC 4.1 tot 7.1 upgrade, werd de bestaande TACACS+ integratie zorgvuldig bewaard om de continuïteit van gecentraliseerde authenticatie, autorisatie te waarborgen. Het upgradeproces valideerde en repliceerde de TACACS+-configuratie in Cisco CNC 7.1, waarbij de afstemming met het gevestigde bedrijfsbeveiligingsbeleid en op rollen gebaseerde toegangscontrolemechanismen (RBAC) werd gehandhaafd.

CNC en CDG Syslog doorsturen naar Splunk

Een syslog forwarding is ingesteld om de alarmen/gebeurtenissen/syslogs door te sturen naar een Splunk server. De out-of-the-box mogelijkheid van CNC om de syslog-server in te stellen, werd gebruikt om dit te bereiken.

Alarmen doorsturen naar OneFM

CNC-alarmen worden ook doorgestuurd naar een noordgebonden systeem zoals OneFM met behulp van de CNC-restconf-verbindingsgeoriënteerde API:

curl -L --request GET \

--url https://{server_ip}:30603/crosswork/notification/restconf/streams/v2/alarm.json \

--header 'Accept: application/txt'). This API must be used over a websocket connection config.

Automatisering van dagelijkse CNC-back-ups

Een geautomatiseerd script maakt gebruik van de CNC-back-up API om de volledige back-up van CNC te maken en slaat het back-upbestand op in de host van het hulpprogramma. Deze operatie wordt dagelijks uitgevoerd.

uitdagingen

Grote sprong in kruiswerkversie

De upgrade van Cross work 4.4 naar 7.1 betekende een aanzienlijke versiesprong in plaats van een routinematige incrementele update. Zo'n grote sprong introduceerde tal van nieuwe functies in meerdere toepassingen, samen met aanzienlijke verfijningen en architectonische veranderingen. Daarom was de CNC-upgrade niet alleen een eenvoudige versievervanging, maar vereiste het ook een grondige validatie om compatibiliteit, stabiliteit en goede functionaliteit voor alle geïntegreerde componenten te garanderen. De uitgebreide functieset en onderliggende verbeteringen betekenden dat bestaande workflows, configuraties en integraties zorgvuldige verificatie vereisten, waardoor uitgebreide testen en validatie cruciaal zijn voor het succes van de upgrade.

Geen upgrade op locatie

CNC biedt geen ondersteuning voor een in-place upgrademodel. In plaats daarvan moeten upgrades een lift-and-shift-aanpak volgen, waarbij de bestaande implementatie wordt behouden terwijl een volledig nieuwe omgeving vanaf nul wordt opgebouwd met de doelversie. Zodra het nieuwe systeem is geïnstalleerd, moeten configuraties, gegevens en integraties zorgvuldig worden gemigreerd en gevalideerd voordat de oudere omgeving kan worden ontmanteld.

Deze aanpak brengt verschillende operationele uitdagingen met zich mee:

• Parallelle omgevingen: zowel de oude als de nieuwe CNC-omgevingen moeten gelijktijdig worden uitgevoerd totdat de migratie en validatie volledig zijn voltooid.
• Hardwaredruk: wanneer twee volledige omgevingen tegelijk worden uitgevoerd, neemt de vraag naar computer-, opslag- en netwerkbronnen aanzienlijk toe, waardoor de beschikbare infrastructuur onder druk kan komen te staan.
• Uitgebreide validatie-inspanning: Alle gemigreerde gegevens, configuraties, beleidsregels en integraties moeten in de nieuwe versie worden geverifieerd om ervoor te zorgen dat ze precies werken zoals verwacht.
• Complexiteit van gegevensmigratie: de overdracht van historische gegevens, toepassingsconfiguraties en operationele instellingen vereist een zorgvuldige planning om inconsistenties of gegevensverlies te voorkomen.
• Vertraagde uitbedrijfname: het oudere systeem en de VM's ervan kunnen niet worden verwijderd totdat de nieuwe implementatie stabiel is gebleken, waardoor het gebruik van bronnen en de operationele overhead worden verlengd.
• Operationele coördinatie: teams moeten tijdens de overgangsperiode synchronisatie tussen beide omgevingen beheren om configuratieverloop of operationele verstoringen te voorkomen.
• Gesloten-loop automatiseringsconflicten: CNC ondersteunt closed-loop automatisering use cases die dynamisch acties activeren op basis van real-time netwerkomstandigheden. Wanneer zowel de oude als de nieuwe controllers actief zijn tijdens de overgang, bestaat het risico dat dezelfde automatiseringslogica kan worden uitgevoerd vanaf beide controllers, wat kan leiden tot dubbele configuratiewijzigingen of tegenstrijdige acties in het netwerk. Dit vereist een zorgvuldige controle van het automatiseringsbeleid tijdens het migratievenster.
• Bestaande operationele gegevens, waaronder historische alarmen, gebeurtenissen, storingsrecords en auditinformatie, worden niet naar de nieuwe omgeving gemigreerd vanwege het ontbreken van eigen exportmogelijkheden. Als gevolg hiervan zijn deze historische gegevens niet beschikbaar in het geüpgradede systeem en moeten ze worden behandeld als niet-herstelbaar na de migratie.

Vanwege deze factoren maakt het lift-and-shift-model CNC-upgrades meer arbeidsintensief en operationeel complex in vergelijking met een standaard in-place upgrade.

Valkuilen bij implementatie zonder terugdraaiopties

Bepaalde implementatiefouten en configuratiefouten na implementatie in CNC hebben geen herstelpad en vereisen een volledige verwijdering en herimplementatie van clusters. Een onjuiste FQDN die is geconfigureerd voor de Crosswork VIP-gegevens, die verplicht is voor de sZTP-use case, maakte sZTP bijvoorbeeld niet-functioneel. Aangezien deze waarde niet kan worden gecorrigeerd na de implementatie, was volledige herschikking vereist.

Evenzo kon een onjuiste configuratie van inloggegevens voor apparaatoverschrijving in Wijzigingsautomatisering niet worden gecorrigeerd na implementatie, wat leidde tot een nieuwe clusterreconstructie. Andere fouten, zoals verkeerd geconfigureerde gateway-IP's of subnetdefinities, worden ook geïdentificeerd als niet-herstelbaar.

Deze scenario's benadrukken het cruciale belang van het valideren van alle onveranderlijke parameters tijdens de initiële implementatie. Nauwgezette planning en controle van de input zijn essentieel om kostbare herwerkzaamheden en planningseffecten te voorkomen.

Beperkingen van diagnostische validatie na implementatie

CNC biedt een diagnostisch hulpprogramma voor het beoordelen van parameters op VM-niveau, zoals lees-/schrijflatentie van schijven, IOPS, synchronisatielatentie, netwerkinterfacesnelheid en CPU-klokfrequentie. Het hulpprogramma rapporteert de gemeten waarden aan de hand van de verwachte drempelwaarden en markeert elke controle als geslaagd of mislukt. Deze diagnoses kunnen echter alleen worden uitgevoerd nadat het cluster is geïmplementeerd, waardoor er geen mechanisme overblijft om de gereedheid van de infrastructuur te valideren voordat deze wordt geïmplementeerd.

Tijdens de installatie is de markering "Diagnostische controles negeren" standaard ingesteld op false. In de praktijk wordt het installatieprogramma stopgezet als een enkele controle mislukt, waardoor de implementatie niet kan worden voortgezet. Als gevolg hiervan worden field engineers vaak gedwongen om deze vlag in te schakelen en diagnostiek volledig te omzeilen, omdat zelfs omgevingen met productiekwaliteit vaak een of meer controles niet uitvoeren. Dit creëert een operationeel dilemma: teams moeten kiezen tussen het afdwingen van strikte validatie die de implementatie blokkeert of doorgaan zonder zekerheid dat de onderliggende infrastructuur voldoet aan de aanbevolen prestatiebenchmarks.

Aangepaste KPI-aanmaakprocedure voor HI wijzigen

In Health Insight 4.1 was het maken van aangepaste KPI's gebaseerd op de tekenscriptlogica, waarbij KPI-definities en verwerkingslogica werden geïmplementeerd met behulp van scripts binnen het tekenframework. In versie 7.1 werd deze aanpak echter vervangen door een op trackerbestanden gebaseerd kader voor het definiëren en beheren van KPI’s.

Vanwege deze architectuurwijziging konden de bestaande aangepaste KPI's niet direct opnieuw worden gebruikt en moesten ze opnieuw worden bewerkt om af te stemmen op de nieuwe bestandsindeling voor trackers. Dit vergde een aanzienlijke hoeveelheid tijd en moeite om:

• Begrijp het nieuwe kader: Het team moest de structuur, syntaxis en operationeel gedrag van het trackerbestand gebaseerde KPI-definitiemodel bestuderen dat in 7.1 werd geïntroduceerd.
• Redesign van bestaande logica: De logica die eerder in Tick-scripts werd geïmplementeerd, moest worden vertaald en aangepast in de bestandsindeling van de tracker.
• BNM-KPI's opnieuw maken: de aangepaste BNM-KPI moest opnieuw worden gemaakt met behulp van het nieuwe kader om ervoor te zorgen dat ze dezelfde resultaten en inzichten opleverden als voorheen.
• KPI-nauwkeurigheid valideren: uitgebreide validatie was vereist om te bevestigen dat de nieuwe implementaties consistente en correcte statistieken genereerden in vergelijking met de vorige versie.
• Testen en afstemmen: Het nieuwe model vereiste ook testen op prestaties en gedrag onder echte netwerkomstandigheden, gevolgd door aanpassingen waar nodig.
• Gebrek aan ondersteuning: Sommige functies die eerder met tekenscript werkten, werden niet langer ondersteund met de nieuwe bestandsimplementatie voor trackers. Er moesten dus compromissen worden gesloten.

Deze verandering in het mechanisme voor het maken van KPI’s verhoogde de vereiste inspanning tijdens de upgrade aanzienlijk, omdat het zowel ging om het leren van een nieuw systeem als om het opnieuw implementeren van de bestaande aangepaste monitoringslogica om de continuïteit van operationele inzichten te waarborgen.

API Timeout in BNM Playbooks Trigger Script

De BNM playbooks worden geactiveerd door middel van een aangepast script dat interageert met CNC API's. Tijdens het upgrade- en validatieproces werden verschillende problemen met betrekking tot API-verificatie en responsafhandeling geïdentificeerd en aangepakt.

De CNC API-token heeft een geldigheid van 8 uur, maar het oorspronkelijke script bevatte geen juiste logica om het token te vernieuwen zodra het verlopen was. Als gevolg hiervan, hoewel de KPI-waarschuwingen in CNC 4.4 correct functioneerden, stopte het playbook-triggerende script met uitvoeren nadat het token was verlopen. Dit probleem bleef lange tijd onopgemerkt, wat betekende dat het automatiseringsscript al meer dan een jaar niet betrouwbaar was. Het probleem werd pas zichtbaar tijdens de migratie- en validatieactiviteiten in CNC 7.1.

Er waren daarom verschillende verbeteringen en verfijningen nodig:

• Token refresh logic: De juiste logica is geïmplementeerd om token-vervaldatum te detecteren en de API-token automatisch te vernieuwen, waardoor een ononderbroken uitvoering van het script wordt gegarandeerd.
• API-responswijzigingen: verschillen tussen CNC-versies veroorzaakten extra problemen. In CNC 4.1 bevatte een verlopen tokenrespons meestal het bericht "verlopen", terwijl in CNC 7.1 het antwoord "Sleutel niet geautoriseerd" retourneert. De scriptlogica moest worden bijgewerkt om de nieuwe responspatronen in 7.1 correct te interpreteren.
• Global token handling: Voorheen werden tokens lokaal opgeslagen en gebruikt binnen functies. Dit creëerde scenario's waarbij het token geldig was bij het invoeren van een functie, maar verlopen vóór de volgende API-aanroepen. De implementatie is aangepast om gebruik te maken van globale tokenverwerking, waardoor consistentie en correcte vernieuwing voor alle functies wordt gewaarborgd.
• Verbeterde foutafhandeling: In sommige gevallen gaf de NSO "check sync" API antwoorden terug die onvolledig waren of verschilden van de verwachte structuur. Dit veroorzaakte KeyError-uitzonderingen, waardoor de scriptuitvoering werd opgeschort. Er zijn extra uitzonderingen en validatielogica geïntroduceerd, zodat het script kan blijven draaien, zelfs wanneer onverwachte API-reacties worden ontvangen.
• Verbeteringen in de stabiliteit van het script: er zijn extra beveiligingen en controles toegevoegd om ervoor te zorgen dat API-fouten, tijdelijke responsproblemen of token-vernieuwingsgebeurtenissen het script niet onverwacht beëindigen.

Deze verbeteringen losten niet alleen de problemen op die tijdens de upgrade aan het licht kwamen, maar verbeterden ook de betrouwbaarheid, veerkracht en onderhoudbaarheid van het BNM-automatiseringsframework voor playbooks aanzienlijk.

BNM-verwerking en Playbook Trigger Ontwerpwijziging

De BNM automatiseringslogica is event-driven en vertrouwt op waarschuwingen gegenereerd door KPI's in de Health Insight-applicatie binnen CNC. De totale workflow werkt als volgt:

1. CNC leest de waarden NB (nominale bandbreedte) en RBW (echte bandbreedte) van het apparaat.
2. Het berekent de bandbreedteverhouding (BW%) met behulp van deze waarden.
3. De Health Insight KPI evalueert deze verhouding aan de hand van vooraf gedefinieerde alarmdrempels.
4. Wanneer een waarschuwing wordt gegenereerd, detecteert het BNM-draaiboekscript de waarschuwing en voert het de bijbehorende corrigerende afspeelboeken uit

Beperking in het oorspronkelijke waarschuwingsontwerp

De geconfigureerde drempelwaarden voor waarschuwingen waren:

• BW% < 60 → KRITIEK
• 60 ≤ LG% ≤ 70 → Waarschuwing
• BW% > 90 → Info

Dit ontwerp werkte goed voor het identificeren van bandbreedtedegradatie, maar het creëerde een functionele kloof tijdens scenario's voor bandbreedteherstel. Het bereik van 70-90% had geen waarschuwingsniveau gedefinieerd.

Dit leidde tot dit gedrag:

• Wanneer BW% onder de 70% zakte, zou een waarschuwing Kritiek of Waarschuwing worden gegenereerd, waardoor afspeelboeken worden geactiveerd die de vorm- en bandbreedtewaarden hebben aangepast.
• Toen de bandbreedte echter herstelde en het BW% boven de 70% steeg, genereerde de KPI geen waarschuwing omdat de waarde in de 70-90%-band viel zonder bijbehorend waarschuwingsniveau.
• Omdat het BNM-automatiseringsscript volledig afhankelijk is van het genereren van waarschuwingen om acties te activeren, had het geen mogelijkheid om bijgewerkte NBW / RBW-waarden te lezen of herstelacties te starten.
• Als gevolg hiervan vond bandbreedteherstel niet automatisch plaats, hoewel voldoende bandbreedte beschikbaar was gekomen. Er was ook geen restauratielogica in het oorspronkelijke ontwerp.

Deze beperking werd zichtbaar in het productienetwerk, waar verbindingen die eerder een bandbreedtevermindering hadden ondergaan, in een beperkte staat bleven, zelfs nadat de omstandigheden waren verbeterd.

Gevolgen van de wijziging van het KPI-kader

Het probleem werd verder verergerd door de kaderwijziging die in CNC 7.1 werd geïntroduceerd. In Health Insight 4.1 ondersteunde de op Tick gebaseerde KPI-implementatie tot vijf waarschuwingsniveaus, waardoor een fijnere controle van drempelbanden mogelijk werd en de herstellogica gemakkelijker te implementeren was.

In CNC 7.1 ondersteunt het op trackerbestanden gebaseerde KPI-framework echter slechts drie waarschuwingsniveaus, waardoor de flexibiliteit bij het definiëren van meerdere hersteldrempels werd verminderd en de waarschuwingslogica opnieuw moest worden ontworpen om binnen deze beperkingen te passen.

Overmatig triggeren van Playbook

Een ander probleem dat in de oorspronkelijke implementatie werd geïdentificeerd, was de extreem hoge frequentie van playbook-executies. De automatiseringslogica bevatte geen wachttijd of stabilisatievenster. Zodra CNC een waarde heeft gelezen van het apparaat dat aan de waarschuwingsvoorwaarde voldeed:

• Het alarm werd onmiddellijk opgeheven.
• Het automatiseringsscript activeerde onmiddellijk de corrigerende playbooks.

Omdat telemetriewaarden vaak fluctueren in live netwerken, veroorzaakte dit dat honderden playbooks elk uur werden geactiveerd, wat niet ideaal was vanuit zowel een netwerkstabiliteit als een toepassingsprestatieperspectief.

opnieuw ontworpen automatiseringslogica

Om deze beperkingen aan te pakken, werd het BNM-automatiseringsontwerp herwerkt met verschillende verbeteringen:

• Herziene waarschuwingsdrempellogica: om ervoor te zorgen dat de herstelband werd vastgelegd binnen de drie waarschuwingsniveaus, werd de logica gewijzigd zodat elke BW% groter dan 70% nu wordt behandeld als een INFO-niveau waarschuwing, ter vervanging van de eerdere aanpak waarbij alleen waarden boven 90% werden geclassificeerd als INFO. Dit zorgde ervoor dat de herstelband van 70-90% actief wordt bewaakt, waardoor herstelplaybooks kunnen worden geactiveerd wanneer de bandbreedteomstandigheden verbeteren.
• Introductie van de wachttijd: er werd een wachttijdmechanisme van 20 minuten geïntroduceerd om ervoor te zorgen dat de bandbreedteomstandigheden gedurende een bepaalde periode stabiel blijven voordat de playbooks worden geactiveerd. Dit voorkomt dat automatisering reageert op kortetermijnfluctuaties.
• Gecontroleerde playbook uitvoering: Met de herziene logica en hold-time, de frequentie van playbook executies drastisch verminderd, het voorkomen van onnodige automatisering acties.
• Boostermechanisme voor ernstige degradatie: voor gevallen van ernstige degradatie van de bandbreedte werd een boosterbenadering geïntroduceerd. In dergelijke scenario's past de automatisering proactief de verkeersvormgeving en bandbreedtetoewijzing aan tot 40% van de NBW, waardoor sneller herstel van congestie mogelijk is.
• Verbeterde automatiseringsstabiliteit: de opnieuw ontworpen workflow zorgt ervoor dat zowel bandbreedtereductie als bandbreedteherstelscenario's effectief worden afgehandeld, zelfs binnen de beperkingen van het op trackers gebaseerde KPI-kader.

uitkomst

Met deze ontwerpwijzigingen, gecombineerd met de eerdere verbeteringen in API-verwerking, tokenbeheer en scriptrobuustheid, werkt het BNM-automatiseringsframework nu op een veel stabielere, efficiëntere en voorspelbaardere manier. Het systeem kan correct reageren op zowel congestie- als herstelomstandigheden, terwijl overmatige playbook-uitvoeringen worden vermeden en een betrouwbare netwerkbandbreedteoptimalisatie wordt gegarandeerd.

Onderdrukking van alarmsysteem van medisch hulpmiddel

In CNC 4.1 werden alarmen doorgestuurd naar een noordgebonden systeem genaamd OneFM via een RESTCONF API. Omdat de CNC 4.1-stack de EMF-functionaliteit niet bevatte, genereerde het platform alleen alarmsignalen op systeemniveau. Deze alarmen werden stroomopwaarts doorgestuurd zonder enige complexiteit met betrekking tot de indeling van de alarmsystemen.

Met de inzet van CNC 7.1 werd de EMF-toepassing geïntroduceerd, waardoor het alarmmodel aanzienlijk werd uitgebreid. Alarmen zijn nu onderverdeeld in drie typen:

• Systeemalarmen – gerelateerd aan CNC-platform en toepassingsgezondheid
• Netwerkalarmen – gerelateerd aan de servicevoorwaarden van het netwerk
• Apparaatalarmen – direct gegenereerd vanaf netwerkapparaten en doorgestuurd via CNC

Er was echter al een EPNM die verantwoordelijk was voor het verzamelen en beheren van alarmsystemen op apparaatniveau. Als CNC deze alarmen ook doorstuurde naar OneFM, resulteerde dit in dubbele alarmen die van beide systemen werden ontvangen. Daarom was de vereiste om apparaatalarmen uit te sluiten van CNC terwijl het systeem en netwerkalarmen nog steeds worden doorgestuurd.

De primaire uitdaging was een beperking van de RESTCONF noordgebonden API die werd gebruikt om alarmen door te sturen naar OneFM. De API ondersteunde geen filteralarmen op basis van de alarmcategorie. Als een dergelijke filtering beschikbaar was geweest, zou de oplossing eenvoudig zijn geweest: sluit apparaatalarmen op API-niveau uit voordat u ze doorstuurt naar het noordelijke systeem.

Verschillende mogelijke oplossingen werden geëvalueerd en besproken:

• Stoppen van apparaatvallen bij de bron: Voorkom dat apparaten vallen naar CNC verzenden.
• Filteren van alarmen op het noordgebonden systeem (OneFM): Laat CNC alle alarmen verzenden, maar filter apparaatalarmen binnen OneFM.
• Filteren binnen CNC voor het doorsturen van alarmen.

Het stoppen van traps op apparaatniveau werd niet haalbaar geacht omdat CNC afhankelijk is van die traps om apparaatgebeurtenissen te detecteren en operationeel bewustzijn van netwerkomstandigheden te behouden. Het uitschakelen van traps zou het vermogen van CNC om te reageren op netwerkproblemen aanzienlijk verminderen.

De uiteindelijk geïmplementeerde oplossing maakte gebruik van een ingebouwde CNC-functie genaamd Device Alarm Suppression. Met deze functie kunnen beheerders specifieke typen apparaatalarmen onderdrukken op basis van apparaatgroepen, waardoor ze niet worden verwerkt of verder stroomopwaarts worden doorgestuurd.

Door het beleid voor het onderdrukken van apparaatwaarschuwingen te configureren, kon het systeem:

• Onderdruk door het apparaat gegenereerde alarmen binnen CNC.
• Doorgaan met het verwerken en doorsturen van systeem- en netwerkalarmen.
• Voorkom dat dubbele apparaatalarmen het OneFM-systeem bereiken.

Deze aanpak zorgde voor een schone en schaalbare oplossing zonder het vermogen van CNC om vallen van apparaten te ontvangen te verstoren. Als gevolg hiervan werd de alarmstroom naar OneFM gestroomlijnd, zodat alleen relevante systeem- en netwerkalarmen werden doorgestuurd en duplicatie met het apparaatalarmbeheer van EPNM werd vermeden.

Veranderingen buiten de band

In de bestaande configuratie vertrouwde het operatieteam vaak op directe CLI-gebaseerde scripts om configuratie-updates naar netwerkapparaten te pushen, met name voor taken zoals ACL-wijzigingen en foutopsporingsactiviteiten. Hoewel deze aanpak op korte termijn effectief was, leidde deze tot een drift in de configuratie, omdat wijzigingen die buiten de NSO werden aangebracht, niet werden bijgehouden in het systeem. Als gevolg hiervan werden de provisioningworkflows van de NSO beïnvloed door inconsistenties tussen de beoogde (gemodelleerde) toestand en de daadwerkelijke apparaatconfiguraties, wat leidde tot storingen en operationele inefficiënties.

L2/L3 VPN-verbinding

Vanwege wijzigingen in de out-of-band configuratie: het netwerkteam had de VPN-gerelateerde configuratie bijgewerkt op apparaten buiten CNC / NSO en de TSDN-workflow. Als gevolg hiervan kwam de toestand die was opgeslagen in NSO (uit het CNC 4.1-tijdperk) niet altijd overeen met de toestand op de apparaten.

Deze discrepanties veroorzaakten meervoudige mislukkingen en inconsistenties in de afstemming. In verschillende gevallen bevatte NSO VPN-servicegegevens die niet langer op de apparaten bestonden (of waren gewijzigd op een manier die NSO niet weerspiegelde). Om NSO af te stemmen op het netwerk, was het noodzakelijk om VPN-servicevermeldingen te verwijderen die alleen in NSO bestonden en niet op de apparaten, en om andere mismatches te corrigeren die werden veroorzaakt door out-of-band veranderingen.

Effect van planning

Het oplossen van deze problemen kostte ongeveer twee extra weken na het oorspronkelijke verzoeningsplan. De extra tijd werd besteed aan het identificeren van mismatches, het valideren van apparaatstatus en het veilig reinigen of corrigeren van NSO CDB-gegevens.

waarnemingen

1. Configuratie-autoriteit: Out-of-band wijzigingen in VPN-configuratie (of een door TSDN beheerde configuratie) zorgen voor een verschuiving tussen NSO en het netwerk en maken het afstemmen ingewikkeld.
2. Basislijn vóór migratie: een duidelijke basislijn van de NC/NSO-beheerde vs. alleen-apparaatstatus vóór migratie zou verschillen gemakkelijker hebben gedetecteerd en opgelost.
3. Automatisering en conversie: Payload conversiescripts en gebruikersspecifieke aanpassingen waren essentieel om op een consistente manier om te gaan met formaat- en modelverschillen tussen 4.1 en 7.1.

Aanbevelingen voor vergelijkbare upgrades

1. Een wijzigingsblokkering voor VPN- (en andere door TSDN beheerde) services afdwingen tijdens het verzoeningvenster, met uitzonderingen alleen via een gecontroleerd proces.
2. Voer een pre-reconciliatie-audit uit waarbij de NSO CDB wordt vergeleken met de apparaatconfiguratie om discrepanties te kwantificeren en op te sommen voordat de reconciliatie wordt gestart.
3. Documenteer en socialiseer dat VPN-wijzigingen na de upgrade via CNC / NSO TSDN moeten worden doorgevoerd om herhaling van out-of-band drift te voorkomen.
4. Conversie- en reconciliatiescripts behouden voor hergebruik in toekomstige upgrades of voor probleemoplossing.

Fout bij CNC-back-up door afhankelijkheid van onderhoudsmodus

Het CNC-back-upmechanisme schrijft voor dat het platform in de onderhoudsmodus wordt geplaatst voordat een back-upbewerking kan worden gestart. De back-up-API handhaaft deze voorwaarde door te ontwerpen; als CNC niet overgaat naar de onderhoudsmodus, wordt het back-upproces automatisch afgebroken.

In de praktijk is het invoeren van de onderhoudsmodus vaak mislukt vanwege lopende systeemactiviteiten, waaronder:

• Uitvoeringen van Active Change Automation Playbook (MOP)
• Lopende sZTP-workflows
• DLM-servicebewerkingen
• KPI-profielbijlage- of detacheringsactiviteiten
• On-demand showtech-collecties
• Achtergrond orkestratie taken

De aanwezigheid van een dergelijke activiteit voorkomt dat CNC de onderhoudsmodus ingaat, waardoor de back-upbewerking mislukt voordat deze wordt uitgevoerd.

operationeel effect

De vereiste dagelijkse CNC-back-ups voor naleving en operationele zekerheid. Door frequente automatiseringsactiviteiten, met name door BNM getriggerde playbooks, kon het systeem echter vaak niet in de onderhoudsmodus komen. Als gevolg hiervan hebben zich herhaaldelijk back-upfouten voorgedaan, waardoor een aanzienlijk operationeel risico ontstond en handmatige interventie noodzakelijk was.

mitigatiestrategie

1. Optimalisering van back-upplanning: er werd een onderhoudsvenster met minimale systeemactiviteit geïdentificeerd. Op basis van de analyse van verkeer en automatisering was de back-uptaak gepland voor 05.00 uur (AEST), wanneer orkestratie en uitvoering van het afspeelboek het minst waarschijnlijk actief waren.

2. Validatie van activiteiten vóór de back-up: er is een geautomatiseerde controle vóór het aanroepen van de back-up-API ingevoerd:

• Het script zoekt CNC-API's om actieve MOP-taken voor wijzigingsautomatisering te detecteren.
• Als een taak wordt gerapporteerd als Running, wacht het script 5 seconden en probeert het opnieuw.
• Deze lus gaat door totdat het systeem geen actieve taken rapporteert.
• Pas nadat is bevestigd dat de omgeving niet actief is, probeert het script de onderhoudsmodus in te schakelen en de back-up te activeren.

Hierdoor konden geen onnodige back-uppogingen worden uitgevoerd terwijl het systeem in een actieve toestand verkeerde.

3. Herstel- en veerkrachtmechanismen: Om tijdelijke systeemtoestanden op te vangen, zijn aanvullende waarborgen toegevoegd:

• Maximaal drie herhalingspogingen als de back-up-API een fout retourneert
• Korte vertragingsintervallen tussen pogingen
• Gracieuze foutafhandeling om scriptbeëindiging te voorkomen

Resultaten en resultaat

De gecombineerde mitigatie verbeterde de betrouwbaarheid van de back-up aanzienlijk:

• Back-upfouten werden drastisch verminderd
• Na de implementatie werden slechts twee fouten waargenomen, beide veroorzaakt door een vastgelopen sZTP-proces, dat buiten de controle van het script valt.
• De invoering van vertragingen in de uitvoering van de BNM playbook automatisering verder verminderd de strijd met onderhoud modus.

Syslogs doorsturen naar Splunk

De syslog-bestemming werd geconfigureerd in CNC om logs door te sturen naar Splunk via TLS. Na ontvangst waren de logs echter onleesbaar aan de kant van Splunk. Vanwege dit probleem afkomstig uit de Splunk-omgeving werd gekozen voor de optie om terug te keren naar UDP-transport, waarna de logs met succes werden verwerkt.

Probleem met migratie naar apparaatgroepering

De gebruiker heeft eerder 18 apparaatgroepen gemaakt in CNC 4.1; die release bood echter geen UI-gebaseerd of API-gestuurd mechanisme om apparaatgroepen te exporteren of importeren. Als gevolg hiervan vereiste de migratie van deze groepen naar CNC 7.1 een niet-standaard aanpak. Er werden twee interne CNC-API's geïdentificeerd: een waarin de hiërarchie van de apparaatgroep wordt weergegeven en een andere waarin de apparaten worden vermeld die zijn toegewezen aan elke hiërarchische node. Met behulp van deze API's werden alle apparaatgroepen en de bijbehorende apparaten geëxtraheerd en opgeslagen als JSON-uitgangen. Vervolgens werd een aangepast script ontwikkeld om de antwoorden te ontleden en alleen de hostnamen van het apparaat uit elke groep te extraheren.

CNC 7.1 introduceerde native import-/exportmogelijkheden voor apparaatgroepen, waaronder een op CSV gebaseerde importsjabloon. Na het extraheren van hostnamen uit het oude systeem, werd een tweede automatiseringsscript gemaakt om de CSV-sjablonen in het vereiste formaat te vullen, zodat elke apparaatgroep nauwkeurig en onafhankelijk kon worden geïmporteerd. Deze automatisering was essentieel; zonder deze automatisering zou de migratie van de apparaatgroepen naar CNC 7.1 aanzienlijk tijdrovender en operationeel complexer zijn geweest.

Apparaten met ernstige bandbreedte isoleren

Ondanks de implementatie van de BNM use case om automatisch lage RBW/NBW-verhoudingen te verhelpen, bleef een subset van apparaten gedurende langere perioden in ernstig gedegradeerde toestand. Hoewel de afspeelboeken voor vormgeving en bandbreedteaanpassing doorgaans kort na degradatiegebeurtenissen apparaten herstelden, bleven verschillende apparaten langer dan een week in kritieke toestand en was handmatige interventie vereist. Het identificeren van deze apparaten vormde echter een uitdaging. Hoewel de CNC UI duidelijke visualisaties van waarschuwingen en bandbreedtemetingen biedt, onthult het niet gemakkelijk apparaten die gedurende een langere periode exclusief in kritieke toestand zijn gebleven.

Om deze operationele kloof te dichten, is een API-gestuurde oplossing ontwikkeld. CNC biedt een API die een lijst van de belangrijkste waarschuwingsgenererende apparaten ophaalt over configureerbare tijdvensters (bijvoorbeeld 7 dagen, een maand). Door deze gegevens op te halen en te filteren op apparaten die tijdens de geselecteerde periode alleen kritieke waarschuwingen hebben gegenereerd, kon het team apparaten die handmatig moesten worden hersteld snel isoleren. Deze geautomatiseerde aanpak verbeterde de efficiëntie van het oplossen van problemen aanzienlijk en verkortte de tijd die nodig was om gevallen van aanhoudende degradatie te identificeren.

Verwijdering van apparaattelemetrieconfig

In CNC 4.1 werden telemetrieconfiguraties die via het NSO werden gepusht via het tcfunction pack automatisch toegepast wanneer een apparaat werd gekoppeld aan een Health Insight (HI) KPI-profiel. Deze configuraties, inclusief CDG VIP-referenties, werden echter niet verwijderd toen het KPI-profiel later werd losgekoppeld. Als gevolg hiervan verzamelden apparaten in de loop van de tijd verouderde en redundante telemetriegegevens.

Dit probleem werd meer uitgesproken tijdens de upgrade naar CNC 7.1. Apparaten behielden vaak bestaande CDG VIP-telemetrieconfiguraties van CNC 4.1 naast de nieuwe vermeldingen gegenereerd door CNC 7.1, wat leidde tot meerdere conflicterende telemetrieconfiguraties op meer dan 2.000 apparaten. Er werden zorgen geuit over de operationele impact en de configuratiehygiëne, omdat alleen de CNC 7.1 CDG VIP-configuratie actief moet zijn gebleven.

Om dit aan te pakken, werd een geautomatiseerd script ontwikkeld om verouderde CDG VIP-referenties te identificeren en te verwijderen uit de telemetrieconfiguratie van elk apparaat. Deze oplossing elimineerde inconsistenties in de configuratie, herstelde de afstemming met het verwachte 7.1-telemetriemodel en voorkwam wat enkele dagen van handmatige reinigingsinspanningen zou zijn geweest in de grote apparaatvloot.

Problemen oplossen met MDT Collection

In CNC 7.1 zijn de meeste Health Insight (HI) KPI-collecties gebaseerd op Model-Driven Telemetry (MDT). Wanneer een KPI-profiel is ingeschakeld op een apparaat, programmeert NSO automatisch de vereiste sensorpaden en configureert de CDG VIP als de telemetriebestemming. Zodra deze configuratie is toegepast, wordt een corresponderende CDG-verzamelingstaak gemaakt om de telemetriestatus van het apparaat te volgen.

Tijdens de validatie werd gemeld dat meer dan 100 apparaten telemetrieconfiguraties ontbraken. Het identificeren van deze apparaten via de CNC-gebruikersinterface bleek onpraktisch, omdat de gebruikersinterface alleen filtering per apparaat ondersteunt en niet efficiënt schaalbaar is voor een vloot van meer dan 2.000 apparaten. Hiervoor was een geautomatiseerde methode nodig om te bepalen welke apparaten geen telemetrieconfiguratie hadden en de vereiste KPI-heractivering.

Om dit aan te pakken, hebben we de BNM-tag gebruikt die is toegewezen aan apparaten wanneer een KPI-profiel wordt geactiveerd. Eerst werd een export van alle apparaten met de BNM-tag gegenereerd. Een Python-script werd vervolgens ontwikkeld om te communiceren met de CNC Collection API, met paginatielogica om de volledige set van verzameltaken op te halen (elke API-oproep retourneert maximaal 100 vermeldingen). Het script extraheerde hostnamen uit de verzameltaakgegevens en vergeleek deze met de geëxporteerde apparaatlijst met BNM-tags.

Deze vergelijking leverde de lijst met apparaten op die waren gelabeld, maar niet in de BNM-verzamelingstaak werden weergegeven, wat aangeeft dat de MDT-telemetrieconfiguratie niet was toegepast. Het KPI-profiel werd vervolgens opnieuw ingeschakeld op deze apparaten en validatie bevestigde dat alle bijbehorende verzameltaken correct zijn gemaakt.

Deze automatisering heeft het probleemoplossingsproces aanzienlijk gestroomlijnd, waardoor het team alle getroffen apparaten binnen één dag kon identificeren en verhelpen, een inspanning die niet haalbaar zou zijn geweest door handmatige inspectie.

HA Gedragsveranderingen en Consensus Algoritme Aanpassing in NSO 6.4.1.1

Tijdens de upgrade van Cisco NSO 5.7.5.1 naar 6.4.1.1 als onderdeel van de Cisco CNC 7.1-overgang werd een opmerkelijke verandering waargenomen in het gedrag van High Availability (HA) vanwege de impliciete inschakeling van het consensusalgoritme in de nieuwere NSO-versie. Dit was niet het standaardgedrag in NSO 5.7.5.1, wat leidde tot een verschuiving in failoverkenmerken na de upgrade. In het bijzonder wanneer het primaire knooppunt werd verwijderd, ging het secundaire knooppunt over naar een alleen-lezen status, waardoor het geen provisioning-activiteiten kon afhandelen. Evenzo, toen het secundaire knooppunt naar beneden ging, verhuisde het primaire knooppunt van een actieve primaire toestand naar een "geen" -toestand, waardoor de continuïteit van de service werd beïnvloed.

Om het verwachte HA-gedrag te herstellen dat was afgestemd op de vorige implementatie, werd het consensusalgoritme expliciet uitgeschakeld in NSO 6.4.1.1. Deze aanpassing zorgde ervoor dat de primaire en secundaire knooppunten hun beoogde rol hervatten tijdens failover-scenario's, waardoor ononderbroken provisioning mogelijk werd en de operationele stabiliteit in overeenstemming met de eerdere versie van de nationale transmissiesysteembeheerder werd gehandhaafd.

Verbeteringen in NSO-versie en pakketcompatibiliteit

Als onderdeel van de overgang van Cisco CNC 4.1 naar 7.1 werd de onderliggende Cisco NSO-versie opgewaardeerd van 5.7.5.1 naar 6.4.1.1. Deze versie-upgrade introduceerde veranderingen in XML-sjabloonstructuren binnen bestaande NSO-pakketten, wat leidde tot fouten in bepaalde regressietestgevallen die afhankelijk waren van het gedrag van oudere sjablonen.

Om deze compatibiliteitsleemten aan te pakken, werden de betrokken NSO-pakkettemplates geanalyseerd en bijgewerkt om ze af te stemmen op het herziene schema en de verwerkingsvereisten van NSO 6.4.1.1. Deze verbeteringen zorgden ervoor dat alle automatiseringsworkflows en servicemodellen bleven functioneren zoals verwacht, waardoor de regressiestabiliteit werd hersteld en de consistentie in de geüpgradede CNC-omgeving werd gehandhaafd.

Problemen met KPI-inschakeling op schaal

CNC biedt een kant-en-klaar UI-mechanisme voor het inschakelen van KPI-profielen op apparaten. Hoewel deze aanpak goed werkt voor kleine vloten, wordt deze op grote schaal inefficiënt en onbetrouwbaar. Bij deze implementatie hadden meer dan 2.000 SWR-apparaten KPI-activering nodig en de gebruikersinterface bood geen effectieve manier om apparaten in bulk te selecteren of te verwerken.

Aanvankelijk werd een op tagging gebaseerde benadering geprobeerd: alle SWR-apparaten kregen een SWR-tag toegewezen en KPI-activering werd uitgevoerd met tagselectie in plaats van handmatige apparaatselectie. Het verwerken van meer dan 2.000 apparaten in één workflow leidde echter tot aanzienlijke operationele uitdagingen. De taak duurde meer dan drie uur en werd voltooid met honderden mislukkingen. Hoewel alle apparaten in de opzet waren opgenomen, kregen slechts ~750 met succes KPI-activering en herhaaldelijke pogingen produceerden slechts incrementele vooruitgang. Deze aanpak bleek niet schaalbaar of herhaalbaar. Het toonde aanzienlijke problemen met de lading.

Een tweede uitdaging kwam voort uit problemen met de synchronisatie van NSO-apparaten. Veel storingen gaven aan dat NSO niet was gesynchroniseerd met de bijbehorende apparaten. Poging tot handmatige synchronisatie van bewerkingen gevolgd door KPI-heractivering was onpraktisch en zou uitgebreide inspanning van de operator hebben vereist.

Om deze beperkingen aan te pakken, werd een geautomatiseerde, batchgestuurde workflow ontwikkeld:

1. Exporteer de volledige CNC-inventaris.
2. Procesapparaten in batches van 50 (geïdentificeerd als de optimale grootte door afstemming).
3. Activeer voor elke batch een automatische synchronisatie van het apparaat met behulp van UUID's.
4. KPI-activering uitvoeren via de CNC-API.
5. KPI-taakgeschiedenis en logfouten programmatisch bewaken.
6. Verwerk mislukte apparaten opnieuw door de stappen voor synchronisatie en KPI-activering te herhalen.
7. Zodra een batch succesvol is voltooid, gaat u verder met de volgende set van 50 apparaten.

De automatisering omvatte ook de mogelijkheid om KPI-profielen uit te schakelen, waardoor volledig levenscyclusbeheer mogelijk werd.

Deze oplossing leverde een gestroomlijnd, deterministisch en zeer schaalbaar proces voor KPI-provisioning. Het elimineerde handmatige interventie, zorgde voor consistente resultaten en bespaarde meerdere dagen operationele inspanning. Dezelfde automatisering bleek van onschatbare waarde toen KPI-profielen moesten worden uitgeschakeld en opnieuw moesten worden ingeschakeld na de ontwerpwijziging van de BNM, waardoor een snelle en foutloze herconfiguratie mogelijk was voor de gehele vloot van 2000 apparaten.

RESTCONF Northbound API beperkt tot beheerderstoegang

De op RESTCONF gebaseerde northbound API die wordt gebruikt om alarmen en gebeurtenissen van CNC door te sturen, heeft een beperking waardoor deze alleen kan worden aangeroepen met behulp van de admin-account. Pogingen om toegang te krijgen tot de API via serviceaccounts waren niet succesvol, ondanks dat die accounts de vereiste operationele rollen hadden. Als tijdelijke oplossing moest de gebruiker de beheerdersreferenties gebruiken voor het doorsturen van waarschuwingen naar het noordelijke systeem, waardoor een operationele beperking werd ingevoerd en de naleving van de principes voor toegang met de minste privileges werd beperkt.

Automatisering als strategische enabler

Gezien de omvang en complexiteit van het CNC-upgrade- en migratieprogramma bleek handmatige uitvoering van operationele taken al snel onhoudbaar. Activiteiten zoals onboarding van apparaten, KPI-provisioning, configuratie-uitlijning, afstemming en telemetrievalidatie omvatten duizenden netwerkelementen en herhaalde workflows die zeer vatbaar zijn voor menselijke fouten wanneer ze handmatig worden uitgevoerd. Automatisering was daarom niet alleen essentieel om de uitvoering te versnellen, maar ook om consistentie te garanderen, operationele risico's te verminderen en leveringsteams vrij te maken van tijdrovende, repetitieve taken.

Door deze processen te systematiseren via gescripte workflows en API-gestuurde bewerkingen, heeft het upgradeprogramma aanzienlijke efficiëntiewinsten behaald. Automatisering maakte snellere taakvoltooiing, verbeterde nauwkeurigheid en voorspelbare resultaten in alle secties mogelijk. De daaruit voortvloeiende besparingen verminderden niet alleen de totale implementatietijdlijn, maar stelden ingenieurs ook in staat zich te richten op validering en ontwerpinspanningen met een hogere waarde in plaats van op routinematige operationele taken.

Sommige automatiseringsactiviteiten werden geïdentificeerd voordat het upgradeproject van start ging, terwijl sommige evolueerden wanneer er uitdagingen ontstonden. Er waren ook een aantal problemen die noodzakelijk waren vanwege de problemen die zich tijdens het project ontwikkelden.

Deze tabel illustreert de gebieden waarop automatisering een aanzienlijke impact had op het hele programma.

Taakbeschrijving	Handmatige inspanning (dagen)	Inspanning voor automatisering (dagen)	Geschatte besparingen (dagen)
ACL-updates (SWR/LWR)(2K+)	30.0	2.0	28.0
Apparaatmigratie en aansluiting op CDG(2K+)	5	1.0	4.0
BNM KPI-aansluiting op apparaten (2K+)	4.0	1,5 (AVG)	2.5
serviceconciliatie	7	2.5	4.5
Migratie van apparaatgroepen	4	0.5	3.5
Apparaten met ernstige bandbreedte isoleren	3	0.5	2.5
Problemen met MDT-verzameling oplossen	3	0.5	2.5
Totalen	56 dagen	8,5 dagen	47,5 dagen

geleerde lessen

Upgrade is niet eenvoudig

CNC ondersteunt geen in-place upgrades en het lift-and-shift-model zorgt voor aanzienlijke operationele complexiteit. Het proces mag nooit worden verondersteld eenvoudig te zijn, vooral wanneer de versiesprong groot is. Onverwachte problemen duiken op in toepassingen, integraties en workflows en vereisen telkens tijd, analyse en zorgvuldige mitigatie. Een grote versiesprong versterkt deze uitdaging en maakt een grondige planning, validatie en gefaseerde uitvoering essentieel. We moesten veel extra tijd besteden aan TAC-gevallen en het oplossen van problemen. Omdat we hier geen buffertijd voor hadden, werd het een uitdaging.

CX moet zwaar tillen

Verwacht aanzienlijke inspanningen op het gebied van CX voor implementatie, integratie, migratie en validatie van end-to-end use-cases. Ga er niet van uit dat workflows die op de oude versie zijn bewezen, zich identiek gedragen op de nieuwe. Veel probleemoplossing en analyse zijn vereist om dingen te laten werken.

Automatisering Toolkit is een noodzaak

Tijdens de upgrade is gebleken dat automatisering geen optioneel gemak is, maar een fundamentele vereiste voor grootschalige CNC-implementaties. We planden al vroeg automatisering voor de nodige kandidaten, maar we kunnen nooit aannemen dat dat genoeg zal zijn. In het midden van het project konden problemen worden vastgesteld in gebruikssituaties waarbij automatisering zeker waarde zou toevoegen, zoals is aangetoond in de eerdere secties.

Vermijd conflicten met dubbele controllers tijdens migratie

Tijdens de upgrade is het van cruciaal belang om ervoor te zorgen dat zowel de bestaande als de nieuwe CNC-omgevingen niet tegelijkertijd actief zijn. Hoewel een korte doorweekperiode noodzakelijk is voor de validering, leidt een aanzienlijke verlenging ervan, zoals in dit project met meer dan twee maanden is gebeurd, tot operationele risico's. Aangezien beide CNC's meer dan 15-20 dagen actief waren, leidden closed-loop automatiseringsfuncties zoals Bandwidth On Demand tot inconsistente en conflicterende acties in het netwerk, omdat de automatiseringslogica vanaf twee controllers tegelijk werd uitgevoerd.

Een belangrijke les is het implementeren van duidelijke vangrails tijdens migratie. Maatregelen zoals het administratief uitschakelen van apparaten in de oude CNC, het pauzeren van automatiseringsworkflows of het beperken van telemetrieabonnementen zouden deze conflicten hebben voorkomen. Bij toekomstige upgrades moet expliciet worden gepland dat de controller strikt wordt geïsoleerd om interferentie met twee controllers te voorkomen en voorspelbaar netwerkgedrag te garanderen.

MOP's zijn niet heilig

Hoewel Methode van Procedure (MOP)-documenten worden gemaakt voor elke implementatie, integratie en use case, is het onrealistisch om aan te nemen dat een MOP die is gevalideerd in laboratoriumomstandigheden zich identiek gedraagt in de productie. De productieomgeving liet consequent afwijkingen zien, sommige klein, sommige significant, waardoor hiaten werden benadrukt die niet zichtbaar waren tijdens gecontroleerde tests. Real-world netwerken, legacy gedrag, externe afhankelijkheden en live verkeer omstandigheden introduceren variabelen die laboratorium simulaties niet altijd kunnen repliceren.

Het belangrijkste leerpunt is dat teams de uitrol van de productie moeten benaderen met de verwachting dat ze onverwacht gedrag, edge cases en nieuwe ontdekkingen tegenkomen. Flexibiliteit, snel probleemoplossend vermogen en de bereidheid om procedures direct aan te passen zijn essentieel voor een succesvolle uitvoering op grote schaal.

Werkzaamheid van TAC-gevallen

Postproductieproblemen zijn onvermijdelijk, en hoewel de eerste probleemoplossing door het afleveringsteam waardevol is, kan alleen vertrouwen op interne inspanningen leiden tot onnodige vertragingen. Het is verstandig om tegelijkertijd een TAC-zaak te openen als vangnet, met name voor productgerelateerde kwesties of complexe gedragingen die niet onmiddellijk diagnosticeerbaar zijn. TAC-onderzoeken vergen vaak tijd, en het uitstellen van de oprichting van een zaak met meerdere dagen kan leiden tot een aanzienlijk verlies van projectmomentum. Door TAC vroegtijdig in te schakelen, is deskundige hulp beschikbaar wanneer dat nodig is, wordt de identificatie van de onderliggende oorzaak versneld en wordt vermijdbare uitglijders van schema's voorkomen.

Schakel CNC BU in voor effectieve kennisondersteuning

Sterke ondersteuning van de CNC Business Unit is zeer waardevol tijdens elk CNC-project. Gebruikers hebben vaak gedetailleerde productinzichten en verduidelijkingen nodig die niet direct beschikbaar zijn met het bezorgteam alleen. Het hebben van een BU-contact dat gedurende de hele service toegankelijk is, versnelt de probleemoplossing, versterkt de technische nauwkeurigheid en helpt bij het opbouwen van meer vertrouwen en een betere gebruikersrelatie.

Best practices voor CNC-upgrade

Een geoptimaliseerde upgradestrategie plannen

CNC ondersteunt geen in-place upgrades, waardoor parallelle implementatie onvermijdelijk is. Behandel de nieuwe omgeving als een nieuwe installatie en wijs voldoende computer-, opslag- en beheercapaciteit toe om twee omgevingen tegelijk uit te voeren. Plan validatiefasen, migratiesequencing en cutover-activiteiten ruim van tevoren.

Een rigoureuze validatie vóór implementatie is essentieel, vooral voor onveranderlijke parameters

Veel ervaringen onderstrepen het cruciale belang van zorgvuldigheid tijdens de eerste inzet. Het vooraf valideren van alle belangrijke ingangen, met name onveranderlijke configuratieparameters, is essentieel om kostbare herimplementaties en planningseffecten te voorkomen. Het gebruik van gestructureerde controlelijsten voorafgaand aan de implementatie, collegiale toetsingen en validaties tijdens het drooglopen wordt daarom sterk aanbevolen om het risico van onomkeerbare configuratiefouten te minimaliseren.

Gebruik een speciale validatieomgeving voordat u de productie aanraakt

Door vroeg in het project een interne CALO/testomgeving op te zetten, kunnen teams experimenteren, workflows valideren, versiespecifieke wijzigingen ontdekken en vertrouwen opbouwen voordat ze de productie aanraken. Dit vermindert onbekenden aanzienlijk tijdens de uiteindelijke uitrol.

Evidence-based dimensionering voor gedistribueerde kruiswerkcomponenten

Bij het ontwerpen van clusters, CDG-distributies en PCE-toewijzingen baseren beslissingen zich op apparaattypen, interfaceschaal, topologiecomplexiteit en verzamelintensiteit in plaats van eenvoudige apparaattellingen. Evenwichtige distributies voorkomen overbelasting en zorgen voor voorspelbare prestaties in het hele cluster.

Automatisering voor repetitief werk met grote volumes

Stel een automatiseringsachterstand in bij kickoff-taken die repetitief, hoog volume of operationeel kritisch zijn en investeer waar automatisering verplicht is. Valideer en verfijn eerst uw automatisering in een SIT-omgeving, zodat de productie niet afhankelijk is van last-minute oplossingen. Schaal verhoogt de kosten van handmatig werk; gestandaardiseerde automatisering verbetert de kwaliteit, snelheid en controle. Resultaten als herbruikbare assets (gedocumenteerde interfaces, geparametriseerde taken, gedeelde bibliotheken) zodat teams dezelfde automatisering kunnen gebruiken voor toekomstige Crosswork-upgrades en aangrenzende projecten, waardoor herwerk- en onboardingtijd wordt verminderd.

Vermijd dubbele controle met gesloten kringloop tijdens parallelle run

Behandel closed-loop automation tijdens co-existentie als een single-writer-mogelijkheid: slechts één orkestratiepad kan actief probleemoplossing of beleidsgestuurde configuratie aansturen. Gelijktijdige CLA op oude en nieuwe stapels riskeert dubbele triggers en uiteenlopende bedoelingen, die de toestanden van het apparaat kunnen destabiliseren. Plan CLA go-live als een mijlpaal in de late fase, na functionele validatie en definitieve overdracht aan de nieuwe controller.

Gestructureerde effectbeoordeling van upgrades uitvoeren

Grote versiesprongen introduceren nieuwe mogelijkheden terwijl oudere worden afgekeurd of gewijzigd. Het is van groot belang om rekening te houden met deze veranderingen. Vaak wordt de wijziging niet gedocumenteerd in de release-notities van de bijgewerkte versie en verschijnt deze wanneer we het veld bereiken. Het uitvoeren van gestructureerde evaluaties van:

• Afgedankte API's
• Wijzigingen in het KPI-kader
• Gedragsverschillen op toepassingsniveau
• Afwijkingen configuratiemodel
• Waarschuwingen, verwerking van topologie en wijzigingen in de uitvoering van playbooks

Compatibiliteit en gedrag testen op het integratieoppervlak

CNC werkt samen met meerdere externe systemen zoals NSO, SSM, CPNR, EPNM, OneFM, Splunk en orkestratiekaders.
Vóór migratie:

• Versiecompatibiliteit valideren
• Alle noord-/zuidgebonden integraties testen
• Bevestig gegevensmodellen, traps, telemetriestromen
• Verificatiegedrag SSL/RESTCONF controleren

Door na de migratie ontdekte integratiefouten ontstaan operationele blinde vlekken.

Een robuuste strategie voor de export van gegevens vóór de migratie opstellen

Exporteer alles voordat u met de migratie begint:

• Referentieprofielen
• Aanbieders
• Tags
• Aangepaste afspeelboeken
• Aangepaste KPI's
• Rollen en RBAC
• sZTP-vouchers
• Apparaatgroepen
• Historische servicemetagegevens

Migratie van batchapparaten met ingebouwde validatiepoorten

Bij het migreren van duizenden apparaten kunt u migreren in gecontroleerde batches:

• Apparaten verplaatsen in vaste cohorten (bijvoorbeeld op regio, CDG-belasting of apparaattype)
• Valideer telemetrie, NSO-synchronisatiestatus en bereikbaarheid voordat u naar de volgende batch gaat
• De batch terugdraaien als zich aanhoudende afwijkingen voordoen

Dit voorkomt een hoge belasting op CDG en CNC in een kort tijdsbestek.

Omgaan met out-of-band configuratiewijzigingen via NSO-integratie

Om de out-of-band-uitdaging aan te pakken als onderdeel van de CNC 4.1 tot 7.1-upgrade, werd een gestructureerde verschuiving naar NSO-gestuurde operaties geïmplementeerd. Het operatieteam kreeg gecontroleerde, gebruikersgebaseerde toegang tot de NSO CLI, terwijl directe administratieve toegang tot de CLI van het apparaat werd beperkt om out-of-band veranderingen te voorkomen. Daarnaast werden legacy CLI-scripts systematisch omgezet in op RESTCONF gebaseerde automatisering geïntegreerd met NSO, waardoor mogelijkheden zoals validatie tijdens dry-run en terugdraaien van transacties mogelijk werden. Deze aanpak zorgde ervoor dat alle configuratiewijzigingen centraal werden beheerd, controleerbaar waren en consistent waren met de servicemodellen van NSO, waardoor configuratiedrift effectief werd geëlimineerd en de betrouwbaarheid van de provisioning werd hersteld.

Leg sterke nadruk op Change Freeze

Tijdens kritieke migratievensters:

• Door gebruiker geïnitieerde netwerkwijzigingen bevriezen
• Config-pushes beperken
• Synchroniseren met veld- en NOC-teams
• Plan een venster voor noodactiviteiten zoals het vervangen van apparaten met behulp van CNC / ZTP enzovoort.

Dit vermindert ruis en zorgt ervoor dat de netwerkstatus tijdens de upgrade stabiel blijft

Conclusie

De migratie van CNC 4.1 naar CNC 7.1 vormt een belangrijke case study in de complexiteit die inherent is aan grootschalige netwerkorkestratieplatformupgrades. Dit project toont aan dat dergelijke overgangen niet alleen versieverbeteringen zijn, maar uitgebreide transformaties over architecturale lagen, operationele workflows en automatiseringsecosystemen. Het ontbreken van een in-place upgradepad vereiste een volledige implementatie van lift-and-shift, waarbij parallelle milieu-uitdagingen werden geïntroduceerd en zorgvuldige coördinatie tussen CNC, NSO, SR-PCE, CDG en externe systeemintegraties vereist was. Het resulterende operationele landschap onderstreepte het belang van robuuste migratiemethodologieën, uitgebreide validatiecycli en strak gecontroleerde doorvoerprocessen om risico's in productieomgevingen te beperken.

De upgrade onthulde verder de kritische aard van automatisering als een onmisbare pijler voor schaalbaarheid en nauwkeurigheid. Met meer dan 2.000 apparaten, uitgebreide telemetrieconfiguraties, meerdere afhankelijke componenten en dynamische workflows voor automatisering met gesloten kringlopen, benadrukte het project de beperkingen van handmatige procedures in omgevingen van deze omvang. Doelgericht gebouwde automatisering die ACL-updates, apparaatonboarding, KPI-provisioning, telemetrie-opruiming en foutisolatie omvat, bleek essentieel voor het waarborgen van determinisme, het verminderen van menselijke fouten en het bereiken van aanzienlijke efficiëntiewinsten. Het automatiseringskader maakte niet alleen operationele continuïteit tijdens de migratie mogelijk, maar legde ook een duurzame basis voor voortdurende netwerkoptimalisatie.

Even belangrijk was de erkenning dat het productiegedrag duidelijk afwijkt van gecontroleerde laboratoriumomstandigheden. Raamwijzigingen, zoals de overgang van op Tick gebaseerde KPI-logica naar op trackers gebaseerde definities, introduceerden onverwachte gedragsverschuivingen die reengineering, hertesten en iteratieve verfijning vereisten. Op dezelfde manier benadrukten operationele uitdagingen rond closed loop-automatisering, telemetrie-betrouwbaarheid en API-gedrag de noodzaak van adaptieve probleemoplossing, proactieve risicobeoordeling en voortdurende betrokkenheid bij TAC- en Business Unit-materiedeskundigen. Deze factoren illustreren gezamenlijk dat grote versieovergangen zowel technische diepgang als organisatorische gereedheid vereisen. Er zijn nog maar weinig openstaande kwesties die naar verwachting zullen worden opgelost in de volgende kruiswerkversie 7.2.

Over het algemeen toont deze upgrade aan dat succesvolle grootschalige CNC-migraties berusten op vier fundamentele pijlers: rigoureuze validatie vóór implementatie, systematische en veerkrachtige automatisering, sterke cross-functionele coördinatie en een adaptieve operationele houding die anticipeert op divergentie tussen laboratorium- en productieomgevingen. De inzichten die zijn opgedaan met deze betrokkenheid hebben niet alleen bijgedragen aan een stabiele CNC 7.1-implementatie, maar bieden ook een blauwdruk voor toekomstige overgangen, het informeren van best practices, het versterken van architecturale vangrails en het versterken van institutionele kennis voor de daaropvolgende evolutie van uw ecosysteem voor netwerkautomatisering.

Woordenlijst van termen

Begrip	Definitie
BNM	Bericht over bandbreedte.
KAT	Crosswork Active Topology
CCA	Crosswork Change Automation
CDG	Crosswork Data Gateway
CHI	Crosswork Health Insight
CNC	Cisco Crosswork Network Controller
COE	kruiswerkoptimalisatiemotor
CPNR	Cisco Prime Network-registratieserver
CWM	Crosswork Workflow Manager
EMF	Elementbeheerfuncties
KPI	kernprestatie-indicator
LWR	Grote draadloze router
MDT	modelgestuurde telemetrie
DWEILEN	Methode van procedure
NBW	nominale bandbreedte
NSO	Network Services Orchestrator
RBW	opgenomen bandbreedte
SR-PCE	element voor de berekening van het routeringspad van het segment
SSM	Cisco Smart Software Manager
SWR	Kleine draadloze router
TAC	centrum voor technische bijstand
TSDN	Transport Software-Defined Networking
ZTP	Zero Touch Provisioning
RR	routereflector
RP	routeprofiel
POI	verbindingspunt
EVPN	Ethernet Virtual Private Network.

Referenties

• Cisco Systems, Cisco Crosswork Network Controller Release Notes, versie 7.1.0 
• Installatiehandleiding Cisco Systems, Cisco Crosswork Infrastructure 7.1
• Cisco Systems, Cisco Crosswork Infrastructure 7.1-beheergids — Conceptenoverzicht: 
• Cisco Systems, Crosswork Network Controller Traffic Engineering and Optimization Guide, versie 7.1
• Cisco Systems, Cisco Crosswork Health Insights Gebruikershandleiding, versie 7.1
• Implementatiehandleiding Cisco Systems, Crosswork Zero Touch Provisioning (ZTP)
• Cisco Systems, Cisco NSO Transport SDN Function Pack, installatiehandleiding, versie 7.1.0  
• Cisco Systems, Cisco SR-PCE Configuration Guide

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
2.0	04-May-2026	Eerste versie, opmaak, koppen, koppelingen, grammatica, spelling.
1.0	30-Apr-2026	Eerste vrijgave