[survivor]

При ip subscriber routed делается все просто. Идет запрос на freeradius, в username идет ip.

Самописный модуль идет с этим ip к обоим dhcpd по dhcp lease query и от него узнает и мак и опцию 82.

 

Постараемся повторить :) спасибо за идею!

 

только не понял:

идет с этим ip к обоим dhcpd

два dhcpd это для redundancy?

[survivor]

Насчет того как на корневом свиче трафик идущий от стермиринованных по L3 домонетчиков повернуть на ASR и не дать ему уйти в аплинк без контроля...

Попробовал на GNS'е такую схемку: на аггрегирующих свичах пихнул клиентов в отдельный VRF, связал аггрегирующие свичи с ядром дополнительно еще одним вланом в соответствующем VRF'е, в нем поднял дополнительный eigrp, в котором default route уже не аплинк, а ASR. Сам ASR подключил к ядру двумя вланами: в одном ASR получает default на глобальную таблицу от корневого свича, во втором ASR сам анонсирует default в VRF'е для аггрегирующих свичей. На ASR'е сделал route leaking через статик роуты.

Теперь весь траффик по прежнему ходит через корневой свич в аплинк, а от клиентов идет до корневого свича, потом в ASR, потом обратно в корневой свич и только потом в аплинк.

Это все по фэншую или извращенство какое-то не пойму :)

Изменено 11 декабря, 2012 пользователем survivor

[denis_vid]

А в чем проблема, op82 на доступе, дхцп отдельно, биллинг отдельно, L3 агрегировать хотя в ядре хоть ближе к абоненту, сводить все на брас в ASR.

Можно RFC1918 назначать динамически op82 и юзать нат. Все это проверено и работает.

 

При ip subscriber routed делается все просто. Идет запрос на freeradius, в username идет ip.

Самописный модуль идет с этим ip к обоим dhcpd по dhcp lease query и от него узнает и мак и опцию 82.

Можно так а можно просто по айпи авторизовывать с op82

Изменено 11 декабря, 2012 пользователем denis_vid

[survivor]

denis_vid проблемы на самом деле две:

1) как авторизовывать абонента по opt82 на брасе, если абонент по L3 терминируется НЕ на брасе, а где-то по пути на уровне аггрегации. Откуда брас получит opt82? opt82 содержится в dhcp пакете который существует только между абонентом и аггрегатором и между аггрегатором и dhcp сервером. На брас уже приходят IP пакеты абонента (в них opt82 нет как вы понимаете). Значит:

A) либо брас должен авторизовывать абонента по IP, что приводит нас либо к статическим адресам (а хочется динамику), либо к хитроумной связке радиуса/dhcp/биллинга, озвученной Дегтярев Илья.

B) либо аггрегатор пробрасывает dhcp запрос не к dhcp серверу, а к брасу, а тот в свою очередь уже к dhcp серверу, при этом нужно настроить opt82 encapsulation, как советовал Zarin. Но есть сомнения на счет того как это будет работать, в частности у m1h.

 

2) вторая проблема - как на корневом свиче IP трафик идущий от абонентов сроутить на брас не дав ему уйти по дефолту к аплинку. Policy routing не подходит из соображений производительности, с VRF-lite не совсем понятно что делать, я попробовал на эмуляторе схему с route leaking'ом, но думаю есть и более красивые решения...

 

Вот, а вы говорите, все просто :)

[denis_vid]

denis_vid проблемы на самом деле две:

1) как авторизовывать абонента по opt82 на брасе, если абонент по L3 терминируется НЕ на брасе, а где-то по пути на уровне аггрегации. Откуда брас получит opt82? opt82 содержится в dhcp пакете который существует только между абонентом и аггрегатором и между аггрегатором и dhcp сервером. На брас уже приходят IP пакеты абонента (в них opt82 нет как вы понимаете). Значит:

A) либо брас должен авторизовывать абонента по IP, что приводит нас либо к статическим адресам (а хочется динамику), либо к хитроумной связке радиуса/dhcp/биллинга, озвученной Дегтярев Илья.

