Перейти к содержимому
Калькуляторы

st_admin

Пользователи
  • Публикации

    22
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные пользователем st_admin


  1. Закончили на мировую.

    Поскольку сам истец уже понял что если он не согласится принять условия мировой, судья намекнул что может отклонить иск и инициировать расторжение контракта.

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

  2. То что вы предлагаете, это классический сценарий обьединения офисов через L3 связность. В провайдерской терминологии L3VPN. Т.е провайдеру нужно согласовать с клиентом сети для стыковки.

    Я на данный момент пытаюсь понять как реализовать на микротик сценарий с L2VPN multipoint, когда я как провайдер, для клиента выгляжу как обычный хаб, и клиент уже сам определяет какие подсети использовать для обьединения своих офисов.

    Цель задачи собрать на себя все вланы из точек присутствия клиента (последняя миля неважно чья, может быть и арендована), и дать этим офисам обмениваться траффиком на моем оборудовании, при этом не заморачиваясь какую адресацию используют клиенты.

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

    Реализуема ли такая задача на Микротик? Или имеет смысл искать оборудование посерьезнее?

     

     

  3. Всем привет.

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

    И как лучше подать эти тегированные вланы на микротик от свича агрегации? Каждый бридж через свой порт?

     

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

    MNG_muliple_vlans.jpg

  5. 19 minutes ago, VolanD666 said:

    Причем тут VPLS? Просто запихайте их в один бридж и все.

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

    Какие настройки должны быть в Bridge Vlan ?

  6. Привет микротиковчане.

    Есть микротик RB1100, к нему транком подключен Cisco3750X. В циску приходят вланы управления от разных провайдеров, но ip управления в этих разных вланах все находятся в одной сети /24.

    Я хочу пробросить эти вланы на микротик и соединить их в один бродкаст домен по типу VPLS или чего-то подобного.

    Можно ли это сделать засунув все вланы в один bridge, и как он должен быть настроен? Или все таки нужно настраивать полноценный VPLS?

     

  7. On 9/17/2019 at 9:07 AM, VolanD666 said:

    Ну дык вы забриджуйте нужный порт с нужным влан интерфейсом, в чем проблема то? Для дебага запускате снифер и смотрите что куда идет и на каком участке у вас проблема.

    Вот начитался

    Чтобы прозрачно пропустить траффик определенного влана через свич чип, не обязательно делать это через vlan interface, я бы даже сказал не рекомендовано. Возникают проблемы со Spanning tree если соседнее железо не поддерживает pvst (cisco)

    Вот здесь описана эта ситуация https://wiki.mikrotik.com/wiki/Manual:Layer2_misconfiguration#VLAN_in_bridge_with_a_physical_interface

  8. Коллеги приветствую

    Ломаю голову второй день.

    На одной стороне rb750 на второй rb1100 с транком в циско свич.

    Между микротами поднял L2TP Ipsec, поверх него EoIP

    Загоняю трафик в порт rb750, вешаю метку влана 5, со второй стороны из EoIP через бридж траффик должен уйти в транковый порт на циску.

    Но на циску все маки с той стороны прилетают в vlan id 1, т.е нетегированый native.

    Вообщем, как получить траффик из EoiP туннеля с нужной меткой влана чтобы отправить его дальше транком в сеть? Умеет ли микротик правильно это делать?

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

    в идеале бы увидеть куски рабочего конфига.

    Заранее благодарю.

  9. а где "некий ИП существенно перебив цену перед нормальными интеграторами." ?

    А видеозвонки нормально не работают внутри АТС или между адресами?

    Я не заметил, что между адресами хоть чтото обязано работать. (либо внутри, либо на ТФОП; причем только голос)

     

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

  10. всех тонкостей их сети не знаю, поскольку сам не углублялся в этот вопрос, но вероятнее всего что она не сегментирована

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

     

    Точную причину проблем установить не удалось,

    В чем причина найти и установить? Значит, ни кому это не надо, заказчик уже и не допустить к своей сети подрядчика.

    Здесь без пинка никто ничего делать не станет, это же Россия.

    Если суд поставит задачу перед экспертом определить причину проблем, то думаю что все встанет на свои места, но опять же деньги, время и нервотрепка.

  11. Кто то может и поспорить, но не думаю что для SOHO D-Linka, хоть и с гигабитными портами, потянуть 25 участников ВКС вполне посильная задача.

    И тем паче если свичи не поддерживают метод быстрой коммутации Cut-through, что вполне могло бы ускорить прохождение пакетов.

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

    На последнем судебном заседании судья выслушал доводы эксперта по части поставленных вопросов.

    Основной вывод: Система работает плохо, для эксплуатации не годится. Точную причину проблем установить не удалось, но из возможных это проблемы в сети заказчика или неправильная настройка серверов и клиентов ВКС.

    Судья принял данные выводы и думаю что на следующем заседании через неделю огласит какое то решение, будь то поддержать исковые требования или отклонить их.

    По поводу задач поставленных контрактом, в принципе там все ясно написано, за исключением некоторых моментов. Приложить здесь не могу, ибо нужно вырезать персональные данные и реквизиты, да и политика ИБ на работе не позволяет загружать файлы во вне.

  12. Вы же понимаете, что если по договору не требовалось сделать чтобы:

    1. Некоторые участники отваливаются от конференции.

    2. Возникает задержка в передаче видео потока.

    то и требовать это никто не имеет права?

    И я сомневаюсь, что истец заказал 2 экспертизы самостоятельно.

    Скорее всего на суде заявил ходатайство и суд удовлетворил. и суд сам выбрал эксперта (по крайнем случае в СПб так).

     

    Мне вот не жалко таких заказчиков.

    потому что виноват заказчик 99% (приложите контракт - точно скажем).

     

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

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

    Клиент конечно сам виноват, но и исполнитель повел себя крайне некрасиво и неквалифицировано.

    Проекта контракта сейчас нет под рукой.

  13. Как же вы допустили, что обе экспертизы были от истца?!

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

    По требованию контракта поставленное оборудование должно обеспечивать видеоконференсвязь, а по факту имеем ВКС с задержками.Однако вторая экспертиза признало это недостатком, но называть причины не решилась.

  14. Данное судебное разбирательство тянется уже более двух лет.

    В 2015 году некая государственная организация обьявила тендер на поставку системы IP телефонии и видеоконференцсвязи.

    Данный тендер выиграл некий ИП существенно перебив цену перед нормальными интеграторами.

    После второй или третьей неудачной попытки сдачи работ заказчику, ИП подает иск в суд с требованием считать контракт выполненным, дабы получить свои деньги.

    Заказчик само собой отпирается, мотивируя это тем что не все пункты контракта по поставке выполнены исполнителем.

    Факт осложняется тем что ТЗ в привычном его представлении не существует. Есть описание обьекта закупки где написано что должно быть поставлено, и какую связь должно обеспечивать.

    В целом, когда меня попросили разобраться в этом деле, я столкнулся с полной некомпетентностью в технологиях как со стороны истца, так и со стороны ответчика:

    Истец, как исполнитель работ, судя из его действий полагался исключительно на авось, продать и забыть, не заботясь ни о последствиях, ни о своей репутации на рынке телеком услуг. Не изучил ситуацию, не провел никакого аудита имеющейся инфраструктуры заказчика, дабы застраховаться от возможных проблем.

    Ответчик же, наш заказчик, интересы которого я представляю, тоже не сильно позаботился о том чтобы услуги по поставке для него были выполнены надлежащим образом. Не составили нормального ТЗ, не подготовили свою инфраструктуру для внедрения столь ресурсозатратной системы как ВКС.

    К мировому соглашению стороны до сих пор не могут придти, отчасти от жадности подрядчика, вернее его женщины-юриста, которая как я считаю слишком переоценивает ситуацию в свою пользу.

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

    Проводилось две экспертизы, причем оба эксперта были приглашены подрядчиком, и их результат, как это неудивительно, оказался в пользу подрядчика. Очевидные проблемы были экспертом грамотно опущены.

    А основные проблемы следующие:

    1. Некоторые участники отваливаются от конференции.

    2. Возникает задержка в передаче видео потока. Грубо говоря человек машет в камеру рукой, а участники конф видят это только спустя 30-60 секунд.

    Любому более менее сведущему в сетях человеку здесь будет понятно что проблема скорее всего в локальной сети заказчика, которая не успевает прогонять большие ВКС пакеты через сеть.

    И еще более мы убедимся в этом если узнаем что локалка построена на гигабитных неуправляемых коммутаторах D-Link SOHO-сегмента.

    Я считаю что проблема именно в локалке заказчика, хотя суд к данным выводам пока еще не пришел.

    Так вот вопрос к юридически подкованным коллегам в данной области:

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

    Или все таки подрядчик, который по идее являясь профи в данной области, допустил критические ошибки в проектировании системы, и как бы заранее должен был представлять к чему это приведет?

  15. Задачу решил написанием своего скрипта на Powershell с использованием библиотеки Posh-SSH, скрипт перебирает строки из файла, коннектится к айпишникам, сливает инфу в лог файл и обзывает файл именем хостнейма из того же файла с айпишниками. Команды выполняются те которые укажешь с нужной задержкой. В принципе кому интересно тоже могу поделиться.

  16. Необходимо собрать данные с 300+ коммутаторов и подобного оборудования различных вендоров.

    Т.е нужно удаленно зайти на коммутатор, выполнить ряд команд типа show tech-support, show mac address-table, сохранить вывод команд в лог.

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

  17. Добрый день, коллеги. Прошу совета, немного забрался в тупик.

    CE клиента подключен к двум PE маршрутизаторам двух провайдеров. У обоих провайдеров бордером стоят Juniper. CE клиента тоже juniper и все работало нормально, сети анонсировались корректно. После того как CE вышел из строя поставили Cisco. После этого начались проблемы с анонсами маршрутов. Операторы не получают маршруты от CE клиента. Хотя на CE маршруты анонсируются. Ниже данные анонсов и конфиг циски. Подскажите если в конфиге чего то не хватает.

    Centralniy_2#sh ip bgp sum

    BGP router identifier 10.211.34.17, local AS number 3468

    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

    10.211.34.18 4 12389 339098 94615 956278 0 0 1w6d 14663

    10.213.34.18 4 50928 768560 86222 956278 0 0 4w1d 10278

     

    sh ip bgp neighbors 10.211.34.18 advertised-routes

    BGP table version is 956285, local router ID is 10.211.34.17

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

    r RIB-failure, S Stale

    Origin codes: i - IGP, e - EGP, ? - incomplete

     

    Network Next Hop Metric LocPrf Weight Path

    *> 10.34.166.0/24 0.0.0.0 0 32768 i

     

    Total number of prefixes 1

     

    sh ip bgp neighbors 10.213.34.18 advertised-routes

    BGP table version is 956285, local router ID is 10.211.34.17

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

    r RIB-failure, S Stale

    Origin codes: i - IGP, e - EGP, ? - incomplete

     

    Network Next Hop Metric LocPrf Weight Path

    *> 10.34.166.0/24 0.0.0.0 0 32768 i

     

    Total number of prefixes 1

     

     

    interface FastEthernet0/0

    description Rostelekom

    ip address 10.211.34.17 255.255.255.252

    speed auto

    full-duplex

    no cdp enable

    !

    interface FastEthernet0/1

    description LAN_UPFR

    no ip address

    speed auto

    full-duplex

    no cdp enable

    !

    interface FastEthernet0/1.1

    description LAN_UPFR

    encapsulation dot1Q 1 native

    ip address 10.34.166.1 255.255.255.0

    no cdp enable

    !

    interface FastEthernet0/1.20

    description Megafon

    encapsulation dot1Q 20

    ip address 10.213.34.17 255.255.255.252

    no cdp enable

    !

    router bgp 3468

    bgp log-neighbor-changes

    timers bgp 30 90

    neighbor 10.211.34.18 remote-as 12389

    neighbor 10.211.34.18 description Rostelekom-VPN

    neighbor 10.211.34.18 timers 30 90

    neighbor 10.213.34.18 remote-as 50928

    neighbor 10.213.34.18 description Megafon

    neighbor 10.213.34.18 timers 30 90

    maximum-paths 2

    !

    address-family ipv4

    neighbor 10.211.34.18 activate

    neighbor 10.211.34.18 weight 300

    neighbor 10.211.34.18 soft-reconfiguration inbound

    neighbor 10.211.34.18 prefix-list bgp_out out

    neighbor 10.211.34.18 route-map prepend-as in

    neighbor 10.213.34.18 activate

    neighbor 10.213.34.18 weight 200

    neighbor 10.213.34.18 soft-reconfiguration inbound

    neighbor 10.213.34.18 prefix-list BGP_out out

    neighbor 10.213.34.18 route-map prepend-as in

    maximum-paths 2

    no auto-summary

    no synchronization

    network 10.34.166.0 mask 255.255.255.0

    exit-address-family

    !

    ip forward-protocol nd

    !

    !

    ip http server

    !

    !

    ip prefix-list BGP_out seq 5 permit 10.34.166.0/24

  18. Чтобы не создавать похожую тему то напишу здесь.

    Ищу интересную подработку сетевиком в Красноярске. Особенно в преддверии Универсиады 2019 я думаю могут понадобиться опытные специалисты на месте. Уровень знаний CCNP. Опыт работы с CISCO,Juniper,Huawei. Есть сертификаты с курсов Cisco, Huawei. Большой опыт работы с R&S, Cisco VOIP(Call manager), Wi-Fi. Опыт работы в питерских провайдерах. Образование - бонч 6 лет.