vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

Эволюция эволюции 2

Дата публикации: 13.03.2013
Количество просмотров: 23504
Автор:

По мере роста абонентской базы сеть расширялась, коммутаторы доступа шли как расходный материал,  наряду с витой парой и разъемами RJ45. Пехота провайдерского фронта бросалась в бой широкими массами, все для победы над конкурентами. Ставку делали на хорошо зарекомендовавшие себя Catalyst, естественно б/у, иногда ряды ветеранов разбивали модели от бюджетных вендоров. Соответственно росла агрегация, районные узлы превращались в полноценно оборудованные площадки. Терминация абонентов производилась по PPPoE, в качестве браса - самосборный сервер FreeBSD, он же шейпер, он же бордер с NAT. Впоследствии, с ростом нагрузки, решено было уйти от принципа «все в одном», брасов стало три, благо PPPoE отлично самостоятельно балансируется. Шейпинг вынесли на отдельный сервер, как и бордер с двумя "фулвью". В результате получилась достаточно надежная и производительная схема, которая долгое время устраивала буквально всех.

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

Едва ли не случайно, в НАГе буквально «заставили» взять его на тест SmartEdge 100. Булшит звучал захватывающе, весь функционал аппаратный – «8000 активных абонентских сессий, 6 Gbps FD, до 16К VLAN, до 1М NAT трансляций, до 1.5М BGP IPv4 маршрутов, поддержка MPLS, H-QoS, QinQ, IPv6». Но Cisco давно приучила "верить с оговорками", поэтому скепсиса хватало. Так как легких путей мы не ищем, решено было сразу пробовать на IPoE, тестировать Static CLIPS с последующим выходом на Dynamic, и сразу с новым биллингом. В свое оправдание скажу, что поход "с нуля" позволил безболезненно оттестировать и доточить решение на сети. 

Эпопея началась с чтения форума и документации lanbilling 1.9. Особое спасибо человеку с форума ланбиллинга с ником oleg_tsk. Его помощь трудно переоценить, так как по SmartEdge в документации к биллингу ничего не имеется, но в целом годно то, что есть по CISCO ISG. Впрочем, на установке операционной системы и биллинга внимание можно не заострять ввиду обилия документации на официальных сайтах.  Куда интереснее конфигурирование и запуск RADIUS сервер биллинга, и все что идет за этим с тарифами и пользователями.

RADIUS-агент:

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

В веб-интерфейсе администратора заходим «Объекты»-«Агенты». Создаем нового агента, если что, слева наверху кнопка с надписью «Создать новый агент».

Тип нового агента «RADIUS». Название - ххххх.
Прописываем все необходимые реквизиты для доступа к базе адрес сервера (server IP), имя базы (DBname), реквизиты подключения к базе (DBlogin, DBpasswd).

В разделе «Особые настройки» прописываем IP-адрес и порты, на которых будет висеть RADIUS-агент.

Два раздела посреди экрана: «Серверы доступа» и «Сети» - имеют очень важное значение.

В разделе «Серверы доступа» перечисляются IP-адреса BRAS-ов и «секреты», c которых будут приходить запросы на авторизацию пользователей. Очень важно верно вбить секрет, при любых сомнениях, лучше перебить, еще лучше с обоих сторон, два раза. В разделе «Сети» указываются подсети (диапазон адресов) которые будут назначаться абонентам.

Рисунок подсказка:

После чего сохраняете все настройки и преходим к запуску самого процесса RADIUS-сервера (lbarcd) из операционной системы.

ВАЖНОЕ ЗАМЕЧАНИЕ! Когда вы создаёте нового агента в биллинге – ему автоматически присваивается порядковый номер (ID). Он будет виден когда вы заходите в админской части в «Объекты»-«Агенты». См. рисунок ниже.

Именно этот ID нужно внести в настройки радиус-агента в /etc/billing.conf.LBarcd в поле ‘sysid =’

