[survivor]

Всем доброго дня!

 

Мучаюсь такой проблемой... очень не хочется пробрасывать по L2 всех клиентов домонета от непосредственно домов по всей сети до BRAS'а в ядре.

Хочется всех по L3 затерминировать где-нибудь на уровне аггрегации (на 3550-м каталисте объединяющем несколько домов), примерно так:

 

int loopback0
ip address 1.1.1.254 255.255.255.0

interface fast0/1
switchport access vlan 101
interface fast0/2
switchport access vlan 102
interface fast0/1
switchport access vlan 103

int vlan101
ip unnumbered loopback0
ip helper-address 2.2.2.2
int vlan102
ip unnumbered loopback0
ip helper-address 2.2.2.2
int vlan103
ip unnumbered loopback0
ip helper-address 2.2.2.2

 

схема известная и популярная :) но как таких клиентов авторизовывать на BRAS'е? ведь до него уже не дойдет информация об option82!

 

Остается использовать:

int gig0/0/0
service-policy type control ISG
ip subscriber routed
 initiator unclassified ip-address

policy-map type control ISG
class type control always event session-start
 10 authorize aaa list AUTH password cisco identifier source-ip-address

 

получается, что логином пользователя в биллинге будет не его номер порта, а IP адрес... Прикольно, но это означает выдачу статических адресов всем домонетчикам, а это хотелось бы вынести в отдельный сервис (статические адреса хорошо продаются), а по умолчанию дать динамический адрес, спустив цену. Есть еще какие-то варианты?

Edited December 10, 2012 by survivor

[m1h]

Мы не стали парится и выдаем RFC1918 адреса статически.

 

Единственное что мне пришло тогда в голову, это писать свой dhcp сервер и привязывать его к биллингу. Но это выливалось в масштабнейшее переписывание биллинга и от идеи сразу же отказались.

[survivor]

m1h спасибо, значит я не ошибся в рассуждениях.

 

Еще такой вопрос: траффик клиентов после аггрегирующего свича уже не будет отделен вланами, он пойдет по магистральным каналам до ядра сети... как там его отделить и отправить на BRAS? Корень сети у меня - 6509, в нем несколько ASR'ов. Нужно как-то перемаршрутизировать на 6509 траффик от клиентов и не дать ему уйти к аплинку, направив его вместо этого на ASR'ы... Неужто policy-routing? Это же будет не cef switched как я понимаю...

Сделать отдельный vrf? Но тогда нужно будет его тянуть по всей сети от точек присутствия, через ядро и до BRAS'ов.

Как правильно?

Edited December 10, 2012 by survivor

[m1h]

Я не совсем понимаю как у вас все построено.

 

1) Почему нельзя прогнать трафик с агрегации до БРАСов по L2? Вланом или через mpls vll

2) Если нужно чтобы на 6509 трафик клиентов не мог напрямую ходить в аплинк, сделайте vrf-lite. Я не понимаю зачем вы хотите распространять vrf по всей сети.

 

У нас примерно так ходит трафик абонентов через платформу тарификации. На ядрёном свиче 2 vrf, в первом он[свич] отдает дефолт клиентам, в другом получает его от бордера. В качестве igp - OSPF. Платформа включена двумя ногами в оба vrf.

[s.lobanov]

survivor

А зачем вам вообще L3 connected? Думаете, что c3550 так хорошо справится с dhcp- и arp-трафиком? Нравится траблшутить high cpu usage на свитчах с дохлыми CPU? Или же просто заняться нечем и решили что-нибудь переделать?

[Skylaer]

А почему кто-то решил, что Opt82 дальше не прокидывается? :)

[survivor]

survivor

А зачем вам вообще L3 connected? Думаете, что c3550 так хорошо справится с dhcp- и arp-трафиком? Нравится траблшутить high cpu usage на свитчах с дохлыми CPU? Или же просто заняться нечем и решили что-нибудь переделать?

 

А вам нравится держать тонны клиентских мак адресов в ядре сети и траблшутить mac flapping совпадающих маков? :) или просто нечего сказать по делу и решили по троллить? ;)

