Обновление коммутатора в среде SD-Access

[AminK]

Здравствуйте, сообщество. У меня есть сеть SD-Access с примерно 50 коммутаторами Catalyst (C9500, C9300, C9200). Когда эти коммутаторы впервые были подключены к SD-Access с помощью DNA, на них была установлена версия IOS-XE 17.03.03. Теперь из-за требований безопасности мне нужно обновить эти коммутаторы. Сначала я обновил DNA Center до золотой версии (v 2.3.7.9 на момент написания — Catalyst Center), а затем приступил к обновлению коммутаторов. Я могу обновить коммутаторы двумя способами 1) Обновить вручную, загрузив файл bin из TFTP и перезагрузив, а затем повторно настроить с помощью Catalyst Center. 2) Обновление с помощью Catalyst Center, а затем настройка коммутатора. Теперь, независимо от того, какой метод я выбираю и какую версию IOS-XE я выбираю (17.12.05 или 17.15.03, в настоящее время gold), я сталкиваюсь с некоторыми странными проблемами. Коммутатор загружается нормально, без ошибок, и isis и LISP запускаются без проблем. Но, например: 1) Коммутатор обновлен, и после загрузки один клиент в коммутаторе не может видеть другого клиента в том же коммутаторе и той же VLAN. Им необходимо общаться друг с другом. Я могу видеть обоих с моего коммутатора на другом этаже. Переход на версию 17.3.3 решил проблему. 2) После обновления коммутатора и его запуска один VRF полностью перестал работать на коммутаторе. Они просто не могли видеть свой шлюз, который работал без проблем. Все остальные VRF работали без проблем. Переход на более раннюю версию решил проблему. Я очистил кэши LISP, такие как eid-table, и попытался обновить их, но безрезультатно. Я поискал в Интернете, но ничего не нашел. Поэтому, если кто-нибудь может подсказать, что мне следует проверить, или какие-либо требования, о которых я не знаю, буду очень признателен. Спасибо.

[Andrii Oliinyk]

При обновлениях я никогда не сталкивался с описанными вами проблемами, будь то через DNAC SWIM или вручную. Основная
причина, которую я могу предположить для случая (2), — это изменение MAC-адреса AcGW на произвольном SVI, в то время как клиенты ARP-cash сохранили запись с предыдущим MAC. AcGW будет отбрасывать пакеты, предназначенные для него, с неправильным MAC-адресом. Почему клиенты не обновили свой ARP-кеш во время перезагрузки коммутатора (подразумевается цикл выключения/включения портов клиентов) — это еще один вопрос в данном случае. Но я сталкивался со случаями, когда iDRAC/iLO серверов сохраняли свой ARP-кеш для GW по умолчанию даже во время замены вышестоящего коммутатора (цикл выключения/включения их портов просто не сработал).

[Andrii Oliinyk]

Есть много пропущенных диагностических результатов, которые необходимо учесть:

1. sho mac ad vlan X / sho ip arp vrf X VLAN X / базовая связь icmp от AcGW на соседнем коммутаторе. На одном и том же коммутаторе конечные точки в одной и той же VLAN должны видеть друг друга в соответствии с ARP, локально передаваемыми на коммутатор.
2. sho vrf X / sho ip arp vrf X . «
   Они (пограничные узлы?) просто не могли видеть свой шлюз, который работал без проблем» — как это возможно? AcGW в затронутом VRF X запустились без VRF или что именно было замечено?

[AminK]

Большое спасибо за ваше время. В первом случае я понизил версию, и это решило проблему. И да, точно, Arp должен по крайней мере затопить в том же коммутаторе. В случае с вторым вариантом, да, шлюз anycast был в состоянии up/up в моем VRF. Но клиенты с той же vlan, что и AcGW, не могли его пинговать. Указание на VRF было неверным, и я приношу за это извинения. Но помимо всего этого, меня беспокоит другое. В чем заключается основная проблема и почему у меня возникают разные проблемы в каждом коммутаторе, ведь они не ограничиваются вышеуказанными проблемами. Должен ли я изменить свой рабочий процесс? Например, сначала обновить Border Control? У вас есть подобный опыт обновления коммутаторов в среде SD-Access?

[AminK]

Спасибо. Я попробую другие версии и обновлю свой пост, если найду что-нибудь новое.