Дополнительно, рекомендую на этапе настройки выставить параметр 'log_level = verbose’ это поможет понять и решить некоторые вопросы на первом этапе. Потом уже можно будет либо изменить на log_level = error , либо на одно из других значений перечисленных в настройках. Это очень хорошее правило и касается настройки любого оборудования или сервера. Оно полезно только если соблюдается другое правило - читать логи!

После этой минимальной настройки RADIUS-агента, запустим его. И перейдем к настройке дополнительных RADIUS-атрибутов для SmartEdge.

Перед настройкой RADIUS-атрибутов пара моментов о самом SmartEdge.

Для начала рекомендую прочитать, как минимум 4 статьи из базы знаний касательно Ericsson SmartEdge:
SmartEdge Install Guide
SmartEdge CLIPS how to
SmartEdge POLICY how to
FAQ
Все это расположено по адресу: http://shop.nag.ru/article/baza-znanij, материалы на великом и могучем, все доступно и понятно. Здесь они в pdf, там же очень полезный документ по настройке AAA, RADIUS, CoA, PPPoE, L2TP - Basic-PTA-howto-revA.pdf, которого нет в базе знаний.

Мы тестировали в следующей конфигурации, SmartEdge терминирует абонентов Static CLIPS over L2. Все пользовательские VLAN-ы, будь то VLAN-per-USER либо SHARED VLAN с сетью размера /26 – все терминируются на SmartEdge, BRAS выступает в роли шлюза для них.

Вот такая конфигурация у нас получилась

service multiple-contexts #здесь мы включили возможность использования множества контекстов
context inet-access
description NEW CONTEX FOR LANBILLING TESTS
no ip domain-lookup

interface subscribers-gw multibind
ip address 192.208.163.190/26
ip source-address radius

Адрес шлюза для абонентов
ip source-address radius – с какого адреса пойдут запросы на radius-сервер

no logging console
aaa authentication administrator local #локальная авторизация для управления
aaa authentication administrator maximum sessions 1
aaa authentication subscriber radius #абонентов авторизуем через radius
aaa accounting subscriber radius
aaa accounting reauthorization subscriber radius
radius accounting server 195.208.163.189 key BLABLABLA #задали адреса нашего серва
radius server 195.208.163.189 key BLABLABLA
radius max-retries 5
radius timeout 30
radius strip-domain

Далее профиль пользователя «по-умолчанию». В нём содержатся настройки, для того случая, когда от RADIUS-сервера не приходят параметры с ограничением скорости, а приходит лишь RADIUS-ACCEPT, для того чтобы пользователь смог выйти в INTERNET.

subscriber default
qos policy policing TARIF-DEFAULT-512K-IN
qos policy metering TARIF-DEFAULT-512K-OUT

Отличительная особенность. Если в cisco для rate-limit использовались команды rate-limit in /rate-limit out , то в SMARTEDGE для IN используется policing , а для OUT используется metering так же, создаём дополнительные профили по скорости для пользователей. В процессе работы их ! можно будет назначать абонентам через RADIUS-атрибуты.

subscriber profile PROFILE-FOR-TARIF-2M
qos policy policing TARIF-2M-IN
qos policy metering TARIF-2M-OUT
subscriber profile PROFILE-FOR-TARIF-1M
qos policy policing TARIF-1M-IN
qos policy metering TARIF-1M-OUT

Интересная особенность. Если профили пользователей создаются внутри контекста, то сами политики для ограничения скорости (qos policy) создаются снаружи.

exit
context local
qos policy TARIF-1M-IN policing

rate 1000 burst 125000
rate-calculation exclude layer-2-overhead
qos policy TARIF-1M-OUT metering
rate 1000 burst 125000
rate-calculation exclude layer-2-overhead
qos policy TARIF-2M-IN policing
rate 2000 burst 250000
rate-calculation exclude layer-2-overhead
qos policy TARIF-2M-OUT metering
rate 2000 burst 250000
rate-calculation exclude layer-2-overhead
qos policy TARIF-DEFAULT-512K-IN policing
rate 512 burst 64
rate-calculation exclude layer-2-overhead
qos policy TARIF-DEFAULT-512K-OUT metering
rate 512 burst 64
rate-calculation exclude layer-2-overhead

