[burevestnik_1983]

Добрый день!

 

Используем в работе CISCO ASR 1002x для ipoe сессий клиентов.

Тип ipoe сессий - ip subscriber l2-connected.

Скорость на клиентских сессиях задаём coa-запросами вида:

User-Name="...",Cisco-Account-Info="SХХХ.ХХХ.ХХХ.ХХХ",cisco-avpair+="ip:sub-qos-policy-in=SHAPE-IN-100000",cisco-avpair+="ip:sub-qos-policy-out=SHAPE-OUT-100000"

 

Политика имеет следующий вид

policy-map SHAPE-IN-100000

class NO_SHAPE

police cir 107520000

 

 

class-map match-all NO_SHAPE

match access-group name NO_SHAPE

 

ip access-list extended NO_SHAPE

deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

.... тут ещё несколько deny для траффика между подсетями, принадлежащими нам

permit ip any any

 

 

Возникла необходимость в альтернативном варианте: не вешать органичение по скорости на каждую сессию, а сделать так, чтобы была какая-то структура с заданной полосой пропускания, через которую будут работать несколько IPOE сессий (но не все). Соответственно, на каждую IPOE сессию никакого ограничения вешаться уже не будет, а задачу по ограничению суммарной полосы пропускания нескольких IPOE сессий будет выполнять данная стуктура. При этом сессии могут быть с разных интерфейсов (вланов).

 

Есть ли возможность создать на ASR 1002 такую структуру?

Если да, в каком цисковском мануале можно подробнее ознакомиться с данным вопросом?

 

 

Или есть только два варианта: ограничение на сессию или на интерфейс?

[kapydan]

полисер?

[burevestnik_1983]

полисер?

 

Он, собственно у нас и используется. Применяется к сессии. Вопрос в том, можно ли один полисер навесить на несколько сессий?

Я так понимаю мануал http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpolsh.html в тему?

[zhenya`]

Между разными сессиями нельзя. Но вот сессии могут быть сабнет.

[kapydan]

насколько помню, нет.

 

Вопрос в том, можно ли один полисер навесить на несколько сессий?

[burevestnik_1983]

Попутно по IP subscriber interface есть вопрос:

cовместим ли данный тип сессий с такими директивами на интерфейсе как ip helper-address и ip unnumbered. В каком именно мануале можно прочитать про совсемстимость или категорическую несовместимость их?

Вот конфиг интерфейса:

 

interface Port-channel1.12444092

description test_jurs

encapsulation dot1Q 1244 second-dot1q 4092

ip dhcp relay information option-insert

ip dhcp relay information policy-action replace

ip unnumbered Loopback5

ip helper-address ххх.ххх.ххх.ххх

service-policy type control ISG-JURS

ip subscriber interface

end

 

Задача, чтобы была одна сессия на интерфейс, куда буду навешивать политики, при этом каждый комп, подключённый через этот интерфейс будет получать IP по dhcp.

Пока получается так, что когда убираю директиву ip subscriber interface, то сразу идут обращения от клиента, подключённого к данному интерфейсу, к IP, указанному в IP helper-address. Как ставлю директиву ip subscriber interface, ничего не происходит, хотя сама интерфейсная сессия подниается. Все dhcp дебаги включены, там нет вообще никаких попыток обратиться на helper-address

Что нужно копать?

 

asr1002x-2#sh running-config interface lo5

Building configuration...

 

Current configuration : 64 bytes

!

interface Loopback5

ip address 10.68.23.1 255.255.255.0

end

 

 

Rule: ISG-JURS

Class-map: always event session-start

Action: 2 authorize identifier nas-port

Executed: 4

 

Action: 5 set-timer UNAUTH-TIMER 50

Executed: 4

 

Class-map: always event session-restart

Action: 2 authorize identifier nas-port

Executed: 0

 

Action: 5 set-timer UNAUTH-TIMER 50

Executed: 0

 

 

Key:

[buckethead]

IP helper address работает 100%, но сессия, разумеется, должна быть authen.

C unnumbered работает в таком ключе: тянет маршрут с лупбека, но на один лупбек можно указать лишь одну interface session. Однако, тут форумчанин нашёл способ обойти это ограничение: на интерфейсе не указывается ip unnumberd, так же как и ip address, но ip unnumbered передаётся в AVpair с RADIUS, и тогда с одного лупбека можно сколько угодно (сколько именно -- не известно) поднять interface session. Мне бы это сильно помогло в своё время, если бы не перешёл на другого вендора, где это из коробки работает.

[burevestnik_1983]

Однако, тут форумчанин нашёл способ обойти это ограничение: на интерфейсе не указывается ip unnumberd, так же как и ip address, но ip unnumbered передаётся в AVpair с RADIUS

Спасибо за информацию. Если это было в теме, а не в ЛС, то киньте ссылку пожалуйста на тему

[burevestnik_1983]

IP helper address работает 100%, но сессия, разумеется, должна быть authen.

Каким образом можно сделать ip subscriber interface сессию authen? Мне казалось, что там по автомату имя интерфеса и именем пользователя.

В каком мануале можно об этом прочитать? ISG configuration guide, раздел Control Policies или в другом мануале циски?

[buckethead]

IP helper address работает 100%, но сессия, разумеется, должна быть authen.

Каким образом можно сделать ip subscriber interface сессию authen? Мне казалось, что там по автомату имя интерфеса и именем пользователя.

В каком мануале можно об этом прочитать? ISG configuration guide, раздел Control Policies или в другом мануале циски?

Это же зависит от идентификатора, который вы примените в политике. У нас настроен nas-port, оттуда на RADIUS регуляркой просто забирается пара STAG/CTAG. Ничего сложного.

[burevestnik_1983]

Это же зависит от идентификатора, который вы примените в политике. У нас настроен nas-port, оттуда на RADIUS регуляркой просто забирается пара STAG/CTAG. Ничего сложного.

 

Если не сложно, приведите кусок конфига (control-policy), который авторизует такие сессии.

А в общем случае,как я понимаю ip subscriber interface сессии можно авторизовать без радиуса, если в качестве имени пользователя использовать nas-port?

[zhenya`]

