Здравствуйте, У меня возникла проблема при развертывании Nexus Dashboard 3.2.2 OVA: когда доходит до этапа загрузки «Пожалуйста, подождите, пока система загрузится», она продолжает перезапускаться с 0% каждый раз, когда достигает 29%. Я установил его, следуя этому руководству: https://www.cisco.com/c/en/us/td/docs/dcn/nd/3x/deployment/cisco-nexus-dashboard-deployment-guide-301/nd-deploy-esx-30x.html#task_zld_z5z_2qb Кто-нибудь сталкивался с этой проблемой? BR Диого

Я настраиваю лабораторную установку с одним узлом. Во время установки я указал IP-адрес управления (192.168..0.x/24) и IP-адрес подсети данных (10.10.10.10/24). Я указал постоянные IP-адреса 10.10.10.11-13, и NDFC перешел на страницу «cluster bring up», где выполняет несколько проверок, но терпит неудачу при «Execute cluster validation tests». В чем причина? Загрузка кластера Запуск кластера завершился сбоем на этапе установки: «Выполнить тесты проверки кластера», пожалуйста, проверьте и повторите попытку

Мне интересно, при использовании ND 4.1.1 и включении телеметрии по-прежнему необходимо настраивать инфраструктуру EPL (локатор конечных точек) или достаточно просто настроить связь в OOB с использованием сети управления кластера ND и интерфейсов mgmt листьев и спинов, чтобы собрать всю информацию, включая конечные точки. Спасибо Марио

Что касается режима приложения Nexus с виртуальной панелью управления, просьба сообщить минимальные требования к аппаратной платформе для размещения ND-VIRTUAL в режиме приложения. В настоящее время у моего клиента имеется только 8 процессоров, тогда как в техническом описании указано, что минимальное количество процессоров должно составлять 16. Клиент хотел бы узнать, может ли ND-VIRTUAL работать с 8 процессорами или минимальное количество процессоров 16 является обязательным. Есть ли какой-либо обходной путь?

Привет, ребята, я тестирую многосайтовую конфигурацию NDFC на симуляторе EVE_ng. Развернул NDFC как виртуальную машину и топологию листьевых и магистральных узлов в EVE-ng. Для внешней связи виртуальной машины я создал сетевое облако и подключил все интерфейсы управления узлов к облаку, чтобы NDFC мог обнаруживать все узлы через сетевой адрес управления в структуре MSD, которую я использую в DCI. Метод развертывания многосайтового оверлея IFC: Direct_to_BGWS Флаг автоматического развертывания многосайтового подслоя IFC — включен Другой сайт 1 сайт 2 и фабрика Core RTR добавлены в качестве дочерней фабрики для многосайтового VRF_lite_deployment — Back2Back2External Проблема, с которой я сейчас сталкиваюсь, заключается в том, что когда я добавляю дочернюю фабрику в MSD, а затем выполняю пересчет и развертывание, он также учитывает интерфейс mgmt для ссылок IFC, удаляет из него ip mgmt и добавляет в него конфигурацию IFC multisite dci tracking. Как я могу отфильтровать интерфейс mgmt из этого или как исключить интерфейс mgmt для ссылки IFC, могу ли я настроить это в NDFC? Я прикрепляю топологию, чтобы было понятно, а также конфигурацию, с которой я столкнулся как с проблемой ![MalavSharma_0-1761370615254.png] interface mgmt0 no ip address 150.1.7.95/24 no vrf member management route-map rmap-redist-direct permit 10 match tag 54321 evpn multisite border-gateway 65502 delay-restore time 300 router bgp 65502 address-family ipv4 unicast redistribute direct route-map rmap-redist-direct maximum-paths 64 maximum-paths ibgp 64 exit address-family ipv6 unicast maximum-paths 64 maximum-paths ibgp 64 exit neighbor 10.10.1.10 удаленный-as 65535 log-neighbor-changes update-source Ethernet1/3 адрес-семейство ipv4 unicast next-hop-self send-community оба exit exit сосед 10.10.1.5 remote-as 65501 log-neighbor-changes update-source mgmt0 address-family ipv4 unicast next-hop-self send-community both exit exit neighbor 10.11.0.3 remote-as 65501 update-source loopback0 ebgp-multihop 5 peer-type fabric-external address-family l2vpn evpn send-community both rewrite-evpn-rt-asn configure terminal interface nve1 multisite border-gateway interface loopback100 interface loopback100 ip address 10.10.0.1/32 tag 54321 ip router ospf UNDERLAY_ospf area 0.0.0.0 ip pim sparse-mode no shutdown** interface mgmt0 no switchport ip address 10.10.1.6/30 tag 54321 evpn multisite dci-tracking mtu 9216 description connected-to-DC1-SPINE-1-mgmt0 no shutdown** interface ethernet1/3 no switchport ip address 10.10.1.9/30 tag 54321 evpn multisite dci-tracking mtu 9216 description connected-to-CORE_RTR-Ethernet1/2 no shutdown interface ethernet1/1 no switchport ip address 10.2.0.2/30 evpn multisite fabric-tracking description connected-to-DC2-LEAF-16-Ethernet1/1 mtu 9216 ip router ospf UNDERLAY_ospf area 0.0.0.0 ip ospf network point-to-point ip pim sparse-mode no shutdown configure terminal Выше приведена конфигурация DC2-SPINE-1, в которой видно, что она удаляет конфигурацию из интерфейса mgmt, а затем задает конфигурацию multisite под интерфейсом mgmt. Буду очень благодарен за любую помощь или совет. [image: be4588c24988afcf222a199bba72a27cf42bbfa5.png]

