+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

SBE T1 карточки.

SBE T1 карточки., RouterOS

csickles

Guest

29.08.2005 18:36:00

Может ли RouterOS поддерживать больше одной SBE-карты в роутере? То есть, мне нужно 3 однопортовые карты для тестирования и 2 четырехпортовые для продакшена. Нужен канал 10 Мбит/с на T1-картах, а не T3. Это для телекома/ISP-провайдера. Крейг.

csickles Guest	#2 0 29.08.2005 23:14:00 Я, кажется, один такой, кто пользуется T1-соединениями???

csickles Guest	#3 0 30.08.2005 23:24:00 Буэлер??

jarosoup Guest	#4 0 31.08.2005 02:13:00 Интересно, должно же это работать, ведь это же просто интерфейс с гейтвеем… верно? У нас много T’s используем, но с картой на Mikrotik роутере еще не пробовали.

csickles

Guest

31.08.2005 04:10:00

Я вижу, что роутер видит только один порт (одну карту). Если я ставлю в систему больше карт, он “видит” только одну. Ресурсы показывают дополнительные карты, но они не отображаются в списке интерфейсов. Крейг.

dwright

Guest

31.08.2005 17:18:00

Ты эти карты на riser устанавливаешь? У нас та же проблема была. Одной картой в riser можно было только установить. Драйвер грузился, а в списке интерфейсов карта не отображалась. Попробуй их в слоты PCI поставить и проверь, появятся ли они. Dan

csickles Guest	#7 0 31.08.2005 18:32:00 Это материнская плата на 4 слота (Intel). Как я и говорил, один слот определяется, остальные "видны" в ресурсах, но драйвер их не подключает. Крэйг

dwright Guest	#8 0 31.08.2005 20:57:00 Ты уже обращался в поддержку MikroTik с файлом поддержки?

csickles

Guest

02.09.2005 17:17:00

Всё работает! Три T1 карты (SBE) в одном роутере. У меня 4.5 Мбит/с по T1 линиям! (по три single port карты на роутер). Система работает на 2X RouterOS 2.9.1 с тремя single port картами в каждом. Для теста используются кроссовер кабели. (У меня договоренности с клиентом из телекома использовать их лабораторию для подключения реальных T1 линий для тестирования). Канал работает, и теперь мне нужно проработать "резервирование". Если я отключаю любой из трех кроссовер кабелей, соединение обрывается до тех пор, пока не восстановится (никаких дополнительных действий, например, перезагрузки и т.д.). Мне нужно, чтобы пропускная способность просто снижалась до восстановления неисправного канала. Думаю, я где-то неправильно поставил настройку… В конечном итоге, тест будет заключаться в использовании двух quad port карт для перекачки 10 Мбит/с трафика (IP и VOIP) по восьми T1 линиям за ДЕСЯТЬ КРАТНО меньшую стоимость T3 линии. Идея в следующем: Telco ---->(10Мбит enet) → RouterOS ---->(8X T1 loops only) -->RouterOS —> (10Мбит enet) = !! Буду выкладывать обновления… Craig http://www.pc-routers.com

changeip Guest	#10 0 02.09.2005 18:40:00 Что тебе пришлось делать, чтобы система их распознала? Сэм.

csickles

Guest

#11

02.09.2005 20:13:00

Получил файл от техподдержки (кажется, это можно считать бета-версию). Они прислали новую версию Sync-файла (для 2.9). Я еще немного протестирую его для них и сообщу о результатах. Пока что все очень стабильно. 4.5 МБ на тесте пропускной способности от роутера к роутеру, используя 3 порта T1. (SBE) Надо достать карты с четырьмя интерфейсами, чтобы поиграться… Пока что все хорошо! Крейг

csickles

Guest

#12

04.09.2005 06:42:00

