[teer]

Есть CCR1009-8G-1S-1S+, софт теперь уже последний текущий, 6.32.3. Конфиг довольно объёмный, так что попробую в общем описать ситуацию.

 

Занят один гигабитник, через который приходит нетегированный трафик и несколько десятков dot1q-сабинтерфейсов. Итого около сотни connected-сетей (несколько сотен ARP-записей). Запущен PPTP-сервер, активных туннелей в среднем три-четыре десятка (с MPPE). Одна PCQ-очередь. Запущен OSPF, около двух десятков соседей. Из соображений безопасности весь трафик проходит через IP firewall (pptp/vlans), там фильтруется (в основном по address-list-ам) и чуть-чуть натится. Несколько десятков статических маршрутов плюс по OSPF прилетает две с лишним сотни, итого не более полутысячи записей в FIB. Включен экспорт Netflow. LCD выключен.

 

Трафика не более 30Mbps в дуплексе, загрузка CPU 2-4%. Всё настроено, всё работает. Ошибок на физике или в логе не видно (если не считать надоедливых OSPF Discarding packet: locally originated).

 

НО есть проблемы. Основная такая: в непредсказуемый момент времени перестаёт форвардиться трафик через один из dot1q-интерфейсов (за ним дюжина OSPF neighbour-ов с кучей анонсов роутов, для них на интефейсе слегка уменьшен MTU). Т.е. теряется связь со всеми сетями за данным сабинтерфейсом, в т.ч. прилетевшие по OSPF. Что интересно: в момент возникновения проблемы с самого CCR всё отвечает, всё пингуется, но с других устройств не откликаются даже устройства с сегменте этого интерфейса. Таблица маршрутизации при этом не меняется, /ip route print where X.X.X.X in dst-address по прежднему показывают 1) дефаулт роут 2) blackhole supernet и 3) connected.

 

Выключение всех правил /ip firewall (filter/nat/mangle) не помогает. Передёргивание OSPF-интерфейса или OSPF-инстанса не помогает. Помогает тупая перезагрузка. Хреново, что у самого CCR всё доступно, так что даже netwatch не настроишь. И как такое отлаживать?

 

Вторая проблема в том, что OSPF-роуты начинают работать, внезапно, только после перезагрузки (хотя присутствуют в FIB). Но это уж мелочь.

 

P.S.: пользователь на железке один, вмешательство исключено.

P.P.S.: это замена Cisco7201, она с аналогичным конфигом работала стабильно, тоже не особо напрягаясь.

Изменено 6 ноября, 2015 пользователем teer

[SyJet]

Гадание на кофейной гуще.

А вообще, из философского, нахрена было с нормального железа перепрыгивать на это гавно? Можно не отвечать - никто ещё не смог ответить, чтобы были понятны причины..

ПыСы

С такой нагрузкой и 7301 справиться, и ценой как сотовый телефон.

[saaremaa]

Попробуйте обновиться до последней RC. По другому IMHO никак

What's new in 6.33rc37 (2015-Oct-30 13:04):

 

*) net - fix possible never ending loop when bad CDP discovery packet is received;

*) log - make default disk file name to reside in flash dir if it exists;

*) romon - change port list to be unordered in export;

*) capsman - limit number of simultaneous DTLS handshakes;

*) capsman - fixed memory leak on CAP joining CAPsMAN when ssld is used;

*) DHCP-PD client - timer problem fixed;

*) winbox - added allow-fast-path to eoip, gre & ipip;

*) winbox - do not show power-cycle properties on non poe ports;

*) l2tp: implemented PPPoE over L2TP in LNS mode, RFC3817;

*) webfig - some of the setting were shifted to the right;

*) packages - allow to reinstall from bundle to separate packages & vice versa;

*) packages - prefer out of bundle packages when both of them are installed;

*) packages - fix a problem of upgrading bundle package to non bundled ones;

*) ipsec - force flow cache validation once in 1h;

*) dhcpv6-client - show current server address;

*) dhcpv6-client - split out IA ops;

*) winbox - make sure that all setting names get shown in full;

*) winbox - added poe power-cycle-ping settings to ethernet interfaces;

*) ppp - handle properly case were ppp client is given same address for local & remote end;

*) winbox - added vlan-mode & vlan-id to virtual-ap interface;

*) winbox - added timeout column to ipv6 address lists;

*) winbox - show SFP Tx/Rx Power properly;

*) winbox - added min-links to bonding interface;

*) winbox - do not show health menu on RB951Ui-2HnD;

