Как работает ARP запрос, который пришел на маршрутизатор с адресом назначения в той же подсети, что и интерфейс его?

Есть сеть, фото прилагается. Сеть настроена, leaf-коммутатор(stp нету), на R1 установлен статический маршрут через R2(да, через другую сеть, по 32 маске). Всего три сети на изображении: между ws и R1, R1-R2(порты swp2), и остальное всё в одной сети: R1(swp1), R2(swp1), server. Насколько мне известно там петля. В задании сказано что сеть работает медленно.
Мне необходимо понять работу сети, и как образуется эта петля.
Моё понимание: С WS отправляется пинг на server. Первым делом ws отправляет arp запрос на R1. R1 Смотрит в таблицу маршрутизации, видит что у него есть статический маршрут в эту сеть и отправляет arp ответ на ws со своим MAC и IP. Далее отправляется ICMP пакет на этот же маршрутизатор. Тот в свою очередь отправляет его на R2. R2 знает MAC получателя, удаляет ICMP и отправляет ARP. ARP приходит на коммутатор leaf. Тот не знает куда отправлять и рассылает во все порты, один доходит до server, а другой до маршрутизатора R1. Вот тут моё понимание заканчивается... Сервер даст ответ коммутатору что вот мол это я, коммутатор запишет его. А R1 даст ответ что у него есть этот статический маршрут и по кругу отправит arp через R2 или увидит что ему пришел запрос на интерфейс в той же подсети, поймет что где-то в ней конечный хост и не будет ничего делать? Если первый вариант, то коммутатор запишет его тоже для доступа к этому хосту и тогда некоторые пакеты будут туда слаться или как? Если всё-таки arp пойдет по второму кругу на R2, что сделает R2 и leaf?
UPD: Статический маршрут на R1 весит через сеть 10.1.5.0/30 в сеть 10.1.3.11/32, т.е. конкретно к серверу

Дополнительно:

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

Задача решена! Петля всё же образуется, но образуется не везде. В частности на оборудовании cisco по умолчанию включен proxy arp. Из-за этого R2 может получить mac адрес R1 вместо server. И пакеты будут бегать по кругу и копиться. Решение: отключить proxy arp на R1, либо задать в ручную mac server'а на R2 в таблицу ARP .

• это временный костыль, а не решение. правильно - перестать эдж называть лифом, на р1 и р2 поднять вррп, заменить статическую маршрутизацию динамической.

Ответы:

Что-то Вы теорию совсем не учили...
Arp запрос - широковещательный. Отправляется всем.
Коммутатор - устройство тупое. Если Mac назначения есть в таблице, отправит в нужный порт; если пакет широковещательный или Mac нет в таблице - пакет уйдёт во все порты.

Для анализа - надо знать таблицы маршрутизации на всем оборудовании.

ARP-запрос, по смыслу, это: отзовись тот, кто имеет такой-то ip. Кто имеет этот ip, тот и сообщит свой Mac. Остальные молчат. Arp работает только в одной под сети.

• И в чем я был не прав? Всё верно, как я и сказал. Коммутатор отправляет во все порты arp, он доходит до сервера и до R1. Вопрос стоит в том что дальше происходит... Насчет таблиц маршрутизации на R1 к server через R2. На R2 к WS через R1. Там где коммутатор - всё одна сеть: R1(swp1) R2(swp1) server Находятся в одной подсети. Не понимаю что я не правильно сказал...
• звучит обидненько насчет не учили теорию, когда сижу над этим столько и столько облазил информации. Ладно бы ещё ответили по делу, а так просто написали тоже самое что и я, а вопрос сам оставили открытым... Нету слов
• Daidin,
  У Вас написано, дословно:
  "на R1 установлен статический маршрут через R2(да, через другую сеть, по 32 маске"

  Задачу надо решать в адресах. Потому что из Вашей фразы надо додумывать, что речь идет про маршрут на server.

  У сервера как прописан маршрут на ws, через R1 или R2?

  Маршрутизатор шлет широковещательный запрос Arp только в 1 порт, который подключён к той сети, где мы ищем соответствие Mac - IP.

• SunTechnik, обновил фотку, добавил ip
• Daidin,
  Отлично.
  Так что с таблицами маршрутизации?
  На 10.1.3.11 какой маршрут на 10.1.2.0 ?
  Или там default-router прописан ? Какой ?
• SunTechnik, там default-router указаны на сервере 10.1.2.2 и на ws 10.1.3.2

• 

• Про "плохо учили теорию" сказано не зря - для доступа к адресу не лежащему в границах собственной сети arp -запросы не используются. Тут, как.минимум, неправильное использование терминов.
  По маршрутам - надо смотреть таблицу маршрутизации и метрики локального маршрута в 10.1.3.0/24 и собственно до 10.1.3.11 через R2. Сам R2, если не знает мака севера пошлёт arp и потом оттенки пакет. Коммутатор без мак-таблицы будет слать пакеты во всё порты
• Тогда получается примено так должно было работать, соглсано Вашему описанию, если нет прописанных ARP записей или ARP-proxy.

  Для уменьшения текста, формальная процедура:
  Получить MAC для IP:
  Послать широковещательный запрос в интерфейса сети IP, для получения MAC-адреса.
  Получить MAC-адрес.

  10.1.2.1, по таблице маршрутизации видит, что пакет для 10.1.3.11 надо послать через 10.1.2.2 Выполняет: Получить MAC для IP: 10.1.2.2 , и послыает ICMP-request на MAC от 10.1.2.2 на IP 10.1.3.11

  10.1.2.2, получив данный пакет, по своей таблице маршрутизации выполняет:
  Получить MAC для IP: 10.1.5.2 и послыает ICMP-request на MAC от 10.1.5.2 на IP 10.1.3.11

  10.1.5.2 получив данный пакет, по своей таблице маршрутизации выполняет:
  Получить MAC для IP: 10.1.3.11 и послыает ICMP-request на MAC от 10.1.3.11 на IP 10.1.3.11

  10.1.3.11 Получив данный пакет, понимает, что он адресован ему, формирует ответ Echo-replay на 10.1.2.1, и согласно свое таблице маршрутизации должен отправить его на 10.1.3.2. Так как от данного IP только что был получен пакет, то ARP запись уже есть, и 10.1.3.11 отправляет Echo-replay на 10.1.2.1 на MAC 10.1.3.2.

  10.1.3.2 Получив данный пакет, согласно своей таблице маршрутизации, понимает, что он должен отправить его на 10.1.5.1. Запись в ARP еже есть, пакет уходит на MAC 10.1.5.1 для IP адреса 10.1.2.1 .

  10.1.5.1 Получив данный пакет, согласно своей таблице маршрутизации, понимает, что он должен отправить его на 10.1.2.1. Запись в ARP еже есть, пакет уходит на MAC 10.1.2.1 для IP адреса 10.1.2.1 .

  10.1.2.1 - Получает пакет и отображает статистику в Ping.

  Именно эти строчки у Вас и зафикисрованы в записи маршрутов ping -R. ( Прямой и обратный маршрут).

  Работа leaf была описана выше. Он не производит никаких преобразований адресов.

  Сеть будет работать, но не оптимальным образом, так как есть лишний промежуточный маршрутизатор R2. Насколько хуже, зависит от скоростей конкретных линков. Может и лучше, если leaf- R1 низкоскоростной (гигабитный порт, а у витой пары перебита 8 жила и порт поднялся на 100Mb/s).

• Дмитрий, а где я сказал что arp запрос отправляется в другую сеть???
• SunTechnik, получается коммутатор когда к нему пришел arp от R2, он рассылает его везде: на R1 и на server. R1 же видит у себя маршрут статический и отправляет ответ, который доходит до R2 и тот запишет его для доступа в нужную ему сеть. Но и сервер же даст ответ. Будет ли правильно сказать что кто быстрее ответит, того и запишут?
• Daidin, коммутатор разошлет arp-запрос на все порты, но ответит на него, только то оборудование, чей IP стоит в запросе. Все остальные будут молчать.

  Поставьте любой анализатор пакетов (tcpdump, wareshark, network monitor) и посмотрите что происходит.

  Указывайте в вопросе конкретные IP.

  R2 посылает ARP запрос для адреса 10.1.3.11. коммутатор разошлет его на все порты.
  Но R1 видит, что спрашивают не его и будет молчать.
  Ответит только server, так как его IP совпадает адресом в arp - запросе.

• >> UPD: Статический маршрут на R1 весит через сеть 10.1.5.0/30 в сеть 10.1.3.11/32, т.е. конкретно к серверу

  Маршрут прописывается через конретный маршрутизатор (IP), а не через сеть.

• Daidin, Нет, коммутаторы обычно (если их специально не просить это делать) на ARP запросы не отвечают. Ответит тот, чей IP-адрес спрашивается в ARP-запросе.

  Ну и по сети, если у Вас коммутаторы не настроены, а есть кольца/петли (а я их вижу!), то любой широковещательный трафик будет убивать вашу сеть, причем будет иногда больно, и непонято, почему вдруг все отваливается, а через минуту - восстанавиливается.

  Поэтому, напрягаем сфинктор и настраиваем STP (или чо там у вас за аналог).
  На почитать - https://habr.com/ru/articles/143768/

  И да, ARP запрос не должен уходить из своего широковещательного сегмента - никогда!!!! Если это происходит - все у вас плохо.

• Алексей Черемисин, Нет там петли. R1 и R2 - маршрутизаторы.
• SunTechnik, Упс, ну тогда нужно поднимать (петля-то есть!) OSPF хотя бы.
• SunTechnik, там есть петля, образуется когда R1 отвечает на arp что за ним, по статическому маршруту лежит сеть назначения. А прописан маршрут статический у меня правильно, просто сказал через какую сеть. Потому что они через две связаны.
• Алексей Черемисин, спасибо. Значит настраиваем STP на коммутаторе и он логически должен выключать порт в направлении R1?
• Daidin, Нет такого запроса и ответа.
  ARP всегда запрос на конкретный IP. Router не отвечат по ARP какие сети за ним лежат....
  ARP таблица содержит только адреса локального сегмента сети.

  Единственные тонкости, какие могут быть в такой конфигурации - если не запрещены icmp-redirect, при ping с сервера R1, обратный ответ пойдет напрямую, а не через R2. (Первый ответ пойдет через R2), потом может произойти коррекция таблицы маршрутизации.

  Мы перешли в фазу - верю-не верю... Тут разрулит только стенд у Вас (судя по всему, он есть), и демонстрация дулированных пакетов.

• STP работает только на коммутаторах. Он может найти петли только коммутаторов и не будет отключать порты к маршрутизатору.
• Daidin, если это уже собрано в железе, назовите модели оборудования, а то окажется, что там коммутаторы L3, а не маршрутизаторы и не вся сеть отрисована...

Широковещательные запросы через маршрутизаторы никуда не пересылаются, т.е. они ими отбрасываются, если на них (маршрутизаторах) не настроено обратное, например, DHCP-relay.