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

CCR 6.0rc7 105 (Недостаточно места в буфере) потеря IPv4

CCR 6.0rc7 105 (Недостаточно места в буфере) потеря IPv4, RouterOS

mspeed

Guest

16.02.2013 03:38:00

Привет, у меня CCR1016-12G с прошивкой 6.0rc7, и я столкнулся с потерей IPv4-сервиса. Впервые у меня в продакшене не выдержал развернутый MikroTik, который хорошо себя показывал на тестировании, но проблема возникла примерно через неделю. После того, как меня оповестили о проблеме, я не мог получить доступ к нему ни через внутреннюю, ни через внешнюю сеть по IPv4. IPv6 на роутере включен, и я смог подключиться через него. Попытки пинговать что-либо по IPv4 давали: 105 (No buffer space available)
105 (No buffer space available)
105 (No buffer space available)
105 (No buffer space available)
sent=4 received=0 packet-loss=100% Трафик роутер обрабатывал примерно 1 мбит/с, загрузка CPU была минимальной. Вывод /system resource print:
uptime: 7m
version: 6.0rc7
build-time: Jan/18/2013 13:04:05
free-memory: 1520.5MiB
total-memory: 1935.8MiB
cpu: tilegx
cpu-count: 16
cpu-frequency: 1200MHz
cpu-load: 2%
free-hdd-space: 437.1MiB
total-hdd-space: 512.0MiB
architecture-name: tile
board-name: CCR1016-12G
platform: MikroTik Я перезагрузил систему (/system reboot), и IPv4 заработал снова. Я использую BGP, NetFlow и имею минимальную конфигурацию (2 VLAN с двумя наборами из 4 бриджовых порта (всего 8) плюс uplink). Проблема с буфером кажется похожей на то, что другие уже испытывали здесь. Это известная проблема, и если да, то какое решение? Кроме того, есть ли какие-то рекомендации по отладке или сбору данных журнала в случае возникновения такой проблемы, которые могли бы помочь в дальнейшем анализе? Спасибо.

Vladimirs_Buts Guest	#2 0 23.04.2013 08:29:00 Получил такое сообщение на 6.0RC13.

goldik

Guest

16.03.2013 16:32:00

У меня та же проблема с буфером, но на x86 core I7-2600K 3600 с RouterOS 6.0r11. На этом роутере работает: BGP: 4 сессии fullview и три сессии localpeers. Трафик около 250000pps в каждом направлении, 1.7 GGb, включая 500Mbit NAT. Не знаю, что можно сделать, чтобы решить эту проблему, потому что на ROS 5.14 все работало хорошо.

mspeed

Guest

16.03.2013 16:36:00

Я уже несколько недель переписываюсь со службой поддержки Mikrotik по этому вопросу, открыт запрос — пока решения нет. Пробовал бета-версию rc12, и там та же проблема. Подозриваю аппаратную проблему, так как это происходит только на одном устройстве, а на остальных с идентичной конфигурацией — нет.

mrz Guest	#5 0 18.03.2013 08:05:00 Мы исправили эту проблему в одной из последних тестовых сборок rc12. Обратитесь в службу поддержки, чтобы получить более новую версию.

mspeed Guest	#6 0 18.03.2013 08:09:00 Отлично, я только что запросил обновление по своему тикету.

JbBoin

Guest

20.03.2013 10:30:00

Похоже, я тоже столкнулся с этой ошибкой на CCR. Сразу после загрузки могу только делать ARP-пинг на IP-адрес роутера, но ICMP-пинг не работает, и подключение по TCP тоже не получается. Но иногда, если вытащить и снова подключить кабель (cat 6 SFTP не кроссовер), всё оживает, но не всегда... (а вот бридж работает без проблем, только доступ к IP-адресу CCR не работает). Кажется, это происходит примерно в половине случаев, когда я переподключаю кабель.

Кстати, кажется, я нашёл причину ошибки, хотя, возможно, это уже другая ошибка. У меня были два порта с IP-адресами в одной подсети, но они не были подключены к одной и той же сети. Похоже, предпочтительный маршрут не всегда был правильным (пакеты не отправлялись на порт, подключённый к сети, из которой они были сгенерированы). Это происходит даже если у второго порта нет соединения.

В моём случае я настроил мост на ether1 & ether2 с IP-адресом 192.168.2.220/24, а ether3 был настроен с IP-адресом 192.168.2.221/24. Когда я изменил IP-адрес на ether3 на 192.168.20.201/24, я больше не мог получить доступ к роутеру со всех трёх портов. Пришлось отключать и включать IP-адрес на сенсорном экране, чтобы вернуть сеть. Но хорошие новости: похоже, исходная проблема ушла.