Возвращаемся в контекст inet-access что бы задать абонентов

context inet-access
абоненты.
subscriber name test-user1
subscriber name test-user2
subscriber name test-user3
ничего им не задано, они и так «наследуют» всё то, что было перечислено в subscriber default

exit
commit #этой командой применяются внесенные изменения

Привяжем наши виртуальные сущности (интерфейсы) к физическим портам

port ethernet 2/1
description *** Port for uplink connections **
no shutdown
medium-type copper
encapsulation dot1q
dot1q pvc 1141
bind interface uplink inet-access
flow apply ip profile inet-flow in
exit
commit

В данном случае физический линк от апстрима приходит ко мне в L2-комутатор, там я назначаю ему VLAN 950 и пробрасываю этот VLAN транком на порт 2/1 SMARTEDGE. Делаем настройки для netflow. netflow у меня так же собирает LanBilling, но не для тарификации по трафику, а просто для того чтобы имелась детальная статистика абонентов.

flow ip profile inet-flow
active-timeout 1000
aggregation-cache-size 8192
exit

flow collector inet-collector
ip-address 195.208.160.226 context inet-access
port 9997
export-version v5
transport-protocol udp
ip profile inet-flow

если netflow пока не нужен, то убираем строку “flow apply ip profile inet-flow in”из настроек dot1q pvc 950 выше.

Возвращаемся в наш контекст

context inet-access
interface zsttk-uplink
description *** ZSTTK UPLINK, VLAN 950 ***
ip address A.B.C.2/30
exit

Настраиваем либо статическую маршрутизацию в сторону аплинка, либо BGP.

ip route 0.0.0.0/0 A.B.C.1 description *** Default route to uplink provider ***

Аплинк со своей стороны прописывает статику для моих сетей через мой IP-адрес роутера.

commit
exit

Начиная с этого момента у вас есть доступ в инет, как минимум, с самого SMARTEDGE 100 (600). Пингуем, проверяем и переходим к настройке пользовательского интерфейса.

context local
port ethernet 2/2
description *** Port for users connections ***
no shutdown
medium-type copper
encapsulation dot1q
dot1q pvc 10
description VLAN-10 for users
bind interface subscribers-gw inet-access

Включаем CLIPS

service clips

Назначаем каждому абоненту, заведённому выше (subscribers), своё статическое CLIPS соединение, на которое и будут вешаться настройки полисинга через радиус clips pvc 100

bind subscriber test-user1@inet-access password 12345
clips pvc 101
bind subscriber test-user2@ inet-access password 12345
clips pvc 102
bind subscriber test-user3@ inet-access password 12345p3
commit
end

Начальный номер 100 взят просто так. Он может быть любым, главное уникальным. В дальнейшем целесообразнее всего использовать user_id из биллинга для однозначной идентификации пользователей. К тому же это поможет автоматизировать заведение clips.

С регистрацией пользователей в SMARTEDGE 100 (600) закончено, переходим к биллингу. Заходим в администраторский интерфейс, далее: «Свойства»-«Тарифы»- «Создать». Создаём новый тариф с типом «Dial-UP (по объёму). Экономическую часть я пропускаю, поэтому величину всех значений типа «Аренда» - выставляем по нулю. Сохраняем.

Тариф создали, теперь надо прикрепить параметры скорости. Для наглядности я создал 2 тарифа: «Тестовый тариф, 1 мбит/сек», «Тестовый тариф, 2 мбит/сек». Помним, что в настройках SMARTEDGE 100 (600) в профиле по-умолчанию скорость выставлена 512 кбит/сек, и дополнительно создано 2 других профиля: 1 мбит/сек и 2 мбит/сек. Теперь самое время покопаться в официальной документации по SMARTEDGE 100 (600) на предмет радиус-атрибутов.

