YaroslavR

Через rib-groups http://kb.juniper.net/InfoCenter/index?page=content&id=KB16133

Увы, на маршутизаторах Cisco нет способов динамически перекидывать маршруты из глобальной таблицы в VRF и обратно. Только статиками. Либо избавляйтесь от VRF для белых адресов, либо переходите на Juniper или ALU.

На 6708 архитектура достаточно нетривиальная... Порты объединены в пары каналами 16G следующим образом - 1,4; 2,3; 5,7; 6,8. На плате 2 асика - первая и третья пара (1, 4, 5 и 7 порты) приходят на один асик, вторая и четвертая (2, 3, 6, 8) - на другой. Между асиками трафик ходит через фабрику. Соответственно попробуйте источники и получатели держать в рамках одного асика.

/127. Читайте draft-ietf-6man-prefixlen-p2p. Особое внимание уделите 5-й части. Да /127 - смотри выше. Link-local там будут по-любому не зависимо от конфигурации глобальных адресов. У этих адресов разные задачи и области применения.

До боли знакомая картина... В реализации Netflow на Sup32/Sup720 всех модификаций есть 4 аппаратных ограничения связанные со спецификой чипа EARL7: 1. Нет пакетного семплирования. Все пакеты попадают в кеш, а оттуда уже семплируются. При 100% загрузке TCAM информация о новых сессиях не сохраняется - соответственно данные Netflow становятся полностью недостоверными. К сожалению этот процесс не зависит напрямую от объема трафика: важна специфика - сколько сессий проходит через железку, насколько удачно их хеши ложатся в TCAM и проч. Решения этой проблемы нет - в качестве временных методов способных ненадолго улучшить ситуацию можно посоветовать отключение семплинга и выкручивание aging таймеров в минимум, а так же установку DFC модулей; 2. Во flow записях не отдаются TCP флаги. Для определенных задач это важно; 3. Netflow не поддерживается для пакетов с MPLS метками. Несмотря на то что соответствующие команды CLI есть: 4. Netflow не экспортируется для отброшенного трафика Если вам важен Netflow - не выбирайте Cisco 7600/6500. Из цисколенда смотрите в сторону ASR1000/ASR9000/Nexus7000 - там с flow /по крайней мере на аппаратном уровне/ все более-менее хорошо.

Попробуйте включить ingress на всех интерфейсах - и на template и на интерфейсе в сторону бекбона. Не забудьте подкрутить таймеры по необходимости, особое внимание следует уделить active flow aging, который по умолчанию составляет 30 минут.

У меня, наверное, не правильный asr1002. Netflow v5 пишет, и мои скриптики их (эти фловы) успешно анализируют на предмет аномалий... ЗЫ. К чему я. Давайте не будем говорить за всех. Я не утверждаю что Netflow v5 не работает ни при каких обстоятельствах. Я утверждаю что при определенных обстоятельствах Netflow v5 вызывает краши и рекомендация вендора - не использовать Netflow v5. Общение с разработчиками ASR1000 подтвердило что поддержку Netflow v5 они отбросили несколько релизов назад - т.е. они не тестируют работоспособность и стабильность Netflow v5. Настоятельно рекомендуется использовать именно v9 чтобы избежать неприятного сюрприза в какой-нибудь момент. Коллегам, испытывающим проблемы со стабильностью ASR1000 при включенном Netflow, настоятельно рекомендуется попробовать переключиться на v9. Это может помочь.

Частая причина крашей на ASR1000 - попытки настроить на нем Netflow v5. Несмотря на наличие команд, Netflow v5 не поддерживается и поддерживаться не будет. Используйте Netflow v9. Комбинацию NAT + Netflow v9 + BBA самолично настраивал полгода назад и все более-менее работало. К сожалению версию IOS уже не помню.

Формально Nexus 7000 - 16K VLANов. Правда не более 4К в одном виртуальном контексте...

Из того оборудования с которым мне доводилось сталкиваться хотелось бы отметить Force10 и Extreme. Force10 S25P вполне отвечает вашему требованию - http://www.force10networks.com/products/s25p.asp Так же обратите внимание на Extreme Summit X480-24x - у него 12 SFP (для которых есть вариант 10/100/1000BaseT) и 12 комбо-портов - http://www.extremenetworks.com/products/su...80.aspx?refID=4

И давно ли C6500 на обычных картах научился делать VPLS? А карты плотностью 12x10G в c6500 тоже есть? И BFD хотя бы 50мс c6500 умеет? Уж простите, но тут вы промазали - архитектурно s9300 очень сильно отличается от c6500.

Из личного опыта: У 7600 очень плохой NetFlow - фактически непредсказуемые потери флоу из кеша, не экспортируются TCP флаги в NetFlow, отсутствует поддержка NetFlow для пакетов с метками; Тип uRPF (loose или strict) настраивается на всю коробку - нет возможности на разные интерфейсы повесить различный тип uRPF; Есть серьезные ограничения на возможности по настройке ACL; В некоторых случаях определенные потоки трафика коммутируются через MSFC вместо PFC/DFC загружая CPU коробки. Так же у 7600/SUP720 по современным меркам очень медленный control-plane - тот же BFD работает настолько непредсказуемо, что им лучше не пользоваться. Не слишком быстро сходятся маршруты внутри VRF. Так же немаловажно что будущее этой железки (а чип EARL7 на котором она построена 2002 года рождения) несколько туманно. Если хочется именно Cisco на бордер с производительностью x*10G - смотрите лучше в сторону ASR9000 или маленького CRS.

Самый яркий пример - Comcast, который за два года смог кардинально изменить структуру своего трафика. http://www.nanog.org/meetings/nanog47/abst...&nm=nanog47 См. 13, 19-20 слайды или видео.

Смотрите в сторону Cisco ASR1000 - умеет все что вам требуется. Есть два варианта производительности data plane - 5Gbps и 10Gbps. По сути - маршрутизатор между 7200 и 7600.