throughtheether

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

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

Суть вопроса: почему роутер сходил с ума?

Если предположить, что дело все-таки в широковещательном трафике, его источник логичнее всего искать в вашей локальной сети. Если у вас между WAN- и LAN- портами устройства была настроена маршрутизация, то широковещательный пакет с WAN- порта не должен быть перенаправлен на LAN-порты. Один из вариантов, у вас в локальной сети возникала L2-петля. Возможности для возникновения петли: бриджинг на сервере, бриджинг в IP-телефоне, бриджинг между LAN и WLAN на клиентском устройстве, если WiFi-точка доступа также настроена в режиме моста (бриджинга).

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

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

Существует ли в спецификации Ethernet какое-нибудь обязательное оповещение со стороны сетевой карты после появления физического соединения?

Честно говоря, не знаю, потому как не читал спецификации на 802.1D (MAC bridges) или 802.3 целиком ни разу. Думаю, нет. Коммутатор (точнее, раз уж речь зашла о спецификациях, мост) может определить состояние физического линка при помощи L1-сигнализации (FLP и прочая).

Или коммутатор получит информацию о MAC-адресе только после отправки первого пакета?

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

Это все верно для случая IPv4-over-Ethernet, в случае IPv6-over-Ethernet все аналогично, с другими протоколами поверх Ethernet (даже не знаю что предположить, IPX?) я не работал.

Как переустановить JunOS?

Вы уверены, что это необходимо? Вы пробовали проводить более глубокую диагностику, нежели наблюдение цвета светодиода? Есть, например, команды:

show chassis alarms
show system alarms

Если все-таки решились, то лучший вариант, я думаю - при помощи usb-носителя. См. документ по ссылке. Проводил такую операцию с EX8200, всем доволен.

Где взять образ?

Если есть контракт на устройство - задайте этот вопрос JTAC. Если у вас есть доступ на сайт Juniper - то с него. Если вы знаете текущую версию JunOS и подозреваете, что файл образа на устройстве испортился - найдите рабочий образ необходимой версии.

Мне представляются следующие варианты.
Switchport protected на 2960 как вегетарианская замена private vlans.
Если хосты общаются между собой при помощи протоколов поверх IP, то можно подумать насчет proxy arp на устройстве, маршрутизирующем данный влан (3750).
Самый тоталитарный вариант - VLAN ACL (mac access-list, vlan access-map) на 2960. Разрешить трафик к хосту только от default gateway (учитывая FHRP, если у вас что-то подобное настроено).

Думал сделать route map, и пакеты в null направлять, а теперь задумался, проходят-ли пакеты внутри влана через интерфейс влана на котором роут мап будет?

Пакеты (фреймы) могут скоммутироваться от источника до адресата уже на уровне access, где, я предполагаю, L3-интерфейсов для этого влана нет.

Возникла необходимость запретить трафику ходить из vlan2 в vlan, но из vlan во vlan 2 доступ должен остаться прежним, т.е. полным.

Необходимо понимать, что ACL в данном случае (Catalyst 3750) - это пакетный фильтр без отслеживания состояния. Соответственно, он может только разрешать/запрещать перенаправлять пакеты от одного интерфейса к другому. Если вы уверены, что именно это вам и нужно, и если маршрутизацией занимается 3750, то вам следует:
1) создать ACL:

ip access-list extended deny_vlan2_to_vlanX
 deny ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
 permit ip any any

2) завесить ACL:

interface vlanX
ip access-group deny_vlan2_to_vlanX out

3) пронаблюдать результат.

Знаю, что это как-то запрещается и разрешается на уровне ACL, но никак не могу настроить, в основном трафик вообще пропадает.

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

ip access-list extended deny_vlan2_to_vlanX_variant2
 permit tcp 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255 established
 deny ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
 permit ip any any

Этот ACL завесить на тот же интерфейс vlanX таким же образом, что и в предыдущем случае.

Буквой X везде отмечен ваш таинственный влан с префиксом 10.0.1.0/24 (который не 2).

External Data Representation

Representation

presentation

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

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

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

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

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

Замечая разницу между общим количеством "дропов" на интерфейсе 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, насколько мне известно, среди маркетинговой хохломы есть и полезные сведения.