Wingman

Читаю тему и немного охреневаю, если честно :) Гидра - очень сложная система. Думаю, при попытке без помощи создать несколько пользователей, бд, пц и тарифов - уже можно было бы понять, что своими силами полностью развернуть рабочую систему, мягко говоря, непросто. А если необходимо мигрировать всё старое накопленное барахло - задача усложняется на порядок. Про себя скажу, что мы с примерно 15к пользователей подготавливали миграцию почти год. Конечно, большинство сложностей было не с самой Гидрой, как таковой, а в переписывании своего софта, подготовке данных (например, из произвольной формы записи телефонов и адресов распарсить со всеми опечатками и перенести в структурированный формат Гидры) - но тем не менее. Сама парадигма (все эти БД, ПЦ, подписки и инвойсы и т.д.) сильно отличается от того же УТМа. Чтобы в неё только вьехать - уже потребовалось немалое время, и по одним только манам это сделать довольно сложно. В целом, пользуемся с февраля 13 года - и несмотря на то, что косяки были - впечатления скорее положительные. Косяки-то дело такое, они у всех есть. Из актуальных проблем, которые раздражают сейчас, только такие: - заметно увеличилось время реакции техподдержки. Сразу видно, что клиентов набрали прилично, а штат инженеров - не настолько расширили ;( - большая беда с документацией по API ;( В основном, большинство вьюх и процедур описано, описаны и изменения между версиями - но только тупо автоформированием из кода и комментариев. Некоторые функции, которые работали раньше, не изменились - но поменяли логику работы, и это нигде не описывается. Для некоторых программных пакетов нет документации вовсе - приходится лезть в БД и читать имеющиеся функции/процедуры и комментарии к ним прямо в кишках базы. При этом, если сам не разберёшься - спрашиваешь у ТП - а это учитываемое время, которое может стоить денег, если выйти за оплачиваемое число часов ;( Очень надеюсь, что читающее тему руководство Латеры обратит внимание на эти моменты (хотя они и ранее неоднократно поднимались их клиентами) Ну и от себя: мы для себя запилили php api для работы с гидрой. Сейчас оно работает с 3.4.5, постепенно перепиливаем под 4.0. Нужно ли оно кому? Стоит выкладывать в опенсурс? Только учтите, что оно довольно сильно анально огорожено :)) Запилено под использование с Laravel (используется его ORM, окружение и фасады), и необходим php7. Если человек несколько проявят интерес - возможно, выложим наружу Это промышленная система, которая пилится для широкого круга ISP. По этой причине было бы странно ожидать появления в ней стыковки с мелкими региональными платежными системами, и по этой же причине добавление любого кастомного функционала - стоит дорого. Как в абсолютно любом промышленном решении. А кто вам мешает, например, нанять программиста и принимать платежи по любому протоколу посредством API Гидры? Если вы считаете, что это будет дешевле 60000, то - вперёд, какие проблемы-то? :) Про ipoe - вообще не знаю, кто и где полагается на функционал билинга. IPOE все строят сильно по разному, и решения у каждого свои. Опять же, с работой с api/базами билингов. Опять же, это ХОТЕЛКА. Либо вы соглашаетесь с ценами Гидры, либо нанимаете программиста и он вам этот функционал запиливает. Мы вот запилили, никаких проблем с достаточно простыми селектами по номеру звонящего - нет.

Трафик вообще ничего не знает об адресах на стыках, он форвардится неизменно (исключая случаи с DF) всеми машрутизаторами по цепочке независимо от того, какие у них адреса. Открывайте спецификацию TCP/IP и вдумчиво изучайте механизм регулирования скорости TCP пакетов. Не забываем про роль icmp пакетов на маршрутизаторах. P.S. МФ ловко выкрутился, для снижения скорости транзита вставлять серые IP. Да и нечем им играться с размерами окна (другой способ регулировать ускорение траффика). И он где-то в isp работает?

Выставлено

Цель: побить несколько больших вланов с широкими броадкаст доменами на vlan-per-user. Одно условие: у клиентов ипы забиты статикой, и перенастраивать их нереально. В идеале было бы круто заюзать ip unnumbered poll на ASR, и добавлять роуты к клиентам на основе арпов от них. Однако всплыл косяк: при использовании ip unnumbered poll на asr1k у вендовых клиентов при назначении адреса вылазит конфликт: видимо, asr отвечает на все арпы подряд своим маком. Кто-нибуть сталкивался с подобным и нашел способ обойти? Было бы очень круто и удобно найти workaround...

