mrrc

Для чего? Вопрос был задан по существу, причем тут тоннель, самостоятельное мониторирование и управление.

Да проще будет другую железку под указанные цели отдать провайдеру. Тот же Zyxel USG FLEX. Жаль, что у нас на борту нет гибкости конфигурирования SNMP. С другой стороны, мониторишь обычно свою инфраструктуру, поэтому не так критично.

Приветствую, встал вопрос поставить на мониторирование у провайдера одну нашу пограничную железку через SNMP. В качестве агрегатора данный рассмотрим PRTG (для проверки). На мониторинг хотелось бы отдавать только загрузку и доступность определенных сетевых наружных интерфейсов микрота. Остальная информация о состоянии железки доступна быть не должна. Вроде в ROS нет фильтров по OID, можно ли правильно сконфигурить SNMP на микроте, чтобы информировать только по требуемым значениям (сенсорам) и не позволяя получать считывающей стороне лишнего? Спасибо.

Необоснованно усложнять и избыточно сепарировать сетевую инфраструктуру тоже неверно. Если в определенных случаях это и применимо, то не должно распространяться просто ради за компанию. По существу проблемы уже на самом объекте - все аплинки от оборудования с повышенной сетевой нагрузкой сведены на порты единого свиччипа, из бриджа с включенным vlan-filtering-ом выведены порты из соседних свитччипов, проапгрейдено до 7.7, принципиальной разницы по скоростным показателям с учетом проанонсированного в свое время HW offload support for vlan-filtering on RTL8367 switch chip не замечено, однако вопрос все же решается применением FastTrack-а, накладываемого на созданные интерфейс-листы задействованных во внутрисетевом обмене vlan-интерфейсов. Дальше наблюдение.

Вы стали бы собственноручно делать подобную реализацию, интересно знать.

Вернулись к тому, с чего начинали - маршрутизатор. Либо обеспечиваем условия для FastTrack между влан-подсетями, либо оборудование с запасом.

Тогда маршрутизацию между подсетями vlan на кого воскладываете?

Соглашусь, кесарю - кесарево. Но тогда вопрос, кто должен осуществлять маршрутизацию подсетей vlan. Коммутатор L3, получается, лишенный обременений в виде FW и т.п., на который переносится и терминирование vlan в таковом случае с маршрутизатора.

А ничем. Очередными дебатами с саабом. У меня возможность применения FastTrack-а в решении задачи направлено именно на внутрисетевой обмен, задействуя быстрый путь только для общения подсетей vlan-интерфейсов между собой. И оно работает, на имеющемся стенде, во всяком случае. Но поднялось только после отключения влан фильтеринга на бридже и переноса с него vlan-ов на свиччип (изменения парадигмы настройки vlan на маршрутизаторе). Для чего включается и где о об этом говорится в документации по FastTrack? Быстрый путь нужен мне для обмена непосредственно между подсетями интерфейсов, через которые происходит высокая нагрузка.

@SUrov_IBM Добрый вечер, спасибо за информацию! Тут проблема скорее в ограничениях от Fast Path-а, который не дружит с vlan-filtering, а из-за этого не отрабатывают правила FastTrack-а. Сам по себе HW offload support for vlan-filtering может и не сделать существенной погоды. Но все это предположения, лишенные практики. Думаю, разумно будет пойти по пути перевода вланов с бриджа на чип, а если на RB1100AHx4 это не сработает (хотя странно, с более младшей моделью RB1100AHx2 все удалось), тогда смотреть в сторону перехода на 7.х, просто если уходить на эту ветку, скорее всего потянет за собой апгрейд и всего комплекса остального оборудования, от 6.х хотя бы точнее знаешь, чего ожидать, так сказать. Про обвязку ресурсоемкого обмена в рамках одного чипа я понял, вписываюсь в его пять портов. Но что я не питаю особой надежды:

На RB1100AHx2 добился результата, переведя на нем vlan-ы с бриджа на Switch Chip заработал и FastTrack, почти удвоив скорость обмена между подсетями вланов, не повредив функциональность ros. Но на продакшн устройстве RB1100AHx4 другие Switch-chip-ы используются, а они согласно wiki не поддерживают VLAN-таблиц и взлетит ли решение там еще не пробовал.

Ну на стенде с RB1100AHx2 пока два свиччипа. То есть для терминирования серверной группы и порт от пользовательских подсетей завести на один из свитччипов (чтобы обмен обвязать в рамках одного чипа), а вход провайдеров и нетребовательного к нагрузкам подключения сделать на втором, если я верно улавливанию вашу мысль. Ну трафик по L2 в рамках вилана (подсети) у меня и не загружает процессор на всем вовлеченном оборудовании, загружает процессор трафик по L3 как раз между посетями виланов при внутренней маршрутизации на маршрутизаторе.

Шейперов нет, FW, да, это рабочий инструмент, манглы только для реализации файловера, заворачивания запросов dns на себя любимого и блокировки софта неконтролируемых доступов. Все это необходимо в решении задач. Никто и не говорил, что вилана добавляются в бридж. Они именно и терминируются на маршрутизаторе. Виланы развернуты на бридже, на котором включен VLAN filtering, такова парадигма настройки и далее раздаются на коммутаторы. Отсюда я и задавался вопросом, что может конкретно на маршрутизаторе перестроить vlan-ы с бриджа на Switch Chip (вроде эти два варианта увязываемы между оборудованием), дабы отказаться от VLAN filtering на бридже, а далее опять же с помощью FastTrack (который может все же заработает?) упростить проход трафика между вовлеченными во внутренний обмен vlan-интерфейсами, как выше приводил пример.

Torch не включал (трафик при транзитной перекачке наблюдал в правилах), FastPath включен, там все по дефолту. В мане по FastPath имеется такое: Но т.к. vlan-ы у меня на бридже и разумеется задействован VLAN filtering, это может являться причиной неработоспособности FastTrack-а? Еще все же действие динамических правил passthrough вместо accept непонятно.

@jffulcrum не очень понял в части приведенной утилиты. Если чем я проверял скоростные показатели - то банально перекачка исошника на 1,5 гига между узлами, находящимися в разных подсетях.