Archangel

Иван: Если устройства не очень мощные и только Cisco есть в инфраструктуре - используйте EIGRP. Хотя как мне кажется, в вашем случаи динамическая маршрутизация - заморочка которая нужна исключительно ради академического интереса.

P.S. Про захват пакетов читать тут: www.cisco.com/c/en/us/support/docs/ios-nx-os-softw...
Так удобно как tcpdump в реальном времени конечно не получится, но в будущем, уверен, еще пригодиться.

https://freedns.afraid.org/

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

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

Я так понимаю, что у вас в каждом филиале стоит либо свой Standard FE либо SBA.
В этом случаи самый правильный и беспроблемный вариант - развернуть новый сервер и перенести всех на него. Конечно для этого придется добавить его в топологию. Там проблем быть не должно никаких, если конечно все пользователи в одном домене.

В таком случаи также можно будет банально перепривязать PSTN-шлюзы к новому Mediation серверу и более никаких настроек на Lync делать не придется.

От раздачи интернета по Wi-Fi можно защититься просто отфутболивая на маршрутизаторе пакеты с TTL больше 1 на локальном интерфейсе. Но, соглашусь с Vladislav_vb от прокси это не спасет.

Вы совершенно правы. На маршрутизаторах с IOS трафик инициированный самим маршрутизатором не попадает под ACL.

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

ip local policy route-map

Если RDP подключение обычное, а не RemoteApp, то проще использовать сторонний RDP менеджер, например mRemote.

Cisco SSL VPN (он же AnyConnect) настраивается так:
www.cisco.com/c/en/us/td/docs/security/asa/asa80/c...

Но с OpenVPN он не совместим. Для совместимости нужно использовать открытый аналог OpenConnect. А вот можно ли его втащить в ваш маршрутизатор я не знаю.

Не нашел кстати вменяемого описания этой железки. Но ясно что в нем Linux. А нет ли в нем случайно более стандартных IPSEC или GRE?

В общем спустя много времени пришлось мне таки вернуться к этому вопросу.
На случай, если кто-нибудь столкнется с подобной проблемой:

policy-based-route test-pbr-new permit node 1
   if-match acl 3003
policy-based-route test-pbr-new permit node 2
   if-match acl 3002
   apply ip-address next-hop 10.10.253.2

Сам PBR составлен верно. Проблема оказалась в ACL-ах.
Во-первых:
Comware в PBR попросту игнорирует permit и deny внутри самого ACL.
Во-вторых:
Экспериментально было выяснено, что ситуация, когда ACL фигурирует в нескольких нодах PBR обрабатывается корректно только в том случаи, если ACL-ы во всех нодах кроме последней имеют и source и destination. В противном случаи обработка не прекращается при срабатывании ACL-а.
В-третьих:
Также экспериментально выявлено, что при указании в ACL-е в качестве единственного source подсети совпадающей с подсетью данного интерфейса при обработке политики все ноды содержащие ACL с destination просто игнорируются.

Т.о.
Для реализации обозначенного выше сценария ACL-и должны быть

Advanced ACL  3002, named -none-, 2 rules,
ACL's step is 5
 rule 10 permit ip source 10.10.254.0 0.0.0.255 destination 10.10.0.0 0.0.255.255 (72 times matched)
 rule 20 permit ip source 10.10.254.0 0.0.0.255 destination 192.168.0.0 0.0.255.255

Advanced ACL  3003, named -none-, 1 rule,
ACL's step is 5
 rule 10 permit ip source 10.10.254.0 0.0.0.127 (6 times matched)

А если нужно завернуть всю подсеть, то во второй ноде PBR просто не нужно указывать ACL вообще.

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

Вам вполне подойдет минимальный вариант - два коммутатора 2960 Plus (у обычных EoL в конце октября уже), например WS-C2960+48PST-S (это PoE) и WS-C2960+48TC-S с базовой L2 лицензией. Стека у них нет, но есть пара 1GE портов, чтоб между собой связать.

Маршрутизатор CISCO1941-SEC/K9 вас в принципе тоже должен устроить по всем параметрам, даже без модуля аппаратного шифрования (он около 2K$ стоит). Благо с недавних пор на SSL VPN отдельно лицензии покупать не надо.
Ну и SmartNET, как минимум к самому маршрутизатору.
Итого:
CISCO1941-SEC/K9 - около $3K по GPL (с сервисным контрактом).
WS-C2960+48PST-S - около $3K по GPL.
WS-C2960+48TC-S - около $1,3K по GPL.
Итого имеем 7300 баксов по GPL. Ну т.е. по факту, с учетом скидок, в 6 килобаксов влезете без проблем.

Управляемый/неуправляемый коммутаторы. Для управляемых можно уточнить, что они L2 или второго уровня.

Никак. Это в принципе не будет работать без L2 связности.
А какая задача стоит? И в чем проблема сеть на нормальные сегменты нарезать?

P.S. Похоже вам все таки нужны не VLAN-ы, а L2 port isolation. Реализация зависит от конкретного устройства.

Никакой. Слишком много геморроя вы себе приобретете. Не зависимо от того, что выберете. Для того, чтобы получить учет трафика и логирование придется разворачивать полноценный биллинг, с RADIUS-ом, NetFlow, инспекцией трафика и прочими заморочками, которые не прибавят производительности устройству, между прочим. Для фильтрации урлов на основе категорий, придется ставить внешний сервер, а не редко и платить за подписку на эти самые базы (это если мы, например про Cisco). К тому же еще и куча ручной работы, для парсинга логов.
Железных решений "все-в-одном" я не встречал.
Тут стоит конкретизировать задачу. Почему именно аппаратное решение. Но в любом случаи, мне кажется - оно того не стоит, если конечно нет какого-нибудь мега-аргумента.

Я так понимаю, у вас проблема в том, что в обеих подсетях DHCP и приходит просто два шлюза по-умолчанию, возможно еще и два DNS-а. Иначе проблемы бы не было в принципе и система сама разбиралась куда ходить.
Если так, то самый просто вариант одно из подключений просто руками настроить.

Судя по маске связность между R1 и R2 - L2.
Если сделать между всеми тремя маршрутизаторами единый L2 домен и дать R3 адрес 192.168.90.3 то можно обойтись без PBR. Только для того, чтобы хосты с одним и тем же адресом из обеих сетей (9.0) имели доступ в 75.0, придется городить встречные NAT-ы.

Точно требую Enterprise CAL:
Архивные ящики.
Расширенные политики хранения.
Юридическое удержание.

Возможно еще какие-то специфические настройки ActiveSync,