المحتويات

المقدمة

معلومات أساسية

المتطلبات الأساسية

المكونات المستخدمة

نظرة عامة على نشر النهج

مثال نظرة عامة

استكشاف الأخطاء وإصلاحها

واجهة المستخدم الرسومية (GUI) لوحدة التحكم FMC

إستخدام محاضر التوزيع

أستكشاف الأخطاء وإصلاحها باستخدام سجلات FMC

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

/var/log/sf/policy_deployment.log

أستكشاف أخطاء الأجهزة المدارة وإصلاحها

/ngfw/var/log/ngfwManager.log

/ngfw/var/log/sf/policy_deployment.log

مثال

رسائل الفشل الشائعة

الاتصال ب TAC للمساعدة

المقدمة

يصف هذا المستند نظرة عامة عالية المستوى على عملية نشر السياسة في FTD بالإضافة إلى تقنيات أستكشاف الأخطاء وإصلاحها الأساسية.

معلومات أساسية

مع Cisco Firepower Threat Defense  (في FTD)، ميزات جدار الحماية التقليدية التي تحدد الحالة التي توفرها Adaptive Security Appliances ASA و Next-Gen ميزات جدار الحماية (يتم تشغيلها بواسطة Snort) مجمعة الآن في منتج واحد.

بسبب هذا التغيير، Policy Deployment Infrastructure على FTD الآن معالجة تغييرات التكوين لكل من رمز ASA (المشار إليه أيضا باسم LINA)، و Snort في حزمة واحدة.

المتطلبات الأساسية

توصي Cisco بمعرفة هذه المنتجات:

- Firepower Management Center (FMC)

- Firepower Threat Defense (FTD)

المكونات المستخدمة

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

نظرة عامة على نشر النهج

يستخدم برنامج FTD من Cisco Policy Deployments لإدارة عمليات التهيئة للأجهزة المسجلة في Firepower Management Center (FMC) نفسها.

وداخل عملية النشر، توجد سلسلة من الخطوات التي يتم تقسيمها إلى "مراحل".

يمكن تلخيص مراحل FMC في هذه القائمة.

المرحلة 0

تهيئة النشر

المرحلة الأولى

مجموعة كائنات قاعدة البيانات

المرحلة الثانية

السياسة ومجموعة الكائنات

المرحلة الثالثة

إنشاء تكوين سطر الأوامر NGFW

المرحلة 4

إنشاء حزمة نشر الأجهزة

المرحلة 5

إرسال حزمة النشر واستقبالها

المرحلة 6

النشر وإجراءات النشر ورسائل نجاح النشر المعلقة

ويمكن أن تساعد معرفة المراحل ومواقع حالات الفشل في العملية على أستكشاف أخطاء هذه العملية وإصلاحها Firepower وجوه النظام.

في بعض الحالات، يكون التعارض ناجما عن تكوينات سابقة أو ناجما عن Advanced Flex Configuration الذي يفتقر إلى كلمة أساسية قد تتسبب في حدوث حالات فشل لا يعالجها تقرير الجهاز.

مثال نظرة عامة

الخطوة 1. انقر Deployment، والذي يحدد الجهاز المطلوب تحديده.

الخطوة 2. عند الالتزام بعملية النشر للجهاز، تبدأ FMC في تجميع جميع التكوينات المتعلقة بالجهاز.

الخطوة 3. عندما يتم تجميع التكوينات، تقوم وحدة التحكم في إدارة الهيكل (FMC) بإنشاء الحزمة وإرسالها إلى المستشعر عبر آلية الاتصال الخاصة به والتي يطلق عليها SFTunnel.

الخطوة 4. تقوم وحدة التحكم في إدارة اللوحة الأساسية (FMC) بإعلام المستشعر ببدء عملية النشر باستخدام السياسة المتوفرة أثناء استماعه للاستجابات الفردية.

الخطوة 5. يفك الجهاز المدار الأرشفة ويبدأ في تطبيق التكوينات والحزم الفردية.

