throughtheether

External Data Representation

Representation

presentation

Здесь подтверждение.

все-таки часто спрашивают:

Мне, например, трудно воспринимать как инженера с практическим опытом человека, который слишком серьезно относится к семиуровневой модели.

Это вообще можно определить по каким-то критериям

Зачем? Что это даст? XDR - протокол шестого уровня, и что из этого следует? Если цель - пройти собеседование, то проще выучить популярные варианты. Я думаю, что если очень долго всматриваться в это наследие 70х (семиуровневую модель), то, вероятно, некую логику можно узреть. Какое это имеет применение на практике, я не знаю. Я считаю, что современные стеки протоколов (HTTP over TCP over IPv4 over Ethernet) яснее описываются 4-уровневой моделью TCP/IP. Я, конечно, могу предположить, что в редких случаях (X-стек) модель OSI внятно отображает стек протоколов и дает какие-то важные следствия, применимые на практике. Жаль, я с такими случаями не встречался.

Как можно избежать потери пакетов на 188.254.44.34, Сибирьтелеком?

Зачем? По факту, хост 188.254.44.34 отбрасывает 90% пакетов, направленных ему. Если этот адрес завешан на интерфейсе устройства (маршрутизатора), то скорее всего, это результат действия Control plane policing - трафик, адресованный устройству, может попасть на обработку центральным процессором (а не оптимизированными микросхемами), поэтому при большом объеме трафика возможен DoS (denial of service) в том или ином проявлении, поэтому такой трафик ограничивается. Если бы проблемы наблюдались на линке между 188.254.44.34 и mail.ru, то хосту mail.ru соответствовал такой же или больший процент отброшенных пакетов. Этого не наблюдается.

Погуглил - люди по всей России жалуются на этот ip еще с мая месяца

И что? В общем случае наблюдаемые вами "потери" не имеют отношения к низкой производительности доступа в интернет. Информации, позволяющей указать на устройство с адресом 188.254.44.34 как на источник ваших проблем, я не наблюдаю.

Подскажите, что можно предпринять?

Я бы порекомендовал разобраться, что означает (в реальности, данной нам в ощущениях, сегментах, пакетах и фреймах) "начал тормозить интернет". Страница медленно загружается? Что это значит (тут поможет водопадная диаграмма загрузки, waterfall diagram, во многих современных браузерах присутствует, насколько я знаю)? Доменное имя медленно разрешается? Неоптимальная работа TCP (здесь поможет wireshark и представления о работе TCP)? Или проблема в компьютере (трояны и прочая)?

Наши в узле связи отмахнулись, не желая разбираться

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

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

Замечая разницу между общим количеством "дропов" на интерфейсе bond0:

bond0     Link encap:Ethernet  HWaddr 00:15:17:D6:B0:14
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:9381 errors:0 dropped:6123 overruns:0 frame:0

и количеством "дропов" на интерфейсе, обрабатывающем трафик влана 3:

bond0.3  Link encap:Ethernet  HWaddr 00:15:17:D6:B0:14
          inet addr:192.168.32.7  Bcast:192.168.32.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1561 errors:0 dropped:146 overruns:0 frame:0

предполагаю:
1) как уже отмечено, скорее всего приходит немаркированный трафик (по умолчанию, native vlan на оборудовании cisco имеет номер 1, в нем пересылается служебный трафик вроде CDP и прочая)
2) также вероятно, на сервер приходит трафик в виде фреймов, маркированных (тегированных) 2 вланом. Со стороны коммутатора он разрешен, а на сервере вы его, как я понял, не обрабатываете
Как возможное решение - назначение неиспользуемого влана в качестве native vlan на стороне коммутатора, разрешение только нужных вланов на транке со стороны коммутатора (влан 3 вы используете, влан 2, предположительно, не нужен).
Наличие "дропов" на интерфейсе bond0.3, к сожалению, объяснить не могу. Вероятно, это какие-то отброшенные пакеты вроде ненужного (непрослушиваемого) мультикаста.

На всякий случай, предоставьте, пожалуйста, вывод
ethtool eth0
ethtool eth1

UPD:
Я попросил предоставить вывод ethtool, чтобы удостовериться в корректном режиме портов (1000Mbps, full duplex). На самом деле, о корректном режиме работы портов говорит отсутствие коллизий и crc-ошибок, но чем больше данных - тем лучше в подобных случаях.

