Кто-нибудь работал с Bonding? *Чувствую себя отброшенным*.

Только что обновил два MT с 2.9.16 до 2.9.18, и теперь всё работает. Но я обновлял через FTP, и после перезагрузок система всё ещё показывает 2.9.16. Пока работает – мне плевать. Извините, я тупой. Просто указывал FTP на неправильные файлы. LOL. Теперь мне нужно узнать, не сломает ли это bonding, если я подцеплю Bonding1 к ether1? Попробую всё равно. Сообщу, как будет!

Winbox не дает мне возможность настроить рабочие устройства как EoIP, только порты ether. Это бы не было проблемой, если бы я разобрался, как настроить Link-Monitoring в Terminal. Помогите!

Извини, я отредактировал свой пост, чтобы показать, что я понимаю, что ты имеешь в виду, прежде чем ты это сказал. Не мог бы ты, пожалуйста, подсказать, как редактировать интерфейс связывания в терминале, или подкинуть нужную документацию, чтобы я мог изучить команды? Тут, в Луизиане, уже 2:33 ночи, так что прости, если я не очень в себе.

Я пытаюсь изменить интерфейс Bonding link-monitor на arp. Но в Winbow слейвы отображаются как ether1 и ether1, а на терминале – правильно, как eoip1 и eoip2. Так что, если я пытаюсь изменить настройку link-monitor или что-то ещё, выдаёт ошибку. Лол, кажется, мне нужна твоя помощь, чтобы пройтись со мной по терминальным командам для редактирования интерфейса bonding. Лол.

Зажегся приглушённый свет!

Вы, похоже, заставляете меня учить каждую мелочь в терминале, да? LOL. Теперь понятно, извините за потраченное время. Затянула WinBox

Офигенно! Теперь могу выдернуть один из сетевых кабелей, а связь останется! Ураааа!

Есть ли способ приоритизировать ACK-пакеты в MT? На асимметричных каналах Интернета, таких как DSL и часто кабельные, большая загрузка, потребляющая всю доступную скорость загрузки, может сделать канал практически непригодным для использования, создавая огромный буфер в модеме DSL/Cable, что увеличивает задержку до нескольких секунд. Поскольку ACK-пакеты (подтверждения TCP) для полученных данных также задерживаются или даже теряются, скорость загрузки также падает. Эту проблему можно решить, приоритизируя эти ACK-пакеты, чтобы они отправлялись до любых других пакетов загрузки. Вот как это сделать с помощью m0n0wall: Прежде всего, вам нужна m0n0wall pb24 или более поздняя версия. Начните с добавления нового канала (pipe) в Traffic Shaper. Это необходимо, потому что нам нужно переместить очередь загрузки в m0n0wall (где порядок, в котором отправляются пакеты, можно изменить, пока пакеты находятся в очереди), а не в модем DSL/Cable. Как только пакеты окажутся в выходной очереди модема DSL/Cable, не будет возможности отправлять ACK-пакеты немедленно. Поэтому очень важно установить для этого канала значение пропускной способности, немного ниже эффективной скорости загрузки вашего интернет-канала. Не забывайте, что, например, ADSL-линия со скоростью 128 кбит/с имеет лишь около 100 кбит/с эффективной скорости. Если вы установите это значение слишком высоким, буфер вашего модема все равно заполнится, и приоритизация не даст никакого эффекта. Когда вы добавите этот канал, добавьте две очереди, связанные с этим каналом, с разными весами, например, одну очередь с весом = 10 и одну с весом = 1. Первая очередь становится вашей высокоприоритетной очередью. Теперь пришло время добавить правила, которые классифицируют трафик загрузки в одну из этих двух очередей. Существует множество возможностей, например, приоритизация по TCP/UDP-порту, но для начала мы сосредоточимся на длине IP-пакета и TCP-флагах. Добавьте новое правило Traffic Shaper, свяжите его с первой (высокоприоритетной) очередью, интерфейс = WAN, протокол = TCP, источник = любой, назначение = любой, направление = наружу, длина IP-пакета 0-80, TCP-флаг: ACK = установлен, всё остальное = неважно. Классифицировать пакеты в высокоприоритетную очередь только на основе флага ACK недостаточно, поскольку (большие) TCP-пакеты загрузки также могут иметь установленный флаг ACK. 0-80 - это всего лишь пример, чтобы начать работу. Сохраните правило и добавьте еще одно под ним, связанное со второй (низкоприоритетной) очередью, интерфейс = WAN, протокол = любой, источник = любой, назначение = любой, направление = наружу. При необходимости включите Traffic Shaper, примените изменения — всё готово. Вот несколько моментов, которые следует помнить: убедитесь, что ни один пакет загруженного трафика не может обойти канал; * даже при приоритизации ACK задержка все равно будет увеличиваться, поскольку невозможно остановить отправку большого пакета посередине; * для отправки пакета размером 1500 байт со скоростью 100 кбит/с потребуется 120 мс; * если вы хотите, чтобы у вас была возможность просматривать веб-страницы во время выполнения большой загрузки, вам также потребуется приоритизировать HTTP-трафик загрузки (т.е. целевой порт = 80) — иначе TCP SYN-пакеты (для установки соединения) к веб-серверам не будут приоритизированы, и будет большая начальная задержка, пока соединение не будет установлено. Хорошей идеей также является приоритизация DNS-пакетов. * Если вы хотите узнать, что делает приоритизация для вас, добавьте правило для классификации исходящих ICMP-пакетов в высокоприоритетную очередь и попробуйте пропинговать какой-либо хост в Интернете во время загрузки — один раз с Traffic Shaper включенным, а другой — выключенным. Разница во времени отклика должна быть огромной.

Как думаете, какой MTU лучше установить на упаковке? Я всё сжимаю. Пожалуйста, учтите, что это будет подключено к PPPoE ADSL, поэтому MTU, по идее, нужно установить на 1492 на сети BellSouth.