ICMP проблем ccr1072-1g-8s+

[gbdesign]

Здравейте. Някой от Вас ползва ли ccr1072-1g-8s+? Имам супер странен проблем с ICMP с такъв. На около 2 седмици, загубва способността си да пингва всичко, включително и локалният хост. В същото време отвън си отговаря на icmp - ping. Ползвам рутера за прекалено много неща, за да мога да имам предположение, какво може да причинява проблема. Конфигурацията с незначителни промени, работеше до скоро на ccr1036-12g-4s и никога не съм имал никакви проблеми с него. Даунгрейдвах до BugFix версията (6.37.5) но проблема остана. След рестарт на рутера всичко си заработва нормално и според очакванията и така около 2 седмици и проблема се повтаря. Писах до Микротик, но за сега отговор нямам. 

[111111]

Stable версии не ползваш ли?

Постни филтрите.

[gbdesign]

Ползмам си стандартни версии. Сега ъпгрейднах до последната, пък ще видим. Конфигурацията ми е прекалено дълга за форума. Примерно адресните листи са над 60 000 реда. Просто по някога нелогичен проблем има нелогично решение, та за това питам, дали и друг не го е ял и не е открил случайно решение. Явно не са изкусурили софтуера за хардуера на този модел, Иначе най-общо казано, интерфейсите ми са два по два в бонд с LACP вързани към суичове в стак. Върху бондовете има и вилани. Сложничка е конфигурацията, но да не мога да си пингна локалният хост, не е до конфигурация.

[111111]

Имаш правило което го забранява

Винаги може да позваш JUMP правила 

както и TORCH

[gbdesign]

Имам такова правило, но има и листа с позволени адреси и то важи само на ъплинка. Проблема се появява сам, от нищото и се оправя с рестарт на рутера. Губя всички статични маршрути, заради което някои неща спират да работят. Не че не мога да пусна OSFP или BGP но рутера е в продукшън и всяко дори и секундно прекъсване е нежелателно, както и по сериозни промени по конфигурацията, които могат да доведат до прекъсвания. Рутера отвън си отговаря на ICMP. Тоест не се троши напълно протокола, но той става неспозобен да произвежда такива пакети. От Микротик нищо не отговарят. Ако се ошашави пак, ще се наложи да си върна CCR10-36. За няма и 2 месеца 3 пъти се случва тая тъпня.

[kokaracha]

Започна със загуба на пинг  и стигна до загуба на рутинг,споменаваш за 2 различни проблема. Проблема е в стената или рутинга и там трябва да гледаш.

[gbdesign]

Рутингите се губят, защото рутера мониторира гейтовете им с ICMP. Като получава request time out си бележи маршрутите, като неактивни и насочва пакетите през дифолт гейта. Резултата е загуба на връзки.  Ако беше до филтри, нямаше да се оправя с ребут.

 

Редактирано 8 Юни, 2017 от gbdesign

[111111]

Направи една адресна група с тези които могат да пингват и забоди правилото за разрешение най-отгоре.

Ако влизат на различни интерфейси може да направи интерфейс група за правилото.

[kokaracha]

Махаш проверката и почваш да слушаш  вход/изход на проблемните интерфейси за този трафик къде и кога се губи/отива.Гейта си е гейт,статичното рутиране ти пада поради  проблем филтър/интерфейс/пренос.

[gbdesign]