Говоря о RADIUS-е и о LanBillinge следует сказать, что в RADIUS-агенте уже числится достаточно большое количество стандартных RADIUS-атрибутов, плюс есть возможность задать свои.

Делается это в словаре RADIUS-атрибутов. Заходим «Свойства»-«Агенты». В выпадающем списке уже заведённых агентов, выбираем нужный нам RADIUS агент и нажимаем «красненьку ю книжку с буквой D». См рисунок.

Это и есть словарь RADIUS-атрибутов. В появившемся окне выбираем нужный нам сервер доступа (мы их должны были завести при регистрации RADIUS-агента) и жмём кнопку «Добавить новую запись». Здесь делаем небольшую паузу для нескольких комментариев касательно того как ограничивать скорость.

Чуть выше, мы создали 3 пользовательских профиля (дефолтный, 1 мбит/сек и 2 мбит/сек) для ограничения скорости. Всё что нужно от RADIUS-а – это передать название профиля, который будет «вешаться» на clips пользователя. Кроме этого, можно вместо имени профиля - отправлять на clips сразу значения police/meter с значениями скорости.

Для этого используются разные атрибуты, нужно лишь задать их. Для задания атрибутов нужно знать 4 параметра: 1. Attribute ID (Номер/VSA в биллинге) ; 2. Vendor ID (Вендор) ; 3. Тип ; 4. Собственно говоря, само значение передаваемого атрибута.

Так для передачи имени профиля используется атрибут Subscriber-Profile-Name, его параметры:

Название

Номер

Вендор

Тип

Subscriber-Profile-Name

91

2352

String

Кроме этого, я не удержался и завёл ещё один параметр

Название

Номер

Вендор

Тип

Dynamic-Qos-Param

196

2352

String

Им можно менять скорость не привязываясь к профилю пользователя (н-р Turbo button?!?)

 Далее надо привязать эти параметры с их конкретными значениями к уже заведённым тарифам. Заходим: «Свойства»-«Radius-атрибуты», выбираем вкладку «Тарифы». Нажимаем кнопку «Добавить атрибут». В поле «Описание» пишем описание (я здесь пишу название атрибута, чтобы было понятно, что это).В качестве «Агент» выбираем наш RADIUS-агент.«NAS» – IP-адрес того сервера доступа, который мы завели в RADIUS-агенте и на который надо будет слать эти атрибуты (если этих серверов доступа несколько).

«Radius-Code» = Access-Accept.

«Атрибут» - в выпадающем списке ищем атрибут, который мы завели 5 минут назад в словаре RADIUS-атрибутов RADIUS-агента. Выбираем его, в поле значение пишем собственно само значение.

Применительно к атрибуту Subscriber-Profile-Name пишем название профиля :
PROFILE-FOR-TARIF-2M или PROFILE-FOR-TARIF-1M

Применительно к атрибуту Dynamic-Qos-Param пишем сразу значение скорости. Причём значение скорости надо писать как для in (police) так и для out (meter), но в отдельном атрибуте. Т.е. выглядеть это будет так:

Далее всё просто – заводим пользователя: «Объекты» - «Пользователи». Вбиваем ФИО, и номер договора (пусть он будет просто №1). В окне редактирования свойств пользователя нажимаем кнопку «Создать учётную запись».

И уже в окне создания учётной записи выбираем типа агента для этой учётной записи – Radius, пишем login + passwd для авторизации, назначаем наш тариф со скоростями, и выделяем пользователю ip-адрес.

Важный момент: Логин+Пароль, который вы назначили пользователю в свойствах учётной записи, должен совпадать с логином и паролем subscriber-a на SMARTEDGE 100 (600). См. рисунок ниже.

И настройки которые я писал выше:

clips pvc 100
bind subscriber test-user1@inet-access password 12345
clips pvc 101
bind subscriber test-user2@inet-access password 12345
clips pvc 102
bind subscriber test-user3@inet-access password 12345p3
commit

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