ألف - النصف الأول من عملية النشر هو Snort التكوين حيث Snort يتم إختبار التكوين محليا لضمان صحته.

عند إثبات صلاحيته، يتم نقل التكوين الجديد إلى دليل الإنتاج ل Snort. في حالة فشل التحقق من الصحة، يفشل نشر النهج في هذه الخطوة.

باء - النصف الثاني من حمل حزمة النشر يتعلق بتكوين نظام LINA حيث يتم تطبيقه مباشرة على عملية LINA بواسطة عملية NGFWmanager.

في حالة حدوث فشل، يتم التراجع عن التغييرات ويحدث فشل في نشر النهج.

الخطوة 6. إذا كان كلاهما Snort وحزم LINA ناجحة إشارات الجهاز المدار Snort لإعادة التشغيل أو إعادة التحميل لتحميل التكوين الجديد وحفظ جميع التكوينات الحالية.

الخطوة 7. في حالة نجاح كافة الرسائل، يرسل المستشعر رسالة نجاح وينتظر حتى يتم الاعتراف بها من قبل مركز الإدارة.

الخطوة 8. وبمجرد تلقيها، تحدد FMC المهمة على أنها ناجحة وتسمح لمجموعة السياسات بالإنهاء.

استكشاف الأخطاء وإصلاحها

المشاكل التي تمت مواجهتها أثناء Policy Deployment قد يكون راجعا إلى، ولكن ليس مقصورا على:

1. تكوين خاطئ

2. الاتصال بين FMC و FTD

3. سلامة النظام وقواعد البيانات

4. عيوب البرامج والتحذيرات

5. حالات فريدة أخرى

قد يتم إصلاح بعض هذه المشاكل بسهولة، في حين قد تتطلب أخرى مساعدة من Cisco Technical Assistance Center (TAC).

الهدف من هذا قسم أن يزود تقنية أن يعزل الإصدار أو يعين الجذر سبب.

واجهة المستخدم الرسومية (GUI) لوحدة التحكم FMC

توصي Cisco ببدء تشغيل كل جلسة أستكشاف أخطاء النشر وإصلاحها على جهاز FMC.

في إطار "إعلام الفشل"، في جميع الإصدارات بعد 6.2.3، هناك أدوات إضافية يمكن أن تساعد في حالات الفشل الأخرى المحتملة.

إستخدام محاضر التوزيع

الخطوة 1. أسحب Deployments القائمة على واجهة مستخدم ويب FMC.

الخطوة 2. في حين Deployments علامة التبويب محددة، انقر فوق Show History.

الخطوة 3. داخل Deployment History يمكنك مشاهدة جميع عمليات النشر السابقة من وحدة التحكم في إدارة اللوحة الأساسية (FMC). حدد النشر الذي ترغب في رؤية مزيد من البيانات فيه.

الخطوة 4. بمجرد تحديد عنصر نشر، فإن Deployment Details يعرض التحديد قائمة بكل الأجهزة الموجودة داخل Transaction. يتم تقسيم هذه الإدخالات إلى هذه الأعمدة: Device Number, Device Name, Status,و Transcript.

الخطوة 5. حدد الجهاز المعني وانقر فوق خيار النسخ للاطلاع على نسخة النشر الفردية التي يمكن أن تطلعك على حالات الفشل بالإضافة إلى عمليات التهيئة التي يتم وضعها على الأجهزة التي تتم إدارتها.

الخطوة 6. يمكن أن يحدد هذا النص حالات فشل معينة وكذلك يشير إلى رقم مهم جدا للخطوة التالية: Transaction ID.

الخطوة 7. في Firepower Deployment,يعرض الأمر Transaction ID هو ما يمكن إستخدامه لتعقب كل قسم فردي من نشر النهج. مع هذا، على سطر الأوامر الخاص بالجهاز، يمكنك الحصول على إصدار أكثر تعمقا من هذه البيانات للإصلاح والتحليل.

تلميح: في حالة عدم قدرتك على تحديد موقع معرف الحركة أو إذا كنت تستخدم إصدارا قبل طباعة هذا الملف، يظل هذا السجل مستخدما لتحديد موقع رسائل الفشل الفردية.

