KonstantinC

А другого способа поклирить policy cache кроме ребута или убирания\добавления ааа сервера нет? clear subscriber session all не помогает, кеш остается неизменным

Тоже не выйдет количество nat серверов периодически меняется, каждый раз редактировать route map не вариант да и с отказоустойчивостью будут проблемы

Нет, крайне важно Ибо на ASR'ах работает isg и пакет должен вернуться строго на тот ASR где уже есть ipoe сессия для данного src ip

Есть "n" ASR-к и "m" линуксовых nat серверов Нужно, чтобы сервера слали ответные пакеты обратно на тот же ASR откуда прилетел пакет

Ага... т.е. хрен её заставишь ещё и полисить такую полосу.. сдохнет раньше Хм А есть инфа по цене SCE10000? В июльском gpl нету такого девайса

Нет мыслей куда копать? Очень нужно знать алгоритм, есть спец который сдублирует этот алгоритм в ядре линуска.. В идеале бы заставить ASR раскидывать пакеты ориентируясь только на src-ip... но железяка этого не умеет

Предположим есть SCE8000, занимается dpi, режет торренты... Через неё сейчас прёт 11Gbit\s.. трафик процессоры загружены на 60% Опытным путем выяснено, что сервис лоссы появляются если загрузка traffic processor'ов переваливает за 90% Т.е. SCE реально сможет прокачать через себя 14,5-15Гбит (это только даунлинк) Вопрос: получится ли добавить на SCE ещё и shaping? Сильно ли вырастет её загрузка? Или там shaping аппаратный и её будет пофиг?

На ASR1k доступны четыре алгоритма ecmp, из них дефолтный "universal" учитывает src и dst ip ASR#ip cef load-sharing algorithm ? include-ports Algorithm that includes layer 4 ports original Original algorithm tunnel Algorithm for use in tunnel only environments universal Algorithm for use in most environments Кто-нибудь знает точное описание этого алгоритма? Есть необходимость повторить его на linux И ещё... тут сказано http://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/116376-technote-cef-00.html что Проверил, по крайней мере на CSR это не соответствует действительности, там при четырех ecmp трафик раскидывает строго в равных пропорциях.. странно

Приветствую На интерфейс ASR прилетают пакеты от абонентов, создаются сессии, авторизует их радиус... всё прекрасно работает Появилась необходимость для конкретных адресов иметь всегда активные сессии где разрешалось бы прохождение трафика interface tenGigabitEthernet 0/0/0.2 encapsulation dot1Q 2 ip address 1.1.1.1 255.255.255.0 service-policy type control ISG-POLICY ip subscriber routed initiator unclassified ip-address initiator static ip subscriber list StaticList ip subscriber list StaticList ip source 1.1.1.2 Проблема в том, что сессия для 1.1.1.2 поднимается, но она не авторизована... и ASR пытается её авторизовать через радиус А нужно, чтобы ASR вовсе не пытался авторизовать 1.1.1.2, а сразу вешал некую subscriber policy Это возможно?

по сути не 65535, а меньше wellknown порты использовать думаю не стоит Один к одному.. где ж столько адресов найти? ) По идее 1000 портов на абонента должно быть достаточно

Добрый день Наверняка уже сто раз обсуждалось, но что-то не могу нагуглить best practices для CGN Какого размера нужен пул белых адресов для NAT'a энного числа абонентов? Сколько абонентов запихнуть в 1 белый IP? Я так понимаю в среднем надо рассчитывать на 50-60 абонентов на 1 белый адрес?

При установке двух и более SCE для корректной работы нужно чтобы пакеты одной сессии всегда ходили через один и тот же девайс Для этого в port channel там где subscriber side ставить алгоритм хеширования ip-src-only, а где network side - ip-dst-only Тогда пакеты будут попадать на одну и ту же SCE Иначе корректно распознавать сессии пара не будет

Спасибо, коллега! Действительно, ip route vrf TestVRF 1.1.1.2 255.255.255.255 port-channel 1.20 1.1.1.2 прокатило

Второй любопытный момент на ASR. Маршрут для unnumbered интерфейса в global прописывается interface Loopback100 ip address 1.1.1.1 255.255.255.0 interface Port-channel1.20 encapsulation dot1Q 20 ip unnumbered Loopback100 ip route 1.1.1.2 255.255.255.255 port-channel 1.20 А вот внутри любого vrf нет: interface Loopback100 ip vrf forwarding TestVRF ip address 1.1.1.1 255.255.255.0 interface Port-channel1.20 encapsulation dot1Q 20 ip vrf forwarding TestVRF ip unnumbered Loopback100 ip route vrf TestVRF 1.1.1.2 255.255.255.255 port-channel 1.20 [b]% For VPN or topology routes, must specify a next hop IP address if not a point-to-point interface[/b]

zhenya` Хм.. ну сам то port-channel пашет QoS не поддерживается значит.. похоже и шейпинг тоже