Здравствуйте, у меня есть небольшой вопрос: маршрутизация, У меня есть брандмауэр Sophos и 2 маршрутизатора Cisco Брандмауэр 192.168.15.1---------------192.168.15.2 (CISCOR12) 192.168.17.1---------------192.168.17.2 (R4) CISCOR12 — сеть 192.168.15.0\24 в области 0 с идентификатором процесса 1 192.168.16.0/24 в области 0 с идентификатором процесса 1 192.168.17.0/24 в области 5 с идентификатором процесса 1 Маршрутизатор R4 имеет 2 сети 192.168.17.0/24 и обратный адрес -15.15.15.15 в области 5 с идентификатором процесса 1 Брандмауэр Sophos 192.168.15.0/24 и 192.168.10.0/24 в области 0 Мой вопрос: почему я получаю LSA 4 здесь. См. прикрепленный скриншот CISCOR12 ![babayagafebruary_0-1767171625634.png] R4 ![babayagafebruary_1-1767171726378.png] [image: 0419951950754e98b2460c108a126523bf8ba603.png] [image: 678eedf7096f682ba3ff5f306542bf4bd96b58be.png]

Здравствуйте, У меня в головном офисе есть Cisco 4400 с двумя подключениями к интернет-провайдерам. Мне нужно настроить VPN Site-2-Site на этом маршрутизаторе через обоих интернет-провайдеров, и для WAN-маршрутизации я выбрал VRF, но это не работает. Иногда IKE работает, но потом все равно выдает ошибку. Вот моя конфигурация: vrf definition isp2 rd 65535:252 crypto keyring KEYRING1 vrf isp2 pre-shared-key address ..95.156 key NEP22SK5ZB23kksfsjY176gFy2H3AD0y2 crypto isakmp policy 1 encryption aes 256 hash sha256 authentication pre-share group 14 криптографический ключ isakmp Afsm1ksfssfPUIO1Mi2e2ssd адрес ..95.156 no-xauth криптографический isakmp агрессивный режим отключить crypto isakmp profile ISAKML-PROFILE keyring KEYRING1 match identity address ..95.156 255.255.255.255 local-address ..38.75 crypto ipsec transform-set TS1 esp-aes 256 esp-sha256-hmac mode transport require crypto ipsec transform-set TS2 esp-aes 256 esp-sha256-hmac mode transport require crypto ipsec profile Profile1 set security-association lifetime seconds 86400 set transform-set TS1 set pfs group14 crypto ipsec profile Profile2 set security-association lifetime seconds 86400 set transform-set TS2 set pfs group14 set isakmp-profile ISAKML-PROFILE interface Port-channel20.502 vrf forwarding isp2 ip address ..38.75 255.255.255.248 интерфейс Port-channel20.700 ip адрес ..116.242 255.255.255.248 интерфейс Tunnel602 ip адрес 172.29.10.9 255.255.255.252 ip mtu 1430 ip tcp adjust-mss 1390 туннель источник ..116.242 туннель назначение ..95.156 туннель ключ 602 туннель защита ipsec профиль Profile1 интерфейс Tunnel802 ip адрес 172.29.11.9 255.255.255.252 ip mtu 1430 ip tcp adjust-mss 1390 туннель источник ..38.75 туннель назначение ..95.156 ключ туннеля 802 туннель vrf isp2 защита туннеля ipsec профиль Profile2 ip route ..95.156 255.255.255.255 ..116.241 ip route vrf isp2 ..95.156 255.255.255.255 ..38.73 На другом сайте находится Cisco с 1 ISP - IP ..95.156, мне нужно настроить балансировку нагрузки + балансировку

У меня есть следующий сценарий, в котором мне нужна помощь для понимания/решения: PC1 подключен к маршрутизатору Cisco (R1) в локальной сети 10.254.0.1/24, который имеет точечный IPSEC VPN-туннель к другому маршрутизатору Cisco (R2) с PC2 в локальной сети 10.254.1.1/24. Я могу обмениваться данными по TCP 443 с PC1 на PC2, пока не добавлю маршрут NAT ниже в R2, чтобы разрешить доступ TCP 443 к PC2 (10.254.1.200) из R2 WAN на внешнем порту 11443: ip nat inside source static tcp 10.254.1.200 443 61.0.1.2 11443 extendable С помощью вышеуказанного маршрута NAT я могу получить доступ к PC2 из R2 WAN, но это прерывает трафик TCP 443 с PC1 через VPN-туннель. Как я могу получить TCP 11443 из R2 WAN в TCP 443 на PC2, сохранив при этом работу трафика TCP 443 между PC1 и PC2 через VPN-туннель? Похоже, что вышеуказанное правило NAT удерживает открытым порт 443? Спасибо за любую помощь/предложения!