Можете авторизовать по любому атрибуту из запроса, все зависит от гибкости вашего радиуса/билинга

[buckethead]

Это же зависит от идентификатора, который вы примените в политике. У нас настроен nas-port, оттуда на RADIUS регуляркой просто забирается пара STAG/CTAG. Ничего сложного.

 

Если не сложно, приведите кусок конфига (control-policy), который авторизует такие сессии.

А в общем случае,как я понимаю ip subscriber interface сессии можно авторизовать без радиуса, если в качестве имени пользователя использовать nas-port?

policy-map type control pm-interface-sessions
class type control Unauth event timed-policy-expiry
 1 service disconnect
!        
class type control always event session-start
 1 authorize aaa password cisco identifier nas-port 
 3 set-timer Unauth 3
!        
class type control always event session-restart
 1 authorize aaa password cisco identifier nas-port 
 3 set-timer Unauth 3
!        
class type control always event access-reject
 1 service-policy type service name OpenGarden
 2 service-policy type service name L4R
 3 set-timer Unauth 3
!        
! 

[stalker86]

IP helper address работает 100%, но сессия, разумеется, должна быть authen.

C unnumbered работает в таком ключе: тянет маршрут с лупбека, но на один лупбек можно указать лишь одну interface session. Однако, тут форумчанин нашёл способ обойти это ограничение: на интерфейсе не указывается ip unnumberd, так же как и ip address, но ip unnumbered передаётся в AVpair с RADIUS, и тогда с одного лупбека можно сколько угодно (сколько именно -- не известно) поднять interface session. Мне бы это сильно помогло в своё время, если бы не перешёл на другого вендора, где это из коробки работает.

 

 

А на кого перешли, если не секрет?

[burevestnik_1983]

policy-map type control pm-interface-sessions

class type control Unauth event timed-policy-expiry

1 service disconnect

!

class type control always event session-start