Наш выбор пал на Dinamic CLIPS для терминации абонентов по IPoE, в процессе расширили функциональность с профилей, перешли на RSE, с некоторых районов по QnQ туннелям подняли абонентов до браса.

Список атрибутов, которые использовали для RADIUS Access-Accept:

Attribute 'Session-Timeout', value: "8640"
Attribute 'Service-Type', value: "5"
Attribute 'Framed-IP-Address', value: "1.2.3.249"
Attribute 'Framed-IP-Netmask', value: "255.255.255.255"
'Class', value: "00000773"
VSA 190 'Service-Name', vendor 2352, value: "InetBand"
VSA 191 'Service-Options', vendor 2352, value: "1"
VSA 192 'Service-Parameter', vendor 2352, value: " InRate=1024 InBurst=8333 OutRate=1024 OutBurst=8333 InterimTime=90"
VSA 'DHCP-Router-Address', vendor DHCP, value: "1.2.3.1"
VSA 'DHCP-Domain-Name-Server', vendor DHCP, value: "8.8.8.8"
VSA 3 'DHCP-Max-Leases', vendor 2352, value: "1"
VSA 104 'IP-Interface-Name', vendor 2352, value: "CLIENTS" //необязателен
VSA 4 'Context-Name', vendor 2352, value: "local"
VSA 87 'Qos_Policing', vendor 2352, value: "POLICING"
VSA 88 'Qos_Metering', vendor 2352, value: "METERING"

Авторизацию абонентов можно производить по User-name/Password (username=MAC-address), либо по Option 82, мы пошли по второму пути. Будем использовать внешний DHCP-сервер ISC c патчем dhcp2radius. Установка подробно описана на официальном сайте. Пример настройки:

/etc/dhcpd.conf
ddns-update-style interim;
ignore client-updates;
use-dhcp2radius true;
radius-servers 192.168.1.32;
radius-send-opts-to-srv 35;
radius-secret supersecret;
radius-password rpass;

Как оно работает. Получив запрос, содержащий DHCP VSA, RADIUS агент пытается найти абонента, инициировавшего запрос. В описанной конфигурации RADIUS Access-Request будет содержать:

- MAC-адрес (атрибут User-Name),
- произвольный пароль (атрибут Password),
- идентификатор DHCP сервера (атрибут NAS-Port),
- признак DHCP запроса (DHCP-Message-Type),
- запрашиваемый адрес (DHCP-Requested-IP-Address)
- опция 82 (DHCP-Relay-Agent-Information).

При этом идентификация учетной записи возможна либо по MAC адресу (транспортному адресу учетной записи), либо по содержимому опции 82 (поиск в хранилище Inventory).
В первом случае достаточно, чтобы для каждой учетной записи было заполнено поле «транспортный адрес», содержащее MAC сетевой карты абонента в HEX представлении. Если учетной записи присвоены несколько IP адресов (назначать подсеть в данном случае нельзя), то при добавлении MAC адреса необходимо привязать его к конкретному IP.

Во втором случае анализируется содержание опции 82 DHCP. Этой возможностью удастся воспользоваться лишь в том случае, если коммутатор, к порту которого подключен абонент, реализует функции DHCP Relay Agent (вставка/подмена опции 82 в DHCP запросы абонентов). Атрибут DHCP-Relay-Agent-Information содержит идентификатор устройства - Agent-Remote-Id и идентификатор порта устройства, на котором был получен DHCP запрос, — Circuit-Id. В качестве Agent-Remote-Id, в зависимости от настроек коммутатора, могут выступать MAC адрес устройства доступа, IP адрес для управления (management ip), IP адрес на соответствующем VLAN и прочее.

Конкретный вид этого параметра не важен, так как поиск устройства в БД Inventory осуществляется по его HEX представлению (содержимое Agent-Remote-Id сравнивается с одноименной опцией устройства в Inventory). Если устройство найдено и к его порту с номером Circuit-Id привязана учетная запись, то IP адрес из настроек этой учетной записи будет помещен в ответный пакет.