Здравствуйте, все Недавно я начал изучать IS-IS и перехватил одно из его сообщений в Wireshark ![Mitrixsen_0-1767640751264.png] Насколько я понимаю, он использует исходный формат Ethernet (не Ethernet 2) вместе с LLC. В LLC SAP примерно аналогичен EtherType в Ethernet 2, верно? SAP в данном случае говорит «ISO Network Layer», поэтому все, что ожидается далее, принадлежит протоколу OSI. Мой вопрос: почему IS-IS имеет два заголовка? Почему сначала идет ISO 10589, а затем IS-IS hello? Почему вся эта информация не включена в hello, почему она разделена между двумя разными заголовками? Спасибо, Дэвид [image: c8ecffdb176ec12ee3378aedf0fd1e80305d4865.png]

Здравствуйте, все. Я прочитал презентацию Cisco Live, в которой идентификатор (NET) для маршрутизатора IS-IS объясняется следующим образом: ![Mitrixsen_0-1767704531730.png] По-видимому, все поле Area Address состоит из AFI (определяет, как интерпретировать остальную часть адреса), IDI и HO-DSP (здесь мы вводим номер области). ![Mitrixsen_2-1767704704240.png] Что меня смущает в этом случае, так это то, что именно является номером области? Если я настрою NET как 47.0004.31ac.0012.2222.2222.00. Является ли номер области в этом случае 0012 или 47.0004.31ac.0012 ? Маршрутизатор включает его в Wireshark следующим образом: ![Mitrixsen_1-1767704669399.png] Однако это полный адрес области, который также содержит конкретный номер области. Есть ли разница между адресом области и областью? Я попробовал изменить AFI или домен, сохранив номер области, и мои маршрутизаторы сформировали только L2-смежность, поэтому я не думаю, что они считали область одинаковой. Спасибо Дэвид [image: 1b395192e34844dae48674a4d036276be5033753.png] [image: b3f73943adea1d78f0f278a41b6222e88da9d42f.png] [image: 73596c83ae8eaab0ca8a690c35a7c3176fb1ab6d.png]

Здравствуйте, все Я недавно начал изучать IS-IS и не могу понять, что здесь происходит. Все маршрутизаторы включены для IS-IS, а их соединения настроены как P2P . ![Mitrixsen_0-1767873652514.png] P2 и P4-XR — это маршрутизаторы L1-2. Они имеют соседство L2 для обмена маршрутами ![Mitrixsen_1-1767873693342.png] Почему на P4-XR я вижу LSP от P1? ![Mitrixsen_0-1767873862265.png] Это какая-то ошибка в Cisco CML или то, что я вижу, верно? P1 настроен как маршрутизатор L1 и ничем больше. Спасибо Дэвид [image: 3ab15d806efc4d5e8a85988c8ee3eda2c3c8dd2e.png] [image: 4679b82b2f8d118c3912e6a007a1d411df6da85f.png] [image: fff736e506145a34268d0e40d300c0d7285963c5.png]

Всем привет! Я ищу, где можно скачать программное обеспечение « c1140-k9w7-tar.153-3.JB.tar» для моей точки доступа. Не могли бы вы дать мне ссылку, по которой я мог бы его скачать? Спасибо

Привет, ребята Я хочу купить несколько новых безопасных маршрутизаторов Cisco, управляемых локально. Лицензии Лицензия R-OS-M-E Cisco OS Essentials — средняя (встроенная, бессрочная) Лицензия LIC-ROS-M-A Cisco Routing Advantage Lic — средняя (84 месяца) Мои вопросы Что произойдет, когда срок действия лицензии Advantage истечет через 7 лет? Функции перестанут работать?

