throughtheether

Насколько мне известно, экзамен CCNA недавно был обновлен. Однако прочитать книгу, думаю, будет весьма полезно.

Слышал (но не использовал) про YANG/NETCONF. Посмотрите, может, вам подойдет.

Проверьте настройки безопасности на роутерах (иногда это называется application layer gateway, ALG).
Проверьте правильность подключения (wan-порт роутера 2 подключен в lan-порт роутера 1).
Проверьте адресацию.

Топология сети какова? Какие устройства (коммутаторы, маршрутизаторы) находятся между ноутбуком и МФУ? Если в печати/traceroute указывать имя принтера (если используется), а не IPv4-адрес (я думаю, у вас именно IPv4) - каковы результаты?

Попробуйте деактивировать все "решения безопасности" на пути между устройствами (брандмауэр windows, возможные настройки маршрутизатора) и пронаблюдайте за ситуацией.

Доступным остаётся от 10 минут до трёх дней, потом надо опять повторить, перезагрузка принтера не помогает, перезагрузка ноутбука тоже (для чистоты эксперимента ноут подключался как кабелем, так и по wi-fi, так же переустанавливалась ОС).

Есть подозрение на проблему с адресацией, проверьте уникальность MAC- и IPv4-адресов на устройствах.

Попробовал запрос сайта curlом сделать в резте получаю хтмл сайта провайдера и так при обращении к любому внешнему сайту.

В чем может быть проблема?

Доступ в интернет оплачен?

Что я уже сделал:
...
2. Отключил Ipv6

Что это значит? Где отключили? На каждой рабочей станции в сети?

все статистики отличные (top,iostat,ifstat,ifconfig,sar) - нигде нет пределов.

На портах коммутаторов показатели смотрели? Количество отброшенных пакетов, размеры очередей?

в чем может быть проблема или как продиагностировать?

Как вариант, пики широковещательного/многоадресного трафика. Диагностировать при помощи снятия соответствующих данных с портов коммутаторов или при помощи анализа трафика.

И при этом выключить сервер, то флуд перерастает в Unicast-флуд и распространяется на все виртуальные интерфейсы на сервере, в некоторых случаях на весь vlan,

Если я вас правильно понял, подразумевается unknown unicast flood.

Ваш хост имеет адрес 109.XX.XX.XX.53? Какой именно трафик распространяется на весь влан - подобный указанному в дампе или, может быть, arp-запросы?

Я с libvirt не работал, но мысли касательно вашей ситуации такие. Есть некий маршрутизатор (устройство или виртуальная сущность), на котором активен IP-адрес из одного префикса ("подсети") с 109.XX.XX.XX.53. На нем есть arp-таблица, где IPv4-адресу 109.XX.XX.XX.53 соответствует некий MAC-адрес aaaa-bbbb-cccc (подразумевается использование ethernet). На (виртуальном) коммутаторе/бридже этому MAC-адресу соответствует некий виртуальный интерфейс.
Когда вы хост выключаете, возможны два варианта:
1) в таблице коммутатора исчезает запись, ставящая в соответствие MAC-адресу aaaa-bbbb-cccc некий виртуальный интерфейс. В таком случае будет наблюдаться unknown unicast flood, а именно трафик, подобный указанному на приведенном вами дампе, будет направляться во все интерфейсы коммутатора (хотя, могут быть нюансы, связанные с виртуализацией). Для решения проблемы вы можете или задать статическое соответствие MAC-адреса aaaa-bbbb-cccc нужному интерфейсу, или, если есть такая возможность, зафильтровать трафик, предназначенный для хоста с MAC-адресом aaaa-bbbb-cccc на время, пока соответствующий сервер неактивен, или фильтровать трафик на 109.XX.XX.XX.53 на вышестоящем оборудовании
2) в arp-таблице маршрутизатора исчезает запись, ставящая в соответствие IPv4-адресу 109.XX.XX.XX.53 MAC-адрес aaaa-bbbb-cccc. В таком случае маршрутизатор будет слать некоторое количество широковещательных arp-запросов. Количественные характеристики зависят от реализации, как именно это сделано в libvirt, трудно предполагать.

Что можно сделать со стороны активного оборудования, чтобы избежать подобных проблем в автоматическом режиме?

