st_admin

Закончили на мировую. Поскольку сам истец уже понял что если он не согласится принять условия мировой, судья намекнул что может отклонить иск и инициировать расторжение контракта. В этой мед организации я проработал еще год на полставки, в течении которого пытался привести их ЛВС в подобающий вид. Немного получилось, модернизировали ядро, убрали большую часть неуправляемых свичей. Ушел оттуда, потому что устал уже рассказывать местных итшникам как нужно делать сети. Оставил их наедине с тем что есть.

То что вы предлагаете, это классический сценарий обьединения офисов через L3 связность. В провайдерской терминологии L3VPN. Т.е провайдеру нужно согласовать с клиентом сети для стыковки. Я на данный момент пытаюсь понять как реализовать на микротик сценарий с L2VPN multipoint, когда я как провайдер, для клиента выгляжу как обычный хаб, и клиент уже сам определяет какие подсети использовать для обьединения своих офисов. Цель задачи собрать на себя все вланы из точек присутствия клиента (последняя миля неважно чья, может быть и арендована), и дать этим офисам обмениваться траффиком на моем оборудовании, при этом не заморачиваясь какую адресацию используют клиенты. Важный момент, сети каждого клиента должны быть изолированы между собой. Именно поэтому я считаю что нужно для каждого клиента нужно заводить отдельный бридж. Реализуема ли такая задача на Микротик? Или имеет смысл искать оборудование посерьезнее?

Всем привет. Есть задача, в принципе стандартная для большинства провайдеров: на центральный узел сходятся несколько вланов из разных офисов, нужно эти вланы обьединить в один бродкаст домен(по сути наверное VPLS, но поскольку MPLS пока не поднят, приходится так). Так вот как эти вланы лучше собрать в одном месте на RB1100ah4 ? Правильно понимаю что лучше всего подойдет сбриджевать эти вланы на микроте, а бридж тем самым будет держать всю таблицу хостов и перекидывать кадры из одного влан в другой? И как лучше подать эти тегированные вланы на микротик от свича агрегации? Каждый бридж через свой порт?

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

Схема достаточно распространенная. Делаете в 10G линке транк со свичом и запускаете два влана( аплинк и пользователи). https://wiki.mikrotik.com/wiki/Manual:Interface/VLAN

Это понятно. А vlan filtering нужно включать? Ведь в бридж пакеты заходят тегироваными. Какие настройки должны быть в Bridge Vlan ?

Привет микротиковчане. Есть микротик RB1100, к нему транком подключен Cisco3750X. В циску приходят вланы управления от разных провайдеров, но ip управления в этих разных вланах все находятся в одной сети /24. Я хочу пробросить эти вланы на микротик и соединить их в один бродкаст домен по типу VPLS или чего-то подобного. Можно ли это сделать засунув все вланы в один bridge, и как он должен быть настроен? Или все таки нужно настраивать полноценный VPLS?

Вот начитался Чтобы прозрачно пропустить траффик определенного влана через свич чип, не обязательно делать это через vlan interface, я бы даже сказал не рекомендовано. Возникают проблемы со Spanning tree если соседнее железо не поддерживает pvst (cisco) Вот здесь описана эта ситуация https://wiki.mikrotik.com/wiki/Manual:Layer2_misconfiguration#VLAN_in_bridge_with_a_physical_interface

Спасибо за ответы. Удалось получить на циске пакеты в 5 влане после того как на бридже к которому привязан транк и eoip включил vlan filtering с pvid 5.

Коллеги приветствую Ломаю голову второй день. На одной стороне rb750 на второй rb1100 с транком в циско свич. Между микротами поднял L2TP Ipsec, поверх него EoIP Загоняю трафик в порт rb750, вешаю метку влана 5, со второй стороны из EoIP через бридж траффик должен уйти в транковый порт на циску. Но на циску все маки с той стороны прилетают в vlan id 1, т.е нетегированый native. Вообщем, как получить траффик из EoiP туннеля с нужной меткой влана чтобы отправить его дальше транком в сеть? Умеет ли микротик правильно это делать? В перспективе будет много таких туннелей которые нужно разбирать по вланам. Может стоит сразу смотреть в сторону vpls? но и для vpls этот вопрос актуальный. в идеале бы увидеть куски рабочего конфига. Заранее благодарю.

Проблемы внутри филиала, про сайт-ту-сайт вкс и речи нет, хотя она худо бедно но работает.

Вообщем все ноги отсюда: http://zakupki.gov.ru/epz/order/notice/ea44/view/common-info.html?regNumber=0119200000114007629

Так может это и надо проверить, выполнить экспертизу, лучше техническую на месте, а не на бумаге. Хотя, заказчику-ответчику это же не нужно, зачем вскрывать проблемы. В чем причина найти и установить? Значит, ни кому это не надо, заказчик уже и не допустить к своей сети подрядчика. Здесь без пинка никто ничего делать не станет, это же Россия. Если суд поставит задачу перед экспертом определить причину проблем, то думаю что все встанет на свои места, но опять же деньги, время и нервотрепка.

Кто то может и поспорить, но не думаю что для SOHO D-Linka, хоть и с гигабитными портами, потянуть 25 участников ВКС вполне посильная задача. И тем паче если свичи не поддерживают метод быстрой коммутации Cut-through, что вполне могло бы ускорить прохождение пакетов. Я всех тонкостей их сети не знаю, поскольку сам не углублялся в этот вопрос, но вероятнее всего что она не сегментирована, а это значит что бродкастов там скорее всего больше чем уникаста, а это никаким гигабитом не компенсируешь. На последнем судебном заседании судья выслушал доводы эксперта по части поставленных вопросов. Основной вывод: Система работает плохо, для эксплуатации не годится. Точную причину проблем установить не удалось, но из возможных это проблемы в сети заказчика или неправильная настройка серверов и клиентов ВКС. Судья принял данные выводы и думаю что на следующем заседании через неделю огласит какое то решение, будь то поддержать исковые требования или отклонить их. По поводу задач поставленных контрактом, в принципе там все ясно написано, за исключением некоторых моментов. Приложить здесь не могу, ибо нужно вырезать персональные данные и реквизиты, да и политика ИБ на работе не позволяет загружать файлы во вне.

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