*) winbox - added support for Login-Timeout & MAC-Auth-Mode in hotspot;

*) cerm - added option to disable crl download in '/certificate settings';

*) winbox - make user ssh key import work again;

*) webfig - make "Copy to Access List" work in CAPsMAN Registration Table;

*) userman - fix report generation problem which could result in some users being skipped from it;

*) winbox - fix to allow cpu-port as mirror-target

*) proxy - error.html parsing enhancement to improve performance

*) CCR1072 - improve ether1 performance under heavy load

*) routerboard - indicate RouterBOOT type in /system routerboard print;

*) mpls - properly use mpls mtu for routes;

*) cerm - fix key decription for signed certificates;

*) trafflow - report flow addresses in v1 and v5 without NAT awerness;

*) dhcpv6 - small fixes for dhcp-pd client and ippool6;

*) hotspot - add mac-auth-mode setting for mac-as-passwd option;

*) hotspot - add login-timeout setting to force login for unauth hosts;

*) auto-upgrade - fixed auto upgrade for smipsbe;

*) dns - do not create duplicate entries for same dynamic dns server addresses;

*) ipsec - fix set on multiple policies which could result in adding non existent dynamic policies to the list;

*) email - allow server to be specified as fqdn which is resolved on each send;

*) fastpath - eoip,gre,ipip tunnels support fastpath (new per tunnel setting "allow-fast-path");

*) ppp, pptp, l2tp, pppoe - fix ppp compression related crashes;

*) cerm - also accept downloaded CRLs in PEM format;

*) userman - added 'history clear' to allow flushing undo history, which may take up significant amount of memory for huge databases whith hundreds of users;

*) health - fix voltage for CRS109, CRS112 and CRS210 if powered from external adapter;

*) userman - added phone number support to signup form;

*) ip pool6 - try to acquire the same prefix if info matches recently freed;

*) ipsec - fix transport mode ph2 ID ports when policy selects specific ip protocol on initiator;

*) ipsec - use local-address for phase 1 matching and initiation;

*) route - fixed crash on removing route that was aggregated;

*) ipsec - fix replay window, was accidently disabled since version 6.30;

*) ssh - allow host key import/export;

*) ssh - use 2048bit RSA host key when strong-crypto enabled;

*) ssh - support RSA keys for user authentication;

*) wlan - improved WMM-PowerSave support in wireless-cm2 package;

*) pptp & l2tp - fixed problem where android client could not connect if both dns names were not provided (was broken since v6.30);

*) auto upgrade - added ability to select which versions to select when upgrading;

*) quickset - fixed HomeAP mode;

*) lte - improved modem identification to better support multiple identical modems;

*) snmp - fix system scripts table;

*) tunnels - eoip,eoipv6,gre,gre6,ipip,ipipv6,6to4 tunnels now support dns name as remote address;

*) fastpath - active mac-winbox or mac-telnet session no longer suspends fastpath;

*) fastpath - added per interface fastpath counters;

*) fastpath - added trafflow support in basic ipv4 and fasttrack ipv4 fastpaths;

*) ppp - added on-up & on-down scripts to ppp profile;

*) winbox - allow to specify dns name in all the tunnels;

*) pppoe - added support for MTU > 1492 on PPPoE;

*) cerm - fix scep server certificate-reply degenerate PKCS#7 signed-data content;

*) ppp-client - added default channels for Alcatel OneTouch L100V;

*) defconf - fix for boards that had bridge with only wlan ports;

*) ovpn: support OpenWRT ovpn clients (or any other with enable-small option enabled);

*) cerm - use certificate file name for imported cert name;

*) fetch - fixed error message when error code 200 was received;

*) cerm - rebuild crl for local ca if crl file does not exist;

*) winbox - make directed broadcasts work for neighbor discovery;

*) upnp: automatically adjust mappings to new external ip change;

*) ppp - added ppp interface to upnp internals/externals if requested;

*) ppp - when adding ipv6 default route use user provided distance;

*) userman - allow to correctly enable CoA on router;

*) cerm - also accept downloaded CRLs in PEM format;

*) cerm - show crl nextupdate time;

*) ppp - added CoA support to PPPoE, PPTP & L2TP (Mikrotik-Recv-Limit, Mikrotik-Xmit-Limit, Mikrotik-Rate-Limit, Ascend-Data-Rate, Ascend-XMit-Rate, Session-Timeout);

*) ppp - added new option under "ppp aaa" - "use-circuit-id-in-nas-port-id";

*) userman - refresh active sessions/users view dynamically;

