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

MPLS — огромная разница в пропускной способности на CHR при использовании explicit nulls

MPLS — огромная разница в пропускной способности на CHR при использовании explicit nulls, RouterOS

tibobo

Guest

09.06.2017 17:23:00

Привет! Я настроил MPLS между двумя роутерами: один — CCR1009, другой — CHR (для справки, с лицензией PU). Оба работают на последнем багфиксе 6.37.5. Канал между роутерами — 200 Мбит/с, задержка меньше 1 мс. MTU на этом канале проблем не вызывает (MTU канала 1590, MPLS MTU установлен на 1508 с обеих сторон, ESXi vswitch с MTU 7500 на портах с jumbo, и так далее). OSPF запущен и работает, LDP тоже без сбоев.

Рассмотрим такую топологию:
A — CHR – 200M канал – CCR1009 — B

Когда я запускаю LDP без explicit-nulls, по двустороннему каналу можно заполнить 200 Мбит/с. Когда запускаю LDP с explicit-nulls, то с B на A скорость тоже 200 Мбит/с, а вот с A на B пропускная способность падает до нескольких Мбит (колеблется около 3-5 Мбит в зависимости от количества одновременно активных сессий). Разумеется, на обоих роутерах выставлены одинаковые настройки explicit-nulls.

Моё мнение: когда CHR должен добавить MPLS-метку (только при использовании explicit-nulls, иначе он просто маршрутизирует пакет и не ставит метку), скоростной режим падает. CPU на CHR при этом загружен очень слабо (меньше 2%), памяти полно (90% свободно), ни одно ядро не загружено серьезно, сетевые интерфейсы на ESXi в порядке и прочее.

У кого-то уже была такая проблема? Получалось её как-то решить, и если да, то как? Я искал по форумам, интернету и changelog’ам, но ничего похожего не нашёл. Любые идеи приветствуются!

Хороших выходных!

tibobo

Guest

25.06.2017 08:16:00

Ты менял MTU на vSwitch в VMware? Изменилась ли у тебя что-то после этого? Конечно, я это сделаю! Какие из роутеров R1, R2, R3, R4 являются CHR? Только R4? Все они участвуют в MPLS? Мне пришлось запустить клиента в продакшн (без explicit nulls, что затормозит другие проекты у клиента, но помогло уложиться в сроки). Так что придется построить другую конфигурацию для дальнейших тестов, но в ближайшее время на это времени не будет.

tazdan

Guest

25.06.2017 23:18:00

Итак: я установил, проверил и подтвердил, а потом попросил кого-то другого перепроверить следующее: значение MTU на физическом хосте через Cisco UCSM — установлено на 9000 байт; значение MTU на хосте ESXi — тоже 9000 байт; значение MTU на vSwitch в VMWare — тоже 9000 байт. Все роутеры — CHR, все они на одном физическом хосте для тестирования. У всех роутеров одна и та же конфигурация, и все они входят в MPLS. Настройка такая: R1 ← vlan10 → R2, R2 ← vlan20 → R3, R3 ← vlan30 → R4. Если создаю VPLS-туннель поверх MPLS от R1 до R4 — всё работает безупречно! Готов предоставить любую дополнительную информацию. Спасибо!

tazdan Guest	#4 0 25.06.2017 23:20:00 Я использую VMXNET3 — пробовал также E1000E, но результата это не дало.

tibobo Guest	#5 0 28.06.2017 18:24:00 Просто чтобы уточнить, какую версию CHR вы используете? Я пробовал с новым патчем (v6.38.7), но проблема осталась та же.

tazdan Guest	#6 0 28.06.2017 22:25:00 Я пробовал версии 6.36, 6.39 и 6.39.2 — результат одинаковый. От поддержки Mikrotik всё ещё нет ответа…

tazdan

Guest

03.07.2017 23:22:00