В общем, такая хрень происходит только если навешивать аккаунтинг-полиси радиусом. Если тот же самый аккаунтинг-лист навешивать вручную в общей полиси-мапе, аккаунтинг отправляется валидный. А также, если передавать не Cisco AVpair := "accounting-list=ISG-ACCT", а Cisco-Account-Info := "Aall-inet-svc", где all-inet-svc: #sh run | s all-inet-svc policy-map type service all-inet-svc class type traffic all-inet accounting aaa list ISG-ACCT ! class type traffic default in-out drop ! то аккаунтинг работает правильно.

Не, аккаунтинг-лист навешивается один:

Нет, это я уже сейчас накрутил... Исключение не пмогло

Совсем другая проблема, но не хочу ещё одну тему плодить. ASR отдаёт в аккаунтинг-стоп acct-input-* и acct-output-* по два раза. Что совсем не по rfc, и радиус с билингом закономерно не хотят пережёвывать такой аккаунтинг. asr: ASR1-224#sh run | in accou aaa accounting delay-start all aaa accounting update periodic 10 aaa accounting network default start-stop group radius aaa accounting network ISG-AUTH start-stop group RG-ISG-AUTH subscriber service session-accounting subscriber service accounting interim-interval 10 aaa accounting network ISG-AUTH start-stop group RG-ISG-AUTH 10 authorize aaa list ISG-AUTH password radius identifier source-ip-address С радиуса при авторизации прилетает Cisco-Avpair := accounting-list=ISG-AUTH, чтобы аккаунтинг работал для сессии. Дебаг циски: Sep 2 19:01:50.775: RADIUS: authenticator A1 58 02 9B 62 4A FA 26 - 64 04 B3 E7 1B 73 B2 C1 Sep 2 19:01:50.775: RADIUS: Acct-Session-Id [44] 10 "00000AA4" Sep 2 19:01:50.775: RADIUS: Framed-IP-Address [8] 6 10.206.141.100 Sep 2 19:01:50.775: RADIUS: Framed-Protocol [7] 6 PPP [1] Sep 2 19:01:50.776: RADIUS: Acct-Input-Packets [47] 6 7690 Sep 2 19:01:50.776: RADIUS: Acct-Output-Packets [48] 6 7694 Sep 2 19:01:50.776: RADIUS: Acct-Input-Octets [42] 6 672134 Sep 2 19:01:50.776: RADIUS: Acct-Output-Octets [43] 6 668824 Sep 2 19:01:50.776: RADIUS: Vendor, Cisco [26] 17 Sep 2 19:01:50.776: RADIUS: ssg-control-info [253] 11 "I0;672134" Sep 2 19:01:50.776: RADIUS: Vendor, Cisco [26] 17 Sep 2 19:01:50.776: RADIUS: ssg-control-info [253] 11 "O0;668824" Sep 2 19:01:50.776: RADIUS: User-Name [1] 17 "10.206.141.100" Sep 2 19:01:50.776: RADIUS: Acct-Authentic [45] 6 Local [2] Sep 2 19:01:50.776: RADIUS: Vendor, Cisco [26] 32 Sep 2 19:01:50.776: RADIUS: Cisco AVpair [1] 26 "connect-progress=Call Up" Sep 2 19:01:50.776: RADIUS: Acct-Session-Time [46] 6 7343 Sep 2 19:01:50.776: RADIUS: Acct-Input-Octets [42] 6 579163 Sep 2 19:01:50.776: RADIUS: Acct-Output-Octets [43] 6 576636 Sep 2 19:01:50.776: RADIUS: Acct-Input-Packets [47] 6 6589 Sep 2 19:01:50.776: RADIUS: Acct-Output-Packets [48] 6 6590 Sep 2 19:01:50.776: RADIUS: Acct-Terminate-Cause[49] 6 admin-reset [6] Sep 2 19:01:50.776: RADIUS: Vendor, Cisco [26] 39 Sep 2 19:01:50.776: RADIUS: Cisco AVpair [1] 33 "disc-cause-ext=Local Admin Disc" Sep 2 19:01:50.776: RADIUS: Acct-Status-Type [40] 6 Stop [2] Sep 2 19:01:50.776: RADIUS: NAS-Port-Type [61] 6 Virtual [5] Sep 2 19:01:50.776: RADIUS: NAS-Port [5] 6 Acct-Input-Packets, Acct-Output-Packets, Acct-Input-Octets, Acct-Output-Octets - в запросе по два раза, причем значения отличаются. С чем такое может быть связано?

Да, я уже примерно понял, спасибо ;(

Так а смысл? Даже если взлетит - не прописывать же всем клиентам, весь смысл в динамике

Хотел завести без dhcp

Изначально так и делал; без poll тоже не взлетало

Понял, крайне печально ;( Пусто там, пока тестировал unnumbered без poll, т.к. налетел на эту проблему. Блин. Придётся заново схему придумывать

Понял, крайне прискорбно ;( Смысл в том, что в билинге хранятся ip`шники. Хранить маки и при смене железа у юзера их перепрописывать - крайне не хочется

Для unclassified mac работать не будет скорее всего, пробуйте identifier mac-address, remote-id, nas-port и другие. У нас схема l2-connected, initiator - dhcp, циска - релей, авторизация по remote-id, из которого достаётся svlan, cvlan, на доступе никаких релеев, опций, снупингов и прочей херни. На агрегации тоже, только qinq/selective qinq. Так работает же. Только не на unnumbered-интерфейсах =\

Пробовал на ней же ;( Там инициатор - мак; ип вбит руками Смотрел - от АСР нет ответов

policy-map type control ISG-POLICY class type control CLASS-UNAUTH event timed-policy-expiry 1 service disconnect ! class type control always event session-start 10 authorize aaa list ISG-AUTH password radius identifier source-ip-address 20 set-timer TIMER-UNAUTH 3 30 service-policy type service name SERVICE-TRUSTED 40 service-policy type service name SERVICE-REDIR ! class type control always event radius-timeout 10 service-policy type service name SERVICE-TRUSTED 20 service-policy type service name SERVICE-REDIR 30 set-timer TIMER-UNAUTH 1 ! class type control always event access-reject 10 service-policy type service name SERVICE-TRUSTED 20 service-policy type service name SERVICE-REDIR-INET 30 service-policy type service name SERVICE-REDIR-LOCAL 50 set-timer TIMER-UNAUTH 5 ! А v6-сессии вообще поддерживаются? Вроде же только paththrough? Вроде как поддерживаются, только не в одной сессии с v4, а в разных

Так в том-то и проблема, блин, что сессия и не пытается создаваться; арпов/маков на кошке и на клиенте не появляется Сессия инициируется только для v4-трафиком, v6 игнорируется

Нет, нету

Продолжаю мучения с аср :) Немного в ступоре. Конфиг интерфейса: interface TenGigabitEthernet0/2/0.4020 encapsulation dot1Q 4020 second-dot1q any ip unnumbered Loopback4020 service-policy type control ISG-POLICY ip subscriber l2-connected initiator unclassified mac-address ipv4 end Конфиг лупбека: interface Loopback4020 ip address 10.100.100.1 255.255.255.0 secondary ip address 10.200.200.1 255.255.255.0 end Так - ничего не работает. Клиент из сети 10.100.100/24 не видит АСР, АСР не видит клиента. Арпов нет с обоих сторон. Но стоит убрать unnumbered, как всё начинает летать: interface TenGigabitEthernet0/2/0.4020 encapsulation dot1Q 4020 second-dot1q any ip address 10.100.100.1 255.255.255.0 secondary ip address 10.200.200.1 255.255.255.0 no ip redirects no ip unreachables service-policy type control ISG-POLICY ip subscriber l2-connected initiator unclassified mac-address ipv4 end Арпы тут же появляются, пинги ходят, юзеры авторизуются. В чем может быть косяк? Рабочая же схема... p.s. пробовал на разных иосах: 3.13 и 3.16

Вылезла проблема: без `poll` - оно да, работает, но через энное время - пропадает и не появляется arp-запись. У клиента, соответственно, всё отваливается

А смысл? Даже если взлетит, для меня будет уже неприменимо ;(

Ты не поверишь... ;( Не пашет

Убирал, не работает

Да в том-то и дело, что мне не нужен initiator dhcp