Jump to content

VLAN на абонента БЕЗ opt.82

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

А если релеить в управляющий?

Гм.. Можно попробовать, конечно, но как-то уж совсем костыльно получается..

Управляющий влан у меня до BRAS-а не проброшен, нечего ему там делать.

Пока только удалось вычислить, где потерялись дхцп броадкасты - оказалось где-то на транзите (два DGS-3120). 

Причину ещё не выяснил. Если что, jumbo frame на транзите включён.

Перебросил "вход" BRAS-а непосредственно на "узел" (где QinQ навешивается ) - запросы от клиента появились, но dhcp их почему-то игнорит..

В логах dhcp про них тишина..

 

P.S. В DHCPARGS eth0.2519 eth0.2519.1101 прописаны, в iptables udp на 67-68 порты разрешён.

 

Share this post


Link to post
Share on other sites

В 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?

Share this post


Link to post
Share on other sites

QinQ устаревшая технология. Вместо нее следует использовать MPLS и IP транспорт.

 

Домовые коммутаторы только упаковывают порт абонента во влан. При этом номера вланов на всех коммутаторах одинаковые. Кому как удобнее, но например 1 порт это 101 влан, 24 порт это 124.

 

Далее по оптике от каждого домового коммутатора все сводится на промежуточный коммутатор с поддержкой MPLS, он упаковывает пачку вланов с абонентского коммутатора в IP.

 

На брасе уже все просто - есть коммутатор с абонентами и есть канал до него с идентификатором туннеля. Так намного удобнее, чем помнить какой там номер влана на 3-м коммутаторе в доме. А если потом производится замена одного коммутатора с 24 портов на 48, не появится путаница с номерами вланов.

Share this post


Link to post
Share on other sites

8 минут назад, Saab95 сказал:

QinQ устаревшая технология. Вместо нее следует использовать MPLS и IP транспорт.

 

Домовые коммутаторы только упаковывают порт абонента во влан. При этом номера вланов на всех коммутаторах одинаковые. Кому как удобнее, но например 1 порт это 101 влан, 24 порт это 124.

 

Далее по оптике от каждого домового коммутатора все сводится на промежуточный коммутатор с поддержкой MPLS, он упаковывает пачку вланов с абонентского коммутатора в IP.

 

На брасе уже все просто - есть коммутатор с абонентами и есть канал до него с идентификатором туннеля. Так намного удобнее, чем помнить какой там номер влана на 3-м коммутаторе в доме. А если потом производится замена одного коммутатора с 24 портов на 48, не появится путаница с номерами вланов.

Сами строили такое?

Share this post


Link to post
Share on other sites

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

Сами строили такое?

Естественно. Только вместо коммутаторов с мплс используется микротик CCR1016 с оптическими портами. Т.к. самый дешевый коммутатор с поддержкой MPLS и необходимым функционалом стоит за 120 тыс.р. На эти деньги можно 4 микротика купить.

 

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

 

В схеме с IP транспортов настройка делается только в центре и на оконечном оборудовании, все остальное уже само идет. Легко диагностировать проблемы.

 

Про одинаковые вланы на коммутаторах тоже все по опыту других=) т.к. сами так не делаем. Обычно же как - идут вланы друг за другом, а потом, как уже писал, меняют коммутаторы на другие с большим количеством портов, а все вланы поштучно уже заняты и разбиты по 24 портам коммутаторов, приходится оставлять 24 влана старых и добавлять 24 новых, совсем с другими номерами.

 

В центре всегда все красиво - одинаковые конфиги по каждому туннелю.

Share this post


Link to post
Share on other sites

2 часа назад, AlKov сказал:

Не получается eth0.2519.1101 без IP. В этом случае dhcp отказывается слушать этот интерфейс..

Если же IP шлюза для этого доступа назначить на eth0.2519 и заставить dhcp слушать его, то он (dhcp) не видит запросы от клиента влан 1101..

Хотя tcpdump показывает эти запросы на eth0.2519.

Какой-то замкнутый круг получился..

Или я где-то накосячил в конфигурации QinQ?

Нужно использовать accel-ppp для таких вещей. Я так понимаю вы пытаетесь обойтись без него.

Share this post


Link to post
Share on other sites

7 минут назад, GrandPr1de сказал:

Нужно использовать accel-ppp для таких вещей. Я так понимаю вы пытаетесь обойтись без него.

Да, Вы правы. Совсем не ощущаю горячей любви к accel-ppp. ;-) Одна эпопея со сборкой чего стоила!

Да и не люблю "комбайны", я более склонен к тому, чтобы котлеты были отдельно.. А в accel чего только не намешано!

Ну а главное, наверное - это очень скудная документация, во всяком случае для IPoE.

Share this post


Link to post
Share on other sites

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 серверами 

Share this post


Link to post
Share on other sites

17 часов назад, kayot сказал:

По IPOE на сайте есть полная дока https://accel-ppp.org/wiki/doku.php?id=ru:ipoe

 

К сожалению, я бы этого не сказал.. Очень скудная дока, практически минимум, ИМХО..

Может быть у Вас найдётся время, описать эту конфигурацию (с QinQ) более подробно.

Был бы очень признателен, да и не я один наверное.

Share this post


Link to post
Share on other sites

4 часа назад, AlKov сказал:

К сожалению, я бы этого не сказал.. Очень скудная дока, практически минимум, ИМХО..

Там весь конфиг состоит в итоге из 10 строк, в доке описана каждая переменная да еще и примеры даны. 

Если что-то конкретное интересует - велкам в личку.

Share this post


Link to post
Share on other sites

В 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, они там в хексе могут быть, могут быть в аски.

А вот это в каком варианте получается?

Share this post


Link to post
Share on other sites

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

А вот это в каком варианте получается?

Во всех :)

В ISG есть прям параметры s-tag, c-tag, которые можно в идентификаторе передавать, но они, по какой-то причине, не работают на тех версиях IOS XE, что я пробовал, а было бы недурно.

Share this post


Link to post
Share on other sites

4 часа назад, xcme сказал:

Попробовал с nas-port - действительно работает, спасибо! А вот при remote-id тишина. У вас, наверное, опцию 82 доступ вставляет? remote-id это же тот самый RID из опции 82?

Нет, мы как раз с опции с доступа с радостью ушли. Там, обратите внимание, что BRAS является relay, он и вставляет этот remote-id, в котором будет пара s-tag/c-tag.

Share this post


Link to post
Share on other sites

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 сказал:

Адреса брасы выдают, зачем опция?

У вас брас выдает, не радиус?

Share this post


Link to post
Share on other sites

В 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.

Share this post


Link to post
Share on other sites

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. Сейчас эта схема на другом вендоре вообще, там полностью брасы выдают случайный из пула, радиус диктует постоянный адрес, если есть услуга, никаких рилеев, опций и такого.

Share this post


Link to post
Share on other sites

3 минуты назад, buckethead сказал:

Выдаёт и брас, если nas-port-id, и релеит (там легаси сетка), если remote-id, radius ничего не выдаёт, а лишь указывает брасу какой конкретно выдавать.

Если я хочу выдавать адреса без отдельного DHCP-сервера, получается, что нужно настроить DHCP-сервер на ASR-1001x, просто в каждом access-accept от радиуса конкретизировать этот адрес?

Share this post


Link to post
Share on other sites

В каждом access-accept должен быть framed-ip-address атрибут. Но мне такая схема видится странной. Если вы хотите, чтобы IP-адреса были прибиты гвоздями к каждому абоненту (у нас так тоже раньше было), то проще имхо dhcp relay+opt.82, просто опцию лучше не с доступа тянуть, а с браса.
Вся красота раздачи адресов брасами, по ему скромному мнению, заключается в динамическом пуле.

Share this post


Link to post
Share on other sites

On 04.12.2017 at 1:09 PM, buckethead said:

В таком случае опция на брасе лучше чем опция на доступе, да.

 

Это что за кошак, у меня есть рабочий BRAS (ISG, asr1k) с авторизацией в RADIUS по паре stag/ctag, там, правда, колхоза немножко, но жить можно.

Расскажите подробнее, как настроили авторизацию в RADIUS по паре stag/ctag? и про колхоз чуть подробнее, если можно :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.