[sirmax]

8 часов назад, alibek сказал:

l4redirect.

В этом топике мой недоопус про isg назвали легендарный что уже говорит о том что скорее всего это решение неверное, pbr в современном мире шифрования мне видится единственным вариантом 

[alibek]

16 часов назад, Andrei сказал:

У меня из биллинга для заблокированных абонентов выдается гостевая сеть типа 10.10.10.0/24

Не хотелось бы приватные сети использовать.

Тогда еще и NAT потребуется делать, для социально-значимых ресурсов.

 

9 часов назад, sirmax сказал:

pbr в современном мире шифрования мне видится единственным вариантом

Резонное замечание.

Но все же хочу попробовать сделать переадресацию.

Да, сейчас 95% веб-трафика это https. Но с другой стороны, на всех смартфонах/планшетах и на многих десктопах в ОС уже встроена проверка на captive portal и при неоплаченной услуге отображается уведомление о недоступном интернете с предложением авторизоваться на ЛК оператора.

[Andrei]

37 минут назад, alibek сказал:

Не хотелось бы приватные сети использовать.

Тогда выделите подсетку реальных, выдавайте их заблокированным абонентами и с помощью pbr заруливайте их на страницу оплаты.

[alibek]

Еще вопрос по COA и POD.

В SE100 было просто, там для идентификации сессии было достаточно контекста (RBN-Context_Name) и логина пользователя (User-Name) или IP-адреса (Framed-IP-Address).

В Cisco это уже не работает.

Для COA нужно указывать логин пользователя (User-Name) и IP-адреса (Framed-IP-Address); если указать только логин, то запрос не выполняется.

А вот для сброса сессий и это не подходит, нужно указывать идентификатор сессии (Acct-Session-Id), тогда запрос выполняется.

Можно ли это как-то "починить"? Чтобы, например, было достаточно только IP-адреса?

У меня под SE100 есть несколько скриптов, делающих сброс сессии, и их придется не только переделывать, но и делать дополнительный запрос в БД, чтобы узнать идентификатор текущей сессии.

[Andrei]

14 часов назад, alibek сказал:

Чтобы, например, было достаточно только IP-адреса?

У меня pppoe-сессия остреливается вот таким скриптом (ему как раз из биллинга передаются ip-адреса NAS-а и юзера для отстрела)

#!/bin/sh
# Input args: Session ID, login, assigned IP, NAS IP
SNMPWALK=`which snmpwalk`
SNMPSET=`which snmpset`
COMMUNITY="ххххххххххххххххххххххххххх"
NAS="$4"
USER_IP="$3"

test -z "$USER_IP" && exit 1
# for Cisco 7204VXR
# INT_NUM=`$SNMPWALK -On -v 1 -c $COMMUNITY $NAS .1.3.6.1.2.1.4.21.1.2.$USER_IP | awk '{print $4}'`
# for Cisco ASR-1002
INT_NUM=`$SNMPWALK -On -v 1 -c $COMMUNITY $NAS .1.3.6.1.2.1.4.24.4.1.5.$USER_IP.255.255.255.255.0.0.0.0.0 | awk '{print $4}'`
test -z "$INT_NUM" && exit 1
$SNMPSET -v 1 -c $COMMUNITY $NAS .1.3.6.1.2.1.2.2.1.7.$INT_NUM i 2 >/dev/null 2>&1
exit 0

 

[alibek]

А не поделитесь ACL на внешний интерфейс?

А то хоть встроенные сервисы (SSH) и закрыты, но все равно на внешнем интерфейсе 70 Мбит/с паразитного трафика.

Сейчас временно соорудил такое:

interface TenGigabitEthernet0/0/0
 description UPLINK
 ip address AA.AA.AA.247 255.255.255.240
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip access-group WAN_ACCESS in
 history BPS
!
ip access-list extended WAN_ACCESS
 10 permit icmp any host AA.AA.AA.247 echo
 11 permit icmp any host AA.AA.AA.247 echo-reply
 20 permit icmp any host AA.AA.AA.247 ttl-exceeded
 80 deny   ip any host AA.AA.AA.247
 90 permit ip any any

 

[Andrei]

3 часа назад, alibek сказал:

ACL на внешний интерфейс

Сам бы посмотрел best practice. :) У меня правда циску снаружи не видно, но всё равно...

А ACL у вас странный.

[alibek]

На большинстве сессий выставляется таймаут 604800.

В биллинге перекопал все настройки, но нигде этого значения не нашел.

Предполагаю, что это может быть настройка Cisco по умолчанию.

Не подскажите, где ее искать?

[Andrei]

53 минуты назад, alibek сказал:

В биллинге

В каком?

[alibek]

Билл-Мастер версии 6, если кто такой знает.

[Andrei]

29 минут назад, alibek сказал:

Билл-Мастер

Не знакОм, не подскажу. У меня ЛанБиллинг, там в свойствах радиус-агента есть настройка - макс.длительность сессии (у меня pppoe). Может и в вашем биллинге есть что-то аналогичное?

[StSphinx]

Bill-Master еще живо???

А по сути вопроса, попробуйте отдавать атрибут Session-Timeout с нужным вам значением.

[Andrei]

15 минут назад, StSphinx сказал:

Session-Timeout

The session timeout determines the time a user can remain idle before the session is terminated and the user must log in again.

 

Это не то.

[alibek]

Нет, это именно тот атрибут.

Просто не пойму, его передает биллинг или его применяет Cisco по умолчанию.

Последнее нелогично, но это было бы проще, я бы тогда просто переопределил бы значение по умолчанию.

Если же этот атрибут передает биллинг, то я нигде не смог найти соответствующую настройку. Напрямую я этот атрибут нигде не указываю.

[StSphinx]

@Andrei, то что вы описываете больше похоже на Idle-Timeout.

То описание, что вы привели конечно находится в первой строке поисковой выдачи, но работает фактически не так как описано.

Session-Timeout задает именно максимальную длительность сессии.

 

@alibek насколько мне известно, дефолтного значения этого атрибута нет. Вам бы стоит посмотреть дамп трафика между БРАСом и Radius'ом. Возможно вы задаете правильно в тарифе, но где-то в настройках есть глобальная политика , которая это переопределяет.

[alibek]

У меня ситуация следующая.

При авторизации биллинг вычисляет время до следующего расчетного периода и указывает его в качестве максимальной длительности сессии.

Например, если тарифы посуточные, то у сессии длительность устанавливается до ближайшей полуночи.

Но если следующий расчетный период далеко (например через месяц), то длительность сессии почему-то выставляется в 604800.

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

Но я перекопал все, что мог (исходные коды, конфигурационные файлы, база данных биллинга) — значения 604800 нигде не нашел.

Так что оно либо зашито где-то в скомпилированных файлах, либо вычисляется, либо это все-таки настройка самого BRAS.

Поэтому и спрашиваю.

 

5 минут назад, StSphinx сказал:

Вам бы стоит посмотреть дамп трафика между БРАСом и Radius'ом.

Посмотрел (правда не дамп, а включая debug radius) — судя по всему этот атрибут приходит из биллинга.

Буду искать еще.

[StSphinx]

@alibek а саппорт биллинга не помогает или оно таки уже все?

[alibek]

В саппорт я написал, но там быстро не ответят.

И скорее всего предложат заключить сервисный контракт.

 

Нет, теперь уже понятно, что эта длительность сессии выставляется именно биллингом, поэтому буду искать дальше.

Но вначале я думал, что может быть это настройка Cisco по умолчанию.

В sh run all я ее не нашел, но для Cisco это не показатель.

[Andrei]

21 минуту назад, alibek сказал:

Например, если тарифы посуточные, то у сессии длительность устанавливается до ближайшей полуночи.

Но если следующий расчетный период далеко (например через месяц), то длительность сессии почему-то выставляется в 604800.

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

Но я перекопал все, что мог (исходные коды, конфигурационные файлы, база данных биллинга) — значения 604800 нигде не нашел.

Тогда видимо вычисляется биллингом в зависимости от параметров тарифного плана.

[sirmax]

9 часов назад, alibek сказал:

604800 нигде не нашел

Значение может быть задано в других единицах и пересчитываться - это как я понимаю 7 дней? 

[alibek]

Маловероятно. Впрочем значение "1w" я тоже искал, пусть и не так глобально, ничего подходящего не нашел.

Видимо это какое-то дефолтное значение, зашитое в исполняемом коде.

В биллинге регистрируются NAS, для них можно задать ряд параметров. Одна из настроек это как раз Session-Timeout. Я задал этот параметр, сейчас применяется уже новое значение. Видимо когда его нет, тогда и берется откуда-то 604800.

[alibek]

Последние пару дней выводил из эксплуатации старые BRAS, переводил абонентов с трех старых SE100 на один новый ASR1001.

Абонентские VLAN переключал на уровне L2 (switchport trunk vlan), после чего переносил IP-адреса.

Два BRAS переключились без каких-либо неожиданностей. А вот с третьим случилось что-то непонятное, довольно большое количество абонентов не могло подключиться, их запросы на RADIUS не направлялись. При этом все BRAS настроены полностью идентично, да и подключены одинаково.