[survivor]

А почему кто-то решил, что Opt82 дальше не прокидывается? :)

 

потому что "opt82" находится в DHCP запросе. В случае терминации абонента по L3 на аггрегирующем свиче, широковещательный DHCP запрос остается в абонентском влане, (аггрегирующий свич форвардит dhcp запрос на DHCP сервер биллинга - ip helper-address), дальше уже от абонента через аггрегирующий свич в ядро сети (где находится BRAS) идут IP пакеты, в которых насколько мне известно option 82 нельзя передать.

Edited December 10, 2012 by survivor

[survivor]

s.lobanov Если честно у меня нет уверенности, что терминировать абонента по L3 это наилучший вариант, я всегда прокидывал его по L2 до ядра и знаю точно - уж проблем достаточно. Новый проект хочу попробовать сделать по другому, из всего читанного на наге, я понял что терминация на аггрегации самый правильный способ... если у вас есть что конкретное сказать про поджидающие меня проблемы - буду очень благодарен их выслушать, только давайте без лишнего сарказма :)

 

m1h спасибо, завтра постараюсь на свежую голову "переварить" ваш совет

[Zarin]

Всем доброго дня!

 

Мучаюсь такой проблемой... очень не хочется пробрасывать по L2 всех клиентов домонета от непосредственно домов по всей сети до BRAS'а в ядре.

Хочется всех по L3 затерминировать где-нибудь на уровне аггрегации (на 3550-м каталисте объединяющем несколько домов), примерно та

 

 

ip dhcp relay information option vpn

ip dhcp relay information policy encapsulate

 

http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_dhcp/configuration/xe-3s/Configuring_the_Cisco_IOS_XE_DHCP_Relay_Agent.html#GUID-A50C5029-5B39-4D44-9C93-4B4C09799E87

 

Соответственно ваша L3 агргеация, должна иметь дефолт на BRAS. И управлять адекватно локальным трафиком вы не сможете. Если конечно не погоните его весь через bras

Edited December 11, 2012 by Zarin

[s.lobanov]

если у вас есть что конкретное сказать про поджидающие меня проблемы - буду очень благодарен их выслушать, только давайте без лишнего сарказма :)

 

поставьте c3550, настройте его по L3 терминацию с ip unnumbered и dhcp, посмотрите что с ним будет от различных атак на control plane(которые нельзя предотвратить на уровне доступа). и просто для размышления подумайте что у вас будет с ipv6

 

вообще несколько странно использовать EOL оборудование для новых проектов. только если оно у вас валяется на складе.

[survivor]

ip dhcp relay information option vpn

ip dhcp relay information policy encapsulate

 

http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_dhcp/configuration/xe-3s/Configuring_the_Cisco_IOS_XE_DHCP_Relay_Agent.html#GUID-A50C5029-5B39-4D44-9C93-4B4C09799E87

 

Соответственно ваша L3 агргеация, должна иметь дефолт на BRAS. И управлять адекватно локальным трафиком вы не сможете. Если конечно не погоните его весь через bras

 

Спасибо, не знал... в моей схеме, аггрегирующий свич будет перебрасывать DHCP запросы ASR'у, на котором я уже смогу сделать:

policy-map type control ISG 
class type control always event session-start 
 10 authorize aaa list AUTH password cisco identifier curcuit-id

 

но ведь ISG сессия стартует на unclassified ip потому что:

int gig0/0/0
ip subscriber routed

 

то есть ПОСЛЕ того как клиент получит ip, а авторизация идет по circuit-id который был в DHCP запросе ДО ТОГО как клиент получил адрес... Лабуда какая-то...

[survivor]

Я не совсем понимаю как у вас все построено.

 

1) Почему нельзя прогнать трафик с агрегации до БРАСов по L2? Вланом или через mpls vll

2) Если нужно чтобы на 6509 трафик клиентов не мог напрямую ходить в аплинк, сделайте vrf-lite. Я не понимаю зачем вы хотите распространять vrf по всей сети.

 