Итак, вот где я сейчас… У меня есть 3 T1 канала, объединенные через EOIP/Bonding (round robin). Вот что я вижу пока. Если один из T1 каналов падает, то падает вся группа bonding. Неважно, как это происходит, например, из-за вырванного кабеля или отключения. Если один EOIP канал выходит из строя, соединение держится. Агрегированная пропускная способность снижается соответственно. Если один из T1 каналов падает и вместе с ним падает EOIP туннель, то объединенное соединение остается активным. Агрегированная пропускная способность снижается соответственно. Вывод: протокол bonding устойчив только по отношению к своим непосредственным протоколам, лежащим в его основе (если EOIP протоколы отваливаются, соединение просто "сбрасывает трафик"). EOIP понятия не имеет, если неисправен IP путь, например, неработающий T1. Если бы EOIP мог быть проинформирован о неработающем пути и отображаться как отключенный или неработающий (при этом продолжая отслеживать неработающий путь для восстановления соединения), то bonding через round robin/EOIP туннели действительно обеспечил бы агрегирование и резервирование. Пример: Предположения: 3 T1 канала, объединенные с использованием EOIP/bondingrr. Случай: Все T1 каналы работают и подключены. EOIP работает на всех интерфейсах. Результат: Агрегированный трафик (примерно 4,5 МБ). Все T1 каналы работают, EOIP работает только на 2 интерфейсах. Результат: Агрегированный трафик (примерно 3 МБ). 2 T1 канала онлайн, один не работает, EOIP работает на всех T1. Результат: поток трафика отсутствует, так как протокол bonding переключается на неработающий канал. Предложения: Включить передачу информации о состоянии канала с интерфейса в EOIP. Например, скриптовый механизм или протокол для отключения EOIP протоколов (или помечать их как неработающие, продолжая отслеживать неработающий путь для восстановления соединения). Это особенно полезно на устройствах интерфейса SBE. Например, если интерфейс SBE вышел из строя или перегорел кабель или телеком снова перерезал линию… (Qwest !!) то драйвер интерфейса уведомил бы все EOIP каналы о том, что неработающий канал не работает и чтобы они вышли в офлайн и отслеживали восстановление соединения, в это время EOIP "вернулся бы в онлайн". Другой вариант — возможность предоставления статуса SBE карты (или аналогичной) операционной системе. Этот статус можно было бы отслеживать, и можно было бы контролировать действия по управлению EOIP туннелем с помощью скрипта или аналогичного действия. Таким образом, опять же, это обеспечило бы надежное агрегированное решение с резервированием. Моя скромная оценка в $1,00 (после того, как мои руки заныли после этого… Мне нужно больше, чем 2 бита…)

Craig

csickles Guest	#13 0 06.09.2005 15:05:00 Только что отправил поддержку копию последнего поста… Сообщу, что они думают… Крейг.

csickles

Guest

#14

08.09.2005 19:45:00

Последнее обновление… Работает!!! Три объединённых T1 с балансировкой нагрузки и отказоустойчивостью!! Связь теперь устойчива даже к отключённому интерфейсу. Я думаю, "фикс" для обнаружения неактивного интерфейса заключался в включении ARP на всех туннелях (EOIP / Bonding). Craig

phendry Guest	#15 0 29.09.2005 19:55:00 Тестировал это и вроде работает нормально, но не знаю, как проверить, если какие-то EoIP-интерфейсы упали и были удалены из интерфейса Bonding. Есть ли что-то, что указывает на то, что EoIP-интерфейс не работает?

csickles

Guest

#16

29.09.2005 21:05:00

Если не работает (не обнаруживает тоннель вниз), то весь набор соединений упадёт. (Так что если ты выдернешь линию и она останется поднятой, значит, всё работает…) Ты можешь увидеть "down" сегмент, посмотрев на трафик по T1 и EOIP туннелю для этого T. (Оба будут по 0). Я даю имена своим T1 и EOIP туннелям, чтобы было проще их сопоставлять, например, T1-XO1 и EOIP-XO1 и т.д. (Так легче понять, что происходит...). Надеюсь, это поможет. Craig

phendry

Guest

#17

30.09.2005 15:44:00

Ну, если один туннель упадет, но не будет исключен из бандла, это же просто будет приводить к потере пакетов для каждого пакета, отправляемого через этот упавший туннель (когда используется rr)? Кроме проверки потока трафика по отдельным EoIP, есть еще какой-то способ?

csickles

Guest

#18

05.10.2005 22:44:00

Случается, что теряется одна связь – и тоннель падает, то есть скорость 0 bps. Потом он «перебалансируется» и продолжает передавать пакеты. IE 3 T1s = 4.5Mb. Один канал пропадает – скорость падает до 0 bps примерно на полсекунды, а потом восстанавливается до 3Mb.
Крейг

phendry

Guest

#19

06.10.2005 10:57:00

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

csickles Guest	#20 0 06.10.2005 21:46:00 Когда ссылка снова заработает, туннель обрушится до 0, а затем восстановится с шириной полосы пропускания восстановленных ссылок. Например: 3X T1, когда одна линия недоступна… скорость = 3.0 Мб. Когда становится доступна третья линия, туннель падает до 0, а затем снова показывает 4.5 Мб. Что касается мониторинга, можно написать скрипт, который будет отслеживать T1 и EOIP-соединения и отправлять сообщение, когда они отключатся. Думаю, это было бы полезно для DUDE.. Крэйг.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры