Problemen oplossen met de implementatie van Firepower Threat Defense Policy
Inhoud
Inleiding
In dit document wordt een overzicht op hoog niveau beschreven van het proces voor beleidsimplementatie op FTD en van de basistechnieken voor probleemoplossing.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
Firewall Management Center (FMC)Firepower Threat Defense (FTD)
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Achtergrondinformatie
Met Cisco Firepower Threat Defense (FTD) worden traditionele stateful firewall-functies van Adaptive Security Appliances (ASA) en Next-Gen firewall-functies (aangedreven door Snort ) nu gecombineerd in één product. Als gevolg van deze wijziging verwerkt Policy Deployment Infrastructure op FTD nu configuratiewijzigingen voor zowel ASA-code (ook wel LINA genoemd) als Snort in één bundel.
Overzicht beleidsimplementatie
Cisco FTD maakt gebruik van Policy Deployments om configuraties te beheren en uit te voeren voor apparaten die zijn geregistreerd bij de Firewall Management Center (FMC) zelf.
Binnen de implementatie zijn er een reeks stappen die in fasen zijn opgedeeld.
De FMC-fasen kunnen in deze lijst worden samengevat.
| Fase 0 | Implementatie-initialisatie |
| Fase 1 | Database Object Collection |
| Fase 2 | Beleid en objectverzameling |
| Fase 3 | NGFW-opdrachtregelconfiguratiegeneratie |
| Fase 4 | Generatie van pakket voor implementatie van apparaat |
| Fase 5 | Het implementatiepakket verzenden en ontvangen |
| Fase 6 | Berichten over het succes van de implementatie, implementatieacties en implementatie in behandeling |
Kennis van de fasen en van de locatie van storingen in het proces kan helpen bij het oplossen van de storingen waarmee een Firepower systeem wordt geconfronteerd.
In sommige situaties kan het een conflict zijn als gevolg van eerdere configuraties of veroorzaakt door een Advanced Flex Configuration dat een trefwoord mist dat fouten kan veroorzaken die het apparaatrapport niet aanpakt.
Voorbeeldoverzicht
Stap 1. Klik op Deployment, dat het apparaat aangeeft dat moet worden geselecteerd.
Stap 2. Wanneer de implementatie voor een apparaat is vastgelegd, begint het FMC alle configuraties te verzamelen die relevant zijn voor het apparaat.
Stap 3. Wanneer de configuraties worden verzameld, maakt de FMC het pakket en stuurt het naar de sensor via zijn communicatiemechanisme genaamd SFTunnel.
Stap 4. De FMC waarschuwt de sensor om het implementatieproces te starten met het meegeleverde beleid terwijl hij luistert naar de individuele reacties.
Stap 5. Het beheerde apparaat pakt het archief uit en begint de afzonderlijke configuraties en pakketten toe te passen.
A. De eerste helft van de implementatie is de Snort configuratie waarbij de Snort configuratie lokaal wordt getest om de geldigheid ervan te garanderen.
Wanneer de nieuwe configuratie geldig is gebleken, wordt deze verplaatst naar de productiemap voor Snort. Als de validatie mislukt, mislukt de beleidsimplementatie in deze stap.
B. De tweede helft van de belasting van het implementatiepakket is voor de LINA-configuratie, waar deze door het ngfwManager-proces rechtstreeks op het LINA-proces wordt toegepast.
Als er een fout optreedt, worden de wijzigingen teruggedraaid en treedt er een fout in de beleidsimplementatie op.
Stap 6. Als zowel Snort - als LINA-pakketten succesvol zijn, moet het beheerde apparaat opnieuw Snort of opnieuw laden om de nieuwe configuratie te laden en alle huidige configuraties op te slaan.
Stap 7. Als alle berichten succesvol zijn, stuurt de sensor een succesbericht en wacht hij tot het wordt bevestigd door het Management Center.
Stap 8. Eenmaal ontvangen, markeert het VCC de taak als een succes en laat het de beleidsbundel afmaken.
Probleemoplossing
Problemen die tijdens de Policy Deployment worden ondervonden, kunnen het gevolg zijn van, maar zijn niet beperkt tot:
- verkeerde configuratie
- Communicatie tussen FMC en FTD
- Database en systeemstatus
- Softwaregebreken en voorbehouden
- Andere unieke situaties
Sommige van deze problemen kunnen eenvoudig worden opgelost, terwijl andere hulp van de Cisco- Technical Assistance Center (TAC)kunnen vereisen.
Het doel van deze sectie is om technieken te bieden om het probleem te isoleren of de onderliggende oorzaak te bepalen.
FMC Graphical User Interface (GUI)
Cisco raadt elke probleemoplossingssessie aan voor implementatiefouten die op het FMC-toestel moeten worden gestart.
In het venster Foutmelding zijn er op alle versies na 6.2.3 aanvullende tools die kunnen helpen bij andere mogelijke storingen.
De implementatietranscripties gebruiken
Stap 1. Haal de Deployments lijst op de FMC Web UI.
Stap 2. Wanneer het tabblad Deployments is geselecteerd, klikt u op Show History.
Stap 3. In het Deployment History kunt u alle eerdere implementaties van uw FMC zien. Selecteer de implementatie waarin u meer gegevens wilt zien.
Stap 4. Zodra een implementatie-element is geselecteerd, geeft de Deployment Details selectie een lijst weer van alle apparaten in de Transaction. Deze vermeldingen zijn onderverdeeld in deze kolommen: Device Number, Device Name, Status,en Transcript.
Stap 5. Selecteer het apparaat in kwestie en klik op de optie transcript om het afzonderlijke transcript voor implementatie te zien, dat u kan informeren over storingen en configuraties die op de beheerde apparaten zijn geplaatst.
Stap 6. Dit transcript kan bepaalde storingsvoorwaarden aanduiden en een zeer belangrijk nummer aangeven voor de volgende stap: Transaction ID.
Stap 7. In een Firepower Deploymentis de Transaction ID wat kan worden gebruikt om elk afzonderlijk onderdeel van een beleidsimplementatie te volgen. Hiermee kunt u op de opdrachtregel van het apparaat een meer diepgaande versie van deze gegevens verkrijgen voor sanering en analyse.
Problemen met FMC-logboeken oplossen
Hoewel het gepast is om Cisco TAC in te schakelen om de logs te analyseren, kan een zoekopdracht door logs helpen bij de initiële probleemisolatie en de oplossing versnellen. Er zijn meerdere logbestanden op FMC die de details van het beleidsimplementatieproces onthullen.
De twee meest gebruikte logs zijn policy_deployment.log en usmsharedsvcs.log.
Alle genoemde bestanden in dit document kunnen worden bekeken met meerdere Linux-opdrachten zoals more, less en vi. Het is echter van groot belang ervoor te zorgen dat er slechts read acties worden uitgevoerd. Alle bestanden hebben root-toegang nodig om ze te kunnen bekijken.
/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log
Dit logboek markeert duidelijk het begin van de beleidsimplementatietaak voor het VCC en de voltooiing van elke fase, wat helpt om de fase te bepalen waarin de implementatie een storing heeft opgelopen, samen met de foutcode.
De transactionID waarde in het JSON-gedeelte van het log kan worden gebruikt om logboekvermeldingen te vinden die verband houden met een bepaalde implementatiepoging.
10-May-2024 18:05:31.249,[INFO],(JsonRESTServerResource.java:111)
com.cisco.nm.vms.api.rest.DeploymentServerResource, ajp-nio-127.0.0.1-9009-exec-3
** REST Request [ DC ]
** ID : e45c6abd-0fff-4341-bdad-ddd5fee10034
** URL: POST https://localhost6/csm/api/deploy/GetTranscript
{
"data": {},
"deviceUUID": "49243dac-0ba7-11ef-af54-a592d78081a7",
"jobID": 34359753974,
"offset": {
"size": 20,
"start": 0
},
"requestID": "e3be908a0ef711ef9d519da21f9032fa",
"version": "7.2.5"
}
/var/log/sf/policy_deployment.log
Hoewel dit logbestand gedurende 6.x-releases heeft bestaan, die beginnen bij 6.4, werd de dekking uitgebreid.
Het beschrijft nu de gedetailleerde stappen die FMC heeft genomen om de implementatiepakketten te bouwen, daarom wordt het het beste gebruikt voor het analyseren van fouten uit fase 1 - 4.
Het begin van elke fase wordt gemarkeerd door een lijn met INFO start.
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: > SF::UMPD::CSMData::getPolicyRollbackInfo start (161.32M)
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: < SF::UMPD::CSMData::getPolicyRollbackInfo end (161.32M, 0.012(sec))
...
Problemen met beheerde apparaten oplossen
Er zijn extra fasen en secties die afhankelijk zijn van het apparaatpakket, de configuratie met hoge beschikbaarheid en het resultaat van eerdere fasen voor elk beheerd apparaat.
Als een implementatieprobleem is geïsoleerd als gevolg van een storing op het beheerde apparaat, kunnen verdere problemen worden opgelost op het apparaat met twee logs op het apparaat: policy_deployment.log en ngfwManager.log.
/ngfw/var/log/ngfwManager.log
Dit logbestand bevat gedetailleerde stappen die Config Communication Manager en Config Dispatcher hebben genomen om te communiceren met FMC, te werken met het implementatiepakket en de validatie en toepassing van Snoort- en LINA-configuraties te orkestreren.
Dit zijn een paar voorbeelden van ngfwManager.log die het begin van de grote fasen vertegenwoordigen:
FTD receives FMC's request for running configuration: May 30 16:37:10 ccm[4293] Thread-10: INFO com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher... May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>... FTD receives FMC's request to download the deployment package: May 30 16:37:18 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236) May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database FTD begins the deployment of policy changes: May 30 16:37:21 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Starting deployment May 30 16:37:21 ccm[4293] Thread-11: INFO com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager FTD begins LINA deployment: May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina FTD begins finalizing the deployment: May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher: Name:Cluster-App-Conf-Finalize-Request
/ngfw/var/log/sf/policy_deployment.log
Dit logboek bevat de details van het beleid dat op Snort. wordt toegepast Hoewel de inhoud van het logboek grotendeels geavanceerd is en analyse door TAC vereist, is het nog steeds mogelijk om het proces te traceren met een paar belangrijke vermeldingen:
Config Dispatcher begins extracting the packaged policies for validation: Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox (Plugin 230 <- Framework 611 <- Transaction 1085) Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO found NGFWPolicy => (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235) ... Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13) Config validation begins: Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB) (Framework 3950<687 <- Transaction 1101 <- main 194) Validation has completed successfully: Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) Config Dispatcher begins moving the validated configuration to the Snort directories in production: Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles (Plugin 230 <- Framework 822 <- Transaction 1662) Snort processes will reload to apply the new configurations: Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9... (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235) Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9 (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235) Snort reload has completed successfully: Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200) After LINA config apply finishes, Snort deployment is finalized: Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB) (Framework 3950<980 <- Transaction 1740 <- main 206)
Voorbeeld
Stap 1. Een implementatie mislukt.
Stap 2. Het verkrijgen van de Deploy Transcript en Transaction ID.
Stap 3. SSH in uw Management Center en gebruik de Linux-hulpprogramma less om het bestand te lezen zoals weergegeven op uw FMC:
Voorbeeld: sudo minder /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log (Het sudo wachtwoord is uw gebruikerswachtwoord voor ssh.)
Stap 4. Wanneer u in less, bent, gebruikt u forward slash en voert u het bericht ID in om te zoeken naar de logs met betrekking tot de implementatie transactionID.
Voorbeeld: /60129547881 (Terwijl in gebruikless, n om naar het volgende resultaat te navigeren.)
Voorbeeld van een bericht uitvoeren
Voorbeeld van een faalbericht
5) Vergelijk de juiste fout met de bijgevoegde tabel met veelvoorkomende foutberichten.
Dat wil zeggen, failed_to_retrieve_running_configuration treedt op tijdens communicatiefouten tussen de twee apparaten.
Veel voorkomende foutmeldingen
Dit zijn veelvoorkomende storingsberichten die aan de voorkant van de Management Center Task kunnen worden gezien, evenals de foutcode die in de backend kan worden gezien.
Deze berichten kunnen worden geanalyseerd en vergeleken met de gemeenschappelijke redenen voor mogelijke resoluties. In het geval dat deze niet worden gezien, of uw situatie niet oplossen, neem dan contact op met TAC voor hulp.
-----------------------------------------------------------
| foutcode |
Foutmeldingen |
reden |
|
|
Implementatiefout - Het apparaat is van domein veranderd. van {SCARDOMAIN} naar {DESTINATIONDOMAIN}. Probeer het later opnieuw. |
Deze fout treedt meestal op wanneer een apparaat is verplaatst of is overgenomen van een tweede domein. Een herimplementatie terwijl er geen domeinoverschrijdende informatie optreedt, wijzigt meestal dit probleem. |
|
|
De implementatie is mislukt vanwege een andere implementatie die aan de gang is voor dit apparaat. Probeer het later opnieuw. |
Dit wordt doorgaans gemeld wanneer de implementatie wordt geactiveerd op een apparaat dat wordt geïmplementeerd. In sommige versies wordt dit voorkomen zonder een foutmelding; deze fase bestaat echter nog steeds voor hulp bij het oplossen van problemen. |
|
|
Implementatie kan niet worden uitgevoerd op een afzonderlijk apparaat dat lid is van een cluster. Probeer het cluster later opnieuw te implementeren. |
Dit bericht is van toepassing op FTD-apparaten met de Firepower eXtensible Operating System (FXOS) Chassis Manager. Als het cluster is gebouwd op FXOS, maar niet op de FMC, wordt dit bericht weergegeven. Maak het cluster op het Management Center-toestel voordat u het probeert te implementeren. |
|
|
Het beleid voor een of meer apparaten is gewijzigd sinds {TIMESTAMP}. Implementatie opnieuw proberen. |
Deze fout wordt weergegeven als een beleid/object wordt gewijzigd voor een apparaat in de implementatietaak nadat de gebruiker de implementatie heeft geactiveerd en voordat CSM-elementen en domeinmomentopnamen zijn gemaakt. Een herschikking lost dit probleem op. Dit kan gebeuren wanneer veel gebruikers dezelfde FMC gebruiken om objecten te bewerken en op te slaan terwijl ze worden geïmplementeerd. |
|
|
Beleid {Beleidsnaam} is gewijzigd sinds {Tijdstempel}. Implementatie opnieuw proberen. |
Deze fout wordt weergegeven als een beleid/object voor het betreffende apparaat is gewijzigd tijdens de implementatietaak, nadat de gebruiker de implementatie heeft geactiveerd en voordat CSM- en domeinmomentopnamen zijn gemaakt. Een herschikking lost dit probleem op. |
|
|
De implementatie is mislukt vanwege het niet verzamelen van beleidsregels en objecten. Als het probleem zich blijft voordoen na een herhaalde poging, neemt u contact op met Cisco TAC. |
Als er een recent importbeleid is opgegeven, wacht dan een uur of zo en probeer een andere implementatie. |
|
|
De implementatie is mislukt vanwege de time-out voor het verzamelen van beleidsregels en objecten. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
De momentopname van het domein heeft standaard een time-out van 5 minuten. Als het systeem onder hoge belasting staat of de hypervisor niet goed werkt, kan dit onnatuurlijke vertragingen in de oproep veroorzaken. Dit kan gebeuren als het beheercentrum of apparaat niet de juiste hoeveelheid geheugenbronnen krijgt. Als dit zonder belasting gebeurt, of niet op een later tijdstip verder gaat, neem dan contact op met TAC. |
|
|
Implementatie mislukt in beleid en verzameling van objecten. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Neem contact op met TAC. Geavanceerde probleemoplossing is vereist. |
|
|
De implementatie is mislukt omdat de configuratiegegevens van het apparaat niet zijn opgehaald. Implementatie opnieuw proberen. |
Dit bericht kan optreden wanneer de connectiviteit tussen een eindsensor en een FMC niet werkt zoals verwacht. Controleer de tunnelstatus tussen de eenheden en controleer de connectiviteit tussen de twee apparaten. |
|
|
De implementatie is mislukt omdat het apparaat een eerdere implementatie of een herstart kan uitvoeren. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Dit bericht wordt weergegeven wanneer FMC een implementatie probeert uit te voeren terwijl een eerdere implementatie op FTD aan de gang is. Meestal gebeurt dit wanneer een eerdere implementatie niet is voltooid op FTD en de FTD opnieuw is opgestart of het ngfwManager-proces op FTD opnieuw is gestart. Een nieuwe poging na 20 minuten om processen in staat te stellen een time-out te maken, moet dit probleem oplossen. Indien na een vertraging of indien de vertraging niet acceptabel is, neem dan contact op met TAC. |
|
|
De implementatie is mislukt vanwege connectiviteitsproblemen met het apparaat of apparaat waarop niet wordt gereageerd. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
FMC geeft bepaalde opdrachten voor LINA-shows uit om de actieve configuratie op te halen voor het genereren van configuraties. Dit kan gebeuren wanneer er connectiviteitsproblemen of problemen zijn met het ngfwManager-proces op de eindsensor. In het geval dat u geen connectiviteitsproblemen ondervindt tussen uw eenheden, neemt u contact op met TAC. |
|
|
Implementatie mislukt door communicatiefout met apparaat. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Meestal treedt een hoge netwerklatentie op tussen de apparaten om een time-out voor het beleid te veroorzaken. Controleer de netwerklatentie tussen apparaten om te controleren of deze overeenkomt met de minima voor de versie die in de gebruikershandleiding wordt vermeld. |
|
|
De implementatie is mislukt omdat de synchronisatie van de clusterconfiguratie wordt uitgevoerd. Implementatie opnieuw proberen. |
Dit is alleen van toepassing op FTD-clusterconfiguraties. Als een implementatie wordt geprobeerd op een FTD-cluster terwijl app-synchronisatie (configuratiesynchronisatie) wordt uitgevoerd, wordt hetzelfde door FTD afgewezen. Dit probleem moet worden opgelost met een herhaling na configuratiesynchronisatie. De huidige clusterstatus kan worden gevolgd met deze opdracht in het beheerde apparaat CLISH: > Clustergegevens weergeven |
| asa_configuration_generation_errors |
De implementatie heeft geen apparaatconfiguratie gegenereerd. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Na beoordeling van de eerder genoemde USMS-logboeken kunt u zien welke configuratie de fout veroorzaakt. Dit zijn meestal bugs waarin de logs kunnen worden doorzocht via de Cisco Bug Tool of contact opnemen met Cisco TAC om verder problemen op te lossen. |
|
|
De implementatie is mislukt omdat de interfaces op het apparaat verouderd zijn. Sla de configuratie op de interfacepagina op en probeer het opnieuw. |
Dit gebeurt op 4100- of 9300-modellen als de interface tijdens of vlak voor een implementatie niet is gekoppeld aan het apparaat. Controleer of de interface volledig is gekoppeld of niet is gekoppeld voordat u de implementatie probeert. |
|
|
De implementatie heeft geen configuratie voor het apparaat gegenereerd. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Deze fout geeft aan dat de configuratie van het apparaat niet is gegenereerd. Neem contact op met TAC. |
|
|
De implementatie is mislukt vanwege de time-out tijdens het genereren van de configuratie. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Dit kan gebeuren als er een latentie bestaat tussen de apparaten buiten de normale bereiken. Neem contact op met TAC als na de latentie is genormaliseerd, dit probleem nog steeds optreedt. |
|
|
De implementatie is mislukt vanwege een storing in de apparaatcommunicatie. Controleer de netwerkconnectiviteit en probeer de implementatie opnieuw. |
Dit bericht is de fallback voor eventuele communicatieproblemen tussen de apparaten. Vanwege het vage karakter wordt het geschreven als de fallback om aan te geven dat er een onbekende connectiviteitsfout is opgetreden. |
|
|
Fout bij beleidsimplementatie. Implementatie opnieuw proberen. |
Een nieuwe poging moet dit probleem oplossen. Dit kan gebeuren wanneer het VCC de implementatie niet kan starten vanwege een tijdelijk slot op de database. |
|
|
Implementatie op apparaat mislukt door time-out. Implementatie opnieuw proberen. |
Dit heeft te maken met FTD-implementatie. Processen op FTD wachten 30 minuten voordat de verzending de implementatie heeft voltooid. Zo niet, dan valt het uit. Als dit het geval is, controleert u de connectiviteit tussen apparaten en als de connectiviteit is zoals verwacht, neemt u contact op met TAC. |
|
|
De implementatie is mislukt vanwege de time-out voor het downloaden van de configuratie naar het apparaat. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Dit heeft te maken met FTD-implementatie. De FTD kan niet alle apparaatconfiguratiebestanden downloaden tijdens de implementatie vanwege connectiviteitsproblemen. Probeer het opnieuw nadat de netwerkverbinding is geverifieerd. Als dit is geverifieerd, neemt u contact op met TAC. |
|
|
De implementatie is mislukt vanwege een configuratiefout. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Eventuele fouten in de configuratie die door FMC voor het apparaat wordt gegenereerd, moeten ertoe leiden dat deze foutpost van toepassing is. Dit moet worden geanalyseerd in de USMS-logboeken om te verifiëren welke problemen worden gezien en proberen ze terug te draaien. Eenmaal gerepareerd, vereist dit meestal TAC-interventie en het maken van fouten als de logs niet kunnen worden gekoppeld aan een bekend defect in de Cisco Bug Search Tool. |
|
|
De implementatie is mislukt vanwege de time-out voor de communicatie met het apparaat. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Deze time-out treedt op als het FMC na ≤ 45 minuten nog niet van een apparaat heeft gehoord. Dit is een communicatiefout. Verifieer de communicatie en neem contact op met TAC indien geverifieerd. |
|
|
Implementatie naar cluster mislukt omdat primaire eenheid is gewijzigd. Implementatie opnieuw proberen. |
Voor een FTD-clustersetup-implementatie wordt deze fout aangegeven als de primaire node switches wanneer de implementatie op het apparaat wordt uitgevoerd (na melding). Probeer het opnieuw zodra de primaire node stabiel is. De huidige status van het clusterlid kan met deze opdracht worden bijgehouden in de CLISH voor het beheerde apparaat: > Clustergegevens weergeven |
|
|
Implementatie naar cluster mislukt vanwege storing in de identificatie van de primaire eenheid. Implementatie opnieuw proberen. |
FMC kan de huidige primaire node niet bepalen tijdens de implementatie. Doorgaans is dit te wijten aan deze mogelijkheden: ofwel connectiviteitsproblemen of huidige primaire problemen worden niet toegevoegd aan het cluster op FMC. Het probleem moet worden opgelost nadat de connectiviteit is hersteld of nadat de huidige primaire verbinding aan het FMC-cluster is toegevoegd en een nieuwe poging is gedaan. De huidige clusterstatus kan worden gevolgd met deze opdracht in het beheerde apparaat CLISH: > Clustergegevens weergeven |
|
|
De implementatie is mislukt omdat de synchronisatie van de clusterconfiguratie wordt uitgevoerd. Implementatie opnieuw proberen. |
Dit kan gebeuren als het apparaat zich in App Sync bevindt. Zodra App Sync is voltooid, kunt u de implementatie opnieuw proberen. |
|
|
Implementatie mislukt vanwege conflict met gelijktijdige eerdere implementatie. Als het probleem zich blijft voordoen na een andere poging, neemt u contact op met Cisco TAC. |
Dit kan gebeuren als een implementatie aan de ene kant gelijktijdig is, maar niet aan de andere kant. Deze worden meestal veroorzaakt door communicatieproblemen tussen de apparaten. Als na de time-out optreedt en u nog steeds niet kunt implementeren, neemt u contact op met TAC. |
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
4.0 |
02-Sep-2026
|
Hercertificering - bijgewerkte opmaak |
3.0 |
13-May-2024
|
hercertificering |
2.0 |
23-Sep-2022
|
Eerste vrijgave |
1.0 |
17-Feb-2020
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)