У нас примерно так ходит трафик абонентов через платформу тарификации. На ядрёном свиче 2 vrf, в первом он[свич] отдает дефолт клиентам, в другом получает его от бордера. В качестве igp - OSPF. Платформа включена двумя ногами в оба vrf.

 

1) Если пробрасывать по L2, все понятно. Не хочу иметь в ядре тонны клиентских MAC адресов, кроме-того очень часто MAC'и совпадают, да и L3 гораздо проще резервируется, траблшутится...

2) У меня все аггрегирующие свичи (по одному на точку присутствия) сводятся в один 6509 в цетре сети. Роутинг EIGRP. От 6509 они видят дефолт. Сам 6509 имеет BGP с аплинком, получает оттуда дефолт на интернет. В 6509 несколько ASR'ов. Для них 6509 дефолт по EIGRP. В том же 6509 сидит (в отдельном влане) биллинг c DHCP, радиусом. Клиенты по L3 терминируются на аггрегирующих свичах, получая IP от DHCP биллинга в зависимости от своего curcuit-id. Проблема в том как им не дать уйти в интернет на 6509, а закинуть на ASR'ы.

На ASR'ах ISG настроен, другого выхода кроме как создавать сессию для сабскрайбера по unclassified ip я не вижу, значит будет:

ip subscriber routed

Но как тогда аутентифицировать сессию в биллинге? Это вторая проблема. Curcuit id то уже нет! Только по IP?

Edited December 11, 2012 by survivor

[m1h]

Я пробовал настраивать так: посылать CircuitID в качестве username, а сессия поднимается по unclassified IP. Судя по трейсу в сторону радиуса уходил пустой username. (Делал на IOS-XE)

 

Upd: вот цитата в доке

 

ISG DHCP Restrictions

ISG cannot relay DHCP requests when a Layer 3 DHCP relay agent is between the ISG device and

subscriber devices.

[Zarin]

ip subscriber routed
 initiator dhcp class-aware

 

На dhcp discover, dpm создаст unauth сессию и будет произведена попытка авторизации с атрибутами, которые вы хотите передать биллингу как юзернейм.

 

В случае, если радиус ответит accept, ASR перешлет discover серверу dhcp. Ну и дальше схема стандартная.

Edited December 11, 2012 by Zarin

[survivor]

с VRF я работал, но не очень расширенно, насколько я помню интерфейс привязывается к какому-то VRF'у и попадает в отдельную табличку маршрутизации.

Но интерфейсы где терминируются абоненты на аггрегирующих свичах, а брасы в центре на 6509. Если брасы подключить в два vrf'а - один интернет и один где сидят абоненты, причем в том где сидят абоненты брасы будут давать дефолт... но как на брасах сделать роутинг МЕЖДУ vrf'ами? И тогда EIGRP по ВСЕЙ сети должен понимать какие роуты в каком vrf'е... так? или пургу несу?

 

Я пробовал настраивать так: посылать CircuitID в качестве username, а сессия поднимается по unclassified IP. Судя по трейсу в сторону радиуса уходил пустой username. (Делал на IOS-XE)

 

Upd: вот цитата в доке

 

ISG DHCP Restrictions

ISG cannot relay DHCP requests when a Layer 3 DHCP relay agent is between the ISG device and

subscriber devices.

 

Вот-вот, я так и думал. Значит придется авторизовывать по IP.

[m1h]

но как на брасах сделать роутинг МЕЖДУ vrf'ами?

Брасы ничего не знают про VRFы.

По одной ноге ои получают дефолт из интернета (от бордера), по другой ноге они получают сети клиентов от агрегации.

 

На агрегации кроме b2c клиентов есть ещё что-то? Что должно ходить мимо браса сразу в бордер?

[survivor]

ip subscriber routed
 initiator dhcp class-aware

 

На dhcp discover, dpm создаст unauth сессию и будет произведена попытка авторизации с атрибутами, которые вы хотите передать биллингу как юзернейм.

 

В случае, если радиус ответит accept, ASR перешлет discover серверу dhcp. Ну и дальше схема стандартная.

 