Хорошо, я уже попробовал это и перезагрузил хост и все CHR, но никакой разницы. Думаю, остаётся либо А) какой-то продвинутый параметр в VMWare, о котором я не знаю, либо Б) настройка в UCS, на которой работает VMWare. У тебя VMWare запущен на шасси Cisco? Может, я могу это исключить, если нет, и тогда открыть кейс в службу поддержки VMWare?

tibobo

Guest

29.06.2017 23:56:00

Кстати, если хотите попробовать настройки TSO/LRO: https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2055140&sliceId=1&docTypeID=DT_KB_1_1&dialogID=512450636&stateId=0%200%20512464428 https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1027511 Не забудьте потом перезагрузить хост.

tazdan Guest	#9 0 30.06.2017 00:30:00 Спасибо за всю твою помощь с этим — попробую и посмотрю, даст ли это какой-то результат.

tibobo

Guest

#10

29.06.2017 15:18:00

Думаю, это сведёт меня с ума… Я только что попробовал версию v6.39.2 с абсолютно новой настройкой с нуля.

CHR1 ↔ CHR2 ↔ CHR3 ↔ CHR4 <-nompls-> BTEST4 (тоже CHR)
Все каналы, кроме CHR4 — BTEST4, настроены с MPLS.
Все CHRx сконфигурированы с explicit-null и loop-detect, использую loopback (bridge) адрес как транспорт и LSR ID.

Когда я запускаю тест пропускной способности с CHR2 на BTEST4 и делаю «torch» на интерфейсе CHR2 — CHR3:
исходящие пакеты имеют MAC-протокол 8847 (MPLS),
входящие пакеты имеют MAC-протокол 800 (IP).

Но CHR2 настроен с explicit-nulls, так что входящие пакеты тоже должны иметь MAC-протокол 8847, или я что-то пропустил?
Сниффинг пакетов показывает те же результаты, что и torch, так что не думаю, что это баг torch.

Если посмотреть на интерфейс CHR3 — CHR4, там исходящие и входящие пакеты с протоколом 8847. Значит, роутер CHR3 сбрасывает метку, даже если на CHR2 запрошены explicit-null.

Если убрать галочку «Use explicit nulls» на CHR2, поведение остаётся точно таким же.
Должно быть два разных поведения при включении и отключении explicit nulls, верно?

Попробую обновить CHR2 и CHR3 до rc, чтобы посмотреть, изменится ли что-то, и сообщу результаты.

tibobo Guest	#11 0 29.06.2017 16:02:00 Переход на RC или возврат к bugfix ничего не меняют. Похоже, проблема не связана с версией. Главное здесь — протокол: UDP работает нормально, независимо от наличия explicit-nulls, а вот TCP, похоже, страдает.

tibobo

Guest

#12

29.06.2017 17:01:00

Еще тесты:
Тест пропускной способности с CHR4 на CHR1 (loopback), с выключенными explicit-nulls (на всех CHRx). Размер пакета 1200 байт, направление двунаправленное, скорость передачи (локальная и удаленная) 5M UDP : 5M TCP с 2 сессиями — меньше 1 Кбит/с, загрузка CPU 50%, половина отображается как unclassified в профайл-туле (я по этому поводу открыл тикет).

Тест пропускной способности с BTEST4 на CHR1 (loopback), с выключенными explicit-nulls (на всех CHRx). Размер пакета 1200 байт, направление двунаправленное, скорость передачи (локальная и удаленная) 100M UDP : 99.9 Мбит/с и 99.3 Мбит/с TCP с 20 сессиями: 740.9 Кбит/с и 1793.1 Кбит/с (CPU полностью загружен на обоих концах).

Тест пропускной способности с BEST4 на CCR через CHR1, с выключенными explicit-nulls (на всех CHRx). Размер пакета 1200 байт, направление двунаправленное, скорость передачи (локальная и удаленная) 10M UDP : 7.9 Мбит/с и 6.9 Мбит/с TCP с 20 сессиями: 7.9 Мбит/с и 6.9 Мбит/с (CPU полностью загружен на BTEST4).