Native VLAN не используется, отдаю в PortChanell только 2 вышеупомянутых VLAN'а.

Предоставьте, пожалуйста, вывод с коммутатора
show interface Port-channel6 switchport Если все-таки выяснится, что на интерфейсе Po6 native vlan установлен в 1, по посмотрите на коммутаторе

show cdp
show cdp interface GigabitEthernet1/3
show cdp interface GigabitEthernet1/39

Как думаете, может это как-то связано с ядром?

К сожалению, я недостаточно владею особенностями работы ядра Linux, чтобы ответить на этот вопрос. Могу лишь предложить использовать tcpdump на интерфейсе bond0.3. Необходимо иметь в виду, что пакет, "дропнутый" ядром, может появиться, а может и не появиться в дампе трафика, в зависимости от причины "дропа". Но вполне может быть, чтоб вы увидите чужой мультикаст, например (OSPF Hello с другого конца L2-домена как вариант). Я хочу сказать, что это может быть связано с ядром, а может - и с обстановкой в сети.

UPD2:

Здесь видно, что все-таки native vlan 1 присутствует, упорно гуглил, но так и не понял как убрать эти параметры из конфигурации..

Создайте новый (ранее неиспользуемый) влан на коммутаторе и назначьте его в качестве native, но только на этот интерфейс. Пример:

configure terminal
interface Port-channel6
switchport trunk native vlan XXXX

, XXXX-номер влана.

Еще хотелось бы поделиться наблюдением:

eth0      Link encap:Ethernet  HWaddr 00:15:17:D6:B0:14
          TX packets:104 errors:0 dropped:0 overruns:0 carrier:0
          
eth1      Link encap:Ethernet  HWaddr 00:15:17:D6:B0:14
          TX packets:1141 errors:0 dropped:0 overruns:0 carrier:0

Как следует из этого листинга, объем исходящего трафик с интерфейса eth1 на порядок превосходит объем трафика с интерфейса eth0. Конечно, с такими незначительными показателями торопиться с выводами не стоит, но я вам настоятельно рекомендую проверить схему с объемом трафика более гигабита. У меня есть подозрение, что, в случае, если потребители трафика находятся в другом L2-сегменте (т.е. трафик до них маршрутизируется через default gateway), то производительность может упереться в 1 Гбит/c. Если подобная ситуация будет наблюдаться, обратите внимание на строчку

# cat ./ifcfg-bond0
BONDING_OPTS="debug=1 mode=802.3ad miimon=100 xmit_hash_policy=layer2 lacp_rate=1"

Вероятно, потребуется сменить алгоритм хэширования на более чувствительный к деталям. Но об этом имеет смысл задумываться, имея результаты тестирования с нагрузкой в 1 Гбит/c и выше.

Сразу отмечу, я невеликий специалист в сетевой подсистеме Linux. Я исхожу из следующих положений:
1) у вас, судя по всему, реализована схема Equal cost multi-path.
2) я предполагаю, что сетевую подсистему Linux реализовывали разумные люди, поэтому выбор исходящего маршрута производится per-flow, т.е. для каждого 'потока' данных ('поток' характеризуется IP-адресами источника назначения, типом протокола (IP protocol number), портами источника и назначения)

Почему при балансировке нагрузки через один шлюз идет больше трафика, чем через другой?

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

В вашем случае, скорее всего, трафик разделяется (load sharing) на основании того, к какому flow он принадлежит. Соответственно, повышенная утилизация одного из линков говорит о том, что есть flow высокой интенсивности (Elephant flow), т.е. большое количество пакетов имеет один и тот же хэш и направляется в один и тот же линк. Также могут быть нюансы с разделением трафика, порожденного самим хостом. Ну и всегда есть вероятность багов в ПО.

Куда копать?

Чтобы удостовериться правильности гипотезы, вы можете снять дамп трафика (в точке до разделения на линки) и изучить его при помощи wireshark (Statitics -> Conversations -> вкладки TCP, UDP, две правые колонки в bps). Если гипотеза верна, вы обнаружите пару сокетов, утилизирующих значительную долю пропускной способности линка.