أستكشاف الأخطاء وإصلاحها باستخدام سجلات FMC

على الرغم من أنه من المناسب إشراك Cisco TAC لتحليل السجلات، فقد يساعد البحث عبر السجلات في عزل المشكلة الأولية وتسريع الحل. هناك العديد من ملفات السجل على FMC التي تكشف تفاصيل حول عملية نشر النهج.

والسجلا المشار إليهما عادة هما policy_deployment.log و usmsharedsvcs.log.

يمكن عرض جميع الملفات المذكورة في هذا المستند باستخدام أوامر Linux المتعددة مثل more، less و vi. ولكن من المهم جدا أن نضمن أن read يتم تنفيذ الإجراءات إليه. تتطلب كافة الملفات الوصول الجذر لتتمكن من عرضها.

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

يحدد هذا السجل بوضوح بداية مهمة نشر السياسة على FMC وإكمال كل مرحلة، مما يساعد على تحديد المرحلة التي تعرض فيها النشر للفشل، بالإضافة إلى رمز الفشل.

يعرض الأمر transactionID يمكن إستخدام القيمة المضمنة في جزء JSON من السجل للعثور على إدخالات السجل المتعلقة بإحدى محاولات النشر المحددة.

22-Nov-2019 01:28:52.844,[INFO],(DefenseCenterServiceImpl.java:1372)

com.cisco.nm.vms.api.dc.DefenseCenterServiceImpl, ajp-nio-127.0.0.1-9009-exec-4

** REST Request [ CSM ]

** ID : e1c84364-0966-42eb-9356-d2914be2b4a3

** URL: Broadcast message.send.deployment

{

"body" : {

"property" : "deployment:deployment_initiated_for_the_device",

"argumentList" : [ {

"key" : "PHASE",

"value" : "Phase-0"

} ]

},

"user" : "68d03c42-d9bd-11dc-89f2-b7961d42c462",

"type" : "deployment",

"status" : "running",

"progress" : 5,

"silent" : true,

"restart" : true,

"transactionId" : 12884916552,

"devices" : [ "93a2089a-fa82-11e9-8219-e1abeec81dc9" ]

}

/var/log/sf/policy_deployment.log

وعلى الرغم من وجود ملف السجل هذا خلال إصدارات 6.x التي تبدأ من 6.4، فقد تم توسيع نطاق تغطيته.

وهو يصف الآن الخطوات التفصيلية التي اتخذت بشأن وحدة إدارة الاتصالات الفيدرالية (FMC) لإنشاء حزم النشر، وبالتالي فهو يستخدم على أفضل وجه لتحليل حالات الفشل من المرحلة 1-4.

يتم تمييز بداية كل مرحلة بسطر معINFO start.. ":

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO starting populateGlobalSnapshot - sqlite = /var/cisco/umpd/8589938337/DC_policy_deployment.db, transaction = 8589938337, time = 1563470402, running as (memory = 56.35 MB) (Framework 3950<196 <- CSMTasks 223<10 <- SF::ActionQueue 2457)

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO deployment threading: disabled (Framework 198 <- CSMTasks 223<10 <- SF::ActionQueue 2457)

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO -> calling SF::UMPD::Plugins::Correlation::Manager::getPluginDependencies (Plugin 298<90 <- Framework 3579<3566<216 <- CSMTasks 223)

...

أستكشاف أخطاء الأجهزة المدارة وإصلاحها

هناك مراحل إضافية وأقسام تعتمد على حزمة الأجهزة والتكوين عالي التوافر ونتائج المراحل السابقة لكل جهاز تتم إدارته.

إذا تم عزل مشكلة نشر إلى فشل على الجهاز المدار، يمكن تنفيذ المزيد من أستكشاف الأخطاء وإصلاحها على الجهاز باستخدام سجلين على الجهاز: policy_deployment.log وngfwManager.log.

/ngfw/var/log/ngfwManager.log

