ISG, схема со стартом сессии и ее авторизацией по IP, выдача адресов на основе option82 (Конфигурация сети)
Материал из BiTel WiKi
(Различия между версиями)
Survivor (Обсуждение | вклад)
(Новая страница: «== Конфигурация сети == Конфигурация свича уровня доступа: <source lang="bash"> spanning-tree mode mst spanning-tree e…»)
Следующая правка →
(Новая страница: «== Конфигурация сети == Конфигурация свича уровня доступа: <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 ***
Задача этого свича:
- физически терминировать кабель абонента,
- поместить его траффик в отдельный влан,
- в 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 ***
Задача этого каталиста:
- стерминировать по 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").
Один ньюанс - 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 запрос, сбрасывая ее.
Нужно учесть еще два ньюанса:
- даже при отрицательном балансе договора, DHCP-сервер BGBilling'а должен продолжать выдавать абоненту IP адрес.
- DHCP-сервер BGBilling'а должен находится до ISG (с точки зрения абонента), внутри VRF "domonet". Для этого можно на сервер завести отдельный влан (для прямого доступа к VRF), не забывая про роутинг, так как DHCP-сервер будет отвечать на GIADDR свича аггрегации (в данном случае - 109.*.48.254). DHCP ответ на этот адрес должен идти через соответствующий влан.
