Напишите пожалуйста потом, был ли хэппи-энд у этой истории? Данные спасены? Все причастные живы-здоровы?
И первое правило работы с серверами - не пытаться там что-то "улучшать", не разобравшись вначале досконально. Ибо слишком часто это плохо кончается.
Покажите хотя, что Avago MegaRAID Storage manager отображает. Статусы физических дисков, статус логического тома. Без этого можно только предполагать, что там случилось. Может, контроллер новый диск подцепил как одиночный, а может массив уже рассыпался и ребилдить нечего...
На новых микротиках с флешкой 16 мб корневой каталог теперь монтируется в виртуальный диск в оперативной памяти. Чтобы сохранить файл перманентно, нужно залить его в каталог /flash
По задаче я бы взял RB1100AHx4 в центр (если трафик до гигабита) и RB750Gr3 в филиалы. Именно HEX S оправдан, только если явно необходимо принимать оптический линк (причем для xPON он все равно не подойдет).
А RB450G уже совсем старый, и после нескольких лет эксплуатации на платах могут вспухать конденсаторы.
fcgm, от зависания чего-либо внутри самого ssh-соединения это конечно не спасет, но спасет от закрытия TCP-соединения по таймауту из-за отсутствия какого-либо трафика в нем, а также от "протухания" записи об этом соединении в таблицах маршрутизаторов, выполняющих NAT. Но вообще конечно лучше всю эту конструкцию реализовать более подходящими и удобными инструментами.
АртемЪ, но это может оказаться и преимуществом, если человек связан с IT и желает изучить сетевые технологии не только на уровне типовой настройки доступа в интернет в вебке домашнего роутера.
P.S. Не далее как вчера обновил прошивку до самую свежей релизной на попавшем в руки Mikrotik RB750G, произведенном более 10 лет назад. Есть ли какой-то другой вендор в soho-сегменте, который обеспечивает столь долгую поддержку своих устройств?
F1rst0ne, найдите фирму-аутсорсера, которая будет заниматься вашими серверами на постоянной основе. Отказоустойчивость, безопасность и надежность возможна только на оборудовании, находящимся хотя бы под минимальным присмотром.
Сергей, на arp-спуфинг похоже. Если в сети есть управляемое сетевое оборудование, то смотрите на нем, откуда этот мак прилетает (и включаете мониторинг всяких аномалий, а потом смотрите в логи). В противном случае остаются wireshark, arpwatch, и ручное отключение портов в поиске виновного.
Евгений Карагодин, вариантов много, но лучше, чтобы это специалист на месте диагностировал, дистанционно сложнее, тем более без доступа к оборудованию. Тут могут быть потери пакетов в сети, кривая настройка шейпера у провайдера, какой-либо несанкционированный трафик, забивающий ваш канал в интернет. Кстати, совет - когда выкладываете куда-то конфигурацию роутера, затирайте в ней чувствительную информацию - пароли, ip-адреса и т.д. Из вашего конфига можно узнать пароль к WiFi и ip-адрес, а также то, что доступ к роутеру не заблокирован со стороны интернета ни по одному из дефолтных протоколов. А правило шейпера можно удалить, если оно ухудшает ситуацию. Кстати, ваша скорость 2мб/с - это два мегабита в секунду, или два мегабайта в секунду? Провайдеры и сервисы типа speedtest обычно меряют в мегабитах/сек, но мало ли? Как вы 100кб/с измерили?
Возможно где-то есть транзитные проблемы с прохождением пакетов с размером, приближающимся к MTU в локальной сети. Попробуйте добавить такое правило файрвола командой:
А чтобы тест скорости показывал стабильные значения, имеет смысл в самом микротике добавить ограничение скорости, соответствующее тарифной скорости провайдера:
Как бывший верстальщик, предположу, что если квадратам добавить тонкие контуры с цветом, совпадающим с цветом заливки, то белые полосы исчезнут. Либо же наоборот, у квадратов уже есть белые контуры, которые нужно убрать.
Дядька Серёжа, может не стоит диагностировать предысторию по гарнитуре шрифта? Я ничего не имею против нормальных специалистов, которые в своих приоритетах имеют, помимо прямых задач по обеспечению безопасности, также и не создание неоправданных проблем и неудобств коллегам и пользователям, но к сожалению, мой личный опыт взаимодействия с такими людьми весьма неоднозначен. Будучи админом очень большой и развесистой сети в госструктуре, где отдел сетевого администрирования и отдел безопасности были в разных структурных подразделениях, насмотрелся всякого. "Юные дарования", которых брали специалистами в сектор сетевой безопасности, дорвавшись до инструментов сканирования уязвимостей, несколько раз вызывали массовые проблемы, в частности, блокировку доменных учеток по причине исчерпания лимита подбора паролей или массовое зависание ip-телефонов. Они же только хлопали глазами, когда в сети начинались какие-то реальные проблемы, например вследствие arp-спуфинга, несмотря на то, что весь трафик зеркалировался на их многочисленные сенсоры, начиная от Snort и кончая чем-то сертифицированным. Продукция компании Инфотекс, которую они ставили везде, где только можно, потому что так положено, и потом обслуживали, регулярно вызывала сбои в работе защищаемых сетей и часто, как следствие, информационных систем, в разы чаще, чем использованное не сертифицированное оборудование традиционных вендоров, и при этом безопасники обычно еще и до последнего отказывались признавать проблему на своей стороне. И это при том, что они административными регламентами вытребовали себе доступ на все сетевое оборудование, при этом оставив контроль за всем, что относится к безопасности, лишь за собой. Когда же на ключевом сетевом оборудовании западного производителя случился сбой, потребовавший обращения в его техподдержку, они фактически заблокировали решение проблемы, запретив выдавать каким-либо зарубежным организациям значимую информацию - конфиги, логи и дампы. А российский партнер, у которого все закупалось, только развел руками и ничем помочь не смог. Конечно, не все было совсем уж только плохо, но в конечном итоге воинствующая паранойя, исходившая от безопасников, стала для меня одним из факторов, побудивших искать новое место работы, где к вопросам безопасности относятся более сбалансировано. А про кодекс корпоративной этики в госструктуре... Я лучше промолчу.