يوفر ملف السجل هذا خطوات تفصيلية تم إتخاذها Config Communication Manager و Config Dispatcher للتواصل مع وحدة التحكم في إدارة الهيكل (FMC)، والعمل مع حزمة النشر، وتنسيق عملية التحقق من مواصفات Snort و LINA وتطبيقها.

هذه أمثلة قليلة على ngfwManager.log التي تمثل بداية المراحل الرئيسية:

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

يحتوي هذا السجل على تفاصيل النهج المطبق عليه Snort. على الرغم من أن محتوى السجل متقدم في معظمه ويتطلب تحليلا بواسطة TAC، إلا أنه لا يزال من الممكن تتبع العملية بعدد قليل من الإدخالات الأساسية:

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)

مثال

الخطوة 1. فشل النشر

الخطوة 2. احصل على Deploy Transcript و Transaction ID.

الخطوة 3. بروتوكول SSH في Management Center واستخدم أداة لينوكس less لقراءة الملف كما هو موضح في FMC:

مثال: sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log" (كلمة المرور sudo هي كلمة مرور المستخدمين ل SSH)

الخطوة 4. عندما تكون في less، أستخدم شرطة مائلة للأمام وأدخل في معرف الرسالة للبحث عن السجلات المرتبطة ب TransactionID للنشر.

مثال:/60129547881 بوصة (أثناء less، أستخدم n للتنقل إلى النتيجة التالية)

مثال على تشغيل الرسالة:

مثال على رسالة الفشل:

5) قارن الفشل الصحيح بالجدول المرفق لرسائل الأعطال الشائعة.

يحدث i_failed_to_recovery_running_configuration أثناء حالات فشل الاتصال بين الجهازين.

رسائل الفشل الشائعة

هذه هي رسائل الفشل الشائعة التي يمكن رؤيتها في الطرف الأمامي من Management Center Task فضلا عن رمز الخطأ الذي يمكن رؤيته في الخلفية.

ويمكن تحليل هذه الرسائل ومقارنتها بالأسباب المشتركة لاتخاذ قرارات محتملة.

في حال عدم رؤية هذه الأمور، أو عدم حلها، يرجى الاتصال ب TAC للحصول على المساعدة.

—

رمز الخطأ

رسائل الخطأ

سبب

device_has_changed_domain

فشل النشر - قام الجهاز بتغيير المجال من {srcdomain} إلى {destinationDomain}. حاول مرة أخرى لاحقا.

يحدث هذا الخطأ عادة عند نقل جهاز أو التقاطه من مجال ثان. يؤدي إعادة النشر في حين لا تحدث معلومات عبر المجال عادة إلى تعديل هذه المشكلة.

device_currently_under_deployment

فشل النشر بسبب عملية نشر أخرى قيد التقدم لهذا الجهاز. حاول مرة أخرى لاحقا.

ويتم الإبلاغ عن ذلك عادة عند تشغيل النشر على جهاز قيد النشر. في بعض الإصدارات، يتم منع هذا الإجراء دون إخطار فشل، ومع ذلك، لا تزال هذه المرحلة موجودة للمساعدة في أستكشاف الأخطاء وإصلاحها.

device_not_member_of_container

لا يمكن إجراء النشر على جهاز فردي عضو في نظام مجموعة. حاول نشر نظام المجموعة مرة أخرى لاحقا.

تنطبق هذه الرسالة على FTD على الأجهزة المزودة ببرنامج FirePOWER Xsible Operation System (FXOS) Chassis Manager. إذا كان نظام المجموعة مبنيا على FXOS، وليس على FMC، يتم عرض هذه الرسالة. الرجاء إنشاء نظام المجموعة على جهاز "مركز الإدارة" قبل محاولة النشر.

policy_altered_after_timestamp_for_other_devices_in_job_error

تم تغيير النهج الخاصة بجهاز واحد أو أكثر منذ {timestamp}. إعادة محاولة النشر.