Настройки я перепроверю.

Но не могло ли это быть каким-то аппаратным ограничением?

Число активных сессий было около трех с половиной тысяч, как я понимаю, для ASR1001 это незначительная нагрузка.

IP-адресов в пуле было восемь тысяч, занято меньше половины.

Сложных ACL нет, хотя на каждой сессии есть полиси. Типичная сессия выглядит так:

Current Subscriber Information: Total sessions 3463
--------------------------------------------------
Type: PPPoE, UID: 1887, State: authen, Identity: ******
IPv4 Address: AA.AA.198.30 
Session Up-time: 14:17:52, Last Changed: 06:23:40
Interface: Virtual-Access2.1000
Switch-ID: 2988513

Policy information:
  Context 7FF57B9304C0: Handle AC000222
  AAA_id 00307A90: Flow_handle 0
  Authentication status: authen
  Downloaded User profile, excluding services:
    timeout              0   85750 (0x14EF6)
    service-type         0   2 [Framed]
    addr                 0   194.85.198.30
    session-id           0   3181094 (0x308A26)
    ssg-account-info     0   "QU;10000000;D;10000000"
  Downloaded User profile, including services:
    timeout              0   85750 (0x14EF6)
    service-type         0   2 [Framed]
    addr                 0   AA.AA.198.30
    session-id           0   3181094 (0x308A26)
    ssg-account-info     0   "QU;10000000;D;10000000"
  Config history for session (recent to oldest):
    Access-type: PPP Client: Push Command-Handler
     Policy event: Process Config
      Profile name: ******, 2 references 
        addr                 0   AA.AA.198.30
        session-id           0   3181094 (0x308A26)
        ssg-account-info     0   "QU;10000000;D;10000000"
    Access-type: PPP Client: SM
     Policy event: Process Config Connecting
      Profile name: ******, 2 references 
        timeout              0   85750 (0x14EF6)
        ssg-account-info     0   "QU;2000000;D;2000000"
        service-type         0   2 [Framed]

Classifiers:
Class-id    Dir   Packets    Bytes                  Pri.  Definition
0           In    44440      3672615                0    Match Any
1           Out   46527      7083666                0    Match Any

Features:

IP Config:
M=Mandatory, T=Tag, Mp=Mandatory pool
Flags  Peer IP Address                  Pool Name             Interface      
       AA.AA.198.30                     [None]                [None]         
       ::                               [None]                [None]         

Static Routes:
Class-id  Configuration Status           Source
0          This feature is enabled       Peruser

Absolute Timeout:
Class-id   Timeout Value    Time Remaining       Source
0          85750            09:31:16             Peruser

Idle Timeout:
Class-id   Dir  Timeout value   Idle-Time            Source
1          Out  60              00:00:05             Virtual-Template1

Policing:
Class-id   Dir  Avg. Rate   Normal Burst  Excess Burst Source
0          In   10000000    1875000       3750000      Peruser
1          Out  10000000    1875000       3750000      Peruser

Configuration Sources:
Type  Active Time  AAA Service ID  Name
USR   14:17:53     -               Peruser
INT   14:17:53     -               Virtual-Template1

 

[StSphinx]

@alibek я опять побуду в роли Кэпа - не мешало бы посмотреть, PADI от проблемных клиентов прилетают или нет.

monitor capture ... либо

debug pppoe events interface | rmac ....

На старом BRAS'е pado delay не настраивали? А то может ASR просто отрабатывает медленнее чем старый и сессия уходит туда.

 

[alibek]

Теперь на ASR большой трафик и дебаг затруднен.

Но кажется я нашел возможную причину.

Включил debug pppoe error и увидел, что достигаются лимиты per-mac и per-vlan.

Пока сделал так:

bba-group pppoe global
 virtual-template 1
 sessions per-mac limit 10
 sessions per-vlan limit 1000
 sessions auto cleanup

Посмотрю, что изменится.

 

18 минут назад, StSphinx сказал:

На старом BRAS'е pado delay не настраивали? А то может ASR просто отрабатывает медленнее чем старый и сессия уходит туда.

Не настраивал, но туда сессия бы попасть не смогла, я отключил абонентские VLAN в том направлении, они только на ASR выходят.

[StSphinx]

sessions per-mac limit 10 - а как это решает вашу проблему? 

У нас сейчас вот так настроено:

bba-group pppoe global                                                                                                                                                           
 virtual-template 1
 vendor-tag circuit-id service
 vendor-tag strip
 sessions max limit 65530
 sessions per-mac limit 1
 sessions per-vlan limit 1024
 sessions per-mac throttle 6 60 240
 sessions auto cleanup