Ммм... для этого на аггрегирующем свиче ip helper-address должен указывать на ASR, так? и opt82 encapsulation должен быть настроен.

А как на ASR'е указать какому именно DHCP серверу пересылать discover? не понял этот момент.

 

но как на брасах сделать роутинг МЕЖДУ vrf'ами?

Брасы ничего не знают про VRFы.

По одной ноге ои получают дефолт из интернета (от бордера), по другой ноге они получают сети клиентов от агрегации.

 

На агрегации кроме b2c клиентов есть ещё что-то? Что должно ходить мимо браса сразу в бордер?

 

Да, мимо браса много чего ходит, нужно внутри работающей сети со множеством сервисов, не нарушая текущих потоков данных, внедрить новый сервис. Из-за этого весь сыр бор

[Zarin]

Ммм... для этого на аггрегирующем свиче ip helper-address должен указывать на ASR, так? и opt82 encapsulation должен быть настроен.

А как на ASR'е указать какому именно DHCP серверу пересылать discover? не понял этот момент.

 

Да. helper-address вашего L3 агрегатора указывает на ASR, а helper-address интерфейса ASR куда будут приходить пакетики от L3 агрегации, на dhcp сервер.

[NikAlexAn]

Ммм... для этого на аггрегирующем свиче ip helper-address должен указывать на ASR, так? и opt82 encapsulation должен быть настроен.

А как на ASR'е указать какому именно DHCP серверу пересылать discover? не понял этот момент.

 

Да. helper-address вашего L3 агрегатора указывает на ASR, а helper-address интерфейса ASR куда будут приходить пакетики от L3 агрегации, на dhcp сервер.

А разве ISG DHCP Restriction не об этом случае говорит?

[Zarin]

А разве ISG DHCP Restriction не об этом случае говорит?

 

ISG DHCP Restrictions
ISG cannot relay DHCP requests when a Layer 3 DHCP relay agent is between an ISG device and subscriber devices.

 

Да вроде не похоже )

[m1h]

Да вроде не похоже )

 

Не берусь ручаться за точность перевода, но IMHO

 

ISG не может пересылать DHCP запросы в случае когда между ISG[bRAS] и устройством клиента есть (ещё один) DHCP пересыльщик работающий на 3-м уровне.

 

Вот в качестве такого ещё одного релея у ТС будет выступать свич агрегации. По всей видимости ISG не ожидает чо к нему придет DHCP запрос в unicast виде, а после релея он именно в unicast и распространяется +добавляются дополнительные поля типа giaddr.

 

С DHCP релей у циски вообще все порой очень странно. Я пытался сделать на интерфейсе 2 хелпер адреса, для физического резервирования DHCP серверов.

Но в этом случае запросы вообще переставали релеиться. Ничего по этому поводу нагуглить не удалось, а поддержки на ASRы мне не купили...

[Zarin]

Не берусь ручаться за точность перевода, но IMHO

 

ISG не может пересылать DHCP запросы в случае когда между ISG[bRAS] и устройством клиента есть (ещё один) DHCP пересыльщик работающий на 3-м уровне.

 

Вот в качестве такого ещё одного релея у ТС будет выступать свич агрегации. По всей видимости ISG не ожидает чо к нему придет DHCP запрос в unicast виде, а после релея он именно в unicast и распространяется +добавляются дополнительные поля типа giaddr.

 

Стоит проверить. У меня на стенде (asr1k2, rp1, esp 10, IOS-XE 3.6.1) работала такая конфигурация.

 

ASR добавлял ряд полей (имя vrf, первичные значения субопций 1 и 2, первичный giaddr) в опцию 82 и переносил первичные значения субопций 1 и 2 в субопцю 9.

Edited December 11, 2012 by Zarin

[survivor]

NikAlexAn а ведь правда! Zarin у вас это работает?

 

упс, не видел вашу переписку :)

Edited December 11, 2012 by survivor

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

А теперь забудьте все, что писали сверху.

 

Перебрали несколько прошивок, везде со стартом сессии по DHCP были баги.

 

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

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

 

По ним уже опознает абонента.