يظهر هذا الخطأ في حالة تغيير أي نهج/كائن لأي جهاز في مهمة النشر بعد قيام المستخدم بتشغيل النشر وقبل إنشاء عناصر CSM ولقطات المجال.  تقوم إعادة النشر بإصلاح هذه المشكلة.

يمكن أن يحدث ذلك عندما يستخدم العديد من المستخدمين نفس FMC لتحرير وحفظ الكائنات أثناء نشرها.

policy_altered_after_timestamp_error

تم تغيير النهج {Policy Name} منذ {timestamp}. إعادة محاولة النشر.

يظهر هذا الخطأ في حالة تغيير أي نهج/كائن للجهاز المعني في مهمة النشر، بعد قيام المستخدم بتشغيل النشر وقبل إنشاء لقطات CSM والمجال.  تقوم إعادة النشر بإصلاح هذه المشكلة.

csm_snapshot_error

فشل النشر بسبب فشل تجميع النهج والكائنات. إذا إستمرت المشكلة بعد محاولة متكررة، اتصل ب Cisco TAC.

في حالة توفير "إستيراد نهج" حديث، انتظر لمدة ساعة أو ما إلى ذلك وحاول عملية نشر أخرى.

إذا لم يسمح ذلك بالمتابعة إلى، اتصل ب TAC لأنه رسالة متعلقة بقاعدة البيانات.

domain_snapshot_timeout

فشل النشر بسبب انتهاء المهلة اللازمة لجمع السياسات والكائنات. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

تحتوي لقطة المجال على مهلة 5 دقائق بشكل افتراضي. إذا كان النظام تحت حمل مرتفع، أو أعطال برنامج hypervisor، فقد يؤدي ذلك إلى حدوث تأخيرات غير طبيعية في المكالمة.

ويمكن أن يحدث ذلك إذا لم يتم توفير "مركز الإدارة" أو "الجهاز" للمقدار المناسب من موارد الذاكرة كذلك.

إذا حدث ذلك دون تحميل، أو لم يتم المتابعة في وقت لاحق، فاتصل ب TAC.

domain_snapshot_errors

فشل النشر في النهج ومجموعة الكائنات. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

الاتصال من خلال TAC. مطلوب أستكشاف الأخطاء وإصلاحها بشكل متقدم.

failed_to_retrieve_running_configuration

فشل النشر بسبب فشل إسترداد معلومات تكوين التشغيل من الجهاز. إعادة محاولة النشر.

يمكن أن تحدث هذه الرسالة عندما لا يعمل الاتصال بين مستشعر نهاية و FMC كما هو متوقع. تحقق من صحة النفق بين الوحدات ومراقبة الاتصال بين الجهازين.

إذا عمل النفق كما هو متوقع ويمكن أن تتصل الأجهزة، اتصل ب TAC.

device_is_busy

فشل النشر نظرا لأن الجهاز قد يكون يقوم بتشغيل عملية نشر سابقة أو إعادة تشغيل. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

يتم عرض هذه الرسالة، عند محاولة FMC النشر، بينما يكون النشر السابق قيد التقدم على FTD. يحدث بشكل نموذجي عند عدم الانتهاء من النشر السابق على FTD أو عند إعادة تشغيل عملية FTD أو عند إعادة تشغيل عملية NGFWmanager على FTD. يجب أن تحل هذه المشكلة إعادة المحاولة بعد 20 دقيقة للسماح للعمليات بانتهاء المهلة رسميا.

إذا كان بعد التأخير أو إذا كان التأخير غير مقبول، اتصل ب TAC.

no_response_for_show_cmd

فشل النشر بسبب مشاكل في الاتصال مع الجهاز أو الجهاز الذي لا يستجيب. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

تصدر FMC أوامر LINA "show" معينة لجلب التكوين الجاري تشغيله لإنشاء التكوين.

يمكن أن يحدث ذلك عند وجود مشاكل في الاتصال أو مشاكل في عملية NGFWmanager في المستشعر الطرفي.

في حالة عدم مواجهة مشاكل في الاتصال بين الوحدات الخاصة بك، اتصل ب TAC.

network_latency_or_device_not_reachable

فشل النشر بسبب فشل الاتصالات مع الجهاز. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

يحدث عادة مع زمن انتقال الشبكة المرتفع بين الأجهزة مما يؤدي إلى مهلة النهج. تحقق من زمن انتقال الشبكة بين الأجهزة للتحقق من مطابقتها للحد الأدنى للإصدار المذكور في دليل المستخدم.

slave_app_sync

فشل النشر نظرا لأن مزامنة تكوين نظام المجموعة قيد التقدم.  إعادة محاولة النشر.

لا ينطبق هذا إلا على مجموعات FTD. إذا تمت محاولة النشر على مجموعة FTD أثناء تقدم مزامنة التطبيق (مزامنة التكوين)، يتم رفض الأمر نفسه بواسطة FTD. يجب أن تحل هذه المشكلة إعادة المحاولة بعد مزامنة التكوين.

يمكن تعقب حالة نظام المجموعة الحالية باستخدام هذا الأمر في CLISH الخاص بالجهاز المدار:

> إظهار معلومات نظام المجموعة

asa_configuration_generation_errors

فشل النشر في إنشاء تكوين الجهاز. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

بعد مراجعة سجلات USMS المذكورة سابقا، قد تتمكن من معرفة التكوين الذي يسبب الخطأ. عادة ما تكون هذه أخطاء يمكن إستعراض السجلات فيها من خلال أداة الأخطاء من Cisco أو اتصل ب Cisco TAC لاستكشاف الأخطاء وإصلاحها بعد ذلك.

interface_out_of_date

فشل النشر لأن الواجهات على الجهاز قديمة. قم بحفظ التكوين في صفحة الواجهات ثم أعد المحاولة.

يحدث هذا على الطرز 4100 أو 9300 إذا كانت الواجهة غير مقترنة بالجهاز أثناء النشر أو قبله مباشرة.

تحقق من أن الواجهة مقترنة بالكامل أو غير مقترنة قبل محاولة النشر.

device_package_error

فشل النشر في إنشاء تكوين للجهاز. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

يشير هذا الخطأ إلى فشل إنشاء تكوين الجهاز للجهاز. الاتصال من خلال TAC.

device_package_timeout

فشل النشر بسبب انتهاء المهلة أثناء إنشاء التكوين. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

ويمكن أن يحدث ذلك إذا كان زمن الوصول موجودا بين الأجهزة الموجودة خارج النطاقات العادية. اتصل ب TAC إن بعد وضع زمن الوصول في الوضع الطبيعي، هذا إصدار بعد يقع.

device_communication_errors

فشل النشر بسبب فشل الاتصال بالجهاز. تحقق من اتصال الشبكة ثم أعد محاولة النشر.

هذه الرسالة هي السبب الاحتياطي لأي مشكلات اتصال بين الأجهزة. نظرا لطبيعته الغامضة، فإنه يكتب على أنه إشارة إحتياطي إلى حدوث خطأ اتصال غير معروف.

unable_to_initiate_deployment_dc

فشل نشر النهج. إعادة محاولة النشر.

هناك محاولة أخرى لحل هذه المشكلة.

يمكن أن يحدث ذلك عندما يتعذر على FMC بدء النشر بسبب تأمين مؤقت على قاعدة البيانات.

device_failure_timeout

فشل النشر على الجهاز بسبب انتهاء المهلة. إعادة محاولة النشر.

يتعلق ذلك بنشر "برنامج الإرسال فائق السرعة (FTD)". تنتظر العمليات في FTD 30 دقيقة حتى يكتمل النشر. إن لم يكن الأمر كذلك، فالوقت أوان.

إذا حدث هذا، فتحقق من الاتصال بين الأجهزة وإذا كان الاتصال كما هو متوقع، اتصل ب TAC.

device_failure_download_timeout

فشل النشر بسبب انتهاء مهلة تنزيل التكوين إلى الجهاز. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

يتعلق ذلك بنشر "برنامج الإرسال فائق السرعة (FTD)". يتعذر على FTD تنزيل كافة ملفات تكوين الجهاز أثناء النشر بسبب مشاكل الاتصال.

