Ринат Гарипов

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

Дело в том, что на вакансию без указания ЗП приходит на порядок меньше кандидатов! Соответственно, закрывать вакансию придется дольше, ниже качество соискателей и так далее. Поэтому, 2/3 вакансий без указания ЗП - это серяк или черняк.

Это ваша ошибка, клиент не виноват. Надо возвращать деньги, либо договариваться на продление срока и доделывать бесплатно.
Какая разница сколько вы работали, если работа бессполезна для клиента?

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

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

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

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

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

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

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

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

Ну так и ставьте себе ubuntu server либо debian, раз с ними уже имели дело. Если лезть в консоль совсем лениво, поставьте pfSense не Linux конечно, зато нужные функции есть из коробки и настраиваются через вебморду.

Возможна ли 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'.

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