Проблемы с EDR-810

[means_nothing]

Здравствуйте, стоят два EDR-810, схема и конфигурации во вложении.
Стояла у них прошивка 4.1, решили прошить на 4.2. После прошивки слетели конфигурации у обоих. настроили заново, вроде стало все нормально.
Проходит недели 2, точно не скажу, и у них перестает работать конфигурирование, как по telnet, так и через web, хоть и пингуется... проходит еще парочка недель и перестает работать Broadcast Forwarding, опять же на обоих EDR-810. После этого мы уже поехали на объект решать проблему. Как выяснилось, по RS-232 они тоже не отвечают, на reset не реагируют. После снятия и подачи питания заработали оба в полном объеме. Проходит еще пара недель и вот сейчас у одного из них не работает и конфигурирование и  Broadcast Forwarding, у второго пока все нормально. 
Видел новую прошивку 5.0, но в истории изменений не нашел похожую проблему.

Что делать и как с этим бороться?

Серийные номера:
TAGBD1052530
TAGBD1052602

 

[Незнайка]

Добрый день.

Судя по описанию, это похоже либо на некий DoS, либо на утечку памяти. Видимо, в данном случае это связано с использованием модуля Broadcast Forward, как с редко используемой функцией. Но в этом случае, в 4.2 нам её уже всё равно не пофиксят, так что моё предложение всё таки поставить 5.0 и, в случае повторения проблемы, тогда уже прислать новые конфигурационные файлы, которые можно будет предоставить производителю.

[means_nothing]

Ладно, как второй маршрутизатор откажется выполнять свои функции, попробуем  перепрошить оба на 5.0.

[means_nothing]

Второй маршрутизатор по такой же схеме отказал.
А есть ли у вас возможность протестировать данный баг? А то у нас они стоят только на одном удаленном рабочем объекте, там не до экспериментов.

[Незнайка]

Плохо

Можно попробовать, только для тестирования нужно создать те условия, в которых данный дефект воспроизведётся.

Если я их просто залью конфигурацию - есть уверенность, что дефект воспроизведётся "в статике", без трафика?

Или предложите свой вариант теста?

[means_nothing]

Ну можно попробовать по такой схеме. По всем TCP соединениям у нас в среднем по 10 пакетов(~100байт каждый) в секунду. Широковещательный UDP где-то по 20 пакетов (~200байт каждый) в секунду.

 

[Незнайка]

Да, схема хорошая.. Но, конечно, непростая в части оборудования..

Напишете мне, пожалуйста (в ЛС), что это за организация и что за объект?

[Незнайка]

UDP точно 2000 байт? Фрагментируется?

[means_nothing]

вроде 200 написал)))) 

[Незнайка]

Дайте, пожалуйста, всё таки некие дампы (pcap) этого TCP и UDP трафика. UDP у нас откуда лететь должен в этой схеме?

Трафик можно снять через Port Mirroring на EDR.

[means_nothing]

Трафик с EDR снять не могу, у них же конфигурирование недоступно.
Вот снял ориентировочные pcap для TCP и UDP(трафик в реале более плотный чем в этом дампе, см. выше).
По схеме:
UDP летит с 10.0.1.1:980;
TCP сервер 10.0.1.33, к нему подключаются 2 клиента(10.0.101.1 и 10.0.0.2), ведется обмен в протоколе iec 60870-5-104;
TCP сервер 10.0.1.1, к нему подключается 1 клиент(10.0.0.2), ведется обмен в протоколе iec 60870-5-104.

Если надо что-то более подробное, то соберу стенд приближенный к реальности по трафику.

TCP.pcapng

UDP.pcapng

[Незнайка]

Добрый день!

Подготавливаясь к тестированию, возникли следующие вопросы:

1.Каковы полные сетевые настройки конечных устройств. Можно ли просто поставить шлюзы по умолчанию на интерфейсы соответствующего VLAN ближайшего EDR?
2.Зачем нужны правила NAT? Просьба пояснить логику их создания. На текущих настройках (с default gateway на устойствах и Static route между EDR) и так всё работает.
3.Адреса 10.0.0.1, 10.0.0.2 не присутствуют на схеме. Убрать это правила?

[means_nothing]

10.0.0.2 на схеме есть, самый правый элемент, это основной сервер. 10.0.0.1 это резервный сервер, его на схеме не указывал(можно убрать правила).

на 10.0.0.2 можно поставить шлюз по умолчанию 10.0.0.100
на 10.0.1.1 шлюз 10.0.1.29
на 10.0.101.1 и 10.0.1.33 шлюзы не нужны.

