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

Движок маршрутизации Multicore для BGP

Движок маршрутизации Multicore для BGP, RouterOS

armandfumal Guest	#1 0 04.12.2013 16:18:00 Привет, есть какие-нибудь новости об эволюции BGP multicore? Спасибо.

Kreacher

Guest

17.03.2014 21:34:00

Возможно, это можно реализовать на одном сайте, но если подумать, если вся система RouterOS работает на многоядерном процессоре, вроде платформы Tilera, то, возможно, вся RouterOS ощутит пользу от этих действий и функций. И, на мой взгляд, и на платформах, отличных от Tilera, стоит использовать многоядерные процессоры. RouterOS на x_86_64 с многоядерным процессором и гораздо большим объемом оперативной памяти – это была бы реальная выгода и прибыль для всех нас.

name29 Guest	#3 0 12.12.2013 21:43:00 +1 абсолютно необходимо!

bennyng

Guest

17.01.2014 13:41:00

+2. Случай произошёл сегодня: произошёл сбой из-за того, что upstream совершил крупное обновление BGP 17 января 2014 года в 10:50 по Гринвичу. Получил от своего Cisco роутера 10-15 тысяч обновлений маршрутов и передал их своему новому CCR-1036. Одновременно часть моих подсетей потеряла соединение, и я подозреваю, что это связано с потерей части таблицы маршрутизации на CCR. При полном сканировании таблицы BGP каждые 30 секунд один из CORE работает на 100% более 20 секунд. Я думаю, из-за этого часть таблицы маршрутизации теряется из-за таймаута. У меня запущено 3 upstream с полными таблицами и около 20 пиров, подключенных к Internet Exchange… ROS у меня последняя 6.7, а прошивка HW 3.10. Надеюсь, BGP будет работать между разными ядрами CPU и ускорит сканирование таблицы…

blehmann

Guest

14.02.2014 20:50:00

+3 Мы надеялись на такое обновление уже давно. Похоже, что каждый раз, когда большие изменения топологии передаются CCR, маршрутизатор сходит с ума из-за загрузки процессора на максимум. В итоге таблица маршрутизации портится, и другие сервисы начинают быстро давать сбои. В нашей среде приходилось перезагружать устройство, чтобы это исправить. Это серьезная проблема, которую необходимо решить, так как она реально мешает использовать серию CCR в полной мере.

Hammy Guest	#6 0 15.02.2014 14:40:00 Если Mikrotik выпускает устройства с 36 ядрами, почему не для КАЖДОЙ услуги RouterOS включена поддержка многоядерности?

crtee

Guest

17.02.2014 21:28:00

+1 Жду "новый маршрутизационный движок". Время загрузки полной таблицы BPG совсем не приемлемое, совсем не то, что ожидаешь от такого количества вычислительной мощности. А поиск маршрутов (" /ip route print where …") занимает неприлично много времени на полной таблице. Пожалуйста, MT, дайте нам хотя бы /какую-то/ информацию, некоторые из нас даже готовы будут протестировать бета-версию… намек намек.

szastan

Guest

18.02.2014 10:37:00

Я тоже жду, когда функции BGP-маршрутизации заработают на каждом ядре. Пришлось перезагружать роутер несколько раз из-за зависших маршрутов/длительного времени перестроения таблицы. Я даже начал искать, не пробовал ли кто-нибудь уже поставить чистую Linux на CCR…

voiceland Guest	#9 0 18.02.2014 13:28:00 +1 от меня!!! Очень срочно!!!

hci Guest	#10 0 21.02.2014 16:11:00 Ну и что такое "table scan"? Ты уже открывал тикет в Mikrotik по этому вопросу и что они ответили?

nz_monkey Guest	#11 0 21.02.2014 20:48:00 +1 Жду "новые маршруты" уже 3 года.

bennyng Guest	#12 0 22.02.2014 04:24:00 Сканирование таблицы маршрутизации — это стандартное поведение BGP-соединения, так как ему нужно сравнивать полученные данные со своей внутренней таблицей маршрутизации и определять лучший путь. Я не создавал заявку, потому что это ожидаемое поведение для однопоточной программы. Вот почему все спрашивают про оптимизацию многоядерности для протокола BGP-маршрутизации.

Читают тему

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