Які найкращі практики переміщення конфігурації ASA на 8.3 та вперед?
Я вручну створив новий конфігураційний файл із такими змінами:
Наступним моїм кроком було б оновлення з 8,2 до 8,3 з урахуванням будь-яких помилок. Замість очищення конфігурації було б простіше повторно робити це за рядком?
Відповіді:
Надайте досить короткий набір конфігурацій, перенастроювання вручну має бути прийнятним варіантом. Ви навіть можете взяти наявну конфігурацію і спробувати її знову реалізувати через ASDM, щоб побачити, що повертає новий графічний інтерфейс.
Якщо ваш конфігурація містить кілька сторінок або має велику кількість об'єктів, можливо, найкраще буде застосувати його до тестового вікна, щоб побачити, що повертається як повідомлення про помилку, перш ніж вводити його у виробництво.
На відміну від міграції PIX до ASA, Cisco ніколи не випускав інструмент перевірки правильності.
Я б точно рекомендував відновити конфігурацію, щоб очистити її. Часто правила вводяться в дію або стають несвіжими або ніколи не використовуються. Це прекрасна можливість почати це з чистого сланця.
На останнє оновлення мені знадобилося близько тижня, щоб переписати правила, але вони були набагато чистішими та маркованими.
Ми нещодавно пройшли це, і я відновив конфігурацію з нуля. У мого конфігурації було лише близько 6 сторінок, так що це не було страшно. Це також дозволило здійснити деяку консолідацію в об'єктні групи та аудит правил, що існували на ASA.
Якщо ваш конфігурація занадто великий, ви можете спробувати налаштувати 8.2 в GNS3, застосувавши конфігурацію, потім оновивши. Ніколи не пробував оновлення ASA у GNS3, але 8,2, 8,3 та 8,4 працювали в GNS3.
Іншим варіантом, якщо у вас є активна пара / режим очікування, буде розрив пари під час технічного обслуговування та оновлення режиму очікування. Після того, як все перевіриться, тоді зробіть його основним і поверніть інший пристрій у пару в режимі очікування після оновлення. Якщо тестування не вдалося, зменшіть режим очікування та поверніть його до старої пари.