Alex's Blog

В этой статье я вкратце расскажу вам о том, как правильно организовать управление абонентами с помощью SSG на Cisco 7206.

Фактически Cisco 7206 с IOS 12.2SR является полнофункциональным BRAS и SSG (Subscriber Service Gateway), на котором мы можем тонко управлять обслуживанием абонентов, используя функции SSG.

Если вы уже прочли часть 1, то смело читайте далее.

...

2. Настройка функционала BRAS/SSG на Cisco 7206

Настройка функционала BRAS/SSG на Cisco 7206 не так сложна, как может показаться на первый взгляд.

Достоинство предлагаемой схемы в том, что она минимизирует нагрузку на CPU Cisco, при использовании максимума удобных функций BRAS/SSG на этой железке. Дабы не быть голословным, скажу, что нагрузка в этой конфигурации почти не зависит от числа абонентов - только от проходящего трафика (PPS).

Начнем с общей конфигурации.

service password-encryption
hostname <доменное имя браса>
aaa new-model
aaa nas port extended
aaa session-id common
clock timezone MSK 3
clock summer-time MSK recurring last Sun Mar 3:00 last Sun Oct 3:00
ip subnet-zero
ip cef
ip multicast-routing
no ip domain lookup
ip domain name <ваш домен>
ip name-server <ваш DNS-сервер, возможно даже не один>
ip accounting-threshold 200000
multilink bundle-name authenticated
vpdn enable
ip classless
ip dhcp relay information option
ip dhcp relay information policy keep
ip dhcp relay information trust-all
no ip dhcp use vrf connected

Далее вам потребуется настроить основные интерфейсы, роутинг, NTP и прочую мелочь - но это выходит за рамки данной статьи. Опять же - если уж взялись за BRAS/SSG - значит знаете, что делаете.

Настраиваем связочку с RADIUS для авторизации абонентов.

Сначала атрибуты.

radius-server attribute 44 include-in-access-req
radius-server attribute 44 extend-with-addr
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 32 include-in-access-req
radius-server attribute 32 include-in-accounting-req
radius-server attribute 55 include-in-acct-req
radius-server attribute 55 access-request include
radius-server attribute 25 access-request include

Теперь сервер.

radius-server host <IP RADIUS-сервера> auth-port <порт авторизации, обычно 1812> acct-port <порт аккаунтинга, обычно 1813> key <ключ RADIUS-сервера для BRAS>

Теперь группу AAA.

aaa group server radius MY_RADIUS
server <IP RADIUS-сервера> auth-port <порт авторизации, обычно 1812> acct-port <порт аккаунтинга, обычно 1813>
ip radius source-interface <интерфейс, который смотрит на RADIUS>

Ну и собственно авторизацию.

aaa authentication ppp PPPOE group MY_RADIUS
aaa authorization network PPPOE group MY_RADIUS
aaa accounting network PPPOE start-stop group MY_RADIUS
aaa accounting update newinfo periodic 5

Теперь приступаем к определению темплейта для пользователей.

interface Virtual-Template1
ip unnumbered <интерфейс, который смотрит в глобальную сеть, не принципиален>
no logging event link-status
no peer default ip address
ppp authentication chap PPPOE
ppp authorization PPPOE
ppp accounting PPPOE

Создаем BRAS-сервис для PPPOE.

bba-group pppoe BRAS-PPPOE
virtual-template 1
sessions-per-vlan limit 1000
sessions auto cleanup

Окей, теперь пришла пора определить наши интерфейсы, где приходит Q-in-Q, для работы с PPPOE.

interface <ваш интерфейс.ваш VLAN>
encapsulation dot1q <внешний тег>  second-dot1q any
pppoe enable group BRAS-PPPOE
no cdp enable

Если очень хочется определить что-то не Q-in-Q-шное для PPPOE, делается это аналогично, только encapsulation меняется.

Теперь создадим основной пул адресов для назначения нашим пользователям. Мы будем "использовать" пул 64.64.64.128-64.64.64.250 (адреса взяты "с потолка", у вас адреса клиентов должны быть свои). Назовем наш пул "users".

ip local pool users 64.64.64.128 64.64.64.250

Сервисные группы в RADIUS являются "обычными" пользователями с предзаданным на концентраторе доступа паролем. Зададим этот пароль на Cisco.

subscriber service password <пароль сервисных групп>

Вот и все - наш BRAS готов к приему абонентов (фактически). Теперь необходимо создать конфигурацию, которая позволила бы нам организовать и разграничить доступ абонентов согласно поставленной задаче.

Проектируем сервисные группы:

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

Согласно поставленной задаче, наши абоненты могут быть подключены и отключены (виртуально - нет доступа в Internet, но есть доступ к определенной группе серверов). Оптимально для этих целей создать две сервисных группы (причем SSG_OFFLINE должна быть более приоритетна, чем SSG_ONLINE).

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

1. Набор групп SSG_ONLINE_<скорость>, приоритет 100 
2. SSG_OFFLINE, приоритет 50

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

3. SSG_SERVERS, приоритет 25

У нас есть еще и локальная сеть, для нее понадобится отдельная сервисная группа. Разумно в случае отключения абонента доступа к локальной сети не давать, а то позаводят прокси.

4. SSG_LAN, приоритет 75

Настраиваем списки доступа:

Начнем с того, что настроим списки доступа для каждой из наших сервисных групп. Тут легко нарваться на очень хитрое ограничение Cisco - каждый ACL в сервисных группах должен использоваться только один раз.

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

ip access-list extended Service_Any_Online
permit ip any any

Теперь создаем список доступа для трафика пользователей в оффлайне (SSG_OFFLINE). Он не менее прост.

ip access-list extended Service_Any_Offline
permit ip any any

Создаем списки доступа на вход и выход для трафика локальной сети (SSG_LOCAL). Я напишу здесь 64.64.64.0/24, обозначая абонентскую сеть, и 64.64.65.0/24, обозначая локальную сеть, а также сервис 123.123.123.16/28, некоторый сайт, доступный на скорости локальной сети. Адреса взяты случайно, кроме того, у вас оных может быть больше.

ip access-list extended Service_LAN_In
remark Clients
permit ip 64.64.64.0 0.0.0.255 any
remark Local
permit ip 64.64.65.0 0.0.0.255 any
remark Services
permit ip 123.123.123.16 0.0.0.15 any

ip access-list extended Service_LAN_Out
remark Clients
permit ip any 64.64.64.0 0.0.0.255
remark Local
permit ip any 64.64.65.0 0.0.0.255
remark Services
permit ip any 123.123.123.16 0.0.0.15

Осталась мелочь - создать список доступа для серверов, доступных абонентам в оффлайне. Мы запихаем туда наш DNS - 64.64.65.12, и Web - 64.64.65.111. IP взяты случайно, у вас этот список будет отличаться.

ip access-list extended Service_Servers_In
remark DNS
permit ip host 64.64.65.12 any
remark WWW
permit ip host 64.64.65.111 any

ip access-list extended Service_Servers_Out
remark DNS
permit ip any host 64.64.65.12
remark WWW
permit ip any host 64.64.65.111

Опять же - я не рекомендую делать, допустим, фильтрации по портам, хотя если очень хочется - то можно.

Еще один access-list понадобится нам для блокировки доступа оффлайновым пользователям (не для классификации трафика, а именно для блокировки). Он очень простой:

ip access-list extended Service_Deny_Any
deny ip any any

И вот - все access-list'ы созданы, сервисные группы спроектированы, можно перейти к заполнению базы RADIUS корректными параметрами. Об этом - в следующей части.