Модулът ASA FirePOWER няма маршрут за управление към FMC
Модулът FirePOWER пази свой адрес за управление и свой шлюз, но свързаният маршрут на ASA може да надделее. Разделете двата стека преди регистрацията във FMC.
FMC показва модула като недостъпен, регистрацията стои в състояние на изчакване, а ping отвътре в ASA работи безупречно. При съществуващо внедряване на ASA FirePOWER тази комбинация е нормална. Модулът има свой адрес за управление, свой шлюз по подразбиране и свои решения за маршрутизация, а споделянето на физическа връзка за управление с ASA на някои платформи не ги слива в един мрежов стек. Две устройства отговарят от две различни гледни точки по един и същ кабел.
Следното се отнася за модули, които вече са в експлоатация. Определете модела на шасито, типа на модула и поддържаната версия на софтуера, преди да приложите каквато и да е схема на портовете от ръководство.
Начертайте модула като отделен хост
Започнете схемата с IP адреса за управление на модула, маската и шлюза по подразбиране, VLAN, който действително носи тази връзка, и адреса на FMC, който трябва да бъде достигнат. След това в отделен правоъгълник запишете адресите на интерфейсите на ASA и пълната му таблица за маршрутизация. Ако двата правоъгълника в крайна сметка споделят подмрежа с адреси, притежавани от различни страни, вие сте открили интересната част от проблема.
Ръководството за модула ASA FirePOWER показва как подредбата на портовете се различава между платформите, включително споделено окабеляване за управление, при което ASA и модулът имат отделни адреси в един и същ сегмент. Тази схема на хардуера е входни данни за проекта, а не бележка под линия.
Открийте къде се къса обратният път
Вземете схема с маршрутизация през ядро. Модулът изпраща трафика към FMC към ядро Layer 3, ядрото препраща отдалечената дестинация за управление към вътрешния интерфейс на ASA, а VPN на обекта го пренася към другата страна. След това отдалеченият обект се нуждае от маршрут обратно към подмрежата за управление на модула. Всяка стъпка в тази верига може да е вярна, докато последният маршрут липсва, и точно затова отказът толкова често изглежда като счупен тунел.
Прочетете собствената гледна точка на ASA, преди да променяте нещо:
show interface ip brief
show route
show running-config interfaceТретата команда е важна, защото адрес на интерфейс, който сте забравили, е точно това, което кара обратния път да попадне на грешното устройство.
Проверете какво ASA смята за свързано
Ако ASA има адрес в подмрежата за управление на модула, неговият свързан маршрут притежава този префикс. Статичният маршрут към ядрото не измества собствеността на свързания маршрут, така че пакетът се връща към ASA и спира там. Регистрацията след това се проваля в точка, която няма нищо общо с идентификационните данни.
Не заключавайте, че определена проверка срещу подправяне е изхвърлила пакета, освен ако пред вас няма собствени наблюдения на устройството. Вместо това сравнете входящия интерфейс, избрания маршрут до дестинацията и поддържаната граница за препращане между управление и данни за тази платформа. Тези три факта обикновено разкриват конфликта в топологията, преди някой да започне да нулира ключовете за регистрация.
Изберете корекция, която оставя модула свързан
Премахването на адреса на ASA от този сегмент и физическото изключване на споделен порт не са равностойни действия. На платформи, където модулът върви по същата физическа връзка за управление, изключването на порта премахва единствената връзка на модула — ще превърнете проблем с маршрутизацията в мъртво устройство. Предпочетете промяната, която преразпределя собствеността върху маршрутизацията за управление, и я планирайте в присъствието на собственика на мрежата.
Втора поддържана възможност е административният път на ASA да получи собствен сегмент, така че подмрежата за управление на модула да има един собственик. Това струва един адрес и малко документация и премахва двусмислието за постоянно. Който и път да изберете, след това потвърдете, че модулът все още достига както FMC, така и своите източници на DNS или NTP.
Регистрирайте само след като пътят е съгласуван
След като обратният път е чист, планирайте свързаността за управление и параметрите за регистрация от съответното ръководство за версията на FMC и модула. Дръжте тайните за регистрация извън споделени бележки и тикети и устойте на изкушението да се регистрирате отново като диагностична стъпка: нов ключ по счупен път просто дава същия отказ с по-ново времево клеймо.
Приемайте пътя от собствения стек за управление на модула, а не от ping, който произхожда от ASA, защото източникът на теста е именно това, което е под подозрение. Запишете следващия хоп на модула, избора на VPN на ASA и маршрута за отговор на FMC и поддържайте независим метод за възстановяване и за двете роли на управление. Именно този запис разграничава поправения транспорт от успешната регистрация.
Когато модулът най-накрая се появи във FMC, изпълнете отново същите три команди и запазете изхода до схемата. Следващият човек, който докосне този сегмент за управление, ще се нуждае точно от това сравнение.