Здравствуйте, команда! Я установил ND 4.1.1g с помощью ova на esxi 8.x. Я следую инструкции по развертыванию с предварительными требованиями, в основном: - 16Vcpu -64 ГБ оперативной памяти -SSD-диск (50 + 500 ГБ) -Добавление vlan 4095 на интерфейсе данных в параметрах vswitch -Деактивировать синхронизацию времени в vmware tools Итак, подведем итоги. Установка проходит без ошибок (1 узел в Vapp). При выключении виртуальной машины (acs shutdown) или перезагрузке виртуальная машина не переходит в состояние «хорошее». Возникает много ошибок (я жду более 1 часа после загрузки) rescue-user@ND-NODE1:/logs$ acs health ====== Статус ====== [major] Проверка работоспособности «deploymentsHealth» завершилась с ошибкой. Статус: «Развертывание dcnm-dhcpd-589497b5b5 в пространстве имен cisco-ndfc не находится в желаемом состоянии, ошибка: в развертывании не запущены все ожидаемые подсистемы, запущенные подсистемы: 0, желаемые подсистемы: 1» «Развертывание dcnm-lan-fabric-657d84b9bb в пространстве имен cisco-ndfc не находится в желаемом состоянии, ошибка: развертывание не имеет всех ожидаемых подсистем, работающих подсистем: 0, желаемых подсистем: 1» «Развертывание dcnm-pmn-7bd4f55584 в пространстве имен cisco-ndfc не находится в желаемом состоянии, ошибка: развертывание не имеет всех ожидаемых подразделений, работающих подразделений: 0, желаемых подразделений: 1» «Развертывание nodectrlr-7948dbcf54 в пространстве имен nodemgr не находится в желаемом состоянии, ошибка: в развертывании не запущены все ожидаемые подсистемы, запущенные подсистемы: 0, желаемые подсистемы: 1» «Развертывание securitymgr-576cf68f9d в пространстве имен securitymgr не находится в желаемом состоянии, ошибка: в развертывании не запущены все ожидаемые подсистемы, запущенные подсистемы: 0, желаемые подсистемы: 1» «Развертывание auditmgr-5947b88b8c в пространстве имен auditmgr не находится в желаемом состоянии, ошибка: в развертывании не запущены все ожидаемые подсистемы, запущенные подсистемы: 0, желаемые подсистемы: 1» [major] Проверка работоспособности «statefulSetsHealth» завершилась с ошибкой. Статус: «StatefulSet csi-controllers в пространстве имен csi-system не находится в желаемом состоянии, ошибка: StatefulSet не имеет всех ожидаемых под в состоянии готовности, готовые под: 0, желаемые под: 1» rescue-user@ND-NODE1:/logs$ kubectl get pods -A | grep -v «Running» Предупреждение: используйте токены из API TokenRequest или вручную созданные токены на основе секретов вместо автоматически сгенерированных токенов на основе секретов. NAMESPACE NAME READY STATUS RESTARTS AGE auditmgr auditmgr-5947b88b8c-g24kp 0/1 RunContainerError 2 (140 минут назад) 2d22h cdb cockroachdb-init-bgjhp 0/1 Completed 0 2d22h cisco-ndfc dcnm-dhcpd-589497b5b5-lwpg2 0/1 CrashLoopBackOff 38 (3 м 11 с назад) 2 д 22 ч cisco-ndfc dcnm-lan-fabric-657d84b9bb-rs5hq 0/1 CrashLoopBackOff 45 (5 м 5 с назад) 2 д 22 ч cisco-ndfc dcnm-pmn-7bd4f55584-rm28b 0/1 CrashLoopBackOff 45 (4 м 36 с назад) 2 д 22 ч csi-system csi-controllers-0 0/4 RunContainerError 12 (145 минут назад) 2d22h gollum pre-enable-async-jbxfv 0/1 Completed 0 2d22h nodemgr nodectrlr-7948dbcf54-pjw84 1/2 RunContainerError 5 (142 м. назад) 2 д. 22 ч. securitymgr securitymgr-576cf68f9d-ph4td 0/1 RunContainerError 4 (141 м. назад) 2 д. 22 ч. statscollect statscollect-7dfbcb76f9-mmg9h 0/1 CrashLoopBackOff 38 (4 м 49 с назад) 2 д 22 ч ![ND.png] Чтобы решить эту проблему, мне всегда нужно выполнять команду «acs reboot clean», но при этом теряется настройка кластера, что отнимает много времени. Я прочитал в разделе о Linux KVM (даже если я использую esxi) следующее: «Чтобы Nexus Dashboard работал при перезагрузке ОС, необходимо добавить UUID в файлы конфигурации fstab операционной системы RHEL, что является единственным способом сохранить Nexus Dashboard при перезагрузке операционной системы RHEL». =>Я не увидел никаких требований со стороны esxi. Кто-нибудь сталкивался с такой же проблемой? Как я могу ее решить? Что я упускаю? Спасибо! Edit: я также установил версию 3.2.2M, и с ней нет никаких проблем. [image: d8c4a78639c2e061c3666087dc9cb42fb067771f.png]

Привет, ребята! Кто-нибудь уже обновил ND до версии 4.1.1g и запустил ее? У меня есть аппаратный кластер с 3 узлами (SE-NODE-G2 / UCS C200 M5) с прошивкой/CIMC Bundle 4.3(2.240077). ND 4.1.1g всегда зависает на 76% процесса установки (во время активации приложений) с сообщением «Не удалось активировать». Сообщения об ошибках показывают только то, что DNS не работает, что и происходит с момента запуска обновления. Раньше DNS работал, и DNS-серверы доступны без проблем с портов управления ND. В CLI мне кажется, что с момента запуска обновления ND пытается подключиться к DNS-серверам через интерфейс приложения, но маршрут по умолчанию, указывающий на интерфейс Mgmt, остается прежним. Кто-нибудь сталкивался с подобными проблемами или может дать какие-то советы? ![] Спасибо и с уважением, Jules [image: 8ce7b2e0e92051bfc545ea7c9a3d8ee9560f4918.png]