*) package - added version tag and show everywhere alongside of version number;

*) wlan - improved 802.11 protocol single connection TCP performance for ac chipset with cm2 package.

 

[teer]

А вообще, из философского, нахрена было с нормального железа перепрыгивать на это гавно? Можно не отвечать - никто ещё не смог ответить, чтобы были понятны причины..

Потому что циска достала своими мелкими глюками, а тут ещё потребовалась именно такая модель в другом месте. Ну и учитывая (небольшой) положительный опыт с микротыком, подумал что под такую небольшую и некритичную нагрузку (управление/мониторинг) CCR будет в самый раз (что сложно налажать в такой простой конфигурации). Финдиректор был доволен после ASR-ров :-)

 

А что вообще из "нормального" можно поставить под такое дело? ASR не хочется, ибо так понимаю там только L2TP+IPsec. Ну и цена, конечно. Если вообще привезут.

[Saab95]

А что же не попробовали выключить и включить проблемный интерфейс, выключить и включить IP адреса на нем, проверить, проходит ли мультикаст и т.п.

Все проблемы и глюки, которые возникают с микротиками, от не правильной настройки обычно возникают.

[rz3dwy]

Saab95, написали же, что в произвольный момент. Причем тут неправильная настройка? А траблшутинг включением/выключением не работает.

[teer]

А что же не попробовали выключить и включить проблемный интерфейс, выключить и включить IP адреса на нем, проверить, проходит ли мультикаст и т.п.

Все проблемы и глюки, которые возникают с микротиками, от не правильной настройки обычно возникают.

 

Пробовал, просто не все шаманские пляски описал. Мультикаст проходит (CDP/MNDP/OSPF).

[Saab95]

Если у вас и с другой стороны микротик, то нужно через торч посмотреть какие данные уходят и приходят на интерфейс. Так же нужно проверить линию между ними, например коммутаторы и т.п. Попробовать поменять мак адрес на интерфейсе. На этом форуме уже как-то описывали похожую проблему, где виной оказался коммутатор, который, по какой-то причине, переставал передавать пакеты по некоторым макам, после его замены все нормализовалось.

[teer]

Если у вас и с другой стороны микротик, то нужно через торч посмотреть какие данные уходят и приходят на интерфейс. Так же нужно проверить линию между ними, например коммутаторы и т.п. Попробовать поменять мак адрес на интерфейсе. На этом форуме уже как-то описывали похожую проблему, где виной оказался коммутатор, который, по какой-то причине, переставал передавать пакеты по некоторым макам, после его замены все нормализовалось.

 

Торчем я смотрел пару раз. Не уверен, что так было во всех случаях, но не видел исходящего трафика на dot1q-сабинтерфейсе. Кстати, до текущей перезагрузки, видел раз торчем что не проходил ответ из-за данного сабинтерфейса, причём только на один IP-адрес (с другого адреса той же подсети всё работало). Сейчас уже не воспроизводится.

 

Так что до коммутаторов даже дело не доходит. Но наверное действительно стОйт посмотреть за ARP-таблицей, может там что-то меняется. И ARP попробовать поотлаживать.

 

Upd: Упс, а на микротыке нет отладки ARP :-(

Изменено 6 ноября, 2015 пользователем teer

[SolarW]

Все проблемы и глюки, которые возникают с микротиками, от не правильной настройки обычно возникают.

Тоже так считал очень долгое время.

Пока в один прекрасный момент не догнал меня один глюк:

- CCR1009 стоящий в качестве центрального роутера сравнительно небольшой сетки не стал повисать на полном скаку.

Причем повисание выглядит как полное "отсыхание" сетевой части, вплоть до того что на присоединенных к нему устройствах показывается ether down.

Сам CCR1009 при этом где-то у себя внутри считает что у него все зашибись - watchdog его не сбрасывает, на команды в консоли (через COM-порт) отвечает, просто не видно никого по сети становится с него.

Правда не на все команды в консоли живут - system reboot приводит к зависанию консоли.

При этом стоявший на этом же месте RB1200 и подставленный на время наименьшей нагрузки RB2011 с полностью аналогичным конфигом жужжат и есть не просят.

Т.е. бага именно в реализации RouterOS под архитектуру CCR, PowerPC и MIPS BE не подвержены такому глюку с такой же версией системы и одинаковых настройках.

Как это выяснил?

Примерно за месяц танцев с бубном выяснилось что гарантированное подвисание CCR1009 можно вызвать... перегрузив некий RB SXT на краю географии (при этом топология сети по OSPF перестраивается).

Причем именно перезагрузка на этом месте - остальные части сети также видные по OSPF сколько не перегружал все без толку...

Пару месяцев общения с саппортом ни к чему не привели.

Хотя вызывал сбой, с консоли создавал supout.rif во время сбоя, отправлял им его неоднократно - ничего критичного в нем не нашли.

Пришлось достать из кучи хлама Lightcom NetPing древнючий и подпереть им высокотехнологичное устройство от Mikrotik...

 

А что касаемо правильных настроек - вроде наловчился делать таковые за более чем 10 лет работы с этой операционкой...

BGP, OSPF, EoIP-туннели, шейпинг - в общем ничего критичного...

 

P.S. Можно еще рассказать про одно место где я никак не могу поднять версию операционки выше чем 6.27 - при подъеме тупо перестает работать сегмент клиентов приходящих на этот микротик через управляемый свитч в неком VLAN'е и через бридж уходящих на другой микротик на еще один свитч в другом VLAN'е... при этом по ARP все видно но пинги не ходят :-). Но по сравнению с первоначально описанной проблемой - это так, мелочи...