B) либо аггрегатор пробрасывает dhcp запрос не к dhcp серверу, а к брасу, а тот в свою очередь уже к dhcp серверу, при этом нужно настроить opt82 encapsulation, как советовал Zarin. Но есть сомнения на счет того как это будет работать, в частности у m1h.

 

2) вторая проблема - как на корневом свиче IP трафик идущий от абонентов сроутить на брас не дав ему уйти по дефолту к аплинку. Policy routing не подходит из соображений производительности, с VRF-lite не совсем понятно что делать, я попробовал на эмуляторе схему с route leaking'ом, но думаю есть и более красивые решения...

 

Вот, а вы говорите, все просто :)

1)Назначаете адреса динамически op82, можно серые, в биллинге(в примере abills с модулем ISG) в качестве CID указываете ip абонента, можно и мак так как описывал в примере Дегтярев Илья.

2)Используете ASR как BRAS&Border, весь трафик наружу заворачиваете на него. На нем же терминируете то что вам надо pppoe/l2tp/ISG, если адреса серые используете NAT

[m1h]

2) вторая проблема - как на корневом свиче IP трафик идущий от абонентов сроутить на брас не дав ему уйти по дефолту к аплинку. Policy routing не подходит из соображений производительности, с VRF-lite не совсем понятно что делать, я попробовал на эмуляторе схему с route leaking'ом, но думаю есть и более красивые решения...

А чего "некрасивого" в этой схеме?

Получается что мы делим корневой свич на два виртуальных форвардинг плэйна. При наличии денег, можно и реально разделить на две железки: через одну БРАС будет видет агрегаторы, через другую интернет в лице бордера.

 

vrf-lite это просто разделение устройства на непересекающиеся контрол и форвардинг плэйны, без организации L3VPN на множестве устройств.

[survivor]

denis_vid

1) если абонент получает динамический адрес, то какой адрес прописывать как CID в биллинге? :)

2) если строить с нуля сеть под задачу этот подход возможен, согласен... или на стенде.

 

m1h отдельные железки я не потяну, а вариант с VRF'ами и route leaking'ом мне очень даже по душе, просто необычно как-то :) есть какие-то подводные камни, которые меня ждут?

[NikAlexAn]

 

вариант с VRF'ами и route leaking'ом мне очень даже по душе

 

А разве нельзя обойтись без VRF-ов на ASR-е в данном случае?

[m1h]

survivor

А ликинг вы зачем используете?

Почему нельзя с агрегации пустить трафик b2c абонентов в отдельных вланах, а трафик который на БРАС идти не должен, в других.[quote name='NikAlexAn'

 

[timestamp='1355307480' post=785334]

А разве нельзя обойтись без VRF-ов на ASR-е в данном случае?

Так vrf'ы у ТС не на ASR а на 6509 которая Core-Switch...

[survivor]

Ну смотрите: есть аггрегирующий свич, к нему приходят сотня вланов, от абонентов. Терминируются по L3 тут же на нем. Далее свич имеет несколько вланов в сторону ядра сети. Если он получит в одном из них дефолт, то весь траффик (и абонентский и прочий) пойдет в тот влан, попадет на 6509 в центре и уйдет в аплинк. Если во всех вланах будет дефолт, то же - только equal cost load balancing.

Надо чтобы домонетовский траффик шел в отдельном влане (опять же вся сложность в том что абонентский траффик уже L3), который в ядре сети будет втыкаться в брас. Как это сделать? Я вижу только один выход - абонентские interface vlan и interface vlan одного из вланов идущих в ядро сети запихнуть в отдельный VRF. И в нем от браса дать дефолт.

Итак до браса все доходит. Проходит ISG, авторизуется... а дальше? Надо попасть обратно в корневой свич, чтобы уйти в аплинк. Т.е. нужно попасть в глобальную таблицу маршрутизации. Значит route leaking.

[denis_vid]

denis_vid

1) если абонент получает динамический адрес, то какой адрес прописывать как CID в биллинге? :)

