throughtheether

Но ведь в таком случае на проектор также пойдут dhcp-запросы и прочий разрешенный в ip forward-protocol бродкаст, что, как мне кажется, нежелательно.

Вы можете отфильтровать эти запросы при помощи ACL на out-направлении интерфейса vlan2, на мой взгляд.

адрес проектора клиентский софт на ПК определяет широковещательным пакетом на адрес 10.0.2.255

а не на 255.255.255.255?

когда я подключен по VPN к работе дома будет ли учитываться трафик домашний

да

или рабочий (на работе сервер имеет выход в интернет)?

тоже да, в чуть меньшем количестве (за вычетом оверхеда инкапсуляции)

Узнать об анонсируемых наружу IPv4-префиксах мы можете здесь (bgp.he.net) или здесь (stat.ripe.net). Узнать, как эти префиксы структурированы, немного сложнее и пока непонятно, необходимо ли.

А вы рассматривали вариант проверять "наличие интернета" при помощи http get, если ваша версия IOS это поддерживает? ICMP, на мой взгляд, не вполне полноправный член семьи IP протоколов, его часто подвергают полисингу (ограничению) в первую очередь.

Соответственно создано подобие сети через несколько хабов.

несколько хабов

Я все-таки надеюсь, что коммутаторов.

Подскажите, чем грозит подсоединение новых пользователей через еще один хаб?

Тем, что вы соедините два коммутатора двумя линками и получите петлю, если на коммутаторах не активен STP.

И какие пути решения могут быть?

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

При звонке в ТП провайдера мне сказали что от меня приходит много битых пакетов и по-этому интернет не работает.

Есть предположение, что не пакетов, а ethernet-фреймов, и диагностику они снимают с порта коммутатора (уточните, если появится возможность). Спросите их, каковы настройки порта коммутатора (скорость, 1гигабит/100мегабит/автоопределение; дуплекс, полный или автоопределение). Попробуйте сами жестко задать скорость передачи данных 100 мбит/с на порту ноутбука/маршрутизатора, подключенного к коммутатору.

Через консоль с linux-машины цепляюсь к windows-серверу с этим логином и паролем без проблем.

Уверены, что логин и пароль используются те же? Не могут ли латинские буквы быть заменены на кириллические, аналогичные в написании (пример, e и е)?

На приведенной схеме все коммутаторы соединены между собой оптикой

Кроме 3750 какие коммутаторы (вендор, модель) в кольце присутствуют, поясните пожалуйста. Сеть моновендорная?

На первый взгляд можно использовать MSTP, и все будет работать.

Можно. А можно использовать и Rapid-PVST+. Во втором случае все будет проще и понятней, на мой взгляд. Но Rapid-PVST+ - вендорспецифичная технология. Но с другой стороны, если вы хотите настроить STP (MSTP, например) в мультивендорном окружении, то будьте готовы к тому, что вам придется диагностировать проблемы, которых "по книжке" быть не должно, но они есть.

На тестовом стенде получили время схождения в пределах секунды-двух.

А вам сколько надо? Если выбирать между даунтаймом в секунду и несколько часов (если линк оборвался, а резервирования нет), то выбор очевиден, на мой вгляд.

Однако, изучая дискуссии по STP (на хабре) пришел к выводу, что данный подход не есть торт.

STP - такая вещь, о которой знает каждый человек с CCNA, но у которой огромное количество нюансов, и в них уже разбирается не так много людей. Это следует учесть при оценке полезности мнения незнакомого вам человека. Кроме того, не только ваш подход "не торт", но и сам STP "не торт". Если смотреть на вещи в развитии, то сама идея ethernet-бриджинга "не торт". Но есть некие идеалы, а есть "реальность", с которой предстоит работать.

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

Не знаю, и никто не знает. Мне вообще сама идея "правильных"/"неправильных" решений не вполне понятна. Есть рабочие решения, есть нерабочие. Есть решения с незначительными побочными эффектами, есть, наоборот, с ощутимыми.
На вашем месте я бы настроил Rapid-PVST+, подкрутил при необходимости таймеры, жестко задал бы приоритет корневого коммутатора (если я правильно понял, 3750 в топологии годится на эту роль) и отработал бы типовые аварии (все это в лабе), не забывал бы о udld. С другой стороны, если в обозримом будущем возможно добавление в кольцо оборудования других производителей, или число вланов слишком велико, стоит подумать о MSTP.

