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

Тоннель работает всего на 400 Мбит/с на CCR1036.

Тоннель работает всего на 400 Мбит/с на CCR1036., RouterOS

eternal0

Guest

13.03.2015 00:44:00

Два CCR1036 подключены напрямую друг к другу. Скорость канала 1000 Мбит/с. При тесте пропускной способности получается результат 990 Мбит/с. Но если настроить между ними туннель EoIP/IPIP/GRE без шифрования, максимальная пропускная способность в туннеле — 400 Мбит/с. При этом нагрузка на cpu1 достигает 100%, остальные ядра простаивают. В чем может быть проблема?

Pe3ucTop Guest	#2 0 09.07.2015 11:44:00 Есть новости? Уже решили проблему, кто-нибудь сообщил?

mrz Guest	#3 0 09.07.2015 12:27:00 Что за трафик? TCP? Сколько соединений? Размер пакета? Всё это может влиять на максимальную пропускную способность.

doneware

Guest

10.07.2015 14:38:00

Привет! Когда работаешь с туннелями EoIP/GRE (да и вообще с любыми туннелями), в игру вступает инкапсуляция. В случае GRE — это накладных 24 байта. Например, если передаёшь обычный IP-пакет с данными, он добавляется к стандартному MTU IP в 1500 байт. В итоге размер пакета становится больше стандартного MTU на Ethernet-интерфейсах большинства роутеров. Поэтому после GRE-инкапсуляции получившийся пакет придётся фрагментировать. Например, вторая часть пакета получит новый IP-заголовок, и два (а в крайних случаях даже больше) сегмента будут передаваться последовательно. Это нагружает CPU, и скорость передачи пакетов точно сократится вдвое.

Если есть возможность увеличить MTU на Ethernet-интерфейсах, чтобы «переваривать» более крупные (на самом деле «забавного» размера) пакеты — это может помочь. Но гарантировать такое через непредсказуемые сетевые сегменты, скажем, интернет — нельзя.

Если же дело касается «обычного» IP-трафика, который чаще всего — TCP, нужно позаботиться, чтобы большие пакеты не передавались. Для этого MTU на туннельных интерфейсах надо снизить, но это только половина дела. Нужно ещё уменьшить максимальный размер сегмента TCP (MSS) до такого значения, чтобы пакеты передавались без фрагментации. Например, 1460 байт MSS + 20 байт TCP-заголовка + 20 байт IP-заголовка = 1500 байт.

Если же используется GRE, то считаем иначе: 1500 — 24 байта GRE-заголовка — 20 байт оригинального IP-заголовка — 20 байт TCP-заголовка = 1436 байт MSS. Чтобы быть полностью уверенным, лучше брать 1420.

Это можно сделать с любой стороны туннеля через firewall mangle-правила, а если у вас версия выше 6.26, можно включить опцию clamp-mss=yes на туннельных интерфейсах. В этом случае MTU туннеля нужно выставить в 1476, и «авто-климпинг» подберёт правильный размер MSS.

atilla74 Guest	#5 0 12.07.2015 19:49:00 Похоже, что ещё один важный кандидат (наряду с заполнением таблиц BGP) для многопоточности в версии 7.0…

mrz Guest	#6 0 13.07.2015 11:49:00 Что? Ipsec и переадресация пакетов уже поддерживают многопоточность.

Maggiore81

Guest

23.09.2015 19:56:00

Здравствуйте. Итак, чистый GRE-туннель (без шифрования) по оптоволоконной линии (MTU1500) между центральным CCR и удалённым RB2011 или 1100AHx2. Какую производительность можно ожидать? В центральном офисе планирую использовать CCR 1009 и настроить 3 туннеля по оптике к трем удалённым площадкам: a — 10 Мбит, b — 30 Мбит, c — 300 Мбит полнодуплекс. Сможет ли 1009 держать более 500 Мбит в чистых GRE-туннелях?

dada

Guest

24.09.2015 07:14:00

Недавно я тестировал RB2011iLS. Два RB2011 были соединены через гигабитный Ethernet (ether1), между ними настроен EoIP, MTU на ether1 установлен в 1550. Для теста пропускной способности UDP через EoIP-связь RB2011 использовались два RB750GL. Результат — чуть больше 850 Мбит/с в одном направлении. Загруженность CPU на RB2011 была 100%. При стандартном MTU на ether1 показатели были намного хуже — около 100 Мбит/с. Так что определённо нужно избегать фрагментации инкапсулированных пакетов... Ожидаю, что CCR мощнее RB2011.

Maggiore81

Guest

05.10.2015 07:46:00

Ну, стандартный MTU для всего пути — 1500 (я имею в виду путь через моего оператора до моего удалённого роутера). MTU всех моих физических интерфейсов тоже 1500. Но когда я создаю туннель, стандартный MTU туннеля — 1476 (потому что у GRE заголовок на 24 байта). 1476 + 24 = 1500 — идеально.

dada

Guest

#10

05.10.2015 08:01:00

Но если устройство с туннелем — это маршрутизатор, то оно получает пакет размером 1500 байт с Ethernet и тогда ему приходится фрагментировать пакет на 2 части при передаче через туннель… Можно попробовать изменить размер MSS сегмента TCP, чтобы избежать фрагментации, но для UDP и других пакетов такого обходного пути нет.

Maggiore81 Guest	#11 0 05.10.2015 13:29:00 Итак, с локальной стороны моего роутера, направленной к маршрутизируемым сетям внутри моей внутренней сети, MTU установлен на 1500. Везде в моей сети MTU равен 1500. Сторона роутера, выходящая в WAN, проходит через облако оператора (MTU 1500) к моему конечному роутеру. Какие у вас есть предложения по поводу MTU?

Читают тему

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