ISG, схема со стартом сессии и ее авторизацией по IP, выдача адресов на основе option82 (Конфигурация сети)

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

(Различия между версиями)
Перейти к: навигация, поиск
Survivor (Обсуждение | вклад)
(Новая страница: «== Конфигурация сети == Конфигурация свича уровня доступа: <source lang="bash"> spanning-tree mode mst spanning-tree e…»)
Следующая правка →

Версия 10:55, 28 марта 2013

Конфигурация сети

Конфигурация свича уровня доступа:

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 ***

Задача этого свича:

  1. физически терминировать кабель абонента,
  2. поместить его траффик в отдельный влан,
  3. в dhcp запросы - вставить option82.

Так как количество вланов в сети очень велико - для Spanning-Tree используется протокол MST. Внутри каждого MST региона (в данном случае - Region-A) должен быть один свич аггрегации, до которого должен иметь возможность пробросить все свои вланы каждый свич уровня доступа.
Интерфейс Vlan51 и route 0.0.0.0 нужны только лишь для удаленного доступа к свичу.

Конфигурация свича уровня аггрегации:

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 ***

Задача этого каталиста:

  1. стерминировать по L3 (на соответствующих SVI) абонентские вланы всех (внутри его MST региона) свичей уровня доступа,
  2. перехватить broadcast запросы к DHCP серверу и перенаправить их (по unicast) внутри VRF "domonet" на сервер BGBilling'а (10.199.1.23), сохранив option82 нетронутым. Биллинг находит договор пользователя по option82 и создает сессию, отвечая: либо - IP адресом, прописанным в данном договоре, либо - свободным IP, в соответствующем пуле.
  3. получив от DHCP сервера BGBilling'а ответ = IP адрес, передать его абоненту, одновременно создавая /32 маршрут (внутри VRF) для этого IP адреса через SVI интерфейс абонента.


В итоге, абонент, прозрачно пройдя авторизацию по номеру порта, получает L3 доступ к сети провайдера (правда только внутри vrf "domonet").
Один ньюанс - IP адрес, выданный абоненту, должен быть из диапазона адресов интерфейса Loopback52. Сам же IP = 109.*.48.254 будет служить маршрутом по-умолчанию для абонента.
Интерфейс 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.
Осталось навесить на BRAS настройки ISG, чтобы этот доступ привести в зависимость от баланса договора и его тарифа в BGBilling'е.

Настройки BRAS'а:

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

ISG настроен следующим образом:

  • как только 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 сервиса:
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

BRAS использует эту конфигурацию и привязывает нужные ISG сервисы к сессии абонента.

Если баланс договора становится отрицательным уже после старта сессии, BGBilling находит соответствующую активную ISG сессию (которая была создана второй) договора и отправляет на BRAS CoA запрос, сбрасывая ее.

Нужно учесть еще два ньюанса:

  1. даже при отрицательном балансе договора, DHCP-сервер BGBilling'а должен продолжать выдавать абоненту IP адрес.
  2. DHCP-сервер BGBilling'а должен находится до ISG (с точки зрения абонента), внутри VRF "domonet". Для этого можно на сервер завести отдельный влан (для прямого доступа к VRF), не забывая про роутинг, так как DHCP-сервер будет отвечать на GIADDR свича аггрегации (в данном случае - 109.*.48.254). DHCP ответ на этот адрес должен идти через соответствующий влан.
Личные инструменты