MagMike

на R1 считается трафик для тех, кто находится в сегменте сервисы,клиенты.

разве в ACL-ах, используемых в PBR можно указывать DSTIP? http://www.cisco.com/en/US/products/ps6599...0800a4409.shtml сам себе отвечаю. получается, что вроде как, можно http://www.cisco.com/en/US/tech/tk364/tech...0801f3b54.shtml вот только если у меня пять подсеток на vpn-ах, и штук 10 в сегменте "сервисы-клиенты", то ACL получится размером 5х10=50 строк... это если я буду PBR применять на интерфейсе от vpn-ов. если от аплинков - то будет 10 строк...

например, как без vrf зарулить трафик от vpn-щиков к "сервисы, клиенты" не через R1, а напрямую (через линк от c6509 на S1)? просто маршруты до этих "сервисы, клиенты" прописать? но трафик из внешнего мира на "сервисы, клиенты" должен ходить через R1.

вот схема: наклонной пунктирной указано разделение двух vrf. cлева вверху - ферма VPN-NAS-ов, подключенных к vrf vpn на c6509. во всем сегменте между NAS-ами и c6509 поднят ospf, чтобы c6509 знал маршрут до каждого юзера, подключившегося по vpn справа вверху - несколько сегментов с сервисами и клиентами. трафик снаружи от аплинков приходит в vrf border и дальше отправляется: для vpn-щиков - в vrf vpn, для сервисов и клиентов - через R1. трафик от vpn-щиков, приходя на vrf vpn, должен смаршрутизироваться в зависимости от назначения - если для сервисов и клиентов - напрямую через свитч S1 (зеленая стрелка), а если наружу, то в зависимости от того, с какого ip-адреса - на соответствующий аплинковский канал (черные пунктирные стрелки). вот тут загвоздка - как сделать такую схему маршрутизации, чтобы в vrf vpn использовалась статика (на сервисы и клиентов), а если пакеты должны идти наружу, тогда PBR (для отправки в аплинки). все остложняется тем, что в таблице маршрутов vrf vpn кроме статических маршрутов на сеть с сервисами и клиентами имеется еще и bgp-шная копия fullview, прилетевшая от vrf border. без нее никак не получится выкинуть трафик наружу.

все так, да не так. из vrf border в vrf vpn "прилетает" full-view, полученный от аплинков. т.е. будут маршруты на все префиксы, имеющиеся в интернете. и тогда set ip default next-hop уже не прокатывает - обязательно найдется маршрут в bgp. а мне надо, чтобы в инет пакеты от определенных ip выходили строго заданным каналом. Можно зафильтровать все маршруты из vrf border, но тогда vrf vpn вообще не будет знать про внешние линки. в принципе, если из border присылать в vpn только маршруты на аплинков, то это было бы самое то. и это можно сделать указанием "redistribute connected" в конфиге bgp в разделе address-family ipv4 vrf border. но как сделать, чтобы этот redistribute шел только в vrf vpn, но не разлетался на самих аплинков? я хоть на аплинки и выставляю distribute-list out, все равно, в случае указания "redistribute connected" туда начинают рассылаться префиксы из моей AS, которые подключены непосредственно к интерфейсам, входящим в vrf border.

ну да, можно. используя отдельный роутер для vpn-сегмента. но в том-то и дело, что не хочется городить цепочку из железок, а хочется использовать одну.

так сложилось, что есть отдельный сегмент с vpn-nas-ами и отдельно еще несколько сегментов, с которыми это nas-овский сегмент соединен напрямую, и к ним же был сегмент от бордера. если насы пристыкую напрямую к бордеру, то пакеты со стороны нас-ов в остальные сегменты будут ходить не напрямую, а через линк от бордера к сегментам. Ну и еще некоторые тонкости, работа которых будет нарушена, если объединить бордерную часть с nas-овской. можно, конечно, оставить nas-овский сегмент на отдельном роутере, но не хочется, чтобы мощности 6509 простаивали, обслуживая только бордер. Так что насчет маршрутизации с применением policy-routing? чтобы вначале маршрутизация шла по статическим маршрутам, а если их нет - тогда уже использовался PBR? как-то можно так сделать?

tgz, я ж написал: Может есть более простые способы организации взаимодействия vrf? вместо того, чтобы пальцы гнуть - лучше б подсказали. PS кстати, в русской раскладке tgz=епя - понятно откуда такая тяга к матам ;)

