Pull to refresh

Comments 16

Спасибо за статьи, очень познавательно.
В первом описанном случае, можно ли отключить отбрасывание ARP-запросов и обойтись без статической привязки ARP?

Интересен вопрос работы Cisco ASA с ARP в сетях с VLAN-ами. На практике, наблюдал ситуацию с проблемами ARP:
Cisco ASA выступает в роли маршрутизатора, разделяет/соединяет несколько сетей /24 в разных VLAN-ах. В сеть включают сервер виртуализации. Управляющий интерфейс сервера в одной сети (и VLAN-е), контейнера в других и сетях и VLAN-ах, через виртуальные сетевые интерфесы. Симптомы такие-же, как и в первом вашем случае и статические записи APR в контейнерах для адресов шлюзов каждой сети проблему решали, но это очень не хороший вариант. К сожалению, у меня тогда не было возможности собрать информацию подробнее. Может подобные случаи были и в вашей практике?

Ещё интересен вопрос особенности работы APR в случае статически агрегированных каналов. Опять же наблюдал схожие проблемы, но тут конкретной информации ещё меньше.
Спасибо за комментарий, отвечаю по пунктам.

Про первый случай, когда у провайдера был secondary IP-address. Да, в случае с ASA, можно отключить отбрасывание ARP-запроса от провайдера. Для этого есть команда "arp permit-nonconnected". Другой вариант — попробовать настроить на ASA статическую ARP-запись с ключом ALIAS (имитация Secondary IP на ASA). Но про ALIAS – нужно проверять. Когда я описывал первый случай, моя основная идея была показать процесс диагностики. В данном случае, как мне кажется, важнее было не найти способ решения проблемы (уже с вами придумали три варианта), а определить причину проблемы и понять, что проблема кроется именно в ARP. Ведь провайдер не сразу признался, что у него наш шлюз прописан как secondary.

ARP в сетях с VLAN-ами. Вот тут, к сожалению, не смогу подсказать. У меня достаточно много примеров сетей, когда ASA маршрутизирует VLAN-ы, но с ARP-проблемами в этом случае никогда не сталкивались. Вы правильно заметили, в этом случае нужно собирать дополнительную информацию.

Статически агрегированные каналы. Опять же, к сожалению (или к счастью) с проблемами не сталкивался. Есть пример, когда маршрутизаторы подключены к коммутаторам ядра через статически агрегированные порты. Проблем с ARP на возникало, нужно больше информации.
Спасибо за ответ.
При случае, соберу информацию и буду много думать.
Надеюсь на продолжение статей по теме.
Была аналогичная ситуация (пример 1), до сути не докопались, в качестве workaround настроили пинговалку провайдерского адреса (IP SLA) :-).
Плохо, когда не знаешь, да еще забудешь. Прятал два сервера за асу, транслировал их айпи на интерфейс — нет связи с роутером. Сутки убил, не работает. С другими айпи работает, с нужными нет. Вычитал тут про Gratuitous ARP — ну точно, оно. Спасибо за статью, я бы не догадался, а ждать 4 часа, пока арп на роутере почистится не могу, сервера нужны в работе, и доступа к роутеру нет, только шнурок, вот его и дерну.
подскажите, пожалуйста, — сильный флуд на ASA из-за VRRP (Keepalived) & HSRP, вот такого плана сообщения:
4 Jan 18 2017 18:42:18 Received ARP response collision from 10.x.181.4/70ca.xxe5.dd4a on interface VLAN6 with existing ARP entry 10.x.181.4/70ca.xxe5.d16a

как исправить? оно конечно жить особо не мешает, просто лог забивает :(

а еще если подскажите — буду очень признателен! вот такие сообщения:
4 Jan 18 2017 18:37:25 No matching connection for ICMP error message: icmp src VLAN32:10.xx.32.52 dst VLAN111:10.xx.111.15 (type 3, code 3) on VLAN32 interface. Original IP payload: udp src 10.xx.111.15/53 dst 10.xx.32.52/54874.

и как мне кажется поэтому не работает пинг из удаленных сетей через Site-toSite VPN :( (там начинается сообщение No matching session… )
Добрый день. По первому вопросу пока нет идей, подумаем, если что-то появится — сообщим. Объясните, пожалуйста, поподробнее: так у вас VRRP или HSRP? Адрес 10.x.181.4 — это что за адрес? Виртуальный группы VRRP/HSRP или адрес физического интерфейса устройства?

По второму вопросу весьма странная ситуация. Получается, сервер 10.xx.111.15 шлёт DNS ответ клиенту 10.xx.32.52 (UDP порт 53 -> на порт 54874). На это клиент 10.xx.32.52 отвечает ICMP error message типа icmp port unreachable. Я думаю, нужно искать саму причину, почему DNS-сервер шлёт ответ клиенту, а клиент говорит, что ему это не нужно. Я бы посмотрел с помощью packet capture на ASA всё общение между 10.xx.32.52 и 10.xx.111.15 по порту udp 53…
10.x.181.4 это виртуальный адрес HSRP, но такие же сообщения получаем и по виртуальным IP в кластерах VRRP (Keepalived) :(
по второму вот более показательный пример:
4 Jan 19 2017 10:20:58 Denied ICMP type=0, from laddr 10.xx.111.11 on interface prod-infra to 10.11.12.7: no matching session

в данном случае сеть 10.11.12.0\24 — клиенты AnyConnect VPN, у которых шлюз остается прежним и добавляется маршрут только к сети 10.xx.111.0\24 (соотв. для этой сети адреса из 10.11.12.0\24 стучаться с внешнего интерфейса)… не работает только ICMP :(
Про HSRP очень странно. Ведь у виртуального адреса mac-адрес должен быть формата 00-00-0c-07-ac-xx… Можно как-то проверить mac-таблицы на коммутаторах? Откуда берутся mac-адреса 70ca.xxe5.dd4a и 70ca.xxe5.d16a??

Про ICMP, пока задам банальные вопросы: включены ли inspect icmp, inspect icmp error и sysopt connection permit-vpn?
было включено inspect icmp, включил inspect icmp error
на счет sysopt connection permit-vpn — стыдно признаться, — для чего это? без нее работал AnyConnect VPN как и IPSec Site-to-Site…
sysopt connection permit-vpn включён по умолчанию. В show runn не отображается, но можно проверить в show runn all. Это опция позволяет обходить списки доступа для VPN-payload трафика. Если эту опцию убрать, то придётся в acl на внешнем интерфейсе в явном виде прописывать permit для удалённых VPN подсетей. Это полезно, если мы подключаем по VPN недоверенную сеть (например, какого-нибудь контрагента) и хотим оградиться от неё правилами файрвола.

По поводу ICMP появилась не плохая идея. Нет ли у вас ассиметричной маршрутизации? Может быть ICMP echo отправляются в сторону LAN через один интерфейс, а возвращаются через другой?

Используется ли у вас выделенный Management-интерфейс на ASA?
Кстати, к ассиметричному хождению может приводить правило NAT exception. Если в правиле чётко указаны ingress и egress интерфейсы, то для untranslated пакета egress интерфейс будет выбран в соответствии с правилом NAT, даже если маршрут смотрит на другой интерфейс. Если мы хотим этого избежать, в правиле NAT нужно использовать опцию route-lookup
По поводу ICMP появилась не плохая идея. Нет ли у вас ассиметричной маршрутизации? Может быть ICMP echo отправляются в сторону LAN через один интерфейс, а возвращаются через другой?
ну я тоже так думаю (для сети 10.xx.111.0\24 настроен PAT через интерфейс ISP1), для клиентов VPN AnyConnect шлюз не подменяется, а добавляется маршрут только к сети 10.xx.111.0\24 — то есть к туннель идет не весь трафик, а только выбранный (когда весь туда льешь таких проблем нет) — но может есть решение :(?

«Используется ли у вас выделенный Management-интерфейс на ASA?» — используется для модуля FirePower
Обычно пинги от Anyconnect клиентов проходят без проблем даже если не подменять шлюз (использовать split tunneling). Почему у вас не работает — сложно сказать. Может быть пришлёте show runn в ЛС?

Внезапно пригодилось, так как с sysopt noproxyarp outside даже NAT в Интернет с пулом адресов перестаёт работать.

Sign up to leave a comment.