Вот и хотелось бы спросить опытных людей, что делать в такой ситуации?

Делать надо было раньше. Готовить внятный мониторинг, чтобы не гадать, атака это или сервер не справляется с нагрузкой. Налаживать контакты с хостером, чтобы не гадать, реально ли наблюдается атака или это тонкий намек на то, что вам пора арендовать более мощный VPS. Я не понимаю, почему, когда чуть ли не в газетах о DDoS-атаках пишут, единицы из тех, чье финансовое благополучие напрямую зависит от доступности их сайта, примеряют ситуацию на себя и задумываются о технических аспектах безопасности.

Три дня назад сайт стал выдавать 504, 500 и т.д. ошибки.

Очень хорошо, что сервер отвечает статусами 504 и 500. Это значит, что он отвечает. Это значит, что канальная емкость не полностью утилизирована. Это значит, что, скорее всего, есть шанс обойтись оптимизацией непосредственно на сервере. Найдите грамотного серверного администратора, согласного вам помочь.

Хостинг сказал, что на наш сервер идет ddos-атака и они делают все возможное чтобы решить проблему.

На вашем месте я бы запросил краткий отчет от сотрудников хостера. Какая атака наблюдается (качественные, количественные характеристики), какие меры предприняты, что из этого вышло. Запросил бы дамп "вредоносного" трафика.

каким образом все таки правильно хотя бы временно запустить сайт в работу?

На вашем месте я бы собрал на коленке минималистичный статический сайт с описанием ваших товаров и контактными данными. Вы таким образом сможете неудобно, без формы обратной связи и всплывающего окна чатика с консультантом, но все-таки получать заказы.
Вы можете разместить его на своем сервере, это, на мой взгляд, самый прямой путь. Вы можете разместить его где-то на другом хостинге, но придется ждать обновления DNS-записей и прочая.

что делать в такой ситуации?

Самое главное - сделать из этой ситуации выводы и предпринять соответствующие меры в ближайшем будущем.

Но из внешки - по не понятной мне причине оно тупо не проходит.

Что под этим подразумевается? Истекает таймаут или сервер присылает RST-сегмент?
Во втором случае, проверьте настройки сервера (фаерволла, в частности).
Проверить, доходит ли трафик до сервера, вы можете при помощи wireshark/tshark (я предполагаю, на сервере установлена ОС windows).

Кто сталкивался с данным маршрутизатором

Не сталкивался, но пару мыслей выскажу.

сайт из вне более не доступен

Что это значит? Как вы определяете доступность? Когда вы обращаетесь по URL вида http://ipv4address:port, что происходит? Истекает таймаут ("не удалось обнаружить сервер") или вы видите сообщение вроде "сервер сбросил/разорвал соединение"? В первом случае следует проверить настройки "проброса портов", во втором - настройки фаерволла/ACL. Надеюсь, что настройки сервера вы уже проверили.

Подобный вопрос уже задавали. На мой взгляд, логичнее думать не о переходе от электричества к программе, а наоборот, от программы к тому, как процессор обрабатывает данные, то есть, очень грубо говоря, меняет форму "выходного сигнала" в зависимости от формы "входного сигнала".

Основной шлюз имеет 100 мегабитный канал в инет. А один из офисов только 10 мегабитный канал до шлюза.

Уточните пожалуйста, в чем конкретно состоит проблема. На что расходуются 10 мегабит/c полосы пропускания? На что их не хватает?

Каким образом можно сжимать трафик штатными средствами?

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

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

Другой вариант - воспользоваться "ускорителем интернета" (WAN acceleration). В случае cisco - семейство WAAS. Имеет реализацию сжатия трафика, дедупликации данных и оптимизации производительности TCP. Опыта промышленной эксплуатации этого продукта я не имел, но могу предположить, что для грамотного внедрения подобного решения, необходимо понимать, как именно работают приложения в вашей сети, знать нюансы реализации TCP-стека на серверах/рабочих станциях и быть готовым к труднообъяснимым багам. И все это ради негарантированного улучшения производительности в вашем случае.

Наконец, когда-то существовали модули аппаратного сжатия трафика для 2600, 7200, но, если не ошибаюсь, они достигли статуса End-of-life.

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

UPD: Обнаружил такое якобы бесплатное решение. Думаю, стоит обратить на него внимание. Хотя, повторюсь, WAN-оптимизация - дело нетривиальное.