Я также исходил из того, что вы показали актуальные настройки и у вас ровно два маршрута по умолчанию. Если вдруг затесался еще один, с тем же весом (с той же метрикой), то даже в идеальном случае разделение будет, скорее всего 1:1:2. Это обусловлено особенностями реализации ECMP.

TL;DR: Это не балансировка, это разделение трафика. Идеального разделения трафика пополам в общем случае добиться крайне затруднительно.

UPD:

Сейчас машина стоит на тестовом стенде. Здесь нет вообще никакого трафика, кроме двух пингов, запускающихся для теста.

Приведите, пожалуйтса, точные команды, которые вы запускаете. Уточните, запускаете ли вы их на самом сервере-маршрутизаторе с длвумя линками или на сторонней машине. Цели для пингов - отвечают ли они на пинги. Каковы точные количественные характеристики трафика на линках (интерфейс такой-то, столько-то входящего, столько-то исходящего), как вы его меряете (среднее значение за 1,5,10 минут)

Но даже без этих данных можно сказать, что ваш тест не вполне корректен. Per-flow хэширование оптимизировано под UDP и TCP трафик. Поэтому, рекомендую вам на машине за интерфейсов eth0 (и корректно прописанным default gateway) сгенерировать при помощи hping UDP-трафик с рандомизированными адресами источника и назначения, портами источника и назначения. Если в этом случае трафик распределится примерно равномерно, то все работает штатно.

Связь между отделами должна осуществляться или с помощью шлюза, или мостов.

Это промышленная сеть или предмет курсовой работы? Меня использование термина "мост" немного удивило.

Составленная схема правильная?

Если цель схемы - отобразить физическую топологию, то примерно да.

и какое оборудование использовать?

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

И посоветуйте, пожалуйста, гайды по проектированию таких сетей.

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

Возможна ли DoS/DDoS атака на устойство слушающее SPAN-порт?

Атака возможна на что угодно. Другой вопрос, насколько эффективна она будет.

Возможно ли вообще в принципе завалить SPAN порт трафиком так чтобы устройство перестало с ним справляться?

Без уточнения, о каком устройстве идет речь, ответ дать трудно. В общем, если вы подключились в гигабитный порт, и устройство обработает 1.5 миллиона фреймов в секунду, то есть надежда на устойчивую его работу.

На сколько я понимаю технологию зеркалирования вопрос перегрузки SPAN-порта трафиком (и как следствие любого устройства подключенного к нему) вообще не имеет смысла

SPAN-порт (в роли destination) не сможет пропустить трафика больше, чем физически возможно (этот предел задан скоростью среды и размерами буферов). Пример - вы копируете трафик с 3 портов (каждый загружен на 400 Мбит/с в среднем) в один гигабитный (1000 Мбит/с) порт. Примерно одну шестую трафика (3*400 Мбит/с - 1000 Мбит/с =200 Мбит/с) вы будете терять.

т.к. зеркалить можно только заранее аппаратно-определенный поток или вообще только один какой-то порт.

Как правило, копировать трафик можно с порта (иногда с фильтрацией по вланам), группы портов, из влана - в другой порт.

Тогда в чем смысл вообще, если мы что-то важное можем пропустить?

Часто, например, через SPAN мониторят трафик, приходящий на процессор. Увеличение объема такого трафика, как правило, ничего радостного не сулит.

Как мы тогда можем весь трафик видеть который идет через свич?

Если бы я сейчас реализовывал подобный проект (т.е. необходимо видеть "весь" трафик), я бы обратил внимание на продукцию Gigamon (если много денег) или бы поэкспериментировал с пассивными оптическими разветвителями (логично их устанавливать на линки с интересующим нас трафиком).

Вкратце, неясно, какую задачу вы пытаетесь решать. Если вы ее опишете, можно будет говорить более конкретно.

у меня есть сеть и я ставлю чтоб трафик считал только с 111.0.0.0/255.0.0.0

Я немного не понял используемую вами нотацию. Обычно используют или A.B.C.D/n, где n - длина префикса (число от 0 до 32), либо A.B.C.D M.M.M.M, где M.M.M.M - битовая маска (32 бита, 4 десятичных числа через точку, пример 255.255.255.0). Проясните этот момент, пожалуйста.