1 authorize aaa password cisco identifier nas-port

3 set-timer Unauth 3

!

class type control always event session-restart

1 authorize aaa password cisco identifier nas-port

3 set-timer Unauth 3

!

class type control always event access-reject

1 service-policy type service name OpenGarden

2 service-policy type service name L4R

3 set-timer Unauth 3

!

!

 

 

Большое спасибо за кусок конфига. "authorize aaa password cisco identifier nas-port " это всё равно не помогло (хотя счётчик на данное действие каждый раз увеличивается, значит оно выполняется?..). Сессия стартует, но имя юзера пустое. Мне получается на данном этапе и не нужен RADIUS, мне нужно просто чтобы ASR подставил в качестве имени юзера имя порта (что вполне логично на interface-сессии). А в дальнейшем планировал с помощью COA - запросов управлять данной сессией - накидывать или убирать редиректы, opengarden'ы и проч политики.

 

По какому именно параметру надо включить дебаг в данной ситуации, чтобы понять, что происходит, и где затык при работе этой control-policy?

[zhenya`]

Сессия перейдёт в auth только после ответа радиуса. Вам надо радиус крутить

[buckethead]

policy-map type control pm-interface-sessions

class type control Unauth event timed-policy-expiry

1 service disconnect

!

class type control always event session-start

1 authorize aaa password cisco identifier nas-port

3 set-timer Unauth 3

!

class type control always event session-restart

1 authorize aaa password cisco identifier nas-port

3 set-timer Unauth 3

!

class type control always event access-reject

1 service-policy type service name OpenGarden

2 service-policy type service name L4R

3 set-timer Unauth 3

!

!

 

 

Большое спасибо за кусок конфига. "authorize aaa password cisco identifier nas-port " это всё равно не помогло (хотя счётчик на данное действие каждый раз увеличивается, значит оно выполняется?..). Сессия стартует, но имя юзера пустое. Мне получается на данном этапе и не нужен RADIUS, мне нужно просто чтобы ASR подставил в качестве имени юзера имя порта (что вполне логично на interface-сессии). А в дальнейшем планировал с помощью COA - запросов управлять данной сессией - накидывать или убирать редиректы, opengarden'ы и проч политики.

 

По какому именно параметру надо включить дебаг в данной ситуации, чтобы понять, что происходит, и где затык при работе этой control-policy?

BNG без RADIUS это как-то странно, с таким никогда не сталкивался и не понимаю, зачем такое вообще может понадобиться.

[vurd]

Я делал авторизацию интерфейс сессии без радиуса месяц назад. В личку.

 

BNG без RADIUS это как-то странно, с таким никогда не сталкивался и не понимаю, зачем такое вообще может понадобиться.

Лично мне надо, чтобы сессии не зависели ни от чего, чтобы они всегда были в апе. В частности, у меня юрики приземлены в свои вланы, они должны работать всегда. А если мне надо что-то поменять, я пошлю со стороны coa.

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

[buckethead]

Идея интересная. Но обычно архиважные b2b приземляются без ISG, потому как всё на словах и честном слове, а сервис прерывать нельзя даже после не оплаты. Стоит ли овчинка выделки?

Что касается RADIUS, то он прекрасно скейлится, даже если группа серверов выйдет из строя, есть фолбек механизмы, которые могут обеспечить беспрепятственный доступ клиента к Сети. Мне ваше решение кажется странным, потому что в идеале весь контроль над политиками должен быть максимально дистанцирован от BRAS в сторону серверов с политиками.

[zhenya`]

возможности настройки политик на события таймаутов и прочего перекрывают всю эту боль.

[vurd]

Идея интересная. Но обычно архиважные b2b приземляются без ISG, потому как всё на словах и честном слове, а сервис прерывать нельзя даже после не оплаты. Стоит ли овчинка выделки?

Что касается RADIUS, то он прекрасно скейлится, даже если группа серверов выйдет из строя, есть фолбек механизмы, которые могут обеспечить беспрепятственный доступ клиента к Сети. Мне ваше решение кажется странным, потому что в идеале весь контроль над политиками должен быть максимально дистанцирован от BRAS в сторону серверов с политиками.

 

