ISG, схема со стартом сессии и ее авторизацией по IP, выдача адресов на основе option82

Материал из BiTel WiKi

(Различия между версиями)
Перейти к: навигация, поиск
м (→Конфигурация BGBilling'а)
 
(11 промежуточных версий не показаны.)
Строка 27: Строка 27:
*Получение IP адреса абонентом и получение им доступа в сеть (этакий аналог "онлайна") разделены (хотя и зависимы друг от друга). В результате - в мониторе модуля Inet видим две сессии на договор: по одной понимаем, что абонент получил IP адрес, по другой - что он пользуется сетью (при правильно подобранном Idle-Timeout). Если в мониторе всего одна (dhcp) сессия - значит абонент успешно прошел авторизацию (т.е. сидит в разрешенном порту), но интернет ему в данный момент не нужен (или трафик не доходит до BRAS'а). Это очень удобно для аналитики. ISG session-restart также проходит без проблем, потому как ISG сессия авторизуется по source-IP, который у абонента уже есть (при авторизации ISG сессии непосредственно по option82 пришлось бы заново запрашивать IP, чтобы на BRAS попал dhcp запрос). В результате - на циске можно спокойно сбрасывать сессию, будучи уверенным что при первом же пакете она тут же поднимется. Очень удобно при всяком траблшутинге. IMHO.
*Получение IP адреса абонентом и получение им доступа в сеть (этакий аналог "онлайна") разделены (хотя и зависимы друг от друга). В результате - в мониторе модуля Inet видим две сессии на договор: по одной понимаем, что абонент получил IP адрес, по другой - что он пользуется сетью (при правильно подобранном Idle-Timeout). Если в мониторе всего одна (dhcp) сессия - значит абонент успешно прошел авторизацию (т.е. сидит в разрешенном порту), но интернет ему в данный момент не нужен (или трафик не доходит до BRAS'а). Это очень удобно для аналитики. ISG session-restart также проходит без проблем, потому как ISG сессия авторизуется по source-IP, который у абонента уже есть (при авторизации ISG сессии непосредственно по option82 пришлось бы заново запрашивать IP, чтобы на BRAS попал dhcp запрос). В результате - на циске можно спокойно сбрасывать сессию, будучи уверенным что при первом же пакете она тут же поднимется. Очень удобно при всяком траблшутинге. IMHO.
*При отрицательном балансе ISG сессия сбрасывается и создается новая (unauth) сессия с таймером и локальными сервисами, ограничивающими абоненту доступ. Эта сессия каждые N минут переавторизуется на BGBilling'е в надежде, что абонент уже пополнил баланс. И - если баланс выправился - стартует как обычно (с сервисами из биллинга, в соответствие с тарифом). Это не совсем true way для ISG. Правильно - не сбрасывая сессию, снять с нее (через CoA) текущие тарифные ISG сервисы и назначить другие (ограничивающие доступ), а при пополнении баланса - наоборот. BGBilling так может. Почему я сделал по другому? Потому что удобно на циске видеть абонентов с отрицательным балансом (их сессии - unauth) и удобно отслеживать повторные радиус запросы на авторизацию. Это опять же очень удобно для быстрой аналитики и при траблшутинге (почему это у этого абонента ничего не работает? а вот и логи...). Опять же IMHO.
*При отрицательном балансе ISG сессия сбрасывается и создается новая (unauth) сессия с таймером и локальными сервисами, ограничивающими абоненту доступ. Эта сессия каждые N минут переавторизуется на BGBilling'е в надежде, что абонент уже пополнил баланс. И - если баланс выправился - стартует как обычно (с сервисами из биллинга, в соответствие с тарифом). Это не совсем true way для ISG. Правильно - не сбрасывая сессию, снять с нее (через CoA) текущие тарифные ISG сервисы и назначить другие (ограничивающие доступ), а при пополнении баланса - наоборот. BGBilling так может. Почему я сделал по другому? Потому что удобно на циске видеть абонентов с отрицательным балансом (их сессии - unauth) и удобно отслеживать повторные радиус запросы на авторизацию. Это опять же очень удобно для быстрой аналитики и при траблшутинге (почему это у этого абонента ничего не работает? а вот и логи...). Опять же IMHO.
 +
*IP-адрес для абонента можно назначать статический и/или динамический.
-
== Конфигурация сети ==
+
'''Решение'''
-
Конфигурация свича уровня доступа:
+
#[[ISG, схема со стартом сессии и ее авторизацией по IP, выдача адресов на основе option82 (Конфигурация сети)]]
-
<source lang="bash">
+
#[[ISG, схема со стартом сессии и ее авторизацией по IP, выдача адресов на основе option82 (Конфигурация BGBilling'а)]]
-
spanning-tree mode mst
+
-
spanning-tree extend system-id
+
-
!
+
-
spanning-tree mst configuration
+
-
name Region-A
+
-
instance 1 vlan 1-4094
+
-
!
+
-
ip dhcp snooping vlan 1201-1248
+
-
ip dhcp snooping
+
-
!
+
-
interface FastEthernet0/1
+
-
description Abonent-1
+
-
switchport access vlan 1201
+
-
switchport mode access
+
-
switchport nonegotiate
+
-
switchport port-security
+
-
storm-control broadcast level pps 10k
+
-
storm-control multicast level pps 10k
+
-
storm-control unicast level pps 10k
+
-
storm-control action shutdown
+
-
no cdp enable
+
-
spanning-tree portfast
+
-
spanning-tree bpduguard enable
+
-
spanning-tree guard root
+
-
ip verify source
+
-
!
+
-
interface FastEthernet0/2
+
-
description Abonent-2
+
-
switchport access vlan 1202
+
-
switchport mode access
+
-
switchport nonegotiate
+
-
switchport port-security
+
-
storm-control broadcast level pps 10k
+
-
storm-control multicast level pps 10k
+
-
storm-control unicast level pps 10k
+
-
storm-control action shutdown
+
-
no cdp enable
+
-
spanning-tree portfast
+
-
spanning-tree bpduguard enable
+
-
spanning-tree guard root
+
-
ip verify source
+
-
!
+
-
...
+
-
!
+
-
interface FastEthernet0/48
+
-
description Abonent-48
+
-
switchport access vlan 1248
+
-
switchport mode access
+
-
switchport nonegotiate
+
-
switchport port-security
+
-
storm-control broadcast level pps 10k
+
-
storm-control multicast level pps 10k
+
-
storm-control unicast level pps 10k
+
-
storm-control action shutdown
+
-
no cdp enable
+
-
spanning-tree portfast
+
-
spanning-tree bpduguard enable
+
-
spanning-tree guard root
+
-
ip verify source
+
-
!
+
-
interface GigabitEthernet0/1
+
-
description Another-Catalyst-in-Chain
+
-
switchport trunk encapsulation dot1q
+
-
switchport trunk native vlan 50
+
-
switchport mode trunk
+
-
ip dhcp snooping trust
+
-
!
+
-
interface GigabitEthernet0/2
+
-
description Another-Catalyst-in-Chain
+
-
switchport trunk encapsulation dot1q
+
-
switchport trunk native vlan 50
+
-
switchport mode trunk
+
-
ip dhcp snooping trust
+
-
!
+
-
interface Vlan51
+
-
description Management
+
-
ip address ***
+
-
!
+
-
ip route 0.0.0.0 0.0.0.0 ***
+
-
</source>
+
-
Задача этого свича:
+
-
#физически терминировать кабель абонента,
+
-
#поместить его траффик в отдельный влан,
+
-
#в dhcp запросы - вставить option82.
+
-
 
+
-
Так как количество вланов в сети очень велико - для Spanning-Tree используется протокол MST. Внутри каждого MST региона (в данном случае - Region-A) должен быть один свич аггрегации, до которого должен иметь возможность пробросить все свои вланы каждый свич уровня доступа. <br />
+
-
Интерфейс Vlan51 и route 0.0.0.0 нужны только лишь для удаленного доступа к свичу.
+
-
 
+
-
Конфигурация свича уровня аггрегации:
+
-
<source lang="bash">
+
-
ip dhcp relay information policy keep
+
-
ip dhcp relay information trust-all
+
-
!
+
-
ip vrf domonet
+
-
rd 1000:1000
+
-
!
+
-
spanning-tree mode mst
+
-
spanning-tree extend system-id
+
-
!
+
-
spanning-tree mst configuration
+
-
name Region-A
+
-
instance 1 vlan 1-4094
+
-
!
+
-
spanning-tree mst 0-1 priority 0
+
-
!
+
-
interface Loopback52
+
-
description Domonet users at Region-A
+
-
ip vrf forwarding domonet
+
-
ip address 109.*.48.254 255.255.255.0
+
-
!
+
-
interface GigabitEthernet0/1
+
-
description Link-toward-Core
+
-
switchport trunk encapsulation dot1q
+
-
switchport trunk native vlan 50
+
-
switchport trunk allowed vlan 51,52
+
-
switchport mode trunk
+
-
switchport nonegotiate
+
-
spanning-tree bpdufilter enable
+
-
ip dhcp snooping trust
+
-
!
+
-
interface GigabitEthernet0/2
+
-
description Link-to-Access-Layer-Catalysts
+
-
switchport trunk encapsulation dot1q
+
-
switchport trunk native vlan 50
+
-
switchport mode trunk
+
-
ip dhcp snooping trust
+
-
!
+
-
interface Vlan51
+
-
description Management
+
-
ip address ***
+
-
!
+
-
interface Vlan52
+
-
description Traffic
+
-
ip vrf forwarding domonet
+
-
ip address 10.111.1.1 255.255.255.0
+
-
ip authentication mode eigrp 90 md5
+
-
ip authentication key-chain eigrp 90 eigrp-key
+
-
!
+
-
interface Vlan1101
+
-
description SW1-PORT1
+
-
ip vrf forwarding domonet
+
-
ip unnumbered Loopback52
+
-
ip helper-address 10.199.1.23
+
-
!
+
-
interface Vlan1102
+
-
description SW1-PORT2
+
-
ip vrf forwarding domonet
+
-
ip unnumbered Loopback52
+
-
ip helper-address 10.199.1.23
+
-
!
+
-
...
+
-
!
+
-
interface Vlan1148
+
-
description SW1-PORT48
+
-
ip vrf forwarding domonet
+
-
ip unnumbered Loopback52
+
-
ip helper-address 10.199.1.23
+
-
!
+
-
interface Vlan1201
+
-
description SW2-PORT1
+
-
ip vrf forwarding domonet
+
-
ip unnumbered Loopback52
+
-
ip helper-address 10.199.1.23
+
-
!
+
-
...
+
-
!
+
-
interface Vlan1248
+
-
description SW2-PORT48
+
-
ip vrf forwarding domonet
+
-
ip unnumbered Loopback52
+
-
ip helper-address 10.199.1.23
+
-
!
+
-
router eigrp 90
+
-
!
+
-
address-family ipv4 vrf domonet
+
-
  network 0.0.0.0
+
-
  distance eigrp 90 90
+
-
  passive-interface default
+
-
  no passive-interface Vlan52
+
-
  autonomous-system 90
+
-
exit-address-family
+
-
 
+
-
ip route ***
+
-
</source>
+
-
Задача этого каталиста:
+
-
#стерминировать по L3 (на соответствующих SVI) абонентские вланы всех (внутри его MST региона) свичей  уровня доступа,
+
-
#перехватить broadcast запросы к DHCP серверу и перенаправить их (по unicast) внутри VRF "domonet" на сервер BGBilling'а (10.199.1.23), сохранив option82 нетронутым. ''Биллинг находит договор пользователя по option82 и создает сессию, отвечая: либо - IP адресом, прописанным в данном договоре, либо - свободным IP, в соответствующем пуле.''
+
-
#получив от DHCP сервера BGBilling'а ответ = IP адрес, передать его абоненту, одновременно создавая /32 маршрут (внутри VRF) для этого IP адреса через SVI интерфейс абонента.
+
-
 
+
-
 
+
-
В итоге, абонент, прозрачно пройдя авторизацию по номеру порта, получает L3 доступ к сети провайдера (правда только внутри vrf "domonet"). <br />
+
-
Один ньюанс - IP адрес, выданный абоненту, должен быть из диапазона адресов интерфейса Loopback52. Сам же IP = 109.*.48.254 будет служить маршрутом по-умолчанию для абонента. <br />
+
-
Интерфейс Vlan51 и route 0.0.0.0 также нужны только лишь для удаленного доступа к свичу из global роутинга.
+
-
 
+
-
''Тут нужно сделать небольшое отступление - VRF в моем случае был нужен только потому, что проект разворачивался поверх уже существующей сети (с уже работаюшими сервисами и соответствующим роутингом) и нужно было ни в коем случае не затронуть имеющуюся архитектуру и логику роутинга. VRF максимально удобен в этом случае. Для сети строящейся с нуля можно было бы сделать все в одной таблице маршрутизации.''
+
-
 
+
-
Далее, в ядре сети траффик, идущий от абонентов внутри vrf, нужно пропустить (по L3) через BRAS в глобальную таблицу маршрутизации. Это можно сделать несколькими способами - PBR, route leaking, static routing... Главное - чтобы из global роутинга IP адреса абонентов были видны через BRAS и, наоборот, внешний мир изнутри vrf "domonet" был виден через BRAS. В результате, абонент имеет полный доступ в Интернет, но - транзитом (по L3) через BRAS. <br />
+
-
Осталось навесить на BRAS настройки ISG, чтобы этот доступ привести в зависимость от баланса договора и его тарифа в BGBilling'е.
+
-
 
+
-
Настройки BRAS'а:
+
-
<source lang="bash">
+
-
aaa group server radius ipoe-radius
+
-
server-private 109.*.1.23 auth-port 1812 acct-port 1813 non-standard key ***
+
-
ip radius source-interface Loopback0
+
-
!
+
-
aaa group server radius ipoe-services-radius
+
-
server-private 109.*.1.23 auth-port 1811 acct-port 1813 non-standard key ***
+
-
ip radius source-interface Loopback0
+
-
!
+
-
aaa authentication login ipoe-isg-aaa group ipoe-radius
+
-
aaa authorization network ipoe-isg-aaa group ipoe-radius
+
-
aaa accounting network ipoe-isg-aaa start-stop group ipoe-radius
+
-
!
+
-
aaa authorization subscriber-service default local group ipoe-services-radius
+
-
!
+
-
aaa accounting delay-start
+
-
aaa accounting update periodic 2
+
-
aaa nas port extended
+
-
!
+
-
aaa server radius dynamic-author
+
-
client 109.*.1.23 server-key ***
+
-
ignore session-key
+
-
ignore server-key
+
-
!
+
-
redirect server-group NO-MONEY
+
-
server ip 109.*.1.16 port 80
+
-
!
+
-
class-map type traffic match-any LOCAL-TRAFFIC
+
-
match access-group output 2110
+
-
!
+
-
class-map type traffic match-any OPENGARDEN-TRAFFIC
+
-
match access-group input 155
+
-
match access-group output 156
+
-
!
+
-
class-map type traffic match-any ALL-TRAFFIC
+
-
match access-group input 101
+
-
match access-group output 102
+
-
!
+
-
class-map type traffic match-any TRAFFIC-FOR-REDIRECT
+
-
match access-group input name traffic-for-redirect
+
-
!
+
-
class-map type control match-all ISG-IP-UNAUTH
+
-
match timer UNAUTH-TIMER
+
-
match authen-status unauthenticated
+
-
!
+
-
policy-map type service L4REDIRECT
+
-
20 class type traffic TRAFFIC-FOR-REDIRECT
+
-
  redirect to group NO-MONEY
+
-
!
+
-
policy-map type service OPENGARDEN
+
-
40 class type traffic OPENGARDEN-TRAFFIC
+
-
  accounting aaa list ipoe-isg-aaa
+
-
  police input 1024000
+
-
  police output 1024000
+
-
!
+
-
class type traffic default in-out
+
-
  drop
+
-
!
+
-
policy-map type service ISG-LOCAL
+
-
100 class type traffic LOCAL-TRAFFIC
+
-
  accounting aaa list ipoe-isg-aaa
+
-
  police input 102400000
+
-
  police output 102400000
+
-
!       
+
-
policy-map type control IPoE-ISG
+
-
class type control ISG-IP-UNAUTH event timed-policy-expiry
+
-
  1 service disconnect
+
-
!       
+
-
class type control always event session-start
+
-
  10 authorize aaa list ipoe-isg-aaa password cisco identifier source-ip-address
+
-
  20 set-timer UNAUTH-TIMER 1
+
-
  30 service-policy type service name L4REDIRECT
+
-
  40 service-policy type service name OPENGARDEN
+
-
!       
+
-
class type control always event service-stop
+
-
  1 service-policy type service unapply identifier service-name
+
-
  10 log-session-state
+
-
!       
+
-
class type control always event session-restart
+
-
  10 authorize aaa list ipoe-isg-aaa password cisco identifier source-ip-address
+
-
  20 set-timer UNAUTH-TIMER 1
+
-
  30 service-policy type service name L4REDIRECT
+
-
  40 service-policy type service name OPENGARDEN
+
-
!
+
-
interface Loopback0
+
-
ip address 10.100.198.31 255.255.255.255
+
-
!
+
-
interface GigabitEthernet0/0/2.1001
+
-
encapsulation dot1Q 1001
+
-
ip address 10.200.98.31 255.255.255.0
+
-
service-policy type control IPoE-ISG
+
-
ip subscriber routed
+
-
  initiator unclassified ip-address
+
-
</source>
+
-
 
+
-
ISG настроен следующим образом:<br />
+
-
*как только IP траффик абонента (который уже получил IP адрес от DHCP сервера BGBilling'а, авторизовавшись по номеру порта) приходит на BRAS, тот создает для него новую ISG сессию и пытается ее авторизовать на радиусе BGBilling'а, используя в качестве логина - source IP адрес. Биллинг просматривает активные сессии договоров и, конечно же, находит ту самую сессию, которую он сам же создал, выдавая этому абоненту IP адрес. По этой сессии биллинг находит договор и:
+
-
**в случае положительного баланса - отвечает ACCESS-ACCEPT, плюс cisco-SSG-Account-Info параметры, которые берет из тарифа договора. Одновременно BGBilling создает (вторую уже) активную сессию для договора.
+
-
**в случае отрицательного баланса - отвечает ACCESS-REJECT'ом.
+
-
*Если BRAS получает ACCESS-REJECT, то он идет дальше по ''class type control always event session-start'' и привязывает к ISG сессии сервисы L4REDIRECT и OPENGARDEN (локально описанные в конфиге циски: ''policy-map type service OPENGARDEN'' и ''policy-map type service OPENGARDEN''), в которых доступ ограничен только к локальным ресурсам, на скорости 1 Mbps, а весь http траффик редиректится на страничку, информирующую абонента об отсутствии денег на счету. Также стартует таймер UNAUTH-TIMER длительностью в одну минуту, по истечению которой BRAS заново пытается авторизовать ISG сессию в BGBilling'е.
+
-
*Если BRAS получает ACCESS-ACCEPT, то он прекращает выполнение ''class type control always event session-start'' и берет из параметров cisco-SSG-Account-Info информацию о том, какие ISG сервисы нужно привязать к ISG сессии, затем ищет их описание локально в своей конфигурации. Не найдя их, BRAS для каждого сервиса посылает радиус запрос на второй радиус-сервер BGBilling'а (''aaa authorization subscriber-service default local group ipoe-services-radius''), используя в качестве логина - имя ISG сервиса. В биллинге для этого случая заводится отдельный договор, в котором прописываются все необходимые сервисы, в результате чего - BGBilling отвечает на эти запросы ACCESS-ACCEPT'ом с телом ISG сервиса:
+
-
<source lang="bash">
+
-
Packet type: Access-Accept
+
-
Identifier: 134
+
-
Authenticator: {88 A2 CE 7E 66 BF 3E 9C 4C C0 CD 12 C1 0F C1 3C}
+
-
Attributes:
+
-
  Acct-Interim-Interval=60
+
-
  cisco-avpair=subscriber:accounting-list=ipoe-isg-aaa
+
-
  cisco-avpair=ip:traffic-class=in access-group 101 priority 201
+
-
  cisco-avpair=ip:traffic-class=out access-group 102 priority 201
+
-
  cisco-SSG-Service-Info=QU;5120000;384000;768000;D;5120000;960000;1920000
+
-
</source>
+
-
BRAS использует эту конфигурацию и привязывает нужные ISG сервисы к сессии абонента.
+
-
 
+
-
Если баланс договора становится отрицательным уже после старта сессии, BGBilling находит соответствующую активную ISG сессию (которая была создана второй) договора и отправляет на BRAS CoA запрос, сбрасывая ее.<br />
+
-
 
+
-
Нужно учесть еще два ньюанса:
+
-
#даже при отрицательном балансе договора, DHCP-сервер BGBilling'а должен продолжать выдавать абоненту IP адрес.
+
-
#DHCP-сервер BGBilling'а должен находится '''до''' ISG (с точки зрения абонента), внутри VRF "domonet". Для этого можно на сервер завести отдельный влан (для прямого доступа к VRF), не забывая про роутинг, так как DHCP-сервер будет отвечать на GIADDR свича аггрегации (в данном случае - 109.*.48.254). DHCP ответ на этот адрес должен идти через соответствующий влан.
+
-
 
+
-
 
+
-
== Конфигурация BGBilling'а ==
+
-
 
+
-
Устанавливаем модуль inet_5.2_1118.zip, создаем его в редакторе модулей и услуг, добавляем услуги.<br />
+
-
Затем, создаем Опции (имена ISG сервисов), типы трафика и тарифный план (в нем прописываем стоимости типов трафика и подключаем Опции, т.е. ISG сервисы):
+
-
{|
+
-
| [[Файл:ISG-INET-0001.jpg|200px|thumb|left|Модуль, услуги]]  
+
-
| [[Файл:ISG-INET-0002.jpg|200px|thumb|left|Опции (ISG сервисы)]]
+
-
| [[Файл:ISG-INET-0003.jpg|200px|thumb|left|Типы трафика]]
+
-
| [[Файл:ISG-INET-0024.jpg|200px|thumb|left|Тарифный план: стоимость трафика и подключение опций (ISG сервисов)]]
+
-
|}
+
-
 
+
-
Описываем откуда брать информацию о количестве каждого из типов трафика (можно конечно использовать netflow, но я ограничился Acct-Input-Octets и Acct-Output-Octets из radius аккаунтинга, так как тарифов по траффику у меня нет и эта информация нужна всего лишь для статистики):
+
-
{|
+
-
| [[Файл:ISG-INET-0004.jpg|200px|thumb|left|Привяка типов трафика: Local Upstream]]
+
-
| [[Файл:ISG-INET-0005.jpg|200px|thumb|left|Привяка типов трафика: Local Downstream]]
+
-
| [[Файл:ISG-INET-0006.jpg|200px|thumb|left|Привяка типов трафика: Internet Upstream]]
+
-
| [[Файл:ISG-INET-0007.jpg|200px|thumb|left|Привяка типов трафика: Internet Downstream]]
+
-
|}
+
-
Далее, создаем пул IP адресов - они должны быть из диапазона адресов интерфейса Loopback52 (на свиче уровня аггрегации), а default gateway должен быть адрес интерфейса Loopback52.<br />
+
-
Создаем сервис INTERNET, который будем подключать к договору в биллинге (не путать с ISG сервисом, назначаемым на ISG сессию абонента на циске), чтобы собственно предоставить ему (договору) доступ в интернет через модуль Inet.
+
-
{|
+
-
| [[Файл:ISG-INET-0008.jpg|200px|thumb|left|IP-ресурсы]]
+
-
| [[Файл:ISG-INET-0009.jpg|200px|thumb|left|Сервис INTERNET]]
+
-
|}
+
-
Создаем сущность ''коммутатор'', привязываем к ней атрибут ''адрес'' (позже пригодится для указания местоположения свичей доступа, чтобы потом хоть как-то ориентироваться что-где):
+
-
{|
+
-
| [[Файл:ISG-INET-0016.jpg|200px|thumb|left|Сущности]]
+
-
| [[Файл:ISG-INET-0023.jpg|200px|thumb|left|Атрибуты]]
+
-
|}
+
-
Создаем типы устройств:
+
-
#абстрактный тип Access+Accounting, являющийся верхушкой иерархии всех типов устройств, объединяя их все (в нем прописываются настройки общие для всех типов устройств)
+
-
#тип ASR ISG, описывающий BRAS'ы
+
-
#тип SW-1, описывающий свичи уровня аггрегации (они же dhcp релеи)
+
-
#тип Switch, описывающий свичи уровня доступа (те, которые вставляют option82), привязываем к нему сущность ''коммутатор''.
+
-
{|
+
-
|-
+
-
| [[Файл:ISG-INET-0011.jpg|200px|thumb|left|Типы устройств]]
+
-
| [[Файл:ISG-INET-0012.jpg|200px|thumb|left|Типы устройств: Access+Accounting (абстрактный тип, верхушка иерархии типов)]]
+
-
|-
+
-
| [[Файл:ISG-INET-0013.jpg|200px|thumb|left|Типы устройств: ASR ISG (BRAS)]]
+
-
| [[Файл:ISG-INET-0014.jpg|200px|thumb|left|Типы устройств: SW-1 (уровень аггрегации)]]
+
-
| [[Файл:ISG-INET-0015.jpg|200px|thumb|left|Типы устройств: Switch (уровень доступа)]]
+
-
|}
+
-
и привязываем сервис INTERNET к всем этим типам (через абстрактный Access+Accounting):
+
-
{|
+
-
| [[Файл:ISG-INET-0010.jpg|200px|thumb|left|Сервис INTERNET, типы устройств]]
+
-
|}
+
-
Создаем сами устройства (соответствующих типов):
+
-
{|
+
-
|-
+
-
| [[Файл:ISG-INET-0017.jpg|200px|thumb|left|Устройства]]
+
-
| [[Файл:ISG-INET-0018.jpg|200px|thumb|left|Устройства: Access+Accounting (абстрактное устройство, верхушка иерархии устройств)]]
+
-
|-
+
-
| [[Файл:ISG-INET-0019.jpg|200px|thumb|left|Устройства: R31_ASR1002 (BRAS)]]
+
-
| [[Файл:ISG-INET-0020.jpg|200px|thumb|left|Устройства: (каталист уровня аггрегации)]]
+
-
| [[Файл:ISG-INET-0021.jpg|200px|thumb|left|Устройства: (каталист уровня доступа)]]
+
-
|}
+
-
Для свичей доступа указываем местоположение (используя сущность и атрибут ''адрес''):
+
-
{|
+
-
| [[Файл:ISG-INET-0022.jpg|200px|thumb|left|Устройства: (каталист уровня доступа, атрибуты)]]
+
-
|}
+
-
Ну, а теперь осталось привязать сервис INTERNET (выбрав нужный свич уровня доступа и указав правильный номер порта) к договору:
+
-
{|
+
-
|-
+
-
| [[Файл:ISG-INET-0025.jpg|200px|thumb|left|Договор, сервисы (постоянный IP)]]  
+
-
| [[Файл:ISG-INET-0026.jpg|200px|thumb|left|Договор, сервисы (случайный IP)]]
+
-
|-
+
-
| [[Файл:ISG-INET-0027.jpg|200px|thumb|left|Монитор (активные сессии договора)]]
+
-
| [[Файл:ISG-INET-0028.jpg|200px|thumb|left|Отчет (по-сервисный аккаунтинг)]]
+
-
|}
+
-
 
+
-
'''продолжение следует...'''
+

Текущая версия на 10:05, 1 апреля 2013

Данная схема была собрана на лабе, но спроектирована под реальный проект, т.е. - никакой не сферический ISG в вакууме.

Оборудование

  • Уровень доступа (физическое подключение абонентов): catalyst 3550.
  • Уровень аггрегации (объединение нескольких свичей уровня доступа, плюс терминация абонентов по L3): catalyst 3550, с последующей заменой на 3560 при росте сети.
  • Ядро сети: catalyst 6509 (WS-SUP720-3BXL)
  • BRAS (ISG): ASR1002-ESP5

Задача

Подключить абонента по IPoE (без дополнительных инкапсуляций PPPoE или PPTP), выдать адрес по DHCP, авторизовать абонента по номеру порта на соответствующем каталисте уровня доступа, ограничить выход в интернет в соответствие с балансом договора.

Минусы схемы и ее реализации

  • Один IP на абонента (для подключения нескольких устройств абонент должен приобрести CPE - любой ethernet роутер с NAT'ом), потому как cisco реализация ISG создает сессию основываясь на уникальности source IP.
  • Более сложный механизм масштабирования BRAS'ов по сравнению с PPPoE.
  • Нет "локалки" по дому - весь траффик идет через ядро.

Плюсы

  • В простейшем случае (один PC) абоненту вообще не нужно ничего настраивать, достаточно вставить кабель.
  • Транспортная сеть не загромождается MAC-адресами абонентов (при цифрах больше 8-12 тысяч маков приходится переходить на значительно более дорогое железо)
  • Высокая безопасность сети и абонента (изоляция vlan-per-user, "физическая" авторизация абонента через dhcp-snooping, anti-spoofing благодаря ip source guard, динамические /32 маршруты на SVI, создаваемые только после успешной авторизации, изоляция от остальной части сети внутри VRF).
  • Отсутствие дополнительной инкапсуляции в PPP протокол, что разгружает BRAS.

Особенности реализации

  • Получение IP адреса абонентом и получение им доступа в сеть (этакий аналог "онлайна") разделены (хотя и зависимы друг от друга). В результате - в мониторе модуля Inet видим две сессии на договор: по одной понимаем, что абонент получил IP адрес, по другой - что он пользуется сетью (при правильно подобранном Idle-Timeout). Если в мониторе всего одна (dhcp) сессия - значит абонент успешно прошел авторизацию (т.е. сидит в разрешенном порту), но интернет ему в данный момент не нужен (или трафик не доходит до BRAS'а). Это очень удобно для аналитики. ISG session-restart также проходит без проблем, потому как ISG сессия авторизуется по source-IP, который у абонента уже есть (при авторизации ISG сессии непосредственно по option82 пришлось бы заново запрашивать IP, чтобы на BRAS попал dhcp запрос). В результате - на циске можно спокойно сбрасывать сессию, будучи уверенным что при первом же пакете она тут же поднимется. Очень удобно при всяком траблшутинге. IMHO.
  • При отрицательном балансе ISG сессия сбрасывается и создается новая (unauth) сессия с таймером и локальными сервисами, ограничивающими абоненту доступ. Эта сессия каждые N минут переавторизуется на BGBilling'е в надежде, что абонент уже пополнил баланс. И - если баланс выправился - стартует как обычно (с сервисами из биллинга, в соответствие с тарифом). Это не совсем true way для ISG. Правильно - не сбрасывая сессию, снять с нее (через CoA) текущие тарифные ISG сервисы и назначить другие (ограничивающие доступ), а при пополнении баланса - наоборот. BGBilling так может. Почему я сделал по другому? Потому что удобно на циске видеть абонентов с отрицательным балансом (их сессии - unauth) и удобно отслеживать повторные радиус запросы на авторизацию. Это опять же очень удобно для быстрой аналитики и при траблшутинге (почему это у этого абонента ничего не работает? а вот и логи...). Опять же IMHO.
  • IP-адрес для абонента можно назначать статический и/или динамический.

Решение

  1. ISG, схема со стартом сессии и ее авторизацией по IP, выдача адресов на основе option82 (Конфигурация сети)
  2. ISG, схема со стартом сессии и ее авторизацией по IP, выдача адресов на основе option82 (Конфигурация BGBilling'а)
Источник — «http://wiki.bitel.ru/index.php/ISG,_%D1%81%D1%85%D0%B5%D0%BC%D0%B0_%D1%81%D0%BE_%D1%81%D1%82%D0%B0%D1%80%D1%82%D0%BE%D0%BC_%D1%81%D0%B5%D1%81%D1%81%D0%B8%D0%B8_%D0%B8_%D0%B5%D0%B5_%D0%B0%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B5%D0%B9_%D0%BF%D0%BE_IP,_%D0%B2%D1%8B%D0%B4%D0%B0%D1%87%D0%B0_%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%BE%D0%B2_%D0%BD%D0%B0_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5_option82»
Личные инструменты