throughtheether

External Data Representation

Representation

presentation

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

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

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

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

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

В чем может быть дело

Предполагаю, дело в неправильном значении MTU (точнее, MSS в TCP-сегментах). Оно может порождаться излишними настройками фаерволла (отбрасывает ICMP-пакеты "Fragmentation needed", из-за чего не работает определение минимального MTU на маршруте следования пакета, "Path MTU discovery"). Вот дающая представление статья.

и куда стоит копать

Разрешить в настройках фаерволла маршрутизатора прохождение пакетов ICMP "Fragmentation needed" (Type 3, Code 4). Если в настройках WAN-порта/модема есть опция "clamp MSS" - активировать ее. Если есть опция "set MSS" - установить (временно) значение около 1000. Пронаблюдать ситуацию.
Можно, если есть желание, задействовать wireshark. Для этого снять дамп трафика (в формате .pcap) при открытии проблемного сайта через браузер (только пароли свои не надо вводить) при подключении через маршрутизатор и при подключении напрямую. Выложить сюда.

Другой вариант - колхозное "решение безопасности" на маршрутизаторе - IDS, IPS, UTM и прочая. Вполне может быть, что устройство пытается искать сигнатуры в HTTP-трафике (хотя google, насколько мне известно, использует HTTPS даже на странице поиска), нагружая процессор. При использовании VPN такого трафика устройство не видит, ресурсы использует более рационально. Стоит проверить настройки безопасности.

Есть и другие варианты, но пока разумнее проверить актуальность вышеизложенных.

Поиск в ширину, как мне представляется, подойдет вполне.

Если я вас правильно понял, вам нужна реализация snmp-агента на python. Присмотритесь к такому варианту.

Как можно избежать потери пакетов на 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 и выше.

пропуская постоянный ток (зарядное устройство телефона - 4.2 В, 400 мА) через стекло оно разогреется?

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

Если нет, могли бы подсказать идеи для реализации этой затеи?

А в чем, собственно, идея? Что за стекло, зачем его греть?

Научиться принимать абсолютно сырой (Т.е. именно кривую) радиосигнал от WiFi точек. Причём желательно не только 2,4ггц, а диапазон, от 2,3 до 2,5 (минимум, желательно шире). И не просто принимать, а некоторым образом оцифровывать и обрабатывать (получать данные по фазе, спектру, скважности и т.д. и т.п. )

С какой целью? Я понимаю, что данные по спектру, (которые вы в некоторой степени можете получать при помощи трансиверов на 2,4 ггц за 30-50 долларов) могут пригодиться при общем анализе производительности сети (есть ли помехи и т.д.). Зачем вам данные по скважности? Зачем вам форма сигнала?

По поводу обработки вопросов нет.

Поискал... походу найти такой, чтоб частота дискретизации была выше или равна 2,5 Ггц не представляется возможным

Мне непонятно - почему, если правая граница интересующего вас спектра 2,5 гигагерц, вы говорите о частоте дискретизации в 2,5 гигагерц (гигасемплов в секунду)? Что вы там увидите? Вам нужна частота дискретизации 5 гигагерц минимум, это, как говорил поэт, классика, это знать надо.

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

Но бюджет ограничен.

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

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

UPD.

По поводу классики- Это смотря кому надо знать

Это, простите, один из столпов цифровой обработки сигналов. Как вы собираетесь дальше что-то делать, не понимая, насколько ваши семплы отражают реальный сигнал?

"Скакой целью?"-ответ на данный вопрос находится в области понятия "Комерческая тайна".

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

Ознакомился. Не то. Скажем так, более чем избыточный функционал.

Ну вот опять. Я вам сразу сообщил, что для того, чтобы получить "кривую сигнала" вам нужно дорогое оборудование с соответствующей частотой дискретизации. При помощи переноса спектра вы можете получить примерно то же, но с шумами, более пологими фронтами и прочая, то есть с меньшим "количеством" информации. И вдруг выясняется, что для вас это избыточно, хотя информации из этого вы получите меньше, чем путем оцифровки изначального сигнала. Или вы обратили внимание на декодирование Bluetooth-данных? Так вас это делать никто не заставляет, суть в том, что, используя down-converter, можно принять сигнал вне полосы приемника.
Еще раз, какие данные вам нужны и зачем? Мне неинтересно это знать, вы сами себе ответьте, или попытайтесь хотя бы. Без точного представления, что именно вам нужно, вряд ли у вас выйдет что-то путное.

А за ссыль на DIY вариант Wi-Spy спасибо.

Мне нужен только приёмник который позволит на требуемой частоте завести оцифрованный сигнал в ЭВМ

Да пожалуйста, вот вам еще ссылки: USRP (дочерние карты выберете, исходя из потребностей), HackRF, BladeRF. Вообще, приглядитесь к SDR (software-defined radio) - оборудованию. Самый доступный пример - RTL-SDR.

Сразу отмечу, я невеликий специалист в сетевой подсистеме 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-трафик с рандомизированными адресами источника и назначения, портами источника и назначения. Если в этом случае трафик распределится примерно равномерно, то все работает штатно.