throughtheether

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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'.

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

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

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

получается CCENT не обязателен для получения CCNA?

Да, необязателен. См. раздел prerequisites здесь. 'No prerequisites' означает, что получить сертификат можно сразу, без прохождения предыдущих ступеней.

Я не работал с 4500 специфично, но, судя по всему, вам надо на всех интерфейсах дать команду switchport. По умолчанию L2-порты (т.е. конфигурированные с командой switchport) должны работать в аксесс-режиме (без 802.1q-тегирования фреймов) во влане 1, так что "пинг" через коммутатор должен пройти нормально.

При использовании QinQ к уже тэгированному фрейму добавляется еще один тэг. Наиболее часто используется в провайдинге. Например, от клиента 1 все фреймы дополнительно помечаются тэгом 100, от клиента 2 - 200. Таким образом можно отличить фреймы во влане, например, 10, от первого (они будут тегированы 10 , затем 100) и второго (тегированы 10, затем 200) клиентов.

Private vlan используется, когда надо повлиять на 'видимость' хостов внутри влана. Пару раз видел у хостеров - есть, к примеру, /25 сеть и соответствующий влан, надо каждому хосту (один хост - это один клиентский сервер) разрешить видеть только default gateway и возможно служебный сервер для загрузки ОС. В таком случае порты, к которым подключены маршрутизатор и служебный сервер, работают в режиме promiscuous (в терминах private vlan, опять же), каждый клиентский порт - в режиме isolated (как участник isolated vlan). Двойного тэгирования здесь, как я понял, не происходит.

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