throughtheether

можно ли во второй сверху порт (сбоку синяя маркировка)

Фото можете предоставить? Вы уверены, что это второй, а не третий слот (они подписаны)?
Кроме того, возле слота слева может быть написано на синем фоне "SUPERVISOR" - туда устанавливается, соответственно, супервизор, линейную карту туда установить нельзя.
Вкратце, если я правильно понял и это все же 3 слот, то нет, нельзя.

iperf + обвязка на bash как вариант (потребуется сервер для установки ответной части iperf)

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

Как считаете, сэкономлю деньги и время изучая все самостоятельно (время после работы и в выходные)?

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

Как я понял, торренты утилизируют весь канал, а http - нет, я предполагаю, что проблема в работе tcp. Предлагаю:
1) проверить, не режется ли где аксесс-листами icmp (некоторые типы icmp пакетов необходимы для работы path mtu discovery).
2) выбрать один проблемный хост и проверить, icmp-пакеты типа echo request (пинги) какого максимального размера успешно до него доходят.
3) снять дамп трафика при скачивании тестового файла через http (трафик между двумя хостами, в формате .pcap).

Как правильно настроить Cisco, что бы можно было использовать NFS c агрегированием каналов?

Если я правильно понимаю, то вам надо настроить две вещи:
1) поддержку Jumbo-фреймовsystem mtu jumbo 9000(подробнее)

2) etherchannel (агрегацию каналов)

interface AAA
 channel-group XXX mode active
 channel-protocol lacp
 switchport access vlan YYY
 switchport mode access
 exit
interface Port-channel XXX
 switchport access vlan YYY
 switchport mode access
 exit
port-channel load-balance src-dst-ip

(подробнее)

Я не думаю, что какой-либо вендор расскажет вам в деталях, как устроена подобная защита. Мои предположения:
1) настраивается сбор статистики (количество GET/POST запросов в единицу времени, период времени между запросами, характеристики обхода графа ссылок и прочая)
2) натравливаем популярных ботов, собираем статистику
3) обучаем систему на живом трафике
4) учим систему классифицировать трафик, относится ли он к случаю 2) или 3)
5) ???
6) профит!
По поводу эффективности технологии - я не знаю, как ее померять. Зато знаю, что "нажать ссылку" - это довольно примитивная защита, капча и то лучше, полагаю. В случае массовой атаки на сервисы, защищенные капчей, как правило, используются сервисы типа "антикапча", которые стоят денег. То есть под внятную атаку нужен бюджет; есть ограничение по масштабируемости атаки. В случае защиты секретной ссылкой - нужно один раз научиться доставать ссылку (phantomJS и другие headless-решения), и размножить это метод по всем ботам. Насколько мне известно, ботов на основе phantomJS выявляют по тонким отличиям в реакции на субстандартные заголовки.

Правильно ли я сделаю если воткну в WAN патчкорд из сети

Если вы имеете в виду соединить WAN-порт нового маршрутизатора (который будет раздавать wi-fi) и LAN-порт уже установленного маршрутизатора/коммутатора то да, это один из путей решения вашей задачи.

и в настройках DHCP роутера укажу область адресов 192.168.0.80-192.168.0.100. Область адресов соновного DHCP серевра 192.168.0.10-192.168.0.79.

А вот здесь хотелось бы вас поправить. Я подозреваю, используемая маска сети - /24 (255.255.255.0). В таком случае, в настройках DHCP нового маршрутизатора (который будет активен только на беспроводном интерфейсе), следует указать другую, специально выделенную для этого сеть. Например, 192.168.1.0/24, если она нигде более не используется (хосты от 0 до 100, например).
На WAN-интерфейсе следует включить DHCP-клиент.
В таком случае все хосты, подключенные по wi-fi, будут получать адреса из новой сети (192.168.1.0/24 в примере), которые будут натироваться в один адрес из сети 192.168.0.0/24, полученный по DHCP на WAN-порту. При этом ноутбуки (т.е. хосты с wifi-подключением) будут иметь доступ к интернету и другим компьютерам. Уже установленные компьютеры не будут иметь доступа к ноутбукам в общем случае.
Касательно нюансов, которые гипотетически могут возникнуть с windows-доменом при таком решении (работает ли доменная авторизация через NAT, в частности), я ничего не могу сказать.

