JDima

Загадка природы… Возможно, чтобы понимать, что «не езернетом единым».
Но концепция MPLS ИМХО сложновата будет для CCNA. Там еще только учатся IP пакеты форвардить.
И какой смысл учить MPLS без VPN или TE? Ну включили LDP. Ну распространились метки. В результате ничего не изменилось, только на 4 байта увеличились заголовки, ну и где-то глубоко внутри роутера он начал смотреть на другой заголовок при передаче пакета, с тем же результатом… Спросят преподавателя «зачем мы вводили mpls ip на интерфейсах?» — а тому нечего сказать кроме «ну потом можно будет еще вот это настроить».

Cisco — ASA и ISR не реализует все функции.

Аса, понятно, бесполезна в этом сценарии, но вот ISR чем не устроили?

Локальная аутентификация wi-fi есть (зачем?)

Балансировка есть, причем весьма интеллектуальная — PfR, эта штука способна спасти качество сервиса для определенных (указанных) классов трафика при деградации связи, а не только при полном падении связи. Иначе — костыли на базе EEM с массой ограничений и минимумом интеллекта. В самом простом случае тупо ECMP.

Фильтрации по URL, IPS и прочие — к SM модулям.

VPN — не проблема. DMVPN для site-to-site и anyconnect для RA. Можно Flex настроить.

«быстрое обнаружение «узких мест»» — не понял вопрос. Но PfR вместе с QoS способны на многое в автоматическом режиме.

«повышение производительности сервисов, требующих широкой полосы пропускания, таких как VoIP и видеоконференции;»
Легко. Опять же, PfR, позволяющий указывать требования для разных классов трафика и автоматически выбирающий маршрут в зависимости от удовлетворения требований, плюс QoS на выходе.

«QoS;»
Запросто. Вдобавок, у ISR есть, насколько мне известно, уникальная фича «per-tunnel QoS». Суть: центральный офис будет знать про ширину канала у каждого из регионов, и сможет динамически применять политики QoS для каждого региона.

«шейпинг трафика — чтобы один сотрудник не мог занять канал когда возникает очередь, но мог использовать весь канал когда, например, он один в офисе или когда канал не полностью занят и нет очереди.»
Вы назвали это шейпингом, но на самом деле это как раз принцип работы приоритезации QoS, не имеющий к шейпингу никакого отношения.
Или подразумевается, что вешается шейпер, соответствующий ширине провайдерского канала, и в нем уже классические очереди? Это стандартная практика.

То есть по сути, ваш таргет — ISR G2, удовлетворяющий всем требованиям. Это бранчи. В центр, на терминацию VPN каналов лучше ASR1k поставить, благо они относительно недорогие — пиров многовато для ISR. Весь указанный выше функционал (кроме фильтрации URL и вирусов, который без проблем реализуется отдельной железкой) на них тоже есть.

Как вариант — www.youtube.com/playlist?list=PLA0AF9A1586D50544 и «скачать видео youtube» :)
Не узнаю INE. Они что, действительно бесплатно опубликовали весь курс?

Да как бы ничего больше в голову не приходит…

Смотря какой анализ нужен. Если фиксировать наличие заранее известных пакетов, то можно разрешающий ACL повесить (если заранее известно, что пакетов очень мало, то можно даже попробовать со словом «log», но лучше без этого).

1) Проще всего сделать два SSID, один для полноценного просмотра, другой для редиректа через сервер.
2) Прогон трафика через прокси и обратно можно сделать средствами policy-based routing либо разделением на vrfы и статическими маршрутами в каждом (но тогда 100% трафика будет идти через прокси, что в целом тоже неплохо).

Если в требовании «Как перенаправить все запросы определенных пользователей по http на локальный сервер?» можно выделить «определенных пользователей» по IP адресу, то PBR определенно выглядит интереснее.
Только не забудьте сделать его в обе стороны.

IPSec должен шифровать трафик от физического интерфейса до физического интерфейса, а не между туннельными адресами. Т.е. между 1.1.1.1 и 2.2.2.2. Правьте crypto acl.

В нашей компании возникла необходимость установить L3 свитч и фаирволы в основном офисе и филиалах.

Какой требуется функционал?

А так да, жуниперы хорошие железки. Но отталкиваться все же надо не от «цена за порт», а от конкретных задач.

С приличным запасом — 2921 (определитесь с требуемыми лицензиями). Лучше сразу добить ей память до гига.
4-байтные AS уже давно поддерживаются всем не снятым с продаж железом, знающим BGP.

1. Исходящий шейпинг плюс LLQ — легко. В принципе, классификацию трафика можно делать через NBAR, ресурсов должно хватить (если там ничего кроме канала на 4,5мб/с канала нет).
С приоритезацией входящего трафика сложнее. Если в какие-то моменты времени возникнет перегрузка канала (а она будет, ибо TCP всегда работает всплесками, даже если в среднем за 5 секунд канал нагружен лишь наполовину), то дропать пакеты будет железка провайдера, а она не делает различий между голосом и HTTP. У меня (дома) более-менее хорошо работает схема «полисить все кроме голоса до 3/4 от скорости канала». Увы, любая реализация красивых очередей в направлении «in» будет вызывать дропы голосового трафика, и даже предложенная схема не идеальна, кратковременные всплески будут. Ну и канал задействуется неоптимально.
3. Вряд ли.
4. С точки зрения указанной задачи — никакого.

www.cisco.com/en/US/prod/collateral/routers/ps10616/white_paper_c11_556985.html#wp9000801

Для IPSec надо сразу брать security bundle. CISCO1941-SEC/K9.

1) Глобальная настройка: Routed vs Transparent. Совсем глобальная. Transparent теряет массу фич, приобретая ровно одну.

2) Затем, можно выбрать, в одном контексте работать или в нескольких (но вне зависимости от выбора все контексты будут в выбранном в п.1 режиме).

Контексты можно грубо сравнить с виртуальными машинами. Несколько логических ASA в одной железке, им выделены разные интерфейсы, трафик между контекстами не передается, у каждого из них свой конфиг.
Если задействуется failover, то в одноконтекстном режиме одна из железок всегда простаивает (как бы неэффективно), а в многоконтекстном можно размазать контексты по ASAшкам, и если одна из них сдохнет — контексты соберутся на оставшейся. Но один контекст не может работать одновременно на двух устройствах.
Ну и в многоконтекстном режиме теряется терминация VPN и еще ряд фич по мелочи. Хотя скоро это поправят.

Где-то так.

Безусловно.
www.google.ru/search?q=%D0%B1%D0%B8%D0%BB%D0%BB%D0%B8%D0%BD%D0%B3+cisco+callmanager

А еще можно локально глядеть CDRы. Сервис называется CDR Analysis and Reporting (именно требует включения сервиса Cisco CAR Web Service в Feature Services, после чего появится соответствующий пункт в Cisco Unified Serviceability => Tools).