Ну оно не странное, просто, в таком варианте оно удобней. Мне надо, по сути, кинуть на сессию абонента редирект и закрыть доступ, при каких-то определенных условиях. Зачем для этого городить радиус (на минуточку третий. первый для мгмт, второй для обычных абонентов). По сути, управление редиректами и прочими подвесами сервисов будет выполнять точно таким же CoA из биллинга, даже в полноценной реализации.

Архиважные понятно. С ними обычно нет проблем. А вот не архиважные? :)

 

p.s. подскажите, как снять с сессии qos-policy

QoS Policy Map:

Class-id Dir Policy Name Source

0 In 7Mbit Peruser

1 Out 7Mbit Peruser

[buckethead]

Три радиуса это преступно мало :)

По хорошему радиус должен быть отдельно для клиентских сессий, отдельно для клиентских сервисов, это без учёта их дублирования.

 

Я вас понял, буду знать теперь, ещё бы рассказали, как делали, для потомков)

[burevestnik_1983]

Ещё возникла такая засада.

Сессия в апе

Есть IP для управления, 10.81.0.4, для которого записан статический маршрут в тот интерфейс, где поднята сессия

#sh ip route 10.81.0.4
Routing entry for 10.81.0.4/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Port-channel1.12444094
      Route metric is 0, traffic share count is 1   

Этот адрес нужен для отправления COA запросов

При накидывании SHAPE, ASR не ругается на неправильный запрос, а просто его не отвечает, как будто убран там dynamic-author

 

Sending CoA-Request of id 214 to 194.187.204.39 port 1700
        Cisco-Account-Info = "S10.81.0.4"
        Cisco-AVPair += "ip:sub-qos-policy-in=SHAPE-IN-10000"
        Cisco-AVPair += "ip:sub-qos-policy-out=SHAPE-OUT-10000"
Re-sending CoA-Request of id 214 to 194.187.204.39 port 1700
        Cisco-Account-Info = "S10.81.0.4"
        Cisco-AVPair += "ip:sub-qos-policy-in=SHAPE-IN-10000"
        Cisco-AVPair += "ip:sub-qos-policy-out=SHAPE-OUT-10000"
Re-sending CoA-Request of id 214 to 194.187.204.39 port 1700
        Cisco-Account-Info = "S10.81.0.4"
        Cisco-AVPair += "ip:sub-qos-policy-in=SHAPE-IN-10000"
        Cisco-AVPair += "ip:sub-qos-policy-out=SHAPE-OUT-10000"      

 

Кто-нибудь с таким сталкивался?

 При этом на той же машинке есть куча сессий l2-connected, с которым COA запросы как работали, так и работают, то есть в общем случае ASR нормально воспринимал COA запросы.

 

[buckethead]

Я вот тут другим вопросом озадачился, а чего это вы policy-map обозвали shape, когда там policer везде? Policer != shaper. Это первое. Второе, зачем передавать их через атрибуты 'ip:sub-qos-policy-in/out'?

[burevestnik_1983]

В 07.10.2017 в 01:53, buckethead сказал:

Я вот тут другим вопросом озадачился, а чего это вы policy-map обозвали shape, когда там policer везде? Policer != shaper. Это первое. Второе, зачем передавать их через атрибуты 'ip:sub-qos-policy-in/out'?

Насчёт неточности формулировки согласен

Полтика такая

policy-map SHAPE-IN-100000
 class NO_SHAPE
  police cir 107520000

class NO_SHAPE отсеивает группы IP, где скорость не должна ограничиваться, и разрешает все остальные...

 

По поводу странности применения COA запросов - возникло неожиданно, причём успел уже недели две потестить на ASR-1000 - все применялось без проблем.

Вот и хочу понять, какую именно ругань пишет CISCO, когда отказывается принимать COA запрос с данным полисером.

Какой именно debug * нужно включить на ASR, чтобы видеть сообщения, связанные с применением COA запросов?