Другой способ - при той же физической топологии (кабель от коммутатора или LAN-порта существующего маршрутизатора подключен в WAN-порт нового маршрутизатора) включить новый маршрутизатор в режиме моста (bridging) между WAN- и wifi-интерфейсами. В таком случае доступ между wifi-хостами и существующими хостами будет обоюдным. Из минусов - растягивание L2-домена, как мне представляется, и так не самое стабильное решение, здесь же еще добавляются возможные нюансы, связанные с разными физическими средами (излишняя утилизация wifi ненужным броадкастом/мультикастом и прочая).

Вы упомянули что некую "защиту от DDoS" вам предоставляет хостер (можете кстати уточнить модель аппаратного решения?). Если предположить, что ваши сервисы используют UDP (что, думаю, корректно для случая с CS-подобными игровыми серверами без дополнительных оберток трафика), то мысли такие.

Я полагаю, что максимум, что хостер может сделать - это ограничить трафик до сервера при DDoS-атаках (policing, причем хорошо, если политики учитывают порты назначения, а не только IP-адреса) или полностью заблокировать трафик до одного сервера, спасая инфраструктуру от чрезмерного трафика (bgp blackhole к аплинкам, эффективно атакуемый сервер все равно будет недоступен).

При использовании UDP возникает проблема аутентификации трафика. При использовании TCP есть возможность отделить тех, кто действительно устанавливает соединение, от тех, кто шлет SYN-сегменты с подставными адресами - вторые не смогут ответить ACK-сегментом с правильным значением acknowledgement на наш SYN-ACK-сегмент (ну или есть варианты с специально сформированным кривым SYN-ACK ответом, легитимный хост ответит RST c правильным acknowledgment и перепошлет SYN через примерно 3 секунды). В случае с UDP мы такой роскоши лишены. Мы не можем средствами самого UDP определить, кто подделывает адреса, а кто является легитимным хостом. Полагаю, неплохим решением было бы вести на сервере список IP-адресов клиентов и каким-либо образом передавать его хостеру, чтобы он в случае атаки блокировал весь трафик, не удовлетворяющий списку. Но хостер не внедрит новомодныя SDN-технологии (программно-определяемые сети) и не даст вам доступ к соответствующему API, это будет довольно затруднительно организовать.

Далее, что касается проксирования трафика. Самый наивный вариант - udp-прокси, т.е. сокет на сервере 1 принимает данные и копирует их в сокет, отправляющий данные на сервер 2. На сервер 2 пакеты, вмещающие соотвествующие датаграммы, придут с полем адреса источника, равном адресу сервера 1. Со стороны сервера 2 будет казаться, что все игроки имеют один и тот же адрес (если не предпринять никаких мер на уровне приложения, например добавлять в датаграммы дополнительный заголовок с адресом). Иногда это недопустимо.

Более внятный вариант - натирование. Примерная схема на иллюстрации.

Подобная схема часто реализуется при балансировке нагрузки при помощи решений вроде F5. Здесь используется Destination NAT пакетов от клиента к серверу и Source NAT пакетов от сервера к клиенту. Весь трафик от S2 надо будет направить через S1, это может потребовать поднятия какого-либо (например, GRE) туннеля. Также необходимо учесть, что IP-адреса могут использоваться внутри L7-протокола (наиболее известный случай - FTP), это может поднять новые вопросы.

Вообще говоря, ваша задача - широкое минное поле для экспериментов.

Одно из свойств этой нотации - отбрасывание констант перед членами, а также младших (менее быстро растущих) членов. Кроме того, log[base=a](N)=log[base=b](N)/log[base=b](a), т.е. при смене основания логарифма эффективно меняется константа перед соответствующим членом, что в целом не учитывается ('подавляется') О-нотацией.

Читал где-то,что в обычных телефонах (домашних) используется шифрование

Предполагаю, вы читали про DECT. Там, насколько я знаю, некоторое шифрование присутствует.

Я не вполне понимаю схему подключения (схема была бы кстати), но предлагаю проверить настройки автоопределения дуплекса и скорости передачи данных среды. В частности, настройки автоопределения с противоположного конца "кабеля", который вы втыкаете в маршрутизатор. Если на устройстве/устройствах с того конца скорость и дуплекс жестко заданы (100/full), например, а на маршрутизаторе определяются автоматически, то вполне возможно, что порт маршрутизатора поднимется в режиме 100/half. Это чревато потерей пакетов. Также проверьте настройки дуплекса на линках между компьютерами и маршрутизаторами.