throughtheether

Падение линка не падение интерфейса. Подскажите как можно выкрутиться не прибегая к протоколам BGP.

Или самому организовывать добавление/удаление маршрутов в зависимости от "доступности" (ping и прочая) противоположного конца тоннеля, или использовать динамическую маршрутизацию через туннельные интерфейсы (реализации RIPv2, если не ошибаюсь, есть почти под каждую из популярных ОС).

Точнее можно будет ответить после того, как вы предоставите схему организации сети.
UPD:

Очень краткая схема в первом комментарии выше.

Если я правильно понял, то можно (нужно?) изменять маршрут по умолчанию (т.е. маршрутизировать трафик на OPENVPNSERVER1 или OPENVPNSERVER2) на 3750 в зависимости от работоспособности тоннеля?

Когда трава была зеленее я видел использованиe route map в зависимости от пинга, но не запомнил и информации сейчас нет.

На мой взгляд, вам подойдет решение в виде статической маршрутизации вкупе с ip sla tracking. См. раздел Резервирование.
UPD2:

К сожалению со второй стороны также нужно отправлять пакеты, в свою очередь выбирая интерфейс. А там у нас чисто линуксовое решение.

Я полагал, что хотя бы с одной стороны маршруты исчезают при нарушении работоспособности туннеля. Если нет, то остается RIPv2 (на 3 серверах с openvpn и на устройстве cisco).

Если есть две точки, и между ними надо передать данные, то я бы по предпочтению сортировал различные варианты так:
1) Оптоволокно. Наивысшая, на мой взгляд, помехозащищенность, возможность увеличения пропускной способности в будущем при замене трансиверов (xWDM и т.д.). Гальваническая развязка трансиверов, что иногда бывает очень важно.
2) Все то, что называют словом "медь". Витая пара, коаксиальный кабель и т.д. Здесь многие нюансы появляются в зависимости от расстояния между приемником и передатчиком, требований помехозащищенности и прочая.
3) Электромагнитное излучение сквозь "эфир". Оптика (АОЛС), радиорелейная связь, wi-fi, спутниковая связь. Основной проблемой здесь является то, что вы не контролируете среду передачи, в частности, ее характеристики (которые зависят от погоды) и радиоэлектронную обстановку. Может понадобиться получение лицензии. К тому же, как справедливо отметили, спутниковая связь - это отдельный разговор.

Начнем с того, что пример не вполне корректен. В частности, адрес 54.55.218.253 входит в префикс ("подсеть" на жаргоне) 54.55.218.0/24, но не 54.55.218.0/32.

Чтобы вам помочь, необходимо знать, что это за адреса, сколько их всего, есть ли среди них "соседние" (например, 54.55.218.253 и 54.55.218.254) и как они будут использоваться (правила в iptables?).

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

Так вот, можно ли купить IP адрес как домен

Если вы хотите иметь независимость от хостинга, покупка (аренда) одного адреса ничего не решит, но можно купить префикс ("подсеть" на жаргоне). Первая ссылка из гугла привела сюда.

Ведь там не отделаешься доменом, и приходится указывать IP адрес.

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

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

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

По поводу HP ProCurve, мне запомнился менее удобный по сравнению с cisco/juniper cli-интерфейс и странная терминология (то, что я привык называть portchannel/etherchannel/aggregated ethernet, в терминах HP называется Trunk).

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

Чем (схема подключения и т.д.) проблемный компьютер отличается от остальных?

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

Пока судить о причине проблемы довольно затруднительно.

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

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

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

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

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

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

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

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

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

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

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

Не могу подсказать касательно сервиса, но есть такой модуль Python, если вас он устроит.

Скорость на прямую, при подключении кабеля к сетевой карте 40-50 мбит/сек. При подключении через роутер скорость не поднимается больше 20 мбит/сек.

Что такое "скорость"? Как вы ее измеряете? Через speedtest.net и подобные сервисы? Как вы получаете интернет (используется ли VPN или PPPoE)?

Почему так может быть?