Не понимаю вашего фокуса именно на активном оборудовании. На мой взгляд, конструктивнее сначала попытаться решить проблему на уровне виртуализации. Представляется, что среда виртуализации предоставляет более удобные инструменты для автоматизации (т.е. различные скрипты и/или API). Если вышеописанное (установку статической записи в таблицу соответствия MAC-адрес <-> интерфейс коммутатора; установку фильтрующей записи в ту же таблицу, см. cisco-аналог mac address-table static MACADDRESS vlan VLANID drop; фильтрацию на основе L3-данных) не получится реализовать на сервере виртуализации, можно попытаться фильтровать трафик до 109.XX.XX.XX.53 на вышестоящем оборудовании, но сомневаюсь, что это можно будет удобно автоматизировать.

Дальнейшие советы, не зная топологию сети, давать затруднительно.

UPD:

В примере, имелось ввиду, что 109.XX.XX.XX - это IP, 53 это порт,

Извините, проглядел. Вот именно поэтому я не люблю вывод tcpdump и предпочитаю оперировать дампом в виде pcap-файлов.

Я наблюдаю две проблемы:
1) мусорный трафик на один из ваших хостов
2) флуд (умножение) этого трафика на все ваши виртуальные сервера

Касательно первой проблемы есть вопросы. Как вы используете DNS-сервер? Как фильтруется доступ к нему? Если никак, то почему? Разрешены ли рекурсивные запросы? Если да, то желательно заблокировать их обработку, кроме того случая, когда вы точно знаете, что именно делаете. Я подозреваю, в данном случае имеет место попытка атаки 94.41.XX.XX при помощи вашего сервера (dns reflection attack, точнее можно будет сказать, если вы предоставите дамп трафика в формате .pcap, tcpdump -i -s 65535 -w ). Если гипотеза окажется верна, то есть вероятность, что такой мусорный трафик прекратится через некоторое время после того, как вы выключите обработку рекурсивных запросов.
Вообще говоря, я бы на вашем месте запретил бы весь трафик, кроме трафика вашего сервиса и управленческого (ssh, snmp и т.д.) трафика при помощи списков доступа (ACL) на активном оборудовании (на ближайших к вашему оборудованию L3-устройствах, скорее всего их два)

Теперь по второй проблеме.

сетевые инженеры Дата-центра говорят, что установили настройку для влана и свичей в ДЦ "mac-address-table aging-time = 14400"

Именно это, на мой взгляд, и вносит наиболее весомый вклад в проблему. При выключении вашего сервера коммутатор ДЦ еще 4 часа будет слать вам адресованный серверу трафик. Значение 14400 выбрано, скорее всего, с целью избежать проблем рассогласованности arp-таблицы и таблицы MAC-адресов при импользовании ECMP и FHRP (довольно распространенная проблема в ДЦ-окружении). Именно такое значение по умолчанию имеет срок жизни arp-записи в устройствах cisco, если мне не изменяет память.
Одно из возможных решений - снижение срока жизни записи таблицы MAC-адресов. Это возможно, если в ДЦ вам предоставлен отдельный коммутатор или если вам предоставлен отдельный влан (частая схема в ДЦ), и при этом оборудование ДЦ поддерживает изменение срока жизни записи таблицы MAC-адресов в зависимости от влана (cisco catalyst, если не ошибаюсь, это могут, в зависимости от версии IOS).
Второй вариант - при выключении виртуального сервера автоматически создавать соответствующее правило ebtables или статическую запись в таблице MAC-адресов виртуального бриджа, запрещающее трафик до него (думаю, в той или иной степени это реализуемо). Третий вариант - удаление записи таблицы MAC-адресов коммутатора ДЦ по запросу через какой-либо API на данный момент предстает малореальным. Кроме того, можно подумать о реорганизации схемы подключения вашего сервера к оборудованию провайдера с использованием двух L3-линков. В таком случае на вас не влияют L2-настройки оборудования ДЦ (сроки жизни записей arp-таблицы, таблицы mac-адресов), и ваш маршрутизатор (виртуальный) будет отбрасывать трафик до хоста, для которого нет ARP-записи (т.е. для выключенного).

Вы писали касательно описанного мною выше варианта:

Ситуацию спасает просьба о блокировке атакуемого IP на активном оборудовании, либо можно при помощи ebtables запретить форвардинг пакетов на атакуемый ip-адрес, тогда трафик будет идти просто на основной интерфейс физического сервера, не затрагивая виртуальные сервера. Оба варианта не являются выходом поскольку требуют постоянного присутствия как сетевых инженеров в ДЦ, так и приносят проблемы на физическом сервере, потому и хотелось бы узнать возможно ли в автоматическом режиме со стороны сетевого оборудования избегать таких проблем.