الرجاء إعادة المحاولة بعد التحقق من اتصال الشبكة.

إذا تم التحقق من هذا، اتصل ب TAC.

device_failure_configuration

فشل النشر بسبب خطأ في التكوين. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

يجب أن يؤدي أي أخطاء في التكوين الذي تم إنشاؤه بواسطة FMC للجهاز إلى تطبيق مادة نشر الخطأ هذه.

ويلزم تحليل هذا الأمر في سجلات USMS للتحقق من المشاكل التي يتم رؤيتها ومحاولة إسترجاعها.

وبمجرد إصلاحه، يتطلب هذا عادة تدخل TAC وإنشاء الأخطاء إذا تعذر مطابقة السجلات مع عيب معروف في أداة البحث عن الأخطاء من Cisco.

deployment_timeout_no_response_from_device

فشل النشر بسبب مهلة الاتصال مع الجهاز. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

تحدث هذه المهلة إذا لم يتم سماع FMC مرة أخرى من جهاز بعد 45 دقيقة أو أكثر.

هذا خطأ في الاتصال.

تحقق من الاتصال، وإذا تم التحقق، اتصل ب TAC.

device_failure_change_master

فشل النشر إلى نظام المجموعة نظرا لتغير الوحدة الأساسية. إعادة محاولة النشر.

في حالة نشر إعداد مجموعة FTD، يتم الإشارة إلى هذا الخطأ في حالة محولات العقدة الأساسية عندما يكون النشر قيد التقدم على الجهاز (الإعلام اللاحق).

أعد المحاولة بمجرد إستقرار العقدة الأساسية.

يمكن تعقب حالة عضو نظام المجموعة الحالي باستخدام هذا الأمر في CLISH للجهاز المدار:

> إظهار معلومات نظام المجموعة

device_failure_unknown_master

فشل النشر إلى نظام المجموعة بسبب فشل تعريف الوحدة الأساسية. إعادة محاولة النشر.

تعذر على FMC تحديد العقدة الأساسية الحالية أثناء النشر.

ويمكن أن يعزى ذلك عادة إلى إحتمالين: إما مشاكل الاتصال أو مشاكل أساسية حالية لا تضاف إلى المجموعة في FMC.

يجب حلها بعد إعادة تأسيس الاتصال أو بعد إضافة الأساسي الحالي إلى مجموعة FMC وإجراء إعادة المحاولة.

يمكن تعقب حالة نظام المجموعة الحالية باستخدام هذا الأمر في CLISH الخاص بالجهاز المدار:

> إظهار معلومات نظام المجموعة

cd_deploy_app_sync

فشل النشر نظرا لأن مزامنة تكوين نظام المجموعة قيد التقدم.  إعادة محاولة النشر.

يمكن أن يحدث ذلك إذا كان الجهاز في "مزامنة التطبيقات"، فبمجرد اكتمال "مزامنة التطبيقات"، الرجاء إعادة محاولة النشر مرة أخرى.

cd_existing_deployment

فشل النشر بسبب التعارض مع النشر السابق المتزامن. إذا إستمرت المشكلة بعد محاولة أخرى، اتصل ب cisco TAC.

يمكن أن يحدث ذلك إذا كان النشر متوافقا على جانب واحد، وليس على الجانب الآخر.

عادة ما تكون هذه المشاكل ناتجة عن مشكلات في الاتصال بين الأجهزة.

اتصل ب TAC إذا كنت لا تزال غير قادر على النشر بعد حدوث المهلة.

الاتصال ب TAC للمساعدة

في حالة عدم السماح بالمعلومات السابقة بمتابعة نشر النهج، أو إذا بدا أن المشكلة غير مرتبطة بسلوك موثق موجود مسبقا، يرجى إستخدام الخطوات المقدمة في الارتباط التالي لإنشاء ملف أستكشاف الأخطاء وإصلاحها والتواصل مع TAC لتحليل وإنشاء الخطأ.

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html