Если абонент найден по одному из перечисленных критериев, учетная запись не заблокирована и ей назначен IP адрес, то RADIUS формирует ответный Access Accept пакет, в котором указываются выданный IP, маска сети (маска сегмента, из которого выделен адрес), время аренды адреса и другие атрибуты. DHCP-Router-Address (адрес шлюза), DHCP-Domain-Name-Server (DNS серверы) и другие «полезные» DHCP опции не передаются автоматически. Необходимо создать соответствующие атрибуты с одним из предлагаемых вариантов привязки (учетная запись, группа, агент и т.д.). С полным словарем атрибутов, поддерживаемым сервером DHCP, можно ознакомиться здесь.

Если хоть одно из необходимых условий, перечисленных в предыдущем абзаце, не выполнено, агент формирует в ответ пакет Access Reject.

Access Request пакеты, содержащие DHCP запрос, не приводят к созданию новой RADIUS сессии, так как не предполагают последующего поступления Accounting пакетов.

Сконфигурировали следующим образом:

Building configuration...
Current configuration:
Configuration last changed by user 'root' at Wed Jul 18 10:12:58 2012
no service multiple-contexts //используем один контекст
software license
subscriber active 8000 encrypted 1 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
dpi traffic-management protocol http escape-conversion
context local
no ip domain-lookup
interface CLIENTS multibind //интерфейсы для терминации абонентов
description interface for clients
ip address 1.2.3.1/24
dhcp proxy 65535
interface CLIENTS2 multibind
ip address 1.2.4.1/24
dhcp proxy 65535
interface CLIENTS3 multibind
ip address 1.2.5.1/24
dhcp proxy 65535
interface PORT01
description Uplink
ip address 2.1.4.70/30
interface PORT03 //линк на SNR-S3750G, L3 with OSPF,
description ospf_peer //для последующей терминации CLIPS over L3 и для
 ip address 192.168.0.1/30 //управления
interface mgt
ip address 10.10.100.100/24
interface multik //интерфейс смотрящий на головную станцию
ip address 192.168.131.200/24 //получение мультикаста
igmp query-solicitation
pim sparse-mode passive
logging console
logging  syslog 192.168.1.32 facility local7 //логирование из контекста local на удаленный сервер
interface multik_c //интерфейс для multicast vlan
 igmp query-solicitation
 pim sparse-mode passive
router ospf 1 //пример настройки OSPF
 fast-convergence
 router-id 192.168.0.1
 originate-default always
 log-neighbor-up-down
 graceful-restart
 area 0.0.0.0
  interface L3
   network-type point-to-point
   neighbor 192.168.0.254
 redistribute connected
 redistribute static
 redistribute subscriber
policy access-list QOS-IN
seq 50 permit ip any any class Internet //трафик в класс Internet
policy access-list QOS-OUT //ACL для разметки по классам, весь
 seq 50 permit ip any any class Internet //трафик в класс Internet
enable encrypted 1 $1$........$6supersecret
enable authentication local
aaa authentication administrator local //локальная авторизация консоли
aaa authentication subscriber radius //RADIUS авторизация абонентов
aaa accounting subscriber radius //RADIUS аккаунтинг абонетов
aaa update subscriber 10 //периодичность Interim-пакетов
radius accounting server 192.168.1.32 encrypted-key ****************
administrator root encrypted 1 $1$........$5zc********************.1
  privilege max 15
  no timeout session idle //отключаем завершение сессии по таймауту
radius server 192.168.1.32 encrypted-key ****************************** coa-server
radius max-retries 5
radius timeout 30
radius attribute username encaps clips strip-mac-delimiter //убираем разделитель в //мак-адресе, dhcp-сервер так отправляет
subscriber default //настройка профиля абонента по
  ip source-validation //умолчанию
  qos policy policing POLICING
  qos policy metering METERING
  dhcp max-addrs 1