Дальнейшие тесты:
/tool fetch keep-result=no url=“ http://proof.ovh.net/files/1Gio.dat ” запускал с CHR1, CHR2, CHR3 — несколько мегабайт в секунду, а с CHR4 — от 40 до 80 Кбайт в секунду.

Если отключить LDP на CHR1, та же команда, запущенная на CHR4, сразу дает несколько мегабайт в секунду, что подтверждает нашу предыдущую диагностику: добавление MPLS-меток на CHR рушит производительность. А запуск TCP btest на CHR убивает CPU.

Возможно, есть какие-то специальные продвинутые настройки для VMware? Какую версию VMware вы используете?

tazdan

Guest

#13

29.06.2017 23:21:00

Я использую версию 6.5 на одном объекте и версию 6.0 на другом (обновился до 6.5, чтобы убедиться, что проблема не в версии VMWare)… вот ещё ответ от поддержки Mikrotik: «Я проверял вашу точную конфигурацию — MTU интерфейса 1500, MPLS MTU 1590 и VPLS MTU 1500, дефолтные настройки vswitch с MTU, установленным на 9000. Мы использовали: Supermicro SYS-5018D-FN8T и ESXi-6.5.0-4564106-standard. Мне удалось прокачать 900 Мбит/с через VPLS-туннель и обычное коммутацию меток, так что с MPLS на CHR или драйверами виртуальных интерфейсов внутри CHR проблем нет. Проблема в вашей аппаратуре и комбинации с ESXi или настройках vswitch. Известно, что ESXi нестабилен и содержит ошибки». Я готов принять, что проблема в моём железе/софтвере, но мне нужно понять, что именно изменить, чтобы это исправить!!!

tibobo

Guest

#14

29.06.2017 23:25:00

Я пытался отключить в VMware TSO и HRO и перезагрузил ESXi-хост, как советовали в некоторых документах VMware. Без изменений. Я настроил генератор трафика, чтобы проверить пропускную способность через цепочку CHR1-CHR2-CHR3-CHR4. По UDP проходит довольно быстро, а вот TCP-загрузка всё ещё ужасно медленная.

[admin@CHR_BTEST_4] /tool traffic-generator> quick mbps=2000
SEQ ID TX-PACKET TX-RATE RX-PACKET RX-RATE RX-OOO RX-BAD-CSUM LOST-PACKET LOST-RATE LAT-MIN LAT-AVG LAT-MAX JITTER
......
TOT 3 2 586 149 1999.9... 2 585 538 1999.4... 0 611 472.5kbps 44us 396us 4.32ms 4.27ms
TOT 4 2 586 156 1999.9... 2 584 995 1999.0... 0 1 161 897.8kbps 49.1us 416us 4.22ms 4.17ms
TOT TOT 5 172 305 3.9Gbps 5 170 533 3.9Gbps 0 1 772 1370.3... 44us 406us 4.32ms 4.27ms

[admin@CHR_BTEST_4] /tool traffic-generator> /tool fetch keep-result=no url="http://proof.ovh.net/files/1Gio.dat"
status: downloading
downloaded: 1427KiB
total: 1048576KiB
duration: 20s

У меня закончились идеи… Похоже, придётся одновременно запускать сниффинг на всех задействованных интерфейсах, чтобы точно понять, где теряются пакеты…

tibobo Guest	#15 0 29.06.2017 23:32:00 Я все еще работаю на ESXi 5.5. Обновление казалось мне лучшим и последним вариантом (нужен специалист по центру обработки данных и нужно планировать простой). Согласен, что UDP работает хорошо, и VPLS, скорее всего, тоже. Но простой TCP поверх MPLS просто не работает как надо. Похоже, придется обновляться.

Читают тему

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