JDima

создать локальную беспроводную сеть на 1000+ клиентов.

Вообще ни о чем не говорит.

Одно дело — 1000+ клиентов, участников одной конференции, набившиеся в пару-тройку крупных залов.

Другое дело — 1000+ клиентов ровным слоем по целому городу.

Это совершенно разные задачи с совершенно разными решениями.

Раз роуминг не нужен — задача элементарна. Просто тот же SSID с одинаковой аутентификацией.

Mesh сеть (сложно тянуть медь/оптику к каждой точке в парке). Лучше серьезных вендоров — Cisco, Aruba.

Не будет ли слишком медленно работать сеть на компьютерах слева, если они будут обращаться и в интернет, и на сервер к серверу справа через один провод?

Вы не пробовали сложить утилизацию интерфейсов в сторону сервера и в сторону роутера? Это и будет ответом. Как вы представляете себе степень достоверности ответа посторонних людей, понятия не имеющих о характере гоняемого в вашей сети трафика?

crypto isakmp policy 20
authentication rsa-sig

Не сработает — новый дебаг.

А в каком контексте возник вопрос?
А то обычно железки прожигают либо iperf'ом, либо специализированными устройствами вроде Spirent Testcenter… Но в любом случае, шибко много про это не пишут, потому что нечего писать.

У цисок совершенно стандартная реализация IPSec (как вариант — с L2TP). Раз «подешевле» — смотрите в сторону каких-нибудь микротиков и тому подобного. Наверняка и dd-wrt сгодится. Если с бюджетом все не настолько плохо, то действительно можно 8ХХ взять, только внимание на производительность.
Ну и как бы имеет смысл обновить софт… Сказать «12.4(15)T5 устарел лет на пять» — ничего не сказать. Последний представитель той линейки софта — 12.4(15)T17, и кроме багфиксов там толком ничего и не было на протяжении 12-и серий. При задействовании нового функционала рискуете получить много приключений на ровном месте…

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 и вирусов, который без проблем реализуется отдельной железкой) на них тоже есть.

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

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

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

8-портовый управляемый свитч. По две сетевухи на компьютер с агрегацией. Формально будет «более 1гбит/с», т.е. при благополучном расположении звезд и многопоточной передаче — аж 2гб/с.

При этом каждый посетитель должен выходить в инет через VPN.

Как это понимать? Каждый посетитель должен поднимать туннель? Докуда?

А так, при наличии связности между кафешками и каким-либо центральным узлом — ставить в кафе безмозглые точки доступа, в центре — пара контроллеров. Сами точки доступа вообще не требуют конфигурации.

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

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

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

Где-то так.

Все-таки в чем сакральный смысл такой адской комбинации — объединения 10G интерфейсов и хилых Е1-х? Им и 100мб/с канала хватит. Может, заказчик не в курсе, что Е1 тянет лишь 2мб/с? Но я не уверен, что у циски есть нормальное решение для собирания такого количества потоков.
Какой функционал требуется от этой гипотетической вундервафли? Заказчик не пробовал предложить задачу вместо решения?

Если забыть про Е1, то под п.3 берите Nexus 5548UP (внимание — он не осилит роутинг более чем 160гб/с, но свитчинг — запросто line-rate).

По п.2 опять же непонятно, нужен ли L3, и какие будут задачи. Но скорее всего подойдет 3560-X либо 3750-X.

Но на будущее — всегда уточняйте задачу. Вы не написали ровным счетом ничего. Например, если по п.3 требуется MPLS — N5K в пролете.