Здравствуйте, согласно приведенной ниже спецификации C8300, я понимаю, что C8300 поддерживает GRE. Однако нет четкого упоминания о туннелировании IPIP, и я думаю, что C8300 его не поддерживает. Это верно? https://www.cisco.com/c/en/us/products/collateral/routers/catalyst-8300-series-edge-platforms/datas… Спасибо за помощь!

Здравствуйте, все. IS-IS имеет механизм, называемый трехсторонним рукопожатием, который включается на P2P-связях. Он определен в RFC 5303. The basic mechanism defined in the standard is that each side declares the other side to be reachable if a Hello packet is heard from it. Насколько я понимаю, всякий раз, когда маршрутизатор в IS-IS получал приветствие, он сразу же предполагал, что соседний маршрутизатор доступен, что приводило к сбоям на однонаправленных каналах. Этот механизм пытается смягчить эту проблему, включая системный идентификатор соседнего устройства, что позволяет IS-IS проверить, что оба маршрутизатора имеют двунаправленную связь. Мой вопрос: почему это работает только на P2P-связях? Разве двусторонняя связь не должна быть обеспечена и на связях LAN/Broadcast-сегментов? Спасибо. Дэвид

Согласно RFC 5549 и 8950, BGP может использовать соседство IPv6 для передачи семейства адресов IPv4 и наоборот. Если я правильно понимаю, эта функция не работает, если ядро является только IPv4 или IPv6. Так в чем же смысл ее использования, если для пересылки данных на интерфейсе пиринга в любом случае нужны и IPv4, и IPv6?

Я бы никогда не заметил этого, если бы не проанализировал локальные журналы на 2 коммутаторах C9K в SDA Fabric из-за нестабильной работы некоторых интерфейсов. Блок сообщений: 25 июля 13:01:06.457: %LINEPROTO-5-UPDOWN: Протокол линии на интерфейсе TenGigabitEthernet1/1/1, состояние изменено на «up» 25 июля 13:01:07.252: %CLNS-3-INTF_MTU_TOO_SMALL: MTU интерфейса Te1/1/1 1400 меньше, чем lsp-mtu 1492 25 июля 13:01:07.376: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, сосед X.Y.Z.W proc:ISIS, idb:TenGigabitEthernet1/1/1 handle:9 act 25 июля 13:01:08.161: %CLNS-5-ADJCHANGE: ISIS: Соседство с EN0001 (TenGigabitEthernet1/1/1) Up, новое соседство в приведенном ниже выводе каждый порт IS-IS между коммутаторами указывает, что «да, это так» EN0001 L2 TeX/Y/Z X.Y.Z.W UP 22 24 Адрес (а) области: 49.0001.0010 SNPA: ..5ef4 Изменение состояния: 01:08:50 Формат: Фаза V Удаленный TID: 0 Локальный TID: 0 Имя интерфейса: TenGigabitEthernet1/1/1 Идентификатор соседнего контура: 36 Удаленная поддержка BFD: TLV (MTID:0, IPV4) BFD включен: (MTID:0, ipv4) Синхронизация соседей: Полная MTU канала: 1400 Меньше, чем lsp-mtu: 1492 Я пришел к выводу, что CLNS LSP будут отброшены, что может стать проблемой на крупных сайтах SDA Fabric. Есть какие-нибудь подсказки по этому поводу?

Маршрутизатор OSPF имеет 3 напрямую подключенные сети; 172.16.0.0/16, 172.16.1.0/16 and 172.16.2.0/16 Какая команда OSPF network будет рекламировать только 172.16.1.0 network соседям? A. rtr(config-router)# network 172.16.1.0 0.0.255.255 area 0 B . rtr(config-router)# network 172.16.0.0 0.0.15.255 area 0 C. rtr(config-router)# network 172.16.1.0 255.255.255.0 area 0 D. rtr(config-router)# network 172.16.1.0 0.0.0.0 area 0 Джейлин