ip route 0.0.0.0/0 2.1.4.69 //маршрут по умолчанию
radius service profile InetBand //RSE для управления сессиями
 parameter value InRate //абонентов
 parameter value InBurst
 parameter value OutRate
 parameter value OutBurst
 parameter value InterimTime
 parameter list Dir "in out"
 accounting out qos Internet
 accounting in qos Internet
 seq 10 foreach Dir
   seq 20 attribute Dynamic-Policy-Filter "ip $Dir forward class Internet qos"
 exit
 seq 30 attribute Dynamic-Qos-Parameter "police-class-rate Internet rate-absolute $InRate"
 seq 40 attribute Dynamic-Qos-Parameter "police-class-burst Internet $InBurst"
 seq 50 attribute Dynamic-Qos-Parameter "meter-class-rate Internet rate-absolute $OutRate"
 seq 60 attribute Dynamic-Qos-Parameter "meter-class-burst Internet $OutBurst"
 seq 70 attribute Service-Interim-Accounting $InterimTime
service ssh server
dhcp relay server retries 3 timeout 2 //прописываем куда проксировать
dhcp relay server 192.168.1.32 //dhcp-запросы, option 82 не перезапивать
 ** End Context **
logging tdm console
logging timestamp millisecond //отображать миллисекунды
logging active
logging standby short
logging cct-valid //показывать debug-сообщения только //o существующих circuits
qos policy METERING metering radius-guided //qos для ограничения скорости ip access-group QOS-IN local //сессии абонентов
 class Internet
  rate 1024 burst 1500
rate-calculation exclude layer-2-overhead
qos policy POLICING policing radius-guided
ip access-group QOS-OUT local
 class Internet
  rate 1024 burst 1500
rate-calculation exclude layer-2-overhead
snmp server enhance ifmib //включаем SNMP, подключаем
traps ifmib encaps //дополнительные MIB для
traps ifmib ip //мониторинга интерфейсов и
traps nemib non-exclusive //абонентов
traps ssemib
cache-counter-query
snmp view monitor internet included
snmp view monitor interfaces included
snmp view monitor bgp included
snmp view monitor ifMIB included
snmp community rocomm all-contexts view monitor
snmp target STAT 192.168.1.32 address-context local security-name rocomm view monitor inform

port ethernet 1/1
XCRP management port on slot 1
shutdown
bind interface mgt local

card carrier 2
mic 1 ge-2-port
mic 2 ge-2-port

port ethernet 2/1 //порт на Uplink
no shutdown
medium-type copper
bind interface PORT01 local

port ethernet 2/2 //порт в сторону головной станции
no shutdown
medium-type copper
bind interface multik local

port ethernet 2/3 //порт в сторону клиентов
no shutdown
encapsulation dot1q
service clips dhcp context local //вешаем CLIPS на порт
dot1q pvc 100
 bind interface PORT03 local
dot1q pvc 101 encapsulation 1qtunnel //обозначаем qnq-туннель
 dot1q pvc explicit 101:100 through 4000 //”разворачиваем” туннель
  service clips dhcp context local //вешаем CLIPS на vlan`ы из туннеля
dot1q pvc 4090
 bind interface multik_c local

port ethernet 2/4
shutdown
no service console-break
service crash-dump-dram
no service auto-system-recovery
end

Тут к этой схеме нам захотелось добавить автоматическую привязку абонента к порту по dhcp-пакету. Но как выяснилось старые каталисты 2950 не умеют это, а новые очень уж не бюджетны. И так совпало, что просматривая в очередной раз базу знаний на НАГе попалась интересная статья, вот оно. Как оказалось это достаточно распространенные возможности, у Dlink есть, у Zyxel и других. С первым у нас из-за их ненадежности и странной политики по софту не сложилось. В общем, взяли пока потестировать SNR-S2960-24G там посмотрим.

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/22518/evolyutsiya-evolyutsii.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться