Хочу поведать поучительную историю, которая случилась сегодня у меня на работе. Работаю я в одной очень известной компании предоставляющей, в числе прочих, услуги доступа ко всемирной паутине. И суть моей работы заключается в поддержании нормальной работы сети передачи данных. Сеть эта построена по классической структуре Ядро, Агрегация, Доступ. Коммутаторы доступа приблизительно на половину производства D-Link, вторая (большая) часть от Huawei. Управление всем сетевым железом вынесено в отдельный вилан, через него же оно всё и мониторится.
И вот сегодня поутру стало твориться нечто неладное. Система управления и мониторинга железа стала выкидывать «портянки» событий «коммутатор *** офлайн»-«коммутатор *** онлайн». Причём сообщения эти приходили по сегментам сети, в которых установлены были коммутаторы производства Huawei. Беглый просмотр состояния шторм-контроля и загруженности интерфейсов на агрегации ничего не дал, ничего не сказали и логи. День обещал быть весёлым…
Звонок от службы мониторинга сети не добавил радости — завели инцидент по выпадению домовых узлов. При этом массовых жалоб от клиентов об ограничениях в получении услуги не поступало. Удалось даже найти клиента в проблемном сегменте, который отвечал на ICMP обнадёживающими 0,8-ю милисекундами. Попытки зайти на какой-либо коммутатор по телнету были сродни пытке: коннект либо отваливался по тайм-ауту, либо приходилось минутами ждать реакции на ввод логина/пароля и на команды. Отчаявшись посмотреть лог «полуживого» коммутатора я, для очистки совести, помучившись изрядно, перезагрузил его. Секунд 10 после старта коммутатор был жив, бодренько отвечая на ICMP запросы, но тут же «пинги» на глазах стали принимать совершенно неприличные значения в 800-1000 мс, а потом и вовсе пропали.
Тут до меня стало доходить, что процессоры, отнюдь не высокопроизводительные у коммутаторов, явно чем-то загружены и, по всей видимости, на все 100%. Запустив tcpdump на vlan-интерфейсе сервера мониторинга я нашел причину высокой загрузки CPU на коммутаторах. Аномально большое количество ARP трафика в вилане управления — несколько тысяч пакетов в секунду. Причина найдена, но вот как отыскать её источник? Было решено заблокировать вилан управления на всех портах агрегации и потом по очереди разблокировать его обратно пока не будет найден проблемный сегмент.
Я успел проделать эту операцию всего на двух узлах агрегации, как вдруг внезапно вся эта свистопляска прекратилась. Но очень подозрительным мне показалось то, что минутою раньше мой коллега, сидящий за соседним столом, вынул сетевой патчкорд из порта коммутатора который служил для доступа к оборудованию и его настройки. Я попросил коллегу снова подключить свой ноутбук в сеть — спустя 10 секунд «пинги» на коммутаторы опять взлетели до безобразных значений. Источник был найден, но этот ноутбук не один месяц использовался для обновления ПО и настройки сетевого оборудования, что же могло с ним такое случиться?
Для начала решили, хотя и наличествовал установленный антивирус, просканировать на наличие зловредов утилитами от доктора и лаборатории. Ничего существенного найдено не было. Попробовали загрузиться в Linux — сетевая молчала, никакого флуда. Обратно загрузили Windows — стойкий эффект, сразу же вилан наполнялся ARP флудом. Но буквально вчера с ноутбуком всё было в порядке! И тут я зачем-то полез в настройки сетевой карты… Коллега мой не часто занимается настройкой железа и обновлением ПО на нём, поэтому запомнить значения маски и шлюза для сети управления он не мог. И он допустил досадную ошибку в конфигурации сетевой карты — вместо 255.255.224.0 для маски подсети он указал 255.255.254.0!
Но что ещё более меня поразило, так это то, что несмотря на явно неправильную конфигурацию (шлюз в ней оказался за пределами сетевого сегмента из-за неверно указанной маски), операционка безропотно проглотила этот бред! Превратив ноутбук в генератор ARP трафика. Вот что было в настройках протокола ipv4:
IP адрес 10.220.198.111
Маска 255.255.254.0
Адрес шлюза 10.220.192.1
При такой маске подсеть ограничена IP адресами 10.220.198.1 — 10.220.199.254 и шлюз 10.220.192.1 лежит вне этого диапазона. Операционная система не должна разрешать присваивать адрес шлюза из другой сети. Это явный баг!
Был бы признателен если бы кто-то взял на себя труд объяснить механизм возникновения ARP флуда в данной ситуации, от себя же хочу пожелать всем специалистам сетевикам внимательности и ещё раз внимательности. Как говорится — семь раз отмерь, один раз отрежь.
Комментарии (46)
Mendel
06.07.2016 15:20А можно узнать версию форточек? А то или я не заметил или вы не указали.
А вообще — бага конечно, не иначе. Форточки это не тот инструмент которым положено отстреливать себе ноги.
Yoda33
06.07.2016 15:24-4Забыл указать — Windows 7 максимальная. Я бы запретил сетевикам работать с виндой, но у компании и департамента ИБ иная точка зрения, увы.
Ordo05
06.07.2016 16:20+6Никакого бага тут нет, ситуация, когда default gateway находится в другой подсети, хоть и странная, но реальная и возможная.
Шлюз по умолчанию совсем не обязательно должен быть в той же подсети, что и хост.
Важно, чтобы он был просто доступен (был маршрут до этого самого default-gateway).Yoda33
06.07.2016 16:34+1В каком RFC это описано?
agpecam
06.07.2016 21:00+2RFC 1620 — Internet Architecture Extensions for Shared Media например. Суть в том, что сегодня полно сценариев, когда 2 хоста находятся в одном L2 сегменте (SameSM), но в разных IP подсетях (LIS). При этом, один из хостов может быть шлюзом для другого. Чтобы это работало, необходимо лишь указать хосту, что шлюз находится с ним в одной shared media, т. е. вручную прописать на нем маршрут «в интерфейс» (link route), либо раздать его через DHCP option 121
lrsi
06.07.2016 21:01+3Неправильный вопрос, правильный звучит так «В каком RFC явно указывается что default gateway должен находиться в той же подсети что и сетевой интерфейс?»
Правильный ответ — ни в каком, читайте как работают протоколы роутинга и что такое дефолтный маршрут и зачем он нужен.
Mendel
06.07.2016 16:40Да пусть любые воркараунды делает. Мне все равно.
Если оно досит сетевое оборудование, значит баг.
Wicron
06.07.2016 16:29Windows стабильно игнорит ситуации, когда шлюз оказывается за пределами, определенными маской. Такое чувство, что в случае наличия такой ситуации ОС может подменить маску, выданную DHCP сервером на ту, которая позволит достучаться до шлюза. Уведомлений об этом обычно нет. Как по мне Windows таким образом создает прецедент безопасности, хотя такое поведение очень часто фиксит проблемные сети, где так или иначе шлюз оказывается недоступен вследствие неверной маски, что очень часто можно встретить как типовую ошибку.
safari2012
06.07.2016 16:32Технически маску можно сделать вообще любую, хоть с такой дыркой 255.0.255.0 и всё будет работать (и не обязательно неправильно) в соответствии с протоколами маршрутизации и ARP.
imbasoft
06.07.2016 17:15Хотелось уточнить, что значит технически сделать?
Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?
Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?safari2012
06.07.2016 18:54Всё гораздо проще с этими масками.
Ведь как работает маршрутизация на какой-то абстрактный target IP адрес:
1) сначала свой IP и target IP умножается на маску (бинарно).
2) в результате сравнивается то, что остаётся после умножения.
3) если результаты совпадают, то подсеть одна, посылается ARP-request target хосту и в результате пакет пересылается напрямую хосту с IP и MAC-адресом хоста.
4) Если не совпадают, пакет всё равно посылается хосту на с MAC-адресом маршрутизатора (для чего сначала отправляется ARP-request на маршрутизатор).
и да, всё будет работать с дырявыми масками, если вся сеть будет соответствующим образом настроена. проверялось лично лет 15 назад.
navion
06.07.2016 22:26RFC прерывистые маски не запрещает, но на практике никто не тестирует с ними софт и есть веротяность наткнуться на баг. Недавно наткнулся на пропадение крипто-мапы на IOS после применения к ней ACL с опечаткой в маске.
safari2012
07.07.2016 15:00Ключевое слово опечатка (ошибка). Если всё делать преднамеренно и на всей инфраструктуре, то работать будет.
В своё время мне довелось поработать тестировщиком у отечественного производителя VPN. Там иногда тестируется и не такое.
trublast
06.07.2016 16:33+5А что вас смущает в том, что шлюз лежит вне диапазона сети? В линуксе я постоянно пользуюсь такими штуками.
ip addr add 10.100.10.2/24 dev eth0
ip ro add via 10.100.11.1 src 10.100.10.2 dev eth0
всего лишь заставит ОС в случае отсутствия известного маршрута до адреса назначения послать запрос через шлюз. Шлюз указан 10.100.11.1, и поэтому в eth0 будет послан arp who has 10.100.11.1 и после получения ответа все запросы «на шлюз» будут направляться на этот МАС. IP-адрес шлюза больше нигде не участвует в этом, собственно и ваш IP тоже, если маршрутизируем какую-то другую сеть (к примеру 10.200.10.0/24 с eth1).
И даже интереснее бывают проблемы с arp. Например, когда нужно маршрутизировать разные адреса клиентов через один и тот же шлюз, но в разных вланах.
ip ro add via 10.10.20.1 dev eth0.11 table vlan11
ip ro add via 10.10.20.1 dev eth0.12 table vlan12
приходится сделать
sysctl -w net.ipv4.conf.eth0/11.rp_filter=0
sysctl -w net.ipv4.conf.eth0/11.arp_ignore=2
sysctl -w net.ipv4.conf.eth0/12.rp_filter=0
sysctl -w net.ipv4.conf.eth0/12.arp_ignore=2
а то когда одна сетевая карта разными МАСами в разных вланах смотрит в один физический сегмент на один и тот же шлюз, то трафик бывает идет не в тот вланtrublast
06.07.2016 16:41И даже больше скажу: если не шлюзе (роутере, компьютере) не включен arp_ignore, то при получении запроса arp who has
1) с несуществующего в этой сети IP
2) запрашивающий IP-адрес, который отсутствует на этой сетевой карте/влане, но пристутствует на хосте вообще
— роутер ответит
Часто пользуюсь командой, чтобы узнать примерно количество включенных роутеров в влане:
#arping -0 -I eth0.1234 192.168.0.1
#arping -0 -I eth0.1234 192.168.1.1
Посылает запросы с айпишника 0.0.0.0 в сегмент, и все роутеры с дефолтовыми 192.168.0-1.1 адресам отвечают как миленькие.
martin74ua
07.07.2016 14:33это на какой ОС такой ключик у arping?
[root@bsmanage ~]# arping -0
arping: invalid option — '0'
Usage: arping [-fqbDUAV] [-c count] [-w timeout] [-I device] [-s source] destination
-f: quit on first reply
-q: be quiet
-b: keep broadcasting, don't go unicast
-D: duplicate address detection mode
-U: Unsolicited ARP mode, update your neighbours
-A: ARP answer mode, update your neighbours
-V: print version and exit
-c count: how many packets to send
-w timeout: how long to wait for a reply
-I device: which ethernet device to use (eth0)
-s source: source ip address
destination: ask for what ip address
[root@bsmanage ~]# uname -a
Linux bsmanage.lds.net.ua 2.6.32-642.1.1.el6.x86_64 #1 SMP Tue May 31 21:57:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@bsmanage ~]# cat /etc/*rele*
CentOS release 6.8 (Final)trublast
08.07.2016 16:20Ubuntu
ARPing 2.09, by Thomas Habets <thomas@habets.pp.se>
usage: arping [ -0aAbdDeFpqrRuv ] [ -w ] [ -S <host/ip> ]
[ -T <host/ip ] [ -s ] [ -t ] [ -c ]
[ -i ] <host/ip/MAC | -B>
Options:
-0 Use this option to ping with source IP address 0.0.0.0. Use this
when you haven't configured your interface yet. Note that this
may get the MAC-ping unanswered. This is an alias for -S
0.0.0.0.
Без ключика 0 не хочет слать arping с интерфейса, на котором нет IPv4 адреса, а у меня таких интерфейсов сотни, на вланах с proxy_arp. Поэтому использую, потому как алиас "-S 0.0.0.0" писать дольше
Yoda33
06.07.2016 16:45-2Меня смущает результат такого нестандартного использования шлюза, что я и описал в топике.
trublast
06.07.2016 16:56+1А, не смущает полное отсутствие необходимости в шлюзе, к примеру, на ppp-интерфейсах (точка-точка, ppp/tun/tap/etc).
Формально он там обычно указывается, но можно и без него, абсолютно.
#ip ro add dev ppp0
при этом на ppp-интерфейсах на обоих сторонах тоннеля вообще можно IP не вешать, все прекрасно работает.
Да и на обычном компе можно шлюз не указывать, винда по умолчанию (если память не изменяет) в случае отсутствия шлюза в системе просто шлет в сеть запрос «arp who has IP-адрес-назначения». И если на роутере в сети, куда подключен этот интерфейс, включен proxy_arp то интернет прекрасно работает. Просто компьютер «думает» что у него весь интернет в локальной сети, и у всех компов в интернете один и тот же МАС — МАС роутера.
imbasoft
07.07.2016 22:23в eth0 будет послан arp who has 10.100.11.1 и после получения ответа все запросы
Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?
и после получения ответа все запросы «на шлюз» будут направляться на этот МАС
Как обратится к по MAC в другую IP-подсеть?Mystray
08.07.2016 10:02>Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?
Никаким, в ip route можно жестко указать маршрут на connected сеть через интерфейс, даже не имея собственного адреса в этой сети. Маршрут есть — этого достаточно. ARP система сгенерит сама, если nexthop=интерфейс.
>Как обратится к по MAC в другую IP-подсеть?
Никак, на MAC-уровне нет подсетей.
alexmasz
06.07.2016 16:39>> Управление всем сетевым железом вынесено в отдельный вилан, через него же оно всё и мониторится.
ловил «такие» штуки, после чего было решено дробить районы на свои виланы/группы,
ускоряет поиск сюрпризов в управляющей сети, вендоров больше двух :(Yoda33
06.07.2016 16:43-1Когда устройств за 2к и все на мониторинге у людей, которые по каждому чиху заводят инциденты — желание проводить ренамберинг на них в очередной раз как-то улетучивается 8)
Ivan_83
06.07.2016 16:49«При такой маске подсеть ограничена IP адресами 10.220.198.1 — 10.220.199.254 и шлюз 10.220.192.1 лежит вне этого диапазона. Операционная система не должна разрешать присваивать адрес шлюза из другой сети. Это явный баг!»
Wicron: «Windows стабильно игнорит ситуации, когда шлюз оказывается за пределами, определенными маской....»
Вы ничего не понимаете в сетях!
Корявая маска реально баг.
Шлюз из другой подсети не баг а фича, притом вполне себе рабочая и нужная.
IP шлюза используется только для получения MAC шлюза/роутера, а маска только для определения диапазона адресов локальных хостов, для которых нужно делать ARP запрос, всё что за пределами маски уходит на мак шлюза и дальше это его проблемы.
При этом на шлюзе должен быть прописан маршрут до этого хоста индивидуально с привязкой к адаптеру либо на интерфейсе должна стоять широкая маска чтобы хост в неё попадал, иначе пакеты хосту от шлюза не будут приходить.
IP Unnumbered — маску ставят 255.255.255.255 (те всё слать шлюзу, совсем всё) — используется для экономии IP адресов, те чтобы не тратить 4 адреса на p2p связность.
Шлюз может иметь любой адрес кроме совсем уж экзотики вида 224/4, 0/32, 127/8, 255.255.255.255, и мож забыл чего то ещё.
Флуд вероятно возник из за того что маска коряво накладывалась на ip. Но лучще бы посмотреть что оно аскало чтобы не быть телепатом.Yoda33
06.07.2016 16:55-5Согласен почти со всем, но пользовательская ОС это не роутер. По моему мнению в ней всё должно быть однозначно.
Wicron
06.07.2016 16:55-4Чувак, ты явно в ударе, делать заключения аля «вы ничего не понимаете в сетях» на основании одного из высказываний. По моим сведениям, например Router OS для микротиков ведет себя иначе при такой ситуации.
trublast
06.07.2016 16:59Неужели не дает поставить шлюз вне пределов сети??? Нет под рукой микротика сейчас, чтобы проверить, но как-то не вертится в это берд.
Wicron
06.07.2016 17:18Дает поставить, но только какой результат? В Windows ядро маршрутизирует трафик в этом случае, микротик по-моему в таком случае игнорил это, можете проверить, я проверял на случаях, когд DHCP сервер выдавал шлюз за пределами, дозволенными маской.
Ivan_83
06.07.2016 17:54Router OS — это линукс подвергнутый издевательствам микротиковцев, они ещё те дебилы и ориентироваться на их поделие нельзя.
Обычные бытовые мыльницы на линухе вполне себе работают в таких условиях (в большинстве своём), как и винда.
линух, фря — тоже работают.
2 Yoda33:
Не однозначность у венды только в гуе, там где шлюз в той же рамочке что и IP и MASK.
2 Mendel:
Это вы думаете что ARP флуд это бага, а это вполне вероятно особенность работы той конфигурации которую задал юзер.
Скорее всего при такой маске у него куча IP хостов пыталась отрезолвится через ARP, полагая что они локальные раз (IP & mask) == mask, отсюда и столько арп запросов.Mendel
06.07.2016 23:58С какого перепугу УМЕНЬШЕНИЕ размера локальной сети (а ведь именно такая опечатка в маске привела к тому, что шлюз оказался за бортом) должна неправомерно УВЕЛИЧИТЬ количество хостов которые посчитали локальными? Вероятнее наоборот, что часть локальных узлов стали адресоваться через шлюз. Но так мы не объясним флуд.
Предложу более простой сценарий — винда сохраняет МАС только тех, кто в своей сети, справедливо предполагая, что остальных она будет искать только через шлюз. Ну а МАС шлюза она не сохраняет специально _ОШИБОЧНО_ считая, что он всегда из своей сети, а значит уже сохранен. В результате любой запрос за пределы своей сетки вызывает ARP.
У меня правда остается непонимание что за топология такая у которой есть шлюз (напомню, что мы говорим о сервисной сети для администрирования сетевого оборудования), и этот шлюз на один интерфейс отвечает на ARP, а на остальные пересылает его дальше. Но тут или я что-то не понял, или какая-то специфическая структура, или просто проморгали такую возможность. Ну или я не прав и есть другой сценарий.Ivan_83
07.07.2016 00:31Можно долго гадать.
Лучше смотреть в исходники или хотя бы дампы запросов.
ARP протокол простой, но реализуют его почему то часто с косяками.
Там в заголовке есть тип л2, размер л2 адреса, тип л3, размер л3 адреса.
Вот на размер часто не смотрят совсем, попросту игнорируя. А во фре до 2011-12 года размер в запросе не проверяли но использовали при генерации ответа, в итоге кроме ип и мака в пакет копировалось всё (ещё 248+) байт что шло в памяти после. Пофиксили по тихому.
Помню какой то дешманский управляемый длинк не проверял размера, он единственный кто откликался на arp-scan когда был указан неправильный размер но сам пакет сформирован правильно.Mendel
07.07.2016 13:01Ну я диагноз по фотографии ставить не собирался. Я лишь сказал о том, что ваш диагноз по фотографии неверен, а свой привел лишь для иллюстрации того почему неверен ваш.
Mendel
06.07.2016 17:29Плохо не то, что винда позволяет шлюз за пределами маски. Плохо то, что она при этом создает флуд, но не запрещает.
Запретила бы, мол не делай такой шлюз, все бы подстроились, это ж Винда)
Разрешала бы, и не спамила — все было бы тоже ок.
Но разрешать и бажить — плохо.
agpecam
08.07.2016 18:00>IP Unnumbered — маску ставят 255.255.255.255 (те всё слать шлюзу, совсем всё)
Скажу больше, если оборудование поддерживает маску 0.0.0.0, то ему вообще не нужен шлюз ни в каком виде (при определенных усилиях, естественно). Оно будет считать, что все (совсем все) IP адреса находятся с ним в одной подсети и слать ARP запросы в поисках их MAC адресов. Достаточно завести в том же L2 сегменте хост-роутер с Proxy ARP, который будет отвечать на эти запросы и маршрутизировать трафик и, voila, эти железяки уже в интернете.
Конечно, это голая, но небезынтересная теория. Конечно никто не поддерживает маску /0 и конечно размеры ARP таблиц будут чудовищные))
KonstantinSamsonov
06.07.2016 21:02Странно 2016 год, а коммутатор без блокировки ARP storm, обычно глючная карта даунит интерфейс как только широковещалка насчитает 300-500 пакетов в секунду. 5 минут перерыв и интерфейс поднимается 3-5 попыток и даунится интерфейс до операторского вмешательства… ну ладно мож просто не включили. но и в sys log наверняка много интересного упало… хотя я сам когда его смотрел последний раз… Да и втыкать что-то в производственное оборудование как-то не гуд, нет что ли постоянного терминального сервака для настройки обязательно физический доступ к стойке в машинном зале? Разве только с фигой в кармане…
Mystray
07.07.2016 12:06Так судя по всему флуд на коммутаторы доступа прилетал из ядра сети (одмины же, имеют возможность), то есть с аплинкового порта. Включать шторм-контрол на аплинке — не лучшая идея.
Shaz
06.07.2016 22:52+4А с каких пор кривые руки\невнимательность стали багами ОС?
Так-то в этих ваших линуксах можно и похлеще натворить, особенно не проверяя что ты там по настраивал.
Bokrenok
07.07.2016 09:47+1Учительница детям:
— Я уже который раз объясняю, что половина не может быть большей или меньшей! Половины — они одинаковые, на то они и половины!
Однако большая половина класса этого не понимает…
grajdanin
08.07.2016 12:37ip 10.220.198.111/23
GW 10.220.192.1/19
вполне рабочая конфигурация в отличие от
ip 10.220.198.111/23
GW 10.220.192.1/23
возможно у Вас просто неисправен интерфейс
RazorBlade
На Win7, при неправильно указанном адресе шлюза, вываливает предупреждение, но дает сохранить.Так что, ваш коллега, скорее всего не обратил внимание и просто нажал сохранить.
Yoda33
Тогда это не баг, а диверсия. Хотелось бы понять логику разработчиков, заложивших такую потенциальную бомбу.
Deosis
Бритва Хенлона. В данном случае просто не стали ставить дополнительную защиту от дурака.
А кто не читает предупреждения, тот сам себе злобный буратино.