Я пока не понял, к каким проблемам на физическом сервере приводит фильтрация трафика при помощи ebtables. Необходимо понимать, что либо этот трафик (вредоносный, мусорный) каким-то образом фильтрует ДЦ (для этого он сначала должен по каким-то критериям этот злонамеренный трафик выявить, и не факт что его критерии совпадут с вашими), скорее всего за дополнительные деньги (услуга anti-DDoS), либо этот трафик доходит до оборудования под вашим управлением, и тогда уже вы его фильтруете так, как сочтете необходимым.

Резюмируя, на вашем месте я бы:
1) разобрался с трафиком, приведенным в дампе, с настройками DNS-сервера
2) разрешил бы только необходимый для работы проекта трафик при помощи ACL на оборудовании ДЦ
3) настроил бы внятный мониторинг вашего сервера
Практически уверен, что после реализации пп. 1), 2) наблюдаемая проблема бы исчезла. Даже если нет - варианты я привел (изменение L2-настроек оборудования ДЦ, изменение схемы подключения)

UPD2:

Фильтровать никакой трафик нельзя потому, что это не наш трафик, а трафик в сторону клиента, который арендовал VDS. По этой же причине, кого-то блокировать нельзя для входящих пакетов,

Не понимаю, почему нельзя фильтровать клиентский трафик. Так делают практически все. Когда на сервер, арендуемый за 100 долларов в месяц, приходит 10 гигабит/c трафика и больше, как правило, трафик до него блокируется по той простой причине, что расходы на трафик превышают доходы от клиента. Кроме того, часто такой трафик угрожает самой инфраструктуре. Вы задали вопрос касательно анти-DDoS. Что это, если не фильтрация трафика?

Далее, думаю, вам стоит переделать схему аплинка, это наиболее простое и потенциально эффективное решение. Так, чтобы сервер был подключен к маршрутизатору L3-интерфейсом и затем маршрутизировал (а не бриджил) трафик до клиента. Я представляю себе, как бы это выглядело в случае с L3-коммутатором, но тут наверняка проявятся неизвестные мне нюансы реализации поддержки сети в Linux. Рекомендую схему перед применением досконально протестировать.

есть ли где-нибудь в интернетах какие-нибудь сводные таблицы, может быть полученные эксперементальным путем, в которых четко указано значение уровня доступности

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

Касательно отдельных устройств, иногда в информлистах (datasheet) к ним указывают значение среднего времени наработки на отказ (mean time between failure, MTBF). Пример, таблица 2, последняя строка.

Можно дать следующую оценку доступности:
Availability=100%*MTBF/(MTBF+MTTR),
где MTTR (mean time to restore) - среднее время приведения отказавшего устройства в рабочее состояние. Но повторюсь, более конструктивным подходом считаю оценку работы всей системы в комплексе.

Есть небольшая сеть (10-15 машин). Один из них, видеосервер, широковещательно очень сильно флудит.

Что это значит? В чем это проявляется? Мигают светодиоды на коммутаторах? Нарушается работоспособность сети? Почему вы считаете, что речь идет о широковещательном "шторме"?

В чём может быть проблема

Какая проблема? Опишите конкретнее.
Вообще говоря, в случае использования неуправляемых (что, как правило, автоматически означает отсутствие "интеллектуальных" нюансов вроде igmp snooping) многоадресный (мультикаст) трафик обрабатывается так же, как и широковещательный (броадкаст). Поэтому стоит задуматься о применении управляемых коммутаторов (хотя точнее можно будет советовать, получив дамп трафика и схему сети). Решить проблему "чрезмерного" многоадресного трафика (исходящего на порты, не нуждающиеся в нем) при помощи управляемых коммутаторов можно при помощи:
1) igmp snooping + igmp [snooping] querier
2) статической записи igmp snooping
3) статической записи мультикастового MAC-адреса, соответствующего мультикастовой группе.
Наиболее простой, понятный и рекомендуемый вариант - первый.

и как её быстро обнаружить?

Подсоединяете ноутбук/компьютер в свободный порт коммутатора. Запускаете wireshark/tshark/tcpdump, сохраняете дамп трафика, анализируете его (например, в wireshark - Statistics -> Endpoints), делаете выводы.

Как найти петлю в локальной сети?

неуправляемые коммутаторы,

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

Но всё же обнаружил, что при включениии проблемной сети Packet Snifer начинает детектировать адреса ipv6 в сети, при чём некоторые адреса какие-то неполные.

Пример (адреса, дампа трафика) приведите, пожалуйста.

Что, придётся таки идти и дёргать провода последовательно?

Да, придется.

Вероятно "сдурел" один из свичей?

Возможно, но, чтобы это подтвердить, придется "идти и дёргать провода последовательно".