В любом случае, вот примерный список префиксов. Получен вычитанием префиксов rfc1918, префиксов 0/8 и 127/8 из пространства юникаст-адресов.

0) Представим, необходимо передать данные между компьютерами 1 и 2. Никаких Ethernet и IP еще не придумали, допустим. Есть провода, оптоволокно, соответствующие трансиверы. Что делать? (семиуровневая модель и почему это не священная корова, мультиплексирование, инкапсуляция)

1) Коммутация. Как происходит обработка (перенаправление) трафика коммутатором? Допустим, пришел фрейм с таким-то адресом источника и таким-то адресом назначения - что происходит? Что и почему произойдет, если два 'деревянных' (без STP и прочих излишеств) коммутатора соединить двумя линками? Как с этим бороться (STP, в чем минусы)?

2) Статическая маршрутизация IPv4. Зачем вообще нужен IP, когда есть Ethernet или Serial интерфейсы (хотя, по-моему, IP появился раньше, чем Ethernet, но вопрос имеет определенный смысл, пересекается с пунктом 0)? Допустим, на маршрутизатор приходит пакет (точнее, Ethernet-фрейм, а в нем IP-пакет). Что дальше происходит? Чем концептуально отличается перенаправление пакетов на 3 и 2 уровнях ЭМВОС? Почему l2-петля (в случае Ethernet) это скрежет зубовнай, а L3-петля не так страшна? Чем концептульно отличаются IPv4-адреса от MAC-адресов?

3) Как заставить работать вместе Ethernet и IP (это про ARP)?

4) Нарисуйте топологию вида "маршрутизатор на палочке", где маршрутизатор маршрутизирует трафик между двумя вланами. К нему транком подключен коммутатор, к коммутатору - два хоста в разных вланах. Один хост шлет icmp echo запрос другому ('пингует'). Что происходит на каждом устройстве? Какие адреса (IP, MAC) используются в заголовках пакетов и фреймов на разных этапах? Каково содержимое таблиц маршрутизации, коммутации, ARP-таблиц?

5) Уже после четкого освоения вышеописанного: безопасность (ACL, фаерволлы), туннели (зачем нужны, в чем минусы), NAT (зачем нужен, в чем минусы). Динамическая маршрутизация. Как устроен Интернет (и чем Интернет отличается от Worldwide web)

Из книг, Jeff Doyle, 'Routing TCP/IP', volume I, первые несколько глав. И есть неплохая книжка, на тему 'чего не сказали в курсе CCNA'.

Привел самые базовые вопросы. Разобравшись с ними, думаю, дальнейший вектор развития сами будете способны задать.

Это медиаконвертер. К вам приходит оптоволокно (желтый кабель), сигналы принимаются фототранзистором, восстанавливаются, перекодируются и передаются по витой паре. Аналогично в обратном направлении.
Работает, как правило, на первом уровне ЭМВОС, т.е. и на входе и на выходе - Ethernet-фреймы, только кодированные по-разному с учетом используемой среды (оптоволокно или витая пара)

1. Начать с изучения маршрутизации и коммутации, как основы всего.
2. Читаете книжку, выполняете лабы (на GNS3 или на реальном оборудовании). Непонятные моменты уточняете у коллег. Итеративно продолжаете до просветления. Сдаете экзамен.
3. Трудно прогнозировать. Лучше не торопиться, несколько месяцев на CCNA потратить, если вы начинающий сетевик.
4. Если у вас нет никаких сертификатов, то стоит начать с Cisco CCNA. У Juniper тоже интересная линейка (начинается с JNCIA-Junos), и экзамены дешевле.

Из книжек рекомендую Routing TCP/IP, первые несколько глав. По курсу CCNA, говорят, неплохие книжки Одома.

но хосты не пингуют друг друга.

А должны? Может, на хостах фаерволлы настроены (windows 7 как пример)? Записи в arp-таблицах хостов создаются корректно?

может я что-то забыл?

Применить настройки (commit) не забыли? Что показывают команды:

show vlans extensive
show interface ge-0/1/0
show interface ge-0/0/3
show interface ge-0/0/4
show interface ge-0/0/5

И схему подключения уточните, пожалуйста (какие интерфейсы используются, какие из них в режиме транка, какие в режиме доступа).