Jump to content
Калькуляторы

CISCO ASR 1002x - ограничение скорости на несколько сессий.

Добрый день!

 

Используем в работе 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 такую структуру?

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

 

 

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

Share this post


Link to post
Share on other sites

полисер?

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Попутно по 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:

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Это же зависит от идентификатора, который вы примените в политике. У нас настроен 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
!        
! 

Share this post


Link to post
Share on other sites

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

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

 

 

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 это как-то странно, с таким никогда не сталкивался и не понимаю, зачем такое вообще может понадобиться.

Share this post


Link to post
Share on other sites

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Идея интересная. Но обычно архиважные 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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

Сессия в апе

Есть 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 запросы.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
В 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 запросов?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this