Изменено 9 ноября, 2015 пользователем SolarW

[avb1987]

Немного не по теме, но у нас также были глюки и с внезапным зависанием сразу трех (!) CCR в один момент, повторяющиеся без всякой закономерности и неработающий watchdog, и зависание при reboot из консоли. После обновления до последней версии начал глючить RIP (после перезагрузки маршруты приходят а затем через какое то время обновления перестают восприниматься и они пропадают на какое то время). Лечится перезагрузкой или передергиванием RIP-нейборов.

 

Если как вы говорите в таблице маршрутизации везде все норм - пробуйте ставить другую версию, например 6.30.4 или последнюю RC.

Если же маршруты пропадают, попробуйте использовать BGP вместо OSPF - решение конечно кривоватое, но работает стабильнее.

[verhoum]

Может глупость скажу, а если переехать с CCR на x86/mips?

[pppoetest]

Если уж и переезжать на PC, то и ОСь тоже лучше сменить.

[Saab95]

Эти все проблемы не от микротика, а от связанных с ним железок.

[avb1987]

Эти все проблемы не от микротика, а от связанных с ним железок.

Вы тег irony забыли :)

[Ivan_83]

Эти все проблемы не от микротика, а от связанных с ним железок.

Если железки гадят то почему сеть то у тика отсыхает?

Почему тик такой задохлик что ложится под каждую гадливую железку?

[tartila]

Эти все проблемы не от микротика, а от связанных с ним железок.

 

Знаете, в сети каждый день случаются проблемы - Ethernet дал почву для развития таких проблем, которые и не очевидны на первый взгяд. На пограничных свитчах ставятся фильтрующие правила для аномальных пакетов, которые уже успевали проскочить на центральный L3 свитч и там вызвать большой CPU Usage, но не навредив при этом клиентам. На этом L3 свитче пишутся control-plane ACL для того, что бы аномальные пакеты не уходили в CPU свитча. И все работает годами... Почему у одного тика происходит повисон, который даже нельзя вылечить по /sys reboot ? Стоит у меня такой CCR - 1036... Хлебнул я с ним тоже говнеца. Видимо, причина все же не в шаманских "правильных настройках" и не в мыльницах-плохишах... А в смешных багах аля infinite loop on broken CDP packet received :)

[teer]

Спустя пять дней аптайма, внезапно, снова накатило.

 

Что интересно, оказалось, что проблемная сеть на dot1q пингуется с CCR-а только с SRC-адреса из этой сети. С SRC-адресов других сетей (откуда идут сервера мониторинга, которые, собственно, и поднимают тревогу) маршрутизатору тоже не отвечают. Как и обсуждалось, в отсутствии отладки ARP, просто сравниваю ARP-таблицу в нормальной и проблемной ситуации и вижу:

 

teer@teer ~ $diff -U0 arp_good.txt arp_BAD.txt |grep 192.168.127.
-IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.188 = STRING: 0:20:a:b0:b4:4e
+IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.188 = STRING: 0:20:a:b0:cd:9f
+IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.202 = STRING: 0:20:a:b0:b3:e0

teer@teer ~ $egrep 0:20:a:b0:cd:9f arp_good.txt                  
IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.217 = STRING: 0:20:a:b0:cd:9f

teer@teer ~ $egrep 0:20:a:b0:cd:9f arp_BAD.txt                   
IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.188 = STRING: 0:20:a:b0:cd:9f
IP-MIB::ipNetToMediaPhysAddress.28.192.168.127.217 = STRING: 0:20:a:b0:cd:9f

 