у меня была проблема с загрузкой CPU из-за неправильного route-map-а. когда переводил маршрутизацию на схему в vrf, пришлось править те места, где vrf надо указывать. в том числе и route-map-ы. и случайно оставил "set ....." от простого (без vrf) роутинга. т.е. было 2 цели set - одна с vrf, вторая - без. как только убрал лишнюю строчку - загрузка сразу упала. Еще знающий человек процитировал вот такую строку: "Any permit route-map sequence with no set statement will cause matching traffic to be processed by the RP" т.е. не должно быть роут-мапов без set-строки.

casperrr, маршрутизация между vrf и global работает по-другому, и настраивается проще. можно и через него, но тут куча проблем других вылезает.во-первых, в локальный vrf (назвал его vrf vpn), прилетает full-view таблица из бордерного vrf (vrf border). Соответственно, отъедается память. как вариант, можно зарезать префиксы, прилетающие из border в vpn. сразу появился первый вопрос. какие префиксы достаточно принимать?попробовал только до /16 - "sh ip ro vrf vpn sum" показывает 8153 сетей, 4974 подсетей. Попробовал от /0 до /19 - 18345 сетей, 25885 подсетей. боюсь, что в первом случае могут образоваться дыры. Кто-то может сказать по опыту - какой длины префиксы достаточно получать? хотя, я подозреваю, можно обойтись без маршрутов из full-view. Дело в том, что все равно пакеты из локальной сети надо направлять наружу через полиси-роутинг - определенные сети - через определенные аплинки. но тут скрывается очередная проблема. в vrf vpn есть статические маршруты на некоторые локальные сети. пакеты от моих пользователей могут идти либо на внутренние ресурсы, либо наружу. в первом случае они должны роутиться согласно статическим маршрутам, прописанным в vrf vpn, во втором - согласно PBR через один из внешних каналов. отсюда второй вопрос - как сделать, чтобы для локальных dstIP использовались статические маршруты, а для всего остального - PBR. статические маршруты имеют distance 1, а маршруты, полученные с внешних bgp - distance 20. по идее, можно это как-то задействовать. но как - не знаю. либо еще по-другому. в роут-мапах для PBR не нашел. со стороны vrf border другие проблемы. как я до этого писал - в vrf vpn гуляет ospf. от подключенных к этому сегменту vpn-серверов приходят анонсы об ip-адресах подключившихся юзеров. поэтому vrf vpn знает какой ip конечного пользователя за каким vpn-концентратором находится. чтобы не было петель в маршрутах, добавлены маршруты в null0 на все сети из которых vpn-щикам выдаваются ip-адреса. т.е., к примеру, есть маршрут на 10.0.0.0/16 null0. а когда пользователь получает ip 10.0.1.2, то в vrf vpn через ospf появляется маршрут на этот ip-адрес. так вот, если из vrf vpn в vrf border экспортировать только статические маршруты, то в vrf border появляется маршрут "10.0.0.0/16 null0". но пакеты с dstip=10.0.1.2, пришедшие снаружи , не роутятся в vrf vpn, чтобы уже там пройтись по таблице маршутизации vrf vpn, а сразу валятся на null0. поэтому приходиться редистрибьютить ospf из vrf vpn в vrf border. а это значит, что при подключении или отлючении юзера к vpn-серверу, в ospf прилетает маршрут на его ip, и этот маршрут передается в bgp vrf border (где и так содержится fullview). поэтому процесс bgp постоянно занят работой. Следовательно это лишняя нагрузка на CPU Может есть более простые способы организации взаимодействия vrf?

На cisco 6509 попробовал завести 2 vrf - один для бордерной части (где крутится bgp c аплинками), другой - для внутренний сегмент (там ospf). Причем нужна маршрутизация между ними. Первое, что пришло в голову - объединить их через ethernet-порты, находящиеся в разных vrf-ах. как написано в http://www.cisco.com/en/US/tech/tk436/tk83....shtml#diffvrfs конечно, насторожило "this is not a recommended solution", но решил попробовать... к слову сказать, ip-адреса сети /30, которая была на этом линке, навешивались не на физические интерфейсы, а на vlan-овские. все виртуальные интерфейсы в 6509 имеют один и тот же МАС-адрес, И встреченные в сети рекомендации по прописыванию в arp-таблицы нужных ip-мас-адресов, ничего не дали - шлюзовые ip друг друга не пинговали. помогло только изменение на одном из vlan-интерфейсов МАС-адреса на другой. после этого даже не пришлось прописывать МАС-адреса вручную. роутинг работал, пакеты перелетали из одного vrf в другой и обратно. Вроде все чудесно Вот только с производительностью какая-то лажа произошла. Как пустил трафик через этот линк, начались жуткие тормоза - терялись пакеты, причем не только на меж-vrf-ном линке, но и на всех остальных интерфейсах. Вплоть до того, что начали отваливаться bgp-сессии с аплинками. при этом cpu был загружен всего на 30. поток через линк шел на скорости не более 70мбит/с, хотя должен был быть как минимум на порядок больше - до переключения шло несколько сот мегабит. ошибок на ethernet-интерфейсе не было. Кто-то пробовал метод объединения vrf-сегментов? какая пропускная способность обеспечивалась?

