При операции на десне рядом с большей частью зубов разом не возникло ли проблем с нёбом, откуда пришлось отрезать большой кусок плоти? У меня выраженная рецессия десны примерно по всей челюсти, и в ходе консультации в государственной поликлинике врач отсоветовал операцию именно по причине, что неоткуда брать столько материала.
Хочу задать вопрос про построение «опорной» маршрутизации между большим количеством узлов (более ста), если связи между этими узлами никак не укладываются в схему «звезда». Особенно если в центре сети стоит не один маршрутизатор, а два (с целью резервирования). Особенно если в перспективе может появиться ещё пара десятков узлов с разнообразными связями между ними.
Цель этой «опорной» маршрутизации — послужить основой для построения MPLS сети, с L3VPN и прочими радостями. В сеть анонсируются только loopback интерфейсы маршрутизаторов, применяются только point-to-point линки.
При простом растягивании одной зоны OSPF на все узлы разбухает база LSDB, возникает перегрузка на некоторых (слабых) узлах при частом перестроении этой базы из-за флапающего в глубинке линка.
При попытке поделить сеть на несколько зон получается странное поведение трафика, который начинает ходить по плохо предсказуемым путям (наблюдалось на устройствах Mikrotik). Возможно, из-за тонких нюансов протокола OSPF.
Каким путём можно идти, желая сделать более надёжной и масштабируемой такую «опорную» маршрутизацию?
Насколько я знаю, в серии коммутаторов 24хх (очень сырой) используют тайваньские чипы Realtek. Но да, у Элтекса нет и не было ресурсов для разработки чипов в свою продукцию; им бы имеющиеся продукты отладить, и то хорошо.
Если вам не сложно, можете ли развить мысль относительно специализированных чипов Marvell? Вроде бы многие производители пользуются их коммуникационными микросхемами. А в оборудовании Eltex есть что-то ещё?
Я не читал исходный текст, только проверил результат нейросети на ошибки. Четыре лишних знака препинания, шестнадцать недостающих, четырнадцать правильных. Некоторые из ошибок даже MS Word подчёркивает, хотя его система проверки откровенно слаба и сама часто вводит в заблуждение.
Очевидно, что литературная речь со сколько-нибудь сложными конструкциями не являлась вашей целью. А что за корпус текстов вы использовали? Записи в блогах и посты из соцсетей?
Лично мне кажется, что результат работы сети, специально предназначенной для расстановки знаков препинания, в этом случае очень посредственный. И авторская пунктуация тут ни при чём — ошибки обыкновенные. Конечно, по меркам интернет-общения это уже норма, но грамотному человеку, не дислексику, глаз режет.
В этом случае, получается, соединение создаётся без учёта принадлежности пакета VRF. Отсюда и все грустные особенности VRF на RouterOS, особенно в случае потока трафика между двумя VRF, которые в норме должны общаться через внешний сетевой экран.
Исследовали ли вы вопрос о том, в каких блоках диаграммы маршрутизатор принимает решение о принадлежности пакета определённому VRF, точнее, определённой Routing Mark? В частности, в случае деинкапсуляции IP-пакета из MPLS-пакета в рамках L3VPN?
Хочу уточнить: указанная особенность NAT проявляется даже в отсутствие стандартного первого правила firewall filters, разрешающего established и related пакеты?
VRF в Mikrotik неполноценный. Я не разбираюсь в линуксе, но давняя статья поясняет причины, почему в RouterOS не существует VRF-зависимых сервисов (telnet, ssh, DHCP relay и пр.), почему возникает ситуация из моего комментария выше и почему разработчики RouterOS уже лет десять обещают нормально изолированный VRF в ROS7.
Имеется роутер R1. На нём поднят MPLS, создано несколько VRF, из каждого доступен свой набор маршрутов, получаемых по BGP (MPLS L3VPN), а также в каждом VRF имеются локальные интерфейсы. Адресация нигде не пересекается. Имеется роутер с фаерволом R2, с которым каждый VRF на R1 связан динамической маршрутизацией по OSPF: в сторону R2 редистрибутятся все маршруты, обратно получается маршрут по умолчанию. В некотором VRF X есть присоединённая сеть X1, при обращении в которую нужно выполнять простой маскарадинг. Маскарадинг прописан в правилах NAT R1. Некий узел Y1 из другого VRF Y обращается в сеть X1. Трафик проходит из R1 VRF Y на R2, оттуда обратно на R1, но уже в VRF X. Возникает проблема: Mikrotik создаёт одно соединение, к которому пытается применить правило NAT, не глядя на то, что вообще-то потоков трафика два, входящий и исходящий forward, и они типа должны быть изолированы в разных VRF, но вот поди ж ты. В итоге NAT не работает. Прописывание Routing mark в правиле NAT, попытка разметить соединения не помогли. Пришлось решать проблему, искусственно введя лупбек на R2, на котором вторично происходит source nat.
Можете ли вы рассказать, как файервол RouterOS функционирует в случае прохождения трафика через разные VRF на одном маршрутизаторе? Например, если все VRF через динамическую маршрутизацию связаны с неким внешним узлом, выполняющим функцию сетевого экрана. В частности, я сталкивался с некорректной работой NAT.
Подозреваю, что вследствие неполной изоляции VRF на RouterOS здесь есть много тонкостей.
В Кирове. Это далековато как от Новосибирска, так и от Москвы. Про хороших местных хирургов-парадонтологов как-то не слышал.
Опыт операции в Москве методом "наезда" у меня уже был, не понравилось.
Остаётся надежда, что из-за отсутствия половины дёсен зубы раньше времени не вывалятся :)
Я так понял, что длительное время после операции требуется плотное наблюдение и доп. работы у врача, поэтому разовым наездом операцию не сделать?
Операция проходила в Москве? Нет ли информации о квалифицированных хирургах вовне её?
При операции на десне рядом с большей частью зубов разом не возникло ли проблем с нёбом, откуда пришлось отрезать большой кусок плоти? У меня выраженная рецессия десны примерно по всей челюсти, и в ходе консультации в государственной поликлинике врач отсоветовал операцию именно по причине, что неоткуда брать столько материала.
Про удаление конфигов через канал поддержки можно ли подробнее? Очень не похоже на правду.
Хочу задать вопрос про построение «опорной» маршрутизации между большим количеством узлов (более ста), если связи между этими узлами никак не укладываются в схему «звезда». Особенно если в центре сети стоит не один маршрутизатор, а два (с целью резервирования). Особенно если в перспективе может появиться ещё пара десятков узлов с разнообразными связями между ними.
Цель этой «опорной» маршрутизации — послужить основой для построения MPLS сети, с L3VPN и прочими радостями. В сеть анонсируются только loopback интерфейсы маршрутизаторов, применяются только point-to-point линки.
При простом растягивании одной зоны OSPF на все узлы разбухает база LSDB, возникает перегрузка на некоторых (слабых) узлах при частом перестроении этой базы из-за флапающего в глубинке линка.
При попытке поделить сеть на несколько зон получается странное поведение трафика, который начинает ходить по плохо предсказуемым путям (наблюдалось на устройствах Mikrotik). Возможно, из-за тонких нюансов протокола OSPF.
Каким путём можно идти, желая сделать более надёжной и масштабируемой такую «опорную» маршрутизацию?
Насколько я знаю, в серии коммутаторов 24хх (очень сырой) используют тайваньские чипы Realtek. Но да, у Элтекса нет и не было ресурсов для разработки чипов в свою продукцию; им бы имеющиеся продукты отладить, и то хорошо.
Если вам не сложно, можете ли развить мысль относительно специализированных чипов Marvell? Вроде бы многие производители пользуются их коммуникационными микросхемами. А в оборудовании Eltex есть что-то ещё?
Имели ли вы какой-либо опыт с маршрутизаторами Дионис NX, которые обладают государственными сертификациями и могут организовывать туннели DiSec?
Я не читал исходный текст, только проверил результат нейросети на ошибки. Четыре лишних знака препинания, шестнадцать недостающих, четырнадцать правильных. Некоторые из ошибок даже MS Word подчёркивает, хотя его система проверки откровенно слаба и сама часто вводит в заблуждение.
Очевидно, что литературная речь со сколько-нибудь сложными конструкциями не являлась вашей целью. А что за корпус текстов вы использовали? Записи в блогах и посты из соцсетей?
Лично мне кажется, что результат работы сети, специально предназначенной для расстановки знаков препинания, в этом случае очень посредственный. И авторская пунктуация тут ни при чём — ошибки обыкновенные. Конечно, по меркам интернет-общения это уже норма, но грамотному человеку, не дислексику, глаз режет.
Не могу, надо )
В этом случае, получается, соединение создаётся без учёта принадлежности пакета VRF. Отсюда и все грустные особенности VRF на RouterOS, особенно в случае потока трафика между двумя VRF, которые в норме должны общаться через внешний сетевой экран.
Исследовали ли вы вопрос о том, в каких блоках диаграммы маршрутизатор принимает решение о принадлежности пакета определённому VRF, точнее, определённой Routing Mark? В частности, в случае деинкапсуляции IP-пакета из MPLS-пакета в рамках L3VPN?
Хочу уточнить: указанная особенность NAT проявляется даже в отсутствие стандартного первого правила firewall filters, разрешающего established и related пакеты?
VRF в Mikrotik неполноценный. Я не разбираюсь в линуксе, но давняя статья поясняет причины, почему в RouterOS не существует VRF-зависимых сервисов (telnet, ssh, DHCP relay и пр.), почему возникает ситуация из моего комментария выше и почему разработчики RouterOS уже лет десять обещают нормально изолированный VRF в ROS7.
Имеется роутер R1. На нём поднят MPLS, создано несколько VRF, из каждого доступен свой набор маршрутов, получаемых по BGP (MPLS L3VPN), а также в каждом VRF имеются локальные интерфейсы. Адресация нигде не пересекается. Имеется роутер с фаерволом R2, с которым каждый VRF на R1 связан динамической маршрутизацией по OSPF: в сторону R2 редистрибутятся все маршруты, обратно получается маршрут по умолчанию. В некотором VRF X есть присоединённая сеть X1, при обращении в которую нужно выполнять простой маскарадинг. Маскарадинг прописан в правилах NAT R1. Некий узел Y1 из другого VRF Y обращается в сеть X1. Трафик проходит из R1 VRF Y на R2, оттуда обратно на R1, но уже в VRF X. Возникает проблема: Mikrotik создаёт одно соединение, к которому пытается применить правило NAT, не глядя на то, что вообще-то потоков трафика два, входящий и исходящий forward, и они типа должны быть изолированы в разных VRF, но вот поди ж ты. В итоге NAT не работает. Прописывание Routing mark в правиле NAT, попытка разметить соединения не помогли. Пришлось решать проблему, искусственно введя лупбек на R2, на котором вторично происходит source nat.
Можете ли вы рассказать, как файервол RouterOS функционирует в случае прохождения трафика через разные VRF на одном маршрутизаторе? Например, если все VRF через динамическую маршрутизацию связаны с неким внешним узлом, выполняющим функцию сетевого экрана. В частности, я сталкивался с некорректной работой NAT.
Подозреваю, что вследствие неполной изоляции VRF на RouterOS здесь есть много тонкостей.
Уточните, работника-россиянина нещадно эксплуатировали японцы? Из вашего сообщения неясно, кто именно перегрузил его работой сверх меры.
Насчёт RSS подтверждаю. Я, собственно, именно так хабр и читаю последние лет шесть.