Я думаю, уже понятно, что стоит задуматься о приобретении нормальных (управляемых) коммутаторов? Они стоят-то, около 3000 за 16 портов (пример). До тех пор можете попытаться свести нестабильность сети к минимуму, ограничив широковещательные/многоадресные пакеты, запретив чужие DHCP-сервера на центральном маршрутизаторе (как я понял, обе эти задачи на Mikrotik, хоть и с использованием творческого подхода, но решаемы)

Для автосерфинга нужно размножить IPv4 адреса.

С какой целью?

Но проблема в том, что IP сам по себе характеризует не устройство, а соединение в целом.

Я с вами не согласен, или я вас не вполне понял. О каком "соединении" идет речь?

Возможно есть какие-то другие предложения по автосерфингу, или иже с ними приработками?

Если под автосерфингом подразумевается накрутка просмотров веб-страниц, то вам, вероятно, помогут прокси и автоматизация при помощи различных скриптов (например, PhantomJS).

То есть можно ли Token Ring отнести к классу сетевых протоколов?

Да.

технологии или протоколы?

Технология - это описание (логос) какого-то умения (технос). Технология описывает, как именно мы что-то делаем.

Протокол [передачи данных] - набор договоренностей, задающих некий процесс [передачи данных].

Часто эти понятия взаимозаменяемы (протокол Ethernet, технология Ethernet). В целом, на мой взгляд, понятие "технология" более специфично. Например, есть протокол (семейство протоколов) Ethernet и технологии Metro Ethernet, Industrial Ethernet (контекстно-специфичные применения протокола Ethernet), построенные на его базе.

технически, при должным образом подготовленной инфраструктуре - да.

Имеется сервер мощный, но к нему ведется только один белый ipv4 адрес, идея поднять на нем виртаульные машины с белыми ipv6.

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

Если все же хочется поэкспериментировать с IPv6, то

Вот, собственно, и вопрос, если на одной из таких машин будет стоять сайт, будут ли иметь к нему доступ клиенты у которых только ipv4 адрес?

Думаю, нет. Чтобы IPv4-клиенты имели доступ к вашему IPv6-серверу, им (клиентам) будет необходимо воспользоваться неким IPv6-over-IPv4 решением, например, Teredo (в отличие от 6to4, Teredo инкапсулирует данные в UDP-датаграммы, тем самым упрощая взаимодействие с NAT, наличие которого у клиента вполне вероятно).

И как я смогу проверить коннект к такому виртуальному серверу, например, зайти по ssh, если у меня самого ipv4?

Так же, как и потенциальный клиент. Поднять соответствующий интерфейс (teredo), установить SSH-соединение, указав IPv6-адрес сервера.

В этом комментарии я предполагал, что у вашего хостера есть IPv6-связность (т.е. он анонсирует в интернет свои IPv6-префиксы). Если предположение неверно, то и на сервере придется использовать некое IPv6-over-IPv4 решение.

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

Я предполагаю, что в сети используется IPv4, инкапсулированный в Ethernet. В таком случае, на мой взгляд, сначала имеет смысл построить граф взаимодействия Ethernet-хостов (аналог в wireshark: statistics -> conversations -> ethernet). Затем, для каждого ethernet-хоста (определяемого unicast MAC-адресом) ставите в соответствие IPv4-адрес инкапсулированного IPv4-пакета (MAC-адресу источника ставите в соответствие IPv4-адрес источника, аналогично с адресами назначения). У вас получается вид топологии сети из точки, в которой происходил захват трафика. На мой взгляд, если нужна топология всей сети, то и трафик захватывать надо с каждого L2-домена.

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

Технически, я вижу следующие возможности:
1) ACL на сетевом оборудовании. Составляете список "российских" префиксов, транслируете в ACL, навешиваете на необходимый интерфейс. Плюсы: line-rate (или близкая к line-rate) производительность. Минусы: не всякое оборудование подойдет (размер TCAM и т.д.), возможные исключения (клиент жалуется, что он из России, а сайт не открывается) придется прописывать в ACL каждый раз (может быть не очень удобно). Стоит применять, если объем нежелательного трафика велик (флуд и прочая) и этот трафик реально влияет на производительность вашего сервера.
2) фильтрация на самом веб-сервере (модуль geoIP). Плюсы: больше гибкости. Минусы: производительность ограничена производительностью geoIP-базы.
3) комбинация пп. 1) и 2). Грубая фильтрация при помощи ACL, более гибкая - на самом веб-сервере.
4) самый простой - спрятаться за CDN-фронтэнд, предоставляющий подобную услугу.
Есть конечно более специфичные варианты, но вам, думаю, хватит и этих (а точнее, второго или четвертого).