![Screenshot 2026-01-09 at 2.00.14 pm.png] Здравствуйте, эксперты! Здравствуйте, команда! В настоящее время у нас есть две облачные среды (AWS и GCP) , подключенные к нашим конечным устройствам COLO через два транзитных концентратора , с включенной функцией ECMP по всем путям. Существующая конструкция В настоящее время сеть работает в режиме «активный/активный» на обоих транзитных концентраторах. Сейчас возникла необходимость перехода этой конфигурации на модель «активный/резервный ». Архитектура транзитного концентратора Транзитный узел 1 (TR-HUB1) Устройства: Nexus 9K (SW1 и SW2), настроенные как vPC-узлы Протокол: iBGP VRF: AWS VRF GCP VRF Конечная точка VRF В качестве протокола используется BGP Для каждого коммутатора используются отдельные исходные VLAN: VLAN 101 → TR-HUB1-SW1 VLAN 102 → TR-HUB1-SW2 Транзитный концентратор 2 (TR-HUB2) Устройства: коммутаторы Arista (SW1 и SW2) MLAG: не настроен Протокол: iBGP VRF: AWS VRF GCP VRF VRF конечной точки Подключение конечных точек Конечные устройства COLO подключены к обоим транзитным узлам. Для обеспечения масштабируемости и роста в будущем планируется установить дополнительные «синие соединения» между транзитными узлами и конечными устройствами , чтобы увеличить пропускную способность и отказоустойчивость. Требование Нам необходима возможность контролировать трафик, исходящий из облака (например, AWS), таким образом, чтобы: трафик мог перенаправляться на TR-HUB1 или TR-HUB2 при необходимости (техобслуживание, сбой или эксплуатационные потребности) Конструкция должна оставаться масштабируемой и совместимой с планируемым расширением синих каналов связи. Вопросы Можно ли реализовать эту предпочтительную маршрутизацию трафика с помощью атрибутов BGP на маршрутизаторах транзитного концентратора ? Необходимо ли перенастраивать VLAN с HSRP , или это требование может быть выполнено исключительно с помощью инженерии трафика на основе BGP , даже с учетом будущих синих каналов? [image: fb2cd5193e4a8851c3cca09d344895d603a98ca4.png]

Добрый день, У меня есть небольшой вопрос. У меня есть Cisco C3548P, и я пытаюсь понять, почему NAT не работает. Входящий интерфейс — eth1/46, на котором установлен ip nat inside. Исходящий интерфейс — Vlan2799, на котором установлен ip nat outside. Этот VLAN выполняет BGP-пиринг, и когда я выполняю команду show bgp neigh advertise route, я вижу, что рекламирую только подсеть 90.204.124.0/24. Проблема в том, что vlan имеет адрес 10.20.25.74, но я вижу, что другой vlan VLAN433 имеет IP-адрес 90.204.124.22. Когда я проверяю конфигурацию, я вижу, что для этой VLAN есть перегрузка: ip nat inside source list Out-NAT-Allow interface Vlan443 overload. Я не думаю, что это сработает, если я ничего не упустил. Разрешено ли это, и если да, то что я упустил? Заранее спасибо! Уоррен

Как мы знаем, при взаимном перераспределении с двумя или более маршрутизаторами возникнет петля, если мы не будем использовать тег на одном маршрутизаторе перераспределения и блокировать обратное изучение маршрута на другом. Однако даже без настройки тегов и блокировки IOS XE и XR могут каким-то образом автоматически обнаруживать петлю и не учиться обратно маршруту на другом маршрутизаторе? Я осуществлял перераспределение между ISIS и OSPF. Один маршрутизатор, осуществляющий перераспределение, учит маршрут, исходящий из ISIS, через OSPF, но другой учит через ISIS, и я вижу, что его OSPF RIB не учит перераспределенный маршрут. Было ли обновление поведения цикла перераспределения IOS XE и XR?