NAT 10.0.0.1   172.28.198.77  - для организации 2-х одновременных TCP соединений(между 10.0.0.2 и 10.0.1.1) по двум независимым каналам + это требование одного из TCP-клиентов, не указанного на схемах.
остальные NAT для TCP соединений 10.0.0.2 - 10.0.1.33 и 10.0.101.1 - 10.0.1.33  опять же по 2-м независимым каналам.
По идее для 10.0.1.1 нужно было бы аналогичный  набор NAT делать, как для 10.0.1.33, но из-за особенности работы 10.0.1.1 обошлось только одним NAT и там даже шлюз не указан в реальной схеме.
Глядя на схему в первом сообщении должно быть более ясно, зачем все это сделано.
А в тестовой схеме, кончено, можно заставить все работать без NAT, но с NAT это типа приближение к реальности по нагрузке на маршрутизатор

 

[Незнайка]

Подпишите пожалуйста, для всех 4х правил NAT (кроме 10.0.0.1) Outside interface, Local IP и Global IP. А то я не очень понимаю, как пакет следующий с 10.0.0.2 к 10.0.101.1 должен попадать в VLAN 11, если он попадёт в VLAN 101

[means_nothing]

[Незнайка]

Вчера запустили тестирование по маленькой схеме, посмотрите пожалуйста конфиги и трафик, всё ли мы учли. 

EDR Left.ini

EDR Right.ini

TEST.pcap

[means_nothing]

посмотрел по-быстрому. не увидел tcp 10.0.0.2 на 10.0.101.11(увидел только уже за NATом 10.0.1.58 на 10.0.1.33), не увидел tcp 10.0.0.2 на 172.28.198.77(есть только прямое с 10.0.0.2 на 10.0.1.1)

по настройкам правого:
ip route static WAN2 10.0.1.32 255.255.255.224 172.28.198.77 1 не нужно

ну и wan я вообще не пользовался, но, думаю, это не принципиально

[Незнайка]

Угу, это мы не там pcap записали. Маршрут был выключен, убрали совсем что бы не смущал. Посмотрите ещё раз, плз.

EDR Left.ini

EDR Right.ini

TEST.pcap

[means_nothing]

ага, не заметил строкой ниже WAN2 disable)
Сейчас все вижу по трафику, единственное, поплотнее бы его, особенно UDP, раз есть подозрение на загрузку маршрутизатора модулем broadcast forward.

В 10.10.2018 в 10:56, means_nothing сказал:

По всем TCP соединениям у нас в среднем по 10 пакетов(~100байт каждый) в секунду. Широковещательный UDP где-то по 20 пакетов (~200байт каждый) в секунду.

 

 

Кстати дальше пока ничего не отрубается у наших маршрутизаторов. Конфигурирование и broadcast forward не работает, все остальное без сбоев.
Позаказали еще таких же маршрутизаторов на другие объекты еще до этого неприятного случая, надеюсь, удастся найти работоспособную прошивку, удовлетворяющую нас.

[Незнайка]

Ок, уплотним. Ну я тоже надеюсь

Всё, тогда ждём. Напишу как чего.

[means_nothing]

Пока все исправно работает???
Если вдруг все-таки виноват broadcast forward, то сделаю по-другому.
Если на схему в первом посте смотреть, то для того чтобы комп с двумя сетевыми картами(c 802.1q они не дружат) 10.0.101.1 и 10.0.102.1 получил broadcast c 10.0.1.1 по двум каналам, то нужно просто на обоих маршрутизаторах на portG2 добавить по 10vlan в Trunk, а на обоих коммутаторах port2 настроить на hybrid и передавать vlan10 нетегированным))
Не знаю даже, почему мне сразу такая идея в голову не пришла. 

[Незнайка]

Пока да, работает. Но мы с 5.0 проверяем.

При использовании гибридных портов можно получить флуд во все VLAN - но попробуйте...

[means_nothing]

Ну что, не было сбоев в работе?

[Незнайка]

Нет, пока не было. Но тут дело в том, что никак не можем наработать 30 дней, то питание упадёт, то просто кто то комп выключит... Пока максимум 2 недели uptime получился... Сам в шоке

[means_nothing]

Да просто уже через неделю мне в руки попадут новенькие EDR-810, сам уже и погоняю их).
А те, что на объекте стоят, по-прежнему пашут бесперебойно, за исключением  Broadcast Forward и конфигурирования.