UTM5 (5.3-003-rc2) Документация по настройке CISCO+ISG+UTM5. Терминация IPoE и PPPoE
ссылка: https://drive.google.com/open?id=0B4dva ... DZVdnBGdFU
UTM5 (5.3-003-rc2) Документация по настройке CISCO+ISG+UTM5
Re: UTM5 (5.3-003-rc2) Документация по настройке CISCO+ISG+U
Avdoshkin, большое спасибо! Можете еще предоставить список литературы? Просто не хочется тупо слизывать Ваши старания...
-
Avdoshkin
- Сообщения: 156
- Зарегистрирован: Вт май 10, 2005 19:28
- Откуда: Ачинск
- Контактная информация:
Re: UTM5 (5.3-003-rc2) Документация по настройке CISCO+ISG+U
ISG ASR1000Serp писал(а):Avdoshkin, большое спасибо! Можете еще предоставить список литературы? Просто не хочется тупо слизывать Ваши старания...
http://www.cisco.com/c/en/us/td/docs/io ... -book.html
CoA
http://www.cisco.com/c/en/us/td/docs/io ... gcoa3.html
Design ISG
http://www.cisco.com/c/en/us/td/docs/io ... _rls4.html
Re: UTM5 (5.3-003-rc2) Документация по настройке CISCO+ISG+U
А вас не затруднит еще выложить настройки услуги и пользователя?Avdoshkin писал(а):UTM5 (5.3-003-rc2) Документация по настройке CISCO+ISG+UTM5. Терминация IPoE и PPPoE
ссылка: https://drive.google.com/open?id=0B4dva ... DZVdnBGdFU
Пытаюсь подружить JuniperMX(IPoE+PPPoE)+UTM5 со стороны джуна вроди все прилетает, а завести с УТМкой немогу. Уже пытаюсь создать пользователя и вручную через radtest проверить связку логин (префикс+мак) / пароль(общий для профиля ISG) но получаю реджект.
Да у меня пока запара следующего характера. Навешиваю на пользователя услугу передачи трафика, заполнена так:TiRider писал(а):Только AUNL и ALOCAL с маленькой буквы, как указано в документации.
Попробуй так в услуге передача трафика.
Профиль ISG настроен так:
Соответственно для теста делаю отдельный NAS на локалхосте, выбираю у него в качестве профиля, созданный выше. Сохраняю, проверяю связку командой:
Код: Выделить всё
radtest -t pap IPoE.5cf9.dd61.bd59 Test-IPoE 195.114.6.6 1812 test-radius
Sending Access-Request of id 168 to 195.114.6.6 port 1812
User-Name = "IPoE.5cf9.dd61.bd59"
User-Password = "Test-IPoE"
NAS-IP-Address = 195.114.6.6
NAS-Port = 1812
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 195.114.6.6 port 1812, id=168, length=20Вот не пойму где я туплю, без работы проверки вручную, джун начинать прикручивать бесполезно, хотя вот пример дампа запроса с джуна:
Код: Выделить всё
Access Request (1), id: 0x36, Authenticator: 0731bb3549a7ce449d55dddd815d2d07
Username Attribute (1), length: 21, Value: IPoE.5cf9.dd61.bd59
0x0000: 4950 6f45 2e35 6366 392e 6464 3631 2e62
0x0010: 6435 39
Service Type Attribute (6), length: 6, Value: Framed
0x0000: 0000 0002
Unassigned Attribute (89), length: 3, Value:
0x0000: 00
Accounting Session ID Attribute (44), length: 8, Value: 283127
0x0000: 3238 3331 3237
Calling Station Attribute (31), length: 14, Value: xe-1/2/0:997
0x0000: 7865 2d31 2f32 2f30 3a39 3937
Vendor Specific Attribute (26), length: 58, Value: Vendor: Unisphere Networks (4874)
Vendor Attribute: 55, Length: 50, Value: 5..=..\..a.Y..Rico-X-Nout<.MSFT 5.07.....,./.!y..+
0x0000: 0000 130a 3734 3501 013d 0701 5cf9 dd61
0x0010: bd59 0c0b 5269 636f 2d58 2d4e 6f75 743c
0x0020: 084d 5346 5420 352e 3037 0d01 0f03 062c
0x0030: 2e2f 1f21 79f9 fc2b
Vendor Specific Attribute (26), length: 22, Value: Vendor: Unisphere Networks (4874)
Vendor Attribute: 56, Length: 14, Value: 5cf9.dd61.bd59
0x0000: 0000 130a 3810 3563 6639 2e64 6436 312e
0x0010: 6264 3539
Да я пока не с джуна проверяю а вручную, на этом этапе CoA не нужен. CoA работает когда уже есть сабскрайбер, на который можно по id навесить нужную связку, то-есть после этапов ААА. Профили NAS сделаны само собой, как для PPPoE так и для IPoE, джун живой на нем висят PPPoE юзеры, так-же DHCP Opt82, через модуль DHCP, а вот с isg подружить ни как не удается, причем на самом первом этапе, где определяется пускать юзера или не пускать. Для интереса создал фаил users на левом freeradius подцепил часть отвечающую за IPoE по Radius туда - все работает сразу, даже айпишку передавать не нужно, джун сам возьмет свободную из своего пула, ему просто радиус должен сказать пустить или не пустить юзера, все и вот на этом простом этапа с isg у меня запара, я что-то упускаю в настройках, но те 2 страницы официальной доки как-то не очень помогают, по этому и прошу скрин связки реального пользователя, может где не так что задаю. Причем я проверяю еще простой вариант, где в качестве атрибута имени юзера передаются сцепленные через разделитель префикс группы и мак пользователя, в конечном этапе там вместо мака юзера будет Opt82.TiRider писал(а):А где атрибуты и CoA?
Еще, ты для для NAS профили сделал? И на самом джунипере?
Не знаю чем могут тут помочь настройки самого джуна, но выкладываю часть хоть как-то связанную с тестом без CoA, svc и прочего навешиваемого уже после установления сессии, причем так как у меня схема сдвоенная на одних и тех-же виланах может быть и PPPoE и IPoE то конфиг такой и часть отвечающая за PPPoE работает нормально:
Код: Выделить всё
dynamic-profiles {
ppp-profile {
interfaces {
pp0 {
unit "$junos-interface-unit" {
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 60;
family inet {
unnumbered-address lo0.0;
}
}
}
}
}
dhcp-user-profile {
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-underlying-interface-unit" {
proxy-arp;
family inet;
}
}
}
}
Auto-DHCP_PPPoE-Demux {
interfaces {
demux0 {
unit "$junos-interface-unit" {
demux-source inet;
proxy-arp;
vlan-id "$junos-vlan-id";
demux-options {
underlying-interface "$junos-interface-ifd-name";
}
family inet {
unnumbered-address lo0.0 preferred-source-address 91.221.ХХ.ХХ;
}
family pppoe {
duplicate-protection;
dynamic-profile ppp-profile;
}
}
}
}
}
flexible-vlan-tagging;
auto-configure {
stacked-vlan-ranges;
vlan-ranges {
dynamic-profile Auto-DHCP_PPPoE-Demux {
accept any;
ranges {
997-997;
}
}
}
remove-when-no-subscribers;
}
encapsulation flexible-ethernet-services;
access {
profile UTM {
accounting-order radius;
authentication-order radius;
radius {
authentication-server 195.114.ХХ.ХХ;
accounting-server 195.114.ХХ.ХХ;
options {
interface-description-format {
exclude-sub-interface;
exclude-adapter;
}
calling-station-id-format {
interface-description;
inactive: agent-remote-id;
}
accounting-session-id-format decimal;
}
}
radius-server {
195.114.ХХ.ХХ {
port 1812;
accounting-port 1813;
secret "$9$JrZkP9Cp0Ih.P5zn/pudbw2aGkqf5z6evNbY2UDqmf"; ## SECRET-DATA
timeout 10;
retry 5;
max-outstanding-requests 1500;
source-address 91.221.ХХ.ХХ;
}
}
accounting {
order radius;
accounting-stop-on-failure;
accounting-stop-on-access-deny;
immediate-update;
coa-immediate-update;
update-interval 10;
statistics volume-time;
}
}
address-assignment {
pool POOL1 {
link POOL2;
family inet {
network 178.216.хх.0/22;
range 1st {
low 178.216.хх.1;
high 178.216.хх.254;
}
xauth-attributes {
primary-dns 195.114.хх.хх/32;
secondary-dns 91.221.хх.хх/32;
}
}
}
.....
тут еще 2 десятка разных пулов связанных и нет
....
group Test-IPoE {
authentication {
password Test-IPoE;
username-include {
user-prefix IPoE;
mac-address;
}
}
dynamic-profile dhcp-user-profile;
interface demux0.0;
}
Скажи, а в передаче трафика, обязательно передавать mac? Если попробовать передать framed-ip-address, атрибут 8, в терминологии Cisco. В джуне не силен, не работал. Как вариант из под тестового юзверя которого пытаешься скормить, не проходит. С джуна лупбэки для профилей сделать и связать с тестовым радиусом и попробовать.
Можно попробовать, хм, проверю, только смущает что айпишка берется из пула динамически, так что к учетке привязать не выйдет и сделать авторизацию на основании IP тоже, из не меняющихся вариантов Option 82, QinQ Vlan ID, mac. Тут как вариант попробовать использовать модуль DHCP от UTM для первоначальной выдачи IP на основе 82 опции, а джун использовать как dhcp-relay, но это выходит какой-то страшный костыль вообще без использования фишки ISG, а мне очень хочется навешивать на сессию атрибуты динамически.TiRider писал(а):>передать framed-ip-address
Попробовал, та же картина, такое чувство что профиль isg вообще не отрабатывает никак, просто задаю в этого же юзера логин/пароль 123 брать айпишку из пула и радиус все отдает, но блин я с джуновским DHCP связать хочу, там очень красивая реализация выходит технически:TiRider писал(а):С джуна лупбэки для профилей сделать и связать с тестовым радиусом и попробовать.
На одних и тех-же виланах и сабвиланах работает как PPPoE так и DHCP если юзер не авторизировался по DHCP получаем айпишку с отдельного серого пула и можем пробовать PPPoE, если же IPoE установился то учетка уже занята и юзер не подымет вторую сессию по PPPoE для плавного перехода с одной схемы на другую - это идеальный вариант и по идее isg должен был это позволить, а пока у меня получается только нагромождение костылей с разными пулами. Буду копать дальше.
Удивительно но первую проблему поборол, если задавать в настройках юзера логин в виде:
то ничерта не пашет, если же задать как:
то все начинает работать, при этом не важно как именно передается самому радиусу и в каком регистре, да я встречал в документации что все логины приводятся к одному регистру, но разработчики, вашу мать, если вы приводите к одному, то приводите везде при сравнении а не только со стороны радиуса, оставляя поле в самом юзере нетронутым.
Сессия установилась:
А я не хочу указывать подсеть, почему для коммутируемого доступа я могу не указывать ничерта, если хочу динамику и эта функция уйдет целиком на BRAS, а в передаче IP трафика не могу и можно ли это побороть?
Код: Выделить всё
IPoE.5cf9.dd61.bd59Код: Выделить всё
ipoe.5cf9.dd61.bd59Сессия установилась:
Теперь вылезла другая лажа, аутентификация то проходит настройки в джунипер попадают, но как не передавать пул из UTM, я не хочу чтоб пулами рулила UTMка, но если удаляю данные из пул Radius, получаю:Type: DHCP
User Name: IPoE.5cf9.dd61.bd59
IP Address: 10.200.0.39
IP Netmask: 255.255.255.255
Primary DNS Address: 195.хх.хх.38
Secondary DNS Address: 195.хх.хх.6
Logical System: default
Routing Instance: default
Interface: demux0.1073981991
Interface type: Static
Underlying Interface: demux0.1073981991
Dynamic Profile Name: dhcp-user-profile
Dynamic Profile Version: 1
MAC Address: 5c:f9:dd:61:bd:59
State: Active
Radius Accounting ID: 338544
Session ID: 338544
VLAN Id: 997
Login Time: 2015-09-13 20:00:31 GMT-3
Service Sessions: 1
DHCP Options: len 50
35 01 01 3d 07 01 5c f9 dd 61 bd 59 0c 0b 52 69 63 6f 2d 58
2d 4e 6f 75 74 3c 08 4d 53 46 54 20 35 2e 30 37 0d 01 0f 03
06 2c 2e 2f 1f 21 79 f9 fc 2b
IP Address Pool: NoMoney-POOL
Service Session ID: 338546
Service Session Name: svc-pppoe-policer-100m
Service Session Version: 1
State: Active
Family: inet
IPv4 Input Filter Name: policer-100m-pp0.1073766323-in
IPv4 Output Filter Name: policer-100m-pp0.1073766323-out
А я не хочу указывать подсеть, почему для коммутируемого доступа я могу не указывать ничерта, если хочу динамику и эта функция уйдет целиком на BRAS, а в передаче IP трафика не могу и можно ли это побороть?
Разобрался окончательно, через дополнительные Radius атрибуты удалил 9 атрибут для нужной связки, добавил 88 (Pool) кривая маска /32 пропала из ответа radius и все пошло как надо, можно как выдать случайный IP из пула(завел пока отдельный для тестов), так и конкретный. Вобщем ISG профили похоже вообще не работают с джуном (или я олень, не понял как их завести). Но зато разобрался как сделать без них в принципе то, что хотел.
1) PPPoE - для самого тупого/древнего железа (настроено, работает)
2) DHCP-Opt82 - для железа умеющего 82 опцию, снупинг и прочие прелести современности (тоже уже настроено и работает через модуль DHCP-UTM)
3) 802.1X для тех у кого на районах хорошее дорогое железо (ходит вообще без браса, пашет и жрать не просит, но относительно мало)
4) IPoE - там где нет 82 опции (либо она кривая наглухо с неработающим снупингом и вылетающая раз в 2 дня до ребута коммутатора), вот на ней я хочу реализовать QinQ IPoE (сношаюсь сейчас, если выйдет плавно переведу около 5К юзеров с PPPoE на IPoE)
Вот и как-то взлететь со всей этой хреновиной, старые сети, состоящие из кучи скупленных более мелких сетей, соответственно разных вендоров и технологий то еще счастье.
Потому, что мне не нравится как пулы работают на UTM (очень бедный функционал, не считая старых глюков с дубляжом IP, возможно починили, было давно), к тому-же в случае полной смерти биллинга (ну мало ли) я могу за 5 минут поднять фрирадиус, разрешить все всем и все юзеры будут работать как и работали, если выводить функционал пулов на биллинг, то придется как-то решать задачу выдачи IP. Во вторых есть несколько джунов на которые заведены разные белые сети с разных аплинков на разные автономные системы, но в рамках одного биллинга и я не нашел как делить пулы между NASами, а не между тарифами, если знаете - ткните где это можно настроить.TiRider писал(а):Но скажи, зачем ты хочешь выкосить пулы с утм и делать все с помощью джунипера?
Такая связка есть и работает для клиентов GPON по привязке к маку ONU, но не вся сеть на GPON, есть около 300 свичей, не умеющих опцию 82, для них нужна схема QinQ, еще около сотни свечек не умеют даже QinQ (если не считать костыль в виде зафигачить перемычки патчкордами), там остается PPPoE, вот мне и нужно параллельно использовать 3 схемы:TiRider писал(а):Почему не хочешь сделать поделку UTM5_DHCP - Juniper (ip subscriber l2-connected initiator dhcp) - L2 свич - пользователь?
1) PPPoE - для самого тупого/древнего железа (настроено, работает)
2) DHCP-Opt82 - для железа умеющего 82 опцию, снупинг и прочие прелести современности (тоже уже настроено и работает через модуль DHCP-UTM)
3) 802.1X для тех у кого на районах хорошее дорогое железо (ходит вообще без браса, пашет и жрать не просит, но относительно мало)
4) IPoE - там где нет 82 опции (либо она кривая наглухо с неработающим снупингом и вылетающая раз в 2 дня до ребута коммутатора), вот на ней я хочу реализовать QinQ IPoE (сношаюсь сейчас, если выйдет плавно переведу около 5К юзеров с PPPoE на IPoE)
Вот и как-то взлететь со всей этой хреновиной, старые сети, состоящие из кучи скупленных более мелких сетей, соответственно разных вендоров и технологий то еще счастье.