Т.е. один из OSPF-пиров на проблемном интерфейсе сменил (!) MAC-адрес, устроив конфликт (саму железку я проверил, она ни сном ни духом). В логе в момент возникновения проблемы тоже не пусто:

 

Nov 11 09:22:31 MAS OSPFv2 neighbor 192.168.127.225: state change from Full to Init

Nov 11 09:23:11 MAS OSPFv2 neighbor 192.168.127.225: state change from Init to Down

Nov 11 09:31:49 MAS Discarding packet: routerID is zero

Nov 11 09:31:49 MAS source=192.168.127.225

 

Сравнение списка и состояния OSPF-пиров подтверждает, что DR/BDR в сегменте поменялись.

 

Ещё раз посмотрел торчем, подтвердил, что входящие пинги приходят на CCR, но в проблемный сегмент не улетают.

 

Далее т.к. не было больше идей, обновился до 6.33. Помогло, после ребута связь сразу же появилась. MAC-адрес у 192.168.127.188 вернулся старый. Пинг с CCR с src-ip мониторинга пошел.

 

Получается, в данном конкретном случае, Saab95 прав - похоже, что-то нехорошее происходит в ethernet-сегменте, на L2. Другое дело, что это не повод так позорно глючить (циска же работала стабильно). Жалко, что /tool netwatch не поддерживает указание src-ip, хоть автоматизировать костылелестроение.

 

Upd: проверил, количество роутов не уменьшалось. Наоборот, непосредственно перед ребутом было рекордное 452 штуки.

 

P.S.: есть и хорошие стороны. Реально начала работать галка use-encryption=required в PPP-профиле. Т.е. клиенты без поддержки шифрования перестали подключаться. Плюс, пока не видел случая, чтобы было Encryption got out of sync - disabling на ходу. Теперь хорошо бы ещё аналог цисковских source-ip, чтобы можно было разные профили PPP привязывать к разным входящим интерфейсам.

Изменено 11 ноября, 2015 пользователем teer

[teer]

Ан нет, дело не в собственно dot1q-интерфейсе. Только сейчас проверил потери пакетов по всем хостам в этом ethernet-сегменте. Потери были только до 8-ми хостов из 13 железок данного типа (все они являются OSPF-пирами). Ещё полтора десятка разных железок пинговалось штатно.

[saaremaa]

На бриджах включен RSTP?

[teer]

На бриджах включен RSTP?

На самом CCR один бридж без портов и без *STP, используется как Loopback-интерфейс.

 

На свичах проблемного ethernet-сегмента дикая солянка из PVST+, PVRSTP+, CST, MST, каталистов, длинков и безымянных неуправляшек. На умном железе мониторю BRIDGE-MIB, блокировок там не замечено.

[saaremaa]

На свичах проблемного ethernet-сегмента дикая солянка из PVST+, PVRSTP+, CST, MST

Как вариант попробуйте зафильтровать BPDU в сторону CCR. Из нашей практики были проблемы если на бриджах CCR был включен *STP.

[teer]

На свичах проблемного ethernet-сегмента дикая солянка из PVST+, PVRSTP+, CST, MST

Как вариант попробуйте зафильтровать BPDU в сторону CCR. Из нашей практики были проблемы если на бриджах CCR был включен *STP.

 

Спасибо, попробую...

 

Странно, как раз после обновления на 6.33 появились TX Drops на dot1q-интерфейсе серверов (где мониторинг).

[Saab95]

Если микротик работает роутером OSPF, то обязательно указание его Router ID вручную, т.к. если он не указан, то он берет любой попавшийся IP со своих интерфейсов. Если этот интерфейс окажется неактивным, то произойдет смена Router ID на другой и кратковременная потеря связи.

[teer]

Если микротик работает роутером OSPF, то обязательно указание его Router ID вручную, т.к. если он не указан, то он берет любой попавшийся IP со своих интерфейсов. Если этот интерфейс окажется неактивным, то произойдет смена Router ID на другой и кратковременная потеря связи.

 

Уже так и сделано, ICND1/2 читан :-) (стати, RouterID там исторически является IP-шником маршрутизатора из серверной сети). Ни один интерфейс не падает (PPTP не в счёт), т.к. не падает физический линк до свича.

 

Ну и в любом случае, кратковременная потеря связности пока не сойдётся OSPF это несколько не то же самое что, "связи нет неопределённо долго, пока не перезагрузишь".