ну т.е. надо понимать, что с использованием bandwidth все-таки можно сделать то, что мне надо... Спасибо!

Ну тогда вот это: Не нужно. Upstream и так не отдаст больше трафика, чем Вы заплатили. для примера, есть 2 канала - на 50 мбит и на 100 мбит. два класса определяют на какие мои адреса с какого канала идет трафик. соответственно этим классам создается 2 шейпера - один на 50 мбит, второй на 100. затем, зная какие блоки адресов у анлимщиков, какие у помегабайтчиков, для первого шейпера (на 50мбит) создаю 2 "подшейпера", которые шейпят раздельно анлимщиков (к примеру, 30мбит) и помегабайтчков (20 мбит). причем, кажлый из этих "подшейперов" может занимать полосу у соседа, но в пределах своего родительского шейпера (на 50мбит). то же самое - для второго канала. т.е. получается +---- 100 мбит (для трафика от одного провайдера) | +---- 40 мбит (для мегабайтчики) | +---- 60 мбит (анлимщикам) +---- 50 мбит (для трафика от другого провайдера) +---- 20 мбит (для мегабайтчики) +---- 30 мбит (анлимщикам) если убрать первый уровень, то как будет определяться у какого "соседа" можно занимать полосу? чтобы нижележащие подуровни делили трафик между собой только в пределах той полосы, которая приходит от конкретного провайдера. в общем, как я преполагаю, должно получиться что-то типа http://www.cisco.com/en/US/docs/ios/12_1t/....html#wp1025800 чтобы gold, silver и bronze "занимали" полосу только у своих "братьев" в пределах родительской полосы (определяемой соответствующим custX-classes). Это хочется для КАЖДОГО абонента отдельно или для двух групп абонентов помегабайтчики/безлимитчики? нет, это шейпер не персонально на каждого, а общий.

Нет. как я понял, шейпинг можно настраивать только в исходящем направлении. поэтому планируется как раз подцеплять к нему линки в нашу сеть, к абонентам.

А может кто-нибудь рассказать про sip-400? как следует из описания, умеет иерархичный шейпинг. планируется зацепить его на каталист 6509 с sup720. И шейпить внешний трафик с нескольких каналов. именно поэтому нужна иерархичность. чтобы весь поток во внутреннюю сеть был зашейплен: на первом уровне - по входящему каналу (3 разных канала с разными толщинами). на втором уровне - по абонентам. для помегабайтчиков своя полоса, для безлимитчиков своя. на третьем (опционально) - у анлимщиков отдельные полосы для разных видов трафика. например, отдельно для udp полоса и отдельно для tcp. и требуется, чтобы если, например, когда помегабайтчики не качали, свободная часть их полосы отдавалась безлимитчикам. Такое возможно на sip-400, вставленной в c6500 c sup720? какую производительность можно ожидать?

Вопрос как в accel-pptpd понаправлениям считать ) Для меня задача сугубо теоретическая, но очень интересно. Статью у Асмодея читал. А при чем тут accel-pptpd? патч накладывается на pppd. точнее, на ядерный модуль ppp_generic. а чем туннелирование делается - не важно - хоть оригинальный pptpd, хоть accel. более того, у меня на этих же серверах запущен pppoe. и точно так же pppd, запущенный для pppoe-сессии считает трафик с разделением.

