Ошибка в кэше маршрутов IP

У меня такое же возникает на паре RB2011. Сеть перестаёт работать, а если зайти через консоль, то вижу:  
[user@Router] > /system resource print
                  uptime: 2w10h57m37s  
                 version: 6.4  
              build-time: Sep/12/2013 13:52:41  
             free-memory: 95.3MiB  
            total-memory: 128.0MiB  
                     cpu: MIPS 74Kc V4.12  
               cpu-count: 1  
           cpu-frequency: 600MHz  
                cpu-load: 1%  
          free-hdd-space: 110.6MiB  
         total-hdd-space: 128.0MiB  
 write-sect-since-reboot: 24631  
        write-sect-total: 106765  
              bad-blocks: 0%  
       architecture-name: mipsbe  
              board-name: RB2011UAS  
                platform: MikroTik  
[user@Router] > ip route cache print
     cache-size: 16383  
 max-cache-size: 16384  
[user@Router] > ping 8.8.8.8
HOST                                     SIZE TTL TIME  STATUS  
8.8.8.8                                                 таймаут  
8.8.8.8                                                 таймаут  
8.8.8.8                                                 таймаут  
                                                       132 (No buffer space available)  
                                                       132 (No buffer space available)  
                                                       132 (No buffer space available)  
   отправлено=6 получено=0 потеря пакетов=100%  

[user@Router] >

В моём случае мы сейчас не используем BGP или IPv6, но при этом применяем OSPF по ряду беспроводных соединений, из-за чего маршруты могут меняться довольно часто. Планируем скоро начать использовать BGP, а IPv6, возможно, появится позже, но пока что у нас только IPv4 и OSPF.

У меня это происходит на версии 6.7 на одном роутере, запущенном как x86 VM. Я видел, что кеш маршрутов полностью заполняется, и сеть просто переставала работать. Поскольку это виртуальная машина, я мог её перезагрузить и таким образом решить проблему. С этим роутером это случается периодически. Кроме запланированной перезагрузки, есть ли другие варианты решения? Посмотрите эту тему: http://forum.mikrotik.com/t/problem-with-mount-point/94/1 Там предлагают, что проблема исправлена в 6.5, но я так не считаю. В 6.7 она по-прежнему проявляется.

Да, проблема всё ещё очень заметна. У нас большая часть сети работает на версии 6.7, и она всё равно проявляется. Мы считаем, что в нашем случае проблема связана с IPIP туннелями. У нас много устройств, которые не используют IPIP туннели, но работают с динамическими протоколами, такими как OSPF, и у них подобных проблем нет. Однако ВСЕ устройства с IPIP туннелями сталкиваются с «разбеганием» кэша маршрутов и в итоге перестают нормально работать, если их не перезагрузить. Пока мы внедрили скрипт перезагрузки, который полностью предотвращает зависание устройств, но всё равно ОЧЕНЬ раздражает, что наши роутеры периодически перезагружаются. Я планирую обновить один из роутеров с IPIP до версии 6.9, чтобы проверить, сохраняется ли проблема. Также мы добавили мониторинг кэша маршрутов на наш сервер Cacti, что помогает следить за этой проблемой. Не смог найти соответствующий OID, так что реализовал это через скрипт, который входит под пользователем с правами только на чтение и парсит вывод для Cacti.

Эта проблема, похоже, гораздо сильнее проявляется в версии 6.11. Смотрите обсуждение здесь: http://forum.mikrotik.com/t/rb2011uas-2hnd-stops-responding-spontaneously/75301/18. Все признаки указывают на баг в PPP-коде от MikroTik. Мои проблемные роутеры — это те, на которых настроен L2TP.

«Чем больше всё меняется, тем больше остаётся по-прежнему.» Добро пожаловать в 2017-й. После 4 лет в эксплуатации у одного RB2011 внезапно появилась та же проблема вскоре после обновления с 6.37.5 до 6.39.1. (Обновление до 6.39.2 не помогло.) Техподдержка посмотрела supout и указала, что кэш маршрутов заполнен — о таком я раньше даже не слышал — но их объяснения (взлом или торренты?) не соответствуют ситуации. Этот роутер управляет трафиком в отеле и как минимум в трёх прыжках по приватным IP находится от граничного роутера с публичным IP. Он не использует BGP, IPv6 или PPP; только OSPF, бриджи, VLAN и очереди для приоритетной обработки SIP — точно так же, как у нас в каждом здании сети. И в данном случае есть всего один маршрут из здания, так что маршруты не должны меняться; всё либо на локальном интерфейсе, либо идёт через один интерфейс на роутере обратной связи на крыше. По их совету я выставил /ip settings route-cache=no. Размер кэша долгое время держался на однозначных числах, а потом резко стал расти до тысяч и за примерно 15 минут полностью заполнился (в нашем случае — 16К). При /ip settings route-cache=no! Я откатил всё оборудование в здании до 6.37.5 и заменил RB2011 на 1100XH2 (кэш размером 512К). Через 16 часов я вижу размеры кэша в пределах 2-3К (с route-cache=yes). Настроил уведомления на почту, если кэш превысит 10К. Если это окажется стабильным, обновлю до 6.39.2 и отпишусь. Скрестил пальцы, чтобы всё продолжало работать (чтобы была стабильная резервная позиция), но меня совсем не радует отсутствие объяснения проблемы.

У меня теперь такая проблема на RouterBoard, который обеспечивает обратную связь с мотелем по 5 ГГц. Он работает на OSPF, как и всё остальное наше оборудование, включая устройства в других зданиях с такой же конфигурацией. При включённом route-cache кэш растёт примерно на 1000 записей в день. Так что устройство может проработать около двух недель, прежде чем его надо перезагружать, чтобы очистить кэш маршрутов. Без route-cache кэш растёт примерно на 1 запись в секунду. Через 4,75 часа, как по часам, он заполняется и требует перезагрузки. Я тестировал так несколько дней подряд, и максимальное отклонение по времени работы — не больше 15 минут. Тут что-то не так. Но раз нет возможности посмотреть содержимое кэша для поиска причин и нет способа очистить его без перезагрузки, что делать? Я оставил route-cache включённым и настроил скрипт, который запускается ежедневно в 3 часа ночи: проверяет размер кэша, и если он больше 14000 из 16384, перезагружает устройство. Это, конечно, временное решение, но хотя бы автоматическое.

У нас есть пара сотен устройств MT с включённым OSPF — пару сотен примеров, которые работают без единой проблемы. За исключением наших пограничных роутеров, все наши MT кешируют меньше 1K маршрутов (у некоторых меньше 20) с включённым route-cache. И этот даже не самый загруженный. Мотель находится в конце своей ветки, так что канал не несёт трафик для других локаций, только для мотеля. Пара мегабит в каждую сторону, ничего особенного. (Он прямо на пляже, так что большинство гостей сюда не за Wi-Fi приезжает). Между мной и MT уже прошло десяток сообщений по этой проблеме. Они уверены, что именно трафик на этом объекте каким-то образом вызывает постоянный рост route-cache. Я подозреваю, что это баг, связанный с каким-то уникальным сочетанием настроек именно этой платы, потому что при отключённом route-cache он заполняется в 75 раз быстрее. (Не на 75%, а в 75 раз.)