Динамический всмсысле назначается дхцп) Но значение его постоянно, ну а дальше динамик нат

Итак до браса все доходит. Проходит ISG, авторизуется... а дальше? Надо попасть обратно в корневой свич, чтобы уйти в аплинк. Т.е. нужно попасть в глобальную таблицу маршрутизации. Значит route leaking.

Насколько я знаю route leaking с vrf не дружит

Изменено 12 декабря, 2012 пользователем denis_vid

[NikAlexAn]

Ну смотрите: есть аггрегирующий свич, к нему приходят сотня вланов, от абонентов. Терминируются по L3 тут же на нем. Далее свич имеет несколько вланов в сторону ядра сети. Если он получит в одном из них дефолт, то весь траффик (и абонентский и прочий) пойдет в тот влан, попадет на 6509 в центре и уйдет в аплинк. Если во всех вланах будет дефолт, то же - только equal cost load balancing.

Надо чтобы домонетовский траффик шел в отдельном влане (опять же вся сложность в том что абонентский траффик уже L3), который в ядре сети будет втыкаться в брас. Как это сделать? Я вижу только один выход - абонентские interface vlan и interface vlan одного из вланов идущих в ядро сети запихнуть в отдельный VRF. И в нем от браса дать дефолт.

Итак до браса все доходит. Проходит ISG, авторизуется... а дальше? Надо попасть обратно в корневой свич, чтобы уйти в аплинк. Т.е. нужно попасть в глобальную таблицу маршрутизации. Значит route leaking.

 

Не логичней ли ядро (6509) поделить vrf-ами и соединить их через ASR?

[survivor]

Не логичней ли ядро (6509) поделить vrf-ами и соединить их через ASR?

хм, а ведь и правда :) спасибо :)

 

Насколько я знаю route leaking с vrf не дружит

на GNS'е у меня заработало

[Дегтярев Илья]

Зачем извращаться с VRF на 65 циске.

 

Нормально на ней работает pbr. у нас вообще все со стороны абонентов разруливается pbrом, дефолта нет в принципе - тоб пакет из-какого-нибудь локального пиринга не заставил ISG сгенерить сессию.

 

Единственное ограничение 65той платформы - нельзя сделять pbr на адрес в том же влане, откуда прилетел трафик - обрабатывается процом.

Если до ISG идет отдельный влан, set ip default next hop отлично отрабатывает даже в acl с deny.

 

Стоит SUP720-3cxl, ранее работало на 3b

[s.lobanov]

Дегтярев Илья

Просто в курсе CCNP рассказывается что PBR это зло, без уточнения для какой платформы и при каких условиях(конфиге), вот люди и боятся...

[survivor]

NikAlexAn

Не логичней ли ядро (6509) поделить vrf-ами и соединить их через ASR?

Собрал на GNS'е - работает как надо :) спасибо!

 

Дегтярев Илья

Нормально на ней работает pbr.

Отлично! Я действительно думал что PBR это зло :) Спасибо, будет запасным вариантом!

[NikAlexAn]

NikAlexAn

Не логичней ли ядро (6509) поделить vrf-ами и соединить их через ASR?

Собрал на GNS'е - работает как надо :) спасибо!

 

Дегтярев Илья

Нормально на ней работает pbr.

Отлично! Я действительно думал что PBR это зло :) Спасибо, будет запасным вариантом!

VRF как то красивей решение всё же. И управление можно в отдельный vrf вынести к тому же. Меньше вероятность ошибки при настройке.

[Skylaer]

Граждане, ваш параход ушел давно (с)

 

Соберите стенд и проверьте.

Схема:

 

Дом, на нем 3526.

 

Он воткнут в агрегатора, оттуда в локальную терминацию (3550).

 

На 3526 настроен снупинг, от в дхцп вставляет опцию и гонит пакет в 3550.

