Pull to refresh
4
0
Send message

Насколько я знаю, в серии коммутаторов 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 подтверждаю. Я, собственно, именно так хабр и читаю последние лет шесть.

В статье по ссылке описаны пользователи Тёмной стороны, не являющиеся индоктринированными ситами либо являющиеся «павшими» джедаями.

Мне на память приходили, напротив, вполне себе индоктринированные джедаи, систематически выполняющие негласную грязную деятельность, включающую диверсии, пытки и убийства, и при этом всё равно «светлые». Просто они хорошо умеют разделять работу и личную жизнь :)

Кажется, вот: https://starwars.fandom.com/ru/wiki/%D0%94%D0%B6%D0%B5%D0%B4%D0%B0%D0%B9-%D1%82%D0%B5%D0%BD%D1%8C

Если мне не изменяет память, адепты Светлой стороны учатся обуздывать эмоции и не давать им влиять на своё поведение (соответственно, на использование Силы). В отсутствие значимых постоянных возмущений достижима длительная стабильность фукнционирования.

Адепты Тёмной стороны, напротив, используют свои эмоции как топливо для Силовых действий. Поскольку проще всего генерируются отрицательные эмоции, образуется положительная обратная связь: больше гнева/ярости/ненависти, больше эффекта от Силы, больше соблазн прибавить градус неадеквата. Искусство контроля своих эмоций замедляет падение в безумство, но сам принцип работы подтачивает стабильность психики.

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

защиту от BPDU без выключения порта при появлении постороннего коммутатора:

switchport mode access

switchport access vlan 10

spanning-tree portfast

spanning-tree bpdu filtering

spanning-tree bpduguard enable 

Прошу уточнить: такая конфигурация должна именно отключать порт при появлении постороннего коммутатора на порту вследствие срабатывания bpduguard, поскольку собственные BPDU элтекс в этот порт посылать будет. Чтобы не посылал, на порту надо сделать spanning-tree disable.

Information

Rating
Does not participate
Location
Киров (Кировская обл.), Кировская обл., Россия
Registered
Activity