Linux, accel-pptpd либо pppoe (можно даже на одном и том же железе одновременно, pppd, пропатченный для подсчета трафика по разным направлениям (http://abills.net.ua/wiki/doku.php?id=abills:docs:linux:lepppd:ru) шейпинг через tc (htb, sfq) более 1000 сессий - без проблем держит. железо - Xeon™ CPU 3.00GHz и Core™2 Quad CPU Q8200 @ 2.33GHz RAM 2 GB 2xIntel gigabit Ethernet вот в данный момент (далеко не ЧНН) - 1031 сессия Core™2 Quad CPU Q8200 @ 2.33GHz load average: 0.79, 0.91, 0.81

rc_avpair_add(&send, PW_CALLING_STATION_ID, remote_number, 0, VENDOR_NONE); вот, как раз этим передается в атрибуте Calling-Station-Id то, что изначально из командной строки попадает из параметра remotenumber. а ipparam обычно используется в скриптах ip-up, ip-down, куда он передается 6-ым параметром. так что ловите радиусом Calling-Station-Id.

патч, который в МАС-адрес клиента добавляет имя интерфейса затем этот адрес передается в качестве remotenumber и ipparam pppd. --- rp-pppoe-3.10/src/pppoe-server.c 2008-06-30 20:00:43.000000000 +0600 +++ rp-pppoe-3.10-my/src/pppoe-server.c 2009-05-02 16:16:55.000000000 +0600 @@ -1746,6 +1746,16 @@ argv[c++] = "novj"; argv[c++] = "novjccomp"; argv[c++] = "default-asyncmap"; + + snprintf(buffer, SMALLBUF, "%s:%02x:%02x:%02x:%02x:%02x:%02x", + session->ethif->name, + session->eth[0], session->eth[1], session->eth[2], + session->eth[3], session->eth[4], session->eth[5]); + argv[c++] = "ipparam"; + argv[c++] = strdup(buffer); + argv[c++] = "remotenumber"; + argv[c++] = strdup(buffer); + if (Synchronous) { argv[c++] = "sync"; } @@ -1832,6 +1842,16 @@ argv[c++] = "novj"; argv[c++] = "novjccomp"; argv[c++] = "default-asyncmap"; + + snprintf(buffer, SMALLBUF, "%s:%02x:%02x:%02x:%02x:%02x:%02x", + session->ethif->name, + session->eth[0], session->eth[1], session->eth[2], + session->eth[3], session->eth[4], session->eth[5]); + argv[c++] = "ipparam"; + argv[c++] = strdup(buffer); + argv[c++] = "remotenumber"; + argv[c++] = strdup(buffer); + if (PassUnitOptionToPPPD) { argv[c++] = "unit"; sprintf(buffer, "%u", (unsigned int) (ntohs(session->sess) - 1 - SessOffset));

А препенды разве помогают? Я имею в виду не по спецификации протокола, а по жизни? Вы сами дефолтный маршрут выбираете по препендам или выставляете исходя из цены/загрузки каналов?

Если не сложно - отпишись по результатам, пожалуйста.

в соседней ветке похожая проблема - http://forum.nag.ru/forum/index.php?showtopic=47480 при 1500 правилах только ветвление поможет

порядка 400 машина 2-х ядерная 3 ггц акссел работает на том-же ядре где идет софт ирк... если 1-ый проц перегрузится - начнет заниматься второй и так далее... надо распределить софт ирк от сетеых плат по процессорам... щас е вспомню но где-то уже про это на форуме писали в двух словах 1. надо посмотреть на каких ирках висят ваши сетевухи 2. прописать афинити маски для этих ирков (их надо загонять в какой-то стартап скрипт после поднятия сетевух т.к. они сбрасываются при up'е делается все через /proc 1-2 сделанов сервере 2 сетевых. на одной запущен pptp. эта карта работает на CPU0. вторая (на CPU2) смотрит в инет. кстати, чтобы не делать костыли в виде двух процессов, в состав пакета включен патч для pppd-2.4.4 (pppd-allow-mppe.patch), который позволяет подключаться клиентам как с mppe так и без него Совсем недавно искал такой патчик, и не нашел зато нашел что не работает allow but not require mppe.. дайте ссылку на доку плз (( тоже не нашел патч... тоже прошу дать ссылку. нужно именно 4 ядра или пойдет coreduo c включенным HT?

ты используешь шифрование или сжатие трафика ?и какая версия accel-pptp ? запущено 2 серверных процесса - один с mppe, другой без. подавляющее большинство сессий - с mppe. PPTP plugin version 0.8.2 compiled for pppd-2.4.4, linux-2.6.28.5

а у меня другая проблема. похоже, accel-pptp "живет" на одном процессоре. причем вместе с одной из сетёвок 05:45:14 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 05:45:15 PM all 1.49 0.00 2.49 0.00 0.00 46.52 0.00 49.50 4698.00 05:45:15 PM 0 3.00 0.00 7.00 0.00 0.00 86.00 0.00 4.00 3624.00 05:45:15 PM 1 0.00 0.00 2.00 0.00 0.00 1.00 0.00 97.00 0.00 05:45:15 PM 2 0.00 0.00 1.00 0.00 0.00 100.00 0.00 0.00 53.00 05:45:15 PM 3 2.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00 0.00 на CPU2 softirq на 100%, а на остальных sys почти не занят. и это при >900 сессиях. т.е. получается, что скорее всего все-таки pptp висят на этом же втором CPU. как-то заставить работать его на другом можно? или выход только от обратного - переносом irq сетевой карты на CPU3?