mspeed Guest	#8 0 24.03.2013 02:00:00 К сожалению, у меня это до сих пор происходит даже в последней сборке: версия: 6.0rc12 время сборки: 18.03.2013 14:38:02

mspeed

Guest

02.04.2013 00:25:00

К сожалению, это до сих пор происходит, даже в последней сборке: версия: 6.0rc12
build-time: Mar/26/2013 17:18:12 Это происходит на множестве CCR1016-12G, которые у нас есть. К счастью, на CCR1036-12G-4S пока что этого не происходит. Видимо, придётся признать, что Mikrotik пока не готов к полноценной работе с базовым использованием IP (несколько BGP-таблиц + ipt на границе) как я и надеялся. (CCR с 10G, который был бы абсолютно стабилен, действительно привлёк наше внимание и заставил нас серьёзно рассматривать эту платформу.)

mspeed

Guest

#10

23.04.2013 08:38:00

У вас включен NetFlow? Я уже несколько раз переписывался с поддержкой MikroTik по этому вопросу – в итоге все сводится к NetFlow. Они прислали мне патченную версию RC14, но она полностью выбивает BGP из строя. На данный момент я прогонял систему без NetFlow около 5 дней (это самый долгий период), и никаких сбоев не наблюдалось. Скоро вернусь к тестированию последней версии, так как NetFlow критически важен для нашей работы.

Заметьте: после отключения NetFlow у нас тоже произошел сбой. После этого сбоя, когда NetFlow был отключен, повторений не было, поэтому, если у вас он включен, возможно, стоит отключить и перезагрузить устройство.

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

giallone

Guest

#11

17.10.2017 14:41:00

Это всё ещё происходит в версии 6.40.4 на CRS125-24G-1S. Работает как OpenVPN-сервер. Около 50 интерфейсов подключены уже неделю, и когда кэш достигает 25%-30%, теряется IPv4. Задействованная пропускная способность – 5 Мбит/с. ЦП не загружен. Мне пришлось запланировать скрипт на перезагрузку, когда заполненность кэша (которая увеличивается с каждым днём) достигает 20%. Есть какие-нибудь идеи, когда это будет исправлено?

giallone Guest	#12 0 01.06.2018 08:55:00 Проблема по-прежнему сохраняется в V6.42.3. Есть какие-нибудь мысли, когда этим займутся?

giallone Guest	#13 0 01.11.2019 17:26:00 Проблема по-прежнему возникает в последних версиях. Есть какие-нибудь мысли, будет ли это хотя бы немного исправлено?

vmiro Guest	#14 0 26.11.2019 07:22:00 Привет, возникла такая ситуация с моим роутером на ROS 6.43.14 (long-term).

giallone Guest	#15 0 26.11.2019 08:20:00 Ситуация даже хуже с ROS 6.43.14 (long-term). Я вынужден прописывать перезагрузку при 8% использовании /ip route cache get cache-size. Это неприемлемо, и меня заставляет перезагружаться раз в день, отключая все VPN.

pe1chl Guest	#16 0 26.11.2019 10:24:00 Надеемся, что версия 7 выйдет в стабильной форме в ближайшее время. В зависимости от того, как ты используешь роутер, возможно, можно будет протестировать бета-версию.

giallone

Guest

#17

26.11.2019 10:48:00

Большое спасибо за ответ, pe1chl! К сожалению, я обнаружил проблему, когда окружение уже обслуживало 46 клиентов, а сегодня их количество резко возросло. Тестировать бета-версию с ними – это точно не вариант. Скрипт перезагрузки всё ещё менее рискованный, чем возможные катастрофы, которые могут произойти при использовании бета-версии.

pe1chl

Guest

#18

26.11.2019 12:35:00

Решение запускать бета-версию v7, скорее всего, зависит больше от доступного набора функций (не все функции доступны) чем от стабильности. Стабильность, вероятно, в порядке (частых жалоб на это я не видел), но просто может не уметь делать то, что вам нужно. (если ваш роутер — только OpenVPN-сервер, скорее всего, проблем не будет).

giallone

Guest

#19

26.11.2019 12:51:00

Ты вообще в курсе каких-нибудь улучшений с этой стороны, или каких-то изменений в реализации этой функции, чтобы я мог надеяться правильно решить проблему? У меня просто OVPN/L2TP сервер, включая кучу netmaps и Mangles.

pe1chl Guest	#20 0 26.11.2019 13:19:00 Ну, в новых ядрах Linux, используемых в v7, поддержка IP-маршрутной кэш-памяти больше не реализована, так что эта известная проблема больше не должна возникать. В OpenVPN на v7 также есть другие улучшения.

Читают тему

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