3550 - перенаправляет запрос на машину с DHCP сервером. В запросе есть исходные данные Opt82.

DHCP сервер идет в биллинг, берет данные для абонента и отвечает 3550, какие IP и т.д. выдать клиенту.

 

Все работает как часы.

 

p.s. На 3550 точно работает одна ветка IOS. Остальные - не факт :)

[Stak]

Это работало даже 4 года назад)

http://forum.nag.ru/forum/index.php?showtopic=45488&view=findpost&p=351847

[survivor]

Граждане, ваш параход ушел давно (с)

 

Соберите стенд и проверьте.

Схема:

 

Дом, на нем 3526.

 

Он воткнут в агрегатора, оттуда в локальную терминацию (3550).

 

На 3526 настроен снупинг, от в дхцп вставляет опцию и гонит пакет в 3550.

3550 - перенаправляет запрос на машину с DHCP сервером. В запросе есть исходные данные Opt82.

DHCP сервер идет в биллинг, берет данные для абонента и отвечает 3550, какие IP и т.д. выдать клиенту.

 

Все работает как часы.

 

p.s. На 3550 точно работает одна ветка IOS. Остальные - не факт :)

 

Спасибо, именно так и буду делать. Речь была о том, что в такой схеме приходится давать статические (постоянные) адреса абонентам. А я хотел это вынести в отдельную услугу. В принципе сейчас на PPPoE статические адреса приносят неплохой профит. Жалко его терять.

Но есть еще вариант с opt82 encapsulation'ом и ISG как второй helper-address в цепочке DHCP запросов и стартом ISG сессии уже по dhcp discover и авторизацией в биллинге по opt82 - здесь можно дать уже и динамический адрес. Но мне лично эта схема кажется излишне усложненной...

 

Это работало даже 4 года назад)

http://forum.nag.ru/forum/index.php?showtopic=45488&view=findpost&p=351847

 

Работало то конечно - да :) в этой теме речь о деталях: с чего стартовать ISG сессию, как дать динамические адреса (в смысле - случайные из пула), как перероутить абонентов в ISG не делая БРАС центром сети и т.д.

Дьявол, как говорится, кроется в деталях :)

 

В принципе, на все вопросы ответы я получил. Спасибо всем учавствовавшим!

[Skylaer]

Вы не поняли - адреса раздаются из пулов, динамика :)

[survivor]

Вы не поняли - адреса раздаются из пулов, динамика :)

Оооо.... Ну опять 25! :) речь о том, что клиент будет иметь всегда один и тот же адрес, и не важно как он его получил, по dhcp или прописал manually!!!! Это и есть статический адрес! УСЛУГА которую можно продать за отдельные бабки, а тут приходится давать бесплатно. Давайте называть ее ПОСТОЯННЫЙ ip, раз уж это приводит к путанице.

Динамический адрес - это адрес, который выдается случайно из пула. Опять же - пусть будет тогда СЛУЧАЙНЫЙ ip.

[dazgluk]

Вы не поняли - адреса раздаются из пулов, динамика :)

Оооо.... Ну опять 25! :) речь о том, что клиент будет иметь всегда один и тот же адрес, и не важно как он его получил, по dhcp или прописал manually!!!! Это и есть статический адрес! УСЛУГА которую можно продать за отдельные бабки, а тут приходится давать бесплатно. Давайте называть ее ПОСТОЯННЫЙ ip, раз уж это приводит к путанице.

Динамический адрес - это адрес, который выдается случайно из пула. Опять же - пусть будет тогда СЛУЧАЙНЫЙ ip.

А что мешает выдавать серые адреса и НАТить?

[survivor]

Отсутствие серьезного железа для серьезного NAT'а. Если, конечно, не рассматривать решение на писюках.

[denis_vid]

Отсутствие серьезного железа для серьезного NAT'а. Если, конечно, не рассматривать решение на писюках.

А ASR несерьезное железо? Если имеются ввиду баги в версиях иоса то они есть не во всех версиях