Возможные варианты (список неполный):
1) Маршрутизатор не справляется с нагрузкой. Проверьте утилизацию его ресурсов (CPU, память). Возможны также баги в реализации поддержки протоколов.
2) Субоптимальная работа TCP (в случае, если вы пользуетесь результатами speedtest.net). Проверьте настройки MTU и TCP MSS (maximum-segment size), если они есть. Проверьте скорость передачи udp-датаграмм при помощи, например, iperf.
3) Несогласованность дуплекса на каком-либо из портов. Проверьте настройки дуплекса и наличие ошибок на портах.
4) Как частный случай варианта 1), наличие встроенных механизмов "безопасности" (фаерволлы, ids и прочая), утилизирующих ресурсы. Попробуйте их отключить.

Если вы получаете интернет через VPN/PPPoE, то я склоняюсь к первому варианту. Быть может, что маршрутизатор не способен обработать трафик большей интенсивности.
UPD:

Интернет через pppoe. Скорость заметил на торрентах, да и на тестах тоже самое. Данная проблема была не всегда, а появилась совсем не давно. Не прошивал, не настраивал.

В принципе, те же варианты, только в другой формулировке:
1) может быть, маршрутизатор по какой-либо причине перестал нормально функционировать (плохое питание - нестабильная производительность - отбрасывание пакетов, или пробой памяти - нарушение контрольной суммы - отбрасывание пакетов)
2) настройки дуплекса на портах, особенно на WAN-порту маршрутизатора
3) проблемы с MTU также не стоит исключать
4) провайдер или ваш сосед по коммутатору начал слать вам паразитный трафик, маршрутизатор пытается его обрабатывать, что ведет к снижению полезной производительности.
5) провайдер изменил параметры PPPoE, маршрутизатор отреагировал снижением производительности из-за багов в прошивке.

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

Готовых односложных ответов я вам, к сожалению, предоставить не могу. "Домашние" маршрутизаторы мне представляются довольно неудобными в диагностике в силу отсутствия внятных инструментов для этого.

На компьютере не работает интернет, до тех пор, пока не запустишь команду "ping 192.168.5.16". Затем через какое-то время, минут 15, снова пропадает. Тут спасает только "ping 192.168.5.16 -t".

Одна из возможных причин - наличие в L2-домене хоста с IP-адресом, совпадающим с вашим или целенаправленная подделка arp-ответов. Стоит пронаблюдать состояние arp-таблицы на маршрутизаторе. Кроме того, можно самостоятельно (hping, scapy) послать arp-запрос с вашим ipv4-адресом в качестве искомого, посмотреть, кто откликнется.

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

Маршрутизатор, как правило, умеет поднимать VPN-тоннели, иногда (все реже и реже с распространением Ethernet везде) маршрутизаторы поддерживают отличные от Ethernet L2-технологии. Зачастую маршрутизаторы имеют богатую функциональность в области безопасности (встроенный firewall, ips и прочая).

L3-коммутатор умеет обмениваться маршрутами с другими устройствами и перенаправлять ("форвардить") трафик. С целью увеличения производительности используются специализированные аппаратные решения (ASIC для перенаправления трафика, аппаратная поддержка префиксных деревьев и прочая). Так как аппаратные ресурсы дороги, то по некоторым численным характеристикам (количество маршрутов, например) L3-коммутатор может отставать от маршрутизатора.
Кроме того, L3-коммутатор поддерживает технологии из сферы коммутации (xSTP, etherchannel и т.д.)

Таким образом, маршрутизатор обладает богатой L3-функциональностью, L3-коммутатор - более узкой, но оптимизированной, L3-функциональностью и, вдобавок, функциональностью "обычного" коммутатора.

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

Вопрос: не встречались ли вам инструменты, умеющие работать со скоростью приёма/передачи статичных файлов для сокрытия в моменте передачи доп. сообщения?

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

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

Что, если длительность передачи будет разной для этих файлов? Например, трафик с данными одного файла передавался по другим физическим линкам (etherchannel, L3 ECMP при взаимодействии с разными TCP-соединениями). Как их корректно сопоставить (сложить)? Что вообще означает "одновременно передавать"? Какова будет результирующая скорость передачи полезных данных?

Мне эта идея представляется свежей, но крайне непрактичной. Даже если кодировать данные в зарезервированных битах TCP (3 бита на сегмент), получится более применимая схема.

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