firstcalled

Уверены, что в WIn7 это так же при помощи скриптов? А не отрабатывает какой-нибудь протокол? Просто пока я искал решение проблемы под WinXP, я наткнулся на RIP протокол, но и он не особо помог, если честно...

Спасибо за ответ! Пробежался глазами по описанию протокола, реализации под *nix и самой сути, Вы правы, очень хорошо, но проблема в том, как устроена сеть...просто представьте, что 192.168.0.1/32 - оборудование, доступ к которому я не имею, а так же нет свободного железа, чтобы поднять два шлюза, например тот, который уже есть, 192.168.0.2, и, допустим, 192.168.0.3...кризис в стране, хорошо, что один нашел системник под свои нужды. Есть еще варианты? Я понял, что можно написать скрипт для linux, с простой сутью, мы пингуем шлюз, если ответа нет, меняем таблицу маршрутизации, но блин...почему так криво-то? Разве нет способа проще? Даже в win7 все работает...

Здравствуйте! Ситуация такая: есть сеть( 192.168.0.0/24 ), есть в ней два щлюза, 192.168.0.1/32 и 192.168.0.2/32. Я хочу на машинах пользователей указать эти оба шлюза, чтобы при этом, в случае отказа одного из шлюзов, система переключалась на другой. Под Win7 все просто, указывается два шлюза с разной метрикой и все отлично работает. Но вот под linux и WinXP уже все сложнее. Что я пробовал под linux(Debian 8): добавил в /etc/network/interfaces auto eth0 iface eth0 inet static address 192.169.0.3 netmask 255.255.255.0 up ip route add default via 192.168.0.1 dev eth0 metric 100 up ip route add default via 192.168.0.2 dev eth0 metric 200 Под WinXP делал тоже самое, что под Win7, вначале посредством tcp/ipv4 -> свойства -> дополнительно -> основные шлюзы -> добавить, затем, когда это не сработало, ручками прописывал маршруты. Эффекта нет. Выбирается маршрут с наименьшей метрикой, а вот динамического переключения между ними нет, если шлюз, указанный в маршруте с наименьшей метрикой отказал.

Спасибо за ответ! Насколько я помню и исходя из того, что я понял из QoS, если передающая сторона видит, что нет подтверждения от принимающей стороны того, что пакеты были доставлены, она, передающая сторона, должна уменьшить скорость передачи и повторить передачу недошедших пакетов. В squid это прекрасно работает. Должно работать и в tc. Есть, например, youtube и человек качает фильм, при этом полностью вычерпывает весь свой трафик, если мы настроим все правильно, то входящие пакеты, из-за отсутсвия места в очереди, будут отбрасываться, youtube будет снижать скорость и мы получаем то, что нужно. Верно же?

Добрый! Сразу расставлю точки над i: в linux новичок, поэтому большая просьба выражаться яснее и если вы используете спец. лексику, то используйте ее английские аналоги, чтобы я всегда мог загуглить и понять, о чем идет речь вообще. А теперь по существу вопроса. Что есть: системный блок с debian, 2 сетевых интерфейса, на этом деле настроена базовая маршрутизация и nat. Внешний интрефейс - eth0 - пусть будет 10.30.139.2/24, внутренний интерфейс - eth1 - пусть будет 192.168.1.2/24. Есть канал, равный 10мб в сек. Есть 10 пользователей. Чего хочется: чтобы он динамически делился, между всеми пользователями и чтобы все получали поровну. Прочитав мануалы с этих сайтов tldp.org/HOWTO/Traffic-Control-HOWTO/index.html и www.lartc.org/lartc.html и www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html и еще парочку, я примерно понял, как решение выглядит, но потом появился ряд вопросов: Во-первых, вся мощь tc утилины под linux используется только для исходящего трафика, входящий трафик мы не можем шейпить(shaping), все, что мы можем делать с ним - это откидывать(policing, согласно http://www.lartc.org), но я-то хочу не просто, чтобы 10 пользователей получали по 1мб. А чтобы, если канал используется двумя пользователями, то каждый бы получал по 5мб в среднем, если используется тремя, то по 3.3 и тд. Я думаю, вы поняли идею. А достичь этого просто при помощи отбрасывания пакетов мы не сможем. Начал искать и нашел такие вещи, как IMQ и IFB, но читая статьи про них и споры людей, понял, что это вроде бы как работает, но не является правильным использование этих "костылей". Тогда мне в голову пришла простая идея, ради которой и пишется сей опус, а что если шейпить входящий трафик(Internet -> eth0 -> внутренние процессы NAT и routing -> eth1 -> внутренняя сеть), но не на eth0, а на eth1?! Ведь для tc он будет считаться исходящим, ведь приходит он из внутренних процессов и отправляется в сеть, хотя для нас это, по факту, входяший трафик, верно? Или мои рассуждения неверны на корню? Во-вторых, насколько все-таки неверно использование IMQ и IFB? Правда ли это такие костыли, которых лучше избегать?