/ip firewall filter
add action=drop chain=input comment="Drop access to service ports" dst-address=1.2.3.4/28 dst-port=222,1723,8291,2000 protocol=tcp src-address-list=!AllowList
add action=drop chain=input comment="Drop Invalid Connections" connection-state=invalid
add action=accept chain=forward comment="Allowed IP Address" src-address-list=AllowList
add action=accept chain=forward comment="Allowed IP Address" dst-address-list=AllowList
add action=tarpit chain=input comment="Drop Syn-flood Atacker" connection-limit=10,32 in-interface=WAN protocol=tcp src-address-list=SynFlood
add action=add-src-to-address-list address-list=SynFlood address-list-timeout=1h chain=input comment="Syn-Flood Atacker Detect" connection-limit=50,32 in-interface=WAN log=yes log-prefix=SynFlood protocol=tcp tcp-flags=syn
add action=drop chain=forward comment="Drop http DDoS Attacker" connection-limit=50,32 dst-port=80,443 in-interface=WAN protocol=tcp src-address-list=DropList
add action=add-src-to-address-list address-list=DropList address-list-timeout=5m chain=forward comment="Detect http DDoS attack" connection-limit=70,32 dst-port=80,443 in-interface=WAN limit=1,5:packet log=yes log-prefix=DDoS protocol=tcp src-address-list=!AllowList
add action=drop chain=input dst-port=222 in-interface=WAN protocol=tcp
add action=reject chain=input comment="Stop ping from Internet exept AllowList" dst-address=1.2.3.4/28 in-interface=WAN protocol=icmp reject-with=icmp-network-unreachable src-address-list=!AllowList

Аз ли грешно обяснявам или не можете да ме разберете. Всичко работи нормално и според очакванията за около 2 седмици, след което изведнъж рутера спира да може може да пингва дори себе си. Това се случва безпричинно и най-важното без човешка намеса. След рестарт  на рутера се оправя. Не става въпрос за грешка в конфигурацията, а за софтуерен бъг. Понеже рутера е в продукшън, не мога да си експериментирам. Идеята ми беше да питам, дали някой не се е сблъсквал с аналогичен проблем и да е открил причината, която го причинява. По-горе съм пуснал правилата във FILTER. Има и още, но те са и по сорс и по дестинейшън и са прекалено конкретни, за да имат глобално действие. Конфигурацията, като цяло е сложна /3MB plain text/ но работеше от години без никакви проблеми на CCR1036, който хардуерно е доста различен. На ниво настройки, съм експортнал в текстов файл същите от CCR1036, редактирал с текстов редактор имената на интерфейсите /ether1 става sfp-sfpplus1 и т.н./ и импортнал в CCR1072.  Идеята на подмяната беше да мина на SFP+ портове, които са по-безпроблемни от RJ-45 и да съм подсигурен с двойно захранване, през двата отделни кръга, така че евентуално инцидентно падане на предпазител, да не доведе до спиране на услуги. 

[111111]

Не че нещо, ама защо не ползваш RAW за DROP?

Част от правилата ти са безсмислени в частта INPUT,

това все пак са конекции до самия рутер а не към такива с NAT насоченост които са в FORWARD чеина.

/ip firewall {
	filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
	filter add chain=input action=accept connection-state=established,related comment="defconf: accept established,related"
	filter add chain=input action=drop in-interface=ether1 comment="defconf: drop all from WAN"
	filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
	filter add chain=forward action=accept connection-state=established,related comment="defconf: accept established,related"
	filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
	filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1 comment="defconf:  drop all from WAN not DSTNATed"
	}

Анализирай този пример 

[gbdesign]

Има светлина в тунела. От Микротик съпорта: "Seems that we have managed to find a cause of this issue and fix for that. We will soon release 6.40rc21 version with potential fix for this issue."

 

[MiPSus]

neighbor table overflow - нещоси някъде, друг въпрос е, че нямаш достъп за тунинг етц....

[gbdesign]

Бъг на РутерОС с точно този хардуер е. От Микротик, силно се надяват да са го фикснали и ако не ми направи мизерията в рамките на месец, ще вкарат фикса в официалните версии. Оказаха се сериозни хора и влязохме в много активна комуникация. Все-пак това им е най-скъпият рутер. 

[h3ll]

То хардуера е скъп, не софтуера. А затова дали са сериозни е малко смешно за разказване, но исках да кажа - не си мисли че си купил скъпо у-во.