Здравствуйте, У меня есть маршрутизатор ISR829 LTE с модулем Switch. Полагаю, у меня возникла проблема с обратным трафиком из Интернета для некоторых устройств IoT, которые я поместил в новую подсеть и VLAN. Предполагаю, что проблема заключается в том, что когда трафик возвращается из сети поставщика, я не разрешаю его правильно, например, мне нужно разрешить любой трафик для этого конкретного трафика или разрешить IP-адрес интерфейса Cellular0/0, а не внутреннюю подсеть IoT. Я пытаюсь придумать, как лучше всего решить эту проблему. Последнее, что я попробовал, — это отразить ACL, но это тоже не сработало. Итак, вот что у меня есть на данный момент: интерфейс vlan10 описание DATA-NETWORK ip-адрес 172.16.10.0 255.255.255.0 интерфейс vlan 20 описание IOT-NETWORK ip адрес 192.168.20.0 255.255.255.0 ip access-group ACL-IOT in ip nat inside интерфейс Cellular0/0 ip nat outside ip access-group ACL-ACCESS in access-list 20 permit 192.168.20.0 0.0.0.255 ip nat inside source list 20 интерфейс Cellular0/0 overload ip access-list extended ACL-IOT 10 deny ip any 172.16.10.0 0.0.0.255 10 permit tcp any any eq 443 reflect IOTFLEX 20 permit udp any any eq domain reflect IOTFLEX 30 permit udp any any eq ntp reflect IOT FLEX 40 deny ip any any ip access-list extended ACL-ACCESS 10 evaluate IOTFLEX 20 (ряд правил разрешения для VPN для трафика DATA-NETWORK и MGMT) 30 deny ip any any Моя главная забота — открытие правил для пропуска трафика и создание угрозы для DATA-NETWORK. В настоящее время для этого трафика используется VPN-соединение с нашей сетью. Я пытаюсь заставить эти устройства IoT использовать только сотовое интернет-соединение и не допускать их в DATA-NETWORK. Поэтому, если я разрешу сеть поставщика с такими правилами, как... ip access-list extended ACL-ACCESS permit tcp VENDOR-IP CELLULAR0/0-IP eq 443 Как я могу убедиться, что трафик не попадает в сеть передачи данных? Должен ли я использовать маршрутную карту, чтобы заставить все IP-адреса поставщика указывать на интерфейс VLAN20, или NAT-преобразования позаботятся об этом? Есть ли лучший способ сделать это? Спасибо.

У меня следующая топология. Все устройства — C8000V с IOS-XE 17.14.01a ![Capture.PNG] Я пытаюсь установить динамическую политику SR-Policy от R1 до R4, но по какой-то причине она не работает. R1#show segment-routing traffic-eng policy all Имя: DYNAMIC (Цвет: 20 Конечная точка: 4.4.4.4) Владельцы: CLI Статус: Администратор: активен, Рабочий: неактивен в течение 01:35:55 (с 11-06 09:12:27.985) Кандидатные пути: Предпочтение 100 (CLI): Динамический (неактивный) Тип метрики: TE Атрибуты: Связывающий SID: 16 Режим распределения: динамический Состояние: Запрограммированные ограничения IPv6 включены Все конфигурации находятся в приложенных файлах. Может ли кто-нибудь сказать мне, что я делаю не так? [image: e07ff13751b0dfc7c4d9b3740c1a3cecd74ffc3a.png]

Играя с IP SLA, я настроил udp-зонду со случайным портом 65051, а на другой стороне настроил только «ip sla responder», и она начала работать... Я несколько раз менял порт (63500, 64111 и т. д.), и она продолжает работать, что вызывает много опасений по поводу безопасности. Даже если я настроил статический порт на удаленном маршрутизаторе (R2), он продолжает отвечать. Есть ли в сегменте IP или заголовке другое поле, которое сигнализирует, что это тестовое сообщение SLA от другого устройства Cisco, или маршрутизатор просто начинает отвечать на каждое сообщение в каждом порту? (Сейчас не могу получить захват пакетов). R1(config-ip-sla)# udp-jitter 172.16.22.254 65051 num-packets 20 R1(config-ip-sla-jitter)# request-data-size 160 R1(config-ip-sla-jitter)# frequency 30 R1(config-ip-sla-jitter)# exit R1(config)# ! ! ! R2(config)# ip sla responder ![RolandoValenzuela_0-1768423958401.png] ![RolandoValenzuela_1-1768423965231.png] [image: 5af185950ed2371b683264ffb025a1cf125098b6.png] [image: d1d1216b752f35d773e8c0f102130b85b159118a.png]

В IOS XR при настройке BFD в статическом маршруте есть опция multihop, как в 'bfd fast-detect multihop <адрес источника>'. Однако вы не можете настроить пункт назначения, как в IOS XE. Маршрутизатор использует адрес непосредственно подключенного соседнего интерфейса в качестве пункта назначения. Таким образом, мы не можем использовать рекурсивный следующий прыжок в качестве пункта назначения, что является основной целью многопрыжкового BFD. Итак, поддерживает ли IOS XR многоходовой BFD в статическом маршруте?