andryas Опубликовано 5 декабря, 2017 · Жалоба А если релеить в управляющий? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 5 декабря, 2017 · Жалоба 18 минут назад, andryas сказал: А если релеить в управляющий? Гм.. Можно попробовать, конечно, но как-то уж совсем костыльно получается.. Управляющий влан у меня до BRAS-а не проброшен, нечего ему там делать. Пока только удалось вычислить, где потерялись дхцп броадкасты - оказалось где-то на транзите (два DGS-3120). Причину ещё не выяснил. Если что, jumbo frame на транзите включён. Перебросил "вход" BRAS-а непосредственно на "узел" (где QinQ навешивается ) - запросы от клиента появились, но dhcp их почему-то игнорит.. В логах dhcp про них тишина.. P.S. В DHCPARGS eth0.2519 eth0.2519.1101 прописаны, в iptables udp на 67-68 порты разрешён. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 5 декабря, 2017 · Жалоба В 04.12.2017 в 13:19, kayot сказал: В linux-софт-брасе будут интерфейсы eth0.2519.1101 без IP, на них с помощью IP Unnumbered маршрутизируется нужный IP или подсеть. Не получается eth0.2519.1101 без IP. В этом случае dhcp отказывается слушать этот интерфейс.. Если же IP шлюза для этого доступа назначить на eth0.2519 и заставить dhcp слушать его, то он (dhcp) не видит запросы от клиента влан 1101.. Хотя tcpdump показывает эти запросы на eth0.2519. Какой-то замкнутый круг получился.. Или я где-то накосячил в конфигурации QinQ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 5 декабря, 2017 · Жалоба QinQ устаревшая технология. Вместо нее следует использовать MPLS и IP транспорт. Домовые коммутаторы только упаковывают порт абонента во влан. При этом номера вланов на всех коммутаторах одинаковые. Кому как удобнее, но например 1 порт это 101 влан, 24 порт это 124. Далее по оптике от каждого домового коммутатора все сводится на промежуточный коммутатор с поддержкой MPLS, он упаковывает пачку вланов с абонентского коммутатора в IP. На брасе уже все просто - есть коммутатор с абонентами и есть канал до него с идентификатором туннеля. Так намного удобнее, чем помнить какой там номер влана на 3-м коммутаторе в доме. А если потом производится замена одного коммутатора с 24 портов на 48, не появится путаница с номерами вланов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 5 декабря, 2017 · Жалоба 8 минут назад, Saab95 сказал: QinQ устаревшая технология. Вместо нее следует использовать MPLS и IP транспорт. Домовые коммутаторы только упаковывают порт абонента во влан. При этом номера вланов на всех коммутаторах одинаковые. Кому как удобнее, но например 1 порт это 101 влан, 24 порт это 124. Далее по оптике от каждого домового коммутатора все сводится на промежуточный коммутатор с поддержкой MPLS, он упаковывает пачку вланов с абонентского коммутатора в IP. На брасе уже все просто - есть коммутатор с абонентами и есть канал до него с идентификатором туннеля. Так намного удобнее, чем помнить какой там номер влана на 3-м коммутаторе в доме. А если потом производится замена одного коммутатора с 24 портов на 48, не появится путаница с номерами вланов. Сами строили такое? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 5 декабря, 2017 · Жалоба 5 минут назад, vurd сказал: Сами строили такое? Естественно. Только вместо коммутаторов с мплс используется микротик CCR1016 с оптическими портами. Т.к. самый дешевый коммутатор с поддержкой MPLS и необходимым функционалом стоит за 120 тыс.р. На эти деньги можно 4 микротика купить. Тут весь вопрос в администрировании. Т.к. обычно на сети либо биллинг всем управляет, либо админы сидят и постоянно в консоль тычат, вланы перенастраивая и пробрасывая по сети, кому куда ходить разрешено. В схеме с IP транспортов настройка делается только в центре и на оконечном оборудовании, все остальное уже само идет. Легко диагностировать проблемы. Про одинаковые вланы на коммутаторах тоже все по опыту других=) т.к. сами так не делаем. Обычно же как - идут вланы друг за другом, а потом, как уже писал, меняют коммутаторы на другие с большим количеством портов, а все вланы поштучно уже заняты и разбиты по 24 портам коммутаторов, приходится оставлять 24 влана старых и добавлять 24 новых, совсем с другими номерами. В центре всегда все красиво - одинаковые конфиги по каждому туннелю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 5 декабря, 2017 · Жалоба 2 часа назад, AlKov сказал: Не получается eth0.2519.1101 без IP. В этом случае dhcp отказывается слушать этот интерфейс.. Если же IP шлюза для этого доступа назначить на eth0.2519 и заставить dhcp слушать его, то он (dhcp) не видит запросы от клиента влан 1101.. Хотя tcpdump показывает эти запросы на eth0.2519. Какой-то замкнутый круг получился.. Или я где-то накосячил в конфигурации QinQ? Нужно использовать accel-ppp для таких вещей. Я так понимаю вы пытаетесь обойтись без него. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 5 декабря, 2017 · Жалоба 7 минут назад, GrandPr1de сказал: Нужно использовать accel-ppp для таких вещей. Я так понимаю вы пытаетесь обойтись без него. Да, Вы правы. Совсем не ощущаю горячей любви к accel-ppp. ;-) Одна эпопея со сборкой чего стоила! Да и не люблю "комбайны", я более склонен к тому, чтобы котлеты были отдельно.. А в accel чего только не намешано! Ну а главное, наверное - это очень скудная документация, во всяком случае для IPoE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 5 декабря, 2017 · Жалоба 2 часа назад, AlKov сказал: Не получается eth0.2519.1101 без IP. В этом случае dhcp отказывается слушать этот интерфейс.. Если же IP шлюза для этого доступа назначить на eth0.2519 и заставить dhcp слушать его, то он (dhcp) не видит запросы от клиента влан 1101.. Хотя tcpdump показывает эти запросы на eth0.2519. Какой-то замкнутый круг получился.. Или я где-то накосячил в конфигурации QinQ? Не нужно вешать dhcp на эти интерфейсы, это мрак какой-то а не схема получается. Нужно релеить запросы с этих вланов на dhcp, но и это извращение. Accel умеет это делать, без необходимости использовать этот функционал на свичах. По IPOE на сайте есть полная дока https://accel-ppp.org/wiki/doku.php?id=ru:ipoe accel-ppp умеет все то что вы пытаетесь сделать костылями(или то что еще придется делать) 1) автоматом создавать/удалять клиенсткие вланы 2) строить маршруты для unnumbered 3) релеить DHCP запросы 4) отвечать на DHCP-запросы, используя данные из радиуса 5) считать и шейпить трафик по по радиусу 6) балансировать нагрузку между несколькими IPOE серверами Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 6 декабря, 2017 · Жалоба 17 часов назад, kayot сказал: По IPOE на сайте есть полная дока https://accel-ppp.org/wiki/doku.php?id=ru:ipoe К сожалению, я бы этого не сказал.. Очень скудная дока, практически минимум, ИМХО.. Может быть у Вас найдётся время, описать эту конфигурацию (с QinQ) более подробно. Был бы очень признателен, да и не я один наверное. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 6 декабря, 2017 · Жалоба 4 часа назад, AlKov сказал: К сожалению, я бы этого не сказал.. Очень скудная дока, практически минимум, ИМХО.. Там весь конфиг состоит в итоге из 10 строк, в доке описана каждая переменная да еще и примеры даны. Если что-то конкретное интересует - велкам в личку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 6 декабря, 2017 · Жалоба В 05.12.2017 в 09:09, buckethead сказал: 1 authorize aaa password cisco identifier remote-id (здесь ещё можно попробовать nas-port-id) Попробовал с nas-port - действительно работает, спасибо! А вот при remote-id тишина. У вас, наверное, опцию 82 доступ вставляет? remote-id это же тот самый RID из опции 82? В 05.12.2017 в 09:09, buckethead сказал: Колхоз заключается в парсинге того, что приходит на радиус, на предмет stag/ctag, они там в хексе могут быть, могут быть в аски. А вот это в каком варианте получается? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 6 декабря, 2017 · Жалоба 3 часа назад, xcme сказал: А вот это в каком варианте получается? Во всех :) В ISG есть прям параметры s-tag, c-tag, которые можно в идентификаторе передавать, но они, по какой-то причине, не работают на тех версиях IOS XE, что я пробовал, а было бы недурно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 6 декабря, 2017 · Жалоба 4 часа назад, xcme сказал: Попробовал с nas-port - действительно работает, спасибо! А вот при remote-id тишина. У вас, наверное, опцию 82 доступ вставляет? remote-id это же тот самый RID из опции 82? Нет, мы как раз с опции с доступа с радостью ушли. Там, обратите внимание, что BRAS является relay, он и вставляет этот remote-id, в котором будет пара s-tag/c-tag. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 7 декабря, 2017 · Жалоба 6 часов назад, buckethead сказал: Там, обратите внимание, что BRAS является relay, он и вставляет этот remote-id, в котором будет пара s-tag/c-tag. Кстати да, зачем так? Если IP-адрес выдает радиус, то зачем: ip helper-address 192.168.100.27 ? P.S. Убрал релей, переделал интерфейс вот так: ip subscriber l2-connected initiator dhcp И не идут запросы к радиусу. Очевидно, я делаю что-то не так... P.P.S. Наверное, я все же невнимательно прочитал. :) В 04.12.2017 в 10:04, buckethead сказал: Адреса брасы выдают, зачем опция? У вас брас выдает, не радиус? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
x86 Опубликовано 7 декабря, 2017 · Жалоба В 05.12.2017 в 15:36, AlKov сказал: Не получается eth0.2519.1101 без IP. В этом случае dhcp отказывается слушать этот интерфейс.. Если же IP шлюза для этого доступа назначить на eth0.2519 и заставить dhcp слушать его, то он (dhcp) не видит запросы от клиента влан 1101.. Хотя tcpdump показывает эти запросы на eth0.2519. Какой-то замкнутый круг получился.. Или я где-то накосячил в конфигурации QinQ? Внесу свои 5 копеек. У нас каждому интерфейсу назначен IP( он один и тот-же для всех клиентов - и он-же для них default gateway ). А вот DHCP-server у каждого свой, со своим конфигом и слушающий исключительно на этом интерфейсе. Естественно нужно настроить маршрутизацию и если нужно общение между клиентами - то добавить proxy_arp. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 7 декабря, 2017 · Жалоба 5 часов назад, xcme сказал: Кстати да, зачем так? Если IP-адрес выдает радиус, то зачем: ip helper-address 192.168.100.27 ? P.S. Убрал релей, переделал интерфейс вот так: ip subscriber l2-connected initiator dhcp И не идут запросы к радиусу. Очевидно, я делаю что-то не так... P.P.S. Наверное, я все же невнимательно прочитал. :) У вас брас выдает, не радиус? Выдаёт и брас, если nas-port-id, и релеит (там легаси сетка), если remote-id, radius ничего не выдаёт, а лишь указывает брасу какой конкретно выдавать. P.S. Сейчас эта схема на другом вендоре вообще, там полностью брасы выдают случайный из пула, радиус диктует постоянный адрес, если есть услуга, никаких рилеев, опций и такого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 7 декабря, 2017 · Жалоба 3 минуты назад, buckethead сказал: Выдаёт и брас, если nas-port-id, и релеит (там легаси сетка), если remote-id, radius ничего не выдаёт, а лишь указывает брасу какой конкретно выдавать. Если я хочу выдавать адреса без отдельного DHCP-сервера, получается, что нужно настроить DHCP-сервер на ASR-1001x, просто в каждом access-accept от радиуса конкретизировать этот адрес? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 8 декабря, 2017 · Жалоба В каждом access-accept должен быть framed-ip-address атрибут. Но мне такая схема видится странной. Если вы хотите, чтобы IP-адреса были прибиты гвоздями к каждому абоненту (у нас так тоже раньше было), то проще имхо dhcp relay+opt.82, просто опцию лучше не с доступа тянуть, а с браса. Вся красота раздачи адресов брасами, по ему скромному мнению, заключается в динамическом пуле. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Spinaker Опубликовано 15 марта, 2018 · Жалоба On 04.12.2017 at 1:09 PM, buckethead said: В таком случае опция на брасе лучше чем опция на доступе, да. Это что за кошак, у меня есть рабочий BRAS (ISG, asr1k) с авторизацией в RADIUS по паре stag/ctag, там, правда, колхоза немножко, но жить можно. Расскажите подробнее, как настроили авторизацию в RADIUS по паре stag/ctag? и про колхоз чуть подробнее, если можно :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...