Jump to content
Калькуляторы

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

Подскажите, пожалуйста,

 

у некоторых коллег тут на форуме используется VLAN на абонента без opt.82, протянутый до BRAS'а по QinQ

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

 

Такой вопрос - я правильно понимаю, что на доступе коммутаторы пред-настраиваются вида: 1 порт -1001 влан, 48 порт - 1048 влан ?

 

А если дом большой и там, допустим, много коммутаторов - это получается у второго будет: 1 порт - 1049 влан, 48 порт - 1096 влан ?

Так что-ли?

 

Выглядит сложновато как-то: если в S-VLAN закодирован дом, а в C-VLAN стоит 1325 - то сразу и не поймёшь на каком коммутаторе абонент.

Как это админится?

Share this post


Link to post
Share on other sites

ну если у вас есть хоть какая-то система тех. учета - будь то .xls-файл, самописное что-то и или специальное ПО/модуль к биллингу, то что мешает учитывать там S+C-vlan-ы (привязывать их к свитчу), а потом искать? Да, в случае если это специальное ПО/модуль биллинга, то возможно там этого нет из коробки и придется заплатить за доработку, но что уж тут поделать, либо пилите ИТ-системы сами, либо платите кому-то за это (что обычно дешевле в итоге)

Share this post


Link to post
Share on other sites

Тут надо искать золотую середину между удобством администрирования и утилизацией доступного кол-ва svlan,cvlan.  На большой сети второй фактор важнее (+ еще как пунктом инкапсуляции можно использовать мплс).

А так в принципе до какого то момента достаточно и общедоступной таблицы... 

Share this post


Link to post
Share on other sites

Я ещё  потому спрашиваю, что может есть какой-то способ само-документирования в данной схеме, который я не знаю.

 

Листая форум мне попалось, что кто-то завязывается на ip управления коммутатора и оттуда высчитывает вланы.

 

Спасибо за ответы.

Share this post


Link to post
Share on other sites

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

 

ну типа S-vlan - номер цепочки (туда включить например номер агрег. свитча и номер порта агрегационного свитча), C-vlan/48 - номер свитча в цепочке, C-Vlan%48 - номер порта на свитче

 

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

Share this post


Link to post
Share on other sites
1 час назад, Urs_ak сказал:

 

Такой вопрос - я правильно понимаю, что на доступе коммутаторы пред-настраиваются вида: 1 порт -1001 влан, 48 порт - 1048 влан ?

 

А если дом большой и там, допустим, много коммутаторов - это получается у второго будет: 1 порт - 1049 влан, 48 порт - 1096 влан ?

Так что-ли?

У нас подобная схема используется. Все значительно проще.

Каждый свич нумеруется, если он один на доме - имеет номер 1 и вланы 1100-1148.

Если их 2 - второй имеет вланы 1201-1248 и т.д.

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

Share this post


Link to post
Share on other sites
13 часов назад, kayot сказал:

Каждый свич нумеруется, если он один на доме - имеет номер 1 и вланы 1100-1148.

Если их 2 - второй имеет вланы 1201-1248 и т.д.

А 12 коммутатор получается 2201-2248 ?

Ну кстати да - вполне само-документированно

Share this post


Link to post
Share on other sites

А я вот всё думаю, когда провайдеры дозреют спонсировать опенсорц чтобы им фичи пилили, но они всё костылями обкладываются дальше и дальше.

Я сейчас к том, что, например, можно не вешать 100500 релей агентов, по одному на влан а запилит который будет выше этого - сам уметь тэгировать/растегировать нужное количество меток.

Share this post


Link to post
Share on other sites
16 минут назад, Ivan_83 сказал:

А я вот всё думаю, когда провайдеры дозреют спонсировать опенсорц чтобы им фичи пилили, но они всё костылями обкладываются дальше и дальше.

Я сейчас к том, что, например, можно не вешать 100500 релей агентов, по одному на влан а запилит который будет выше этого - сам уметь тэгировать/растегировать нужное количество меток.

 

Это вообще куда применимо?

Нормальная схема с влан пер юзер работает так, что службу дхцп реализует брас, а ему ип-адреса и остальные параметры дает уже радиус, который посмотрит в биллинг. Это вроде как у всех вендоров работает.

Share this post


Link to post
Share on other sites

Это применимо к тем кто сидит на опенсорсе а не на вендорах.

Share this post


Link to post
Share on other sites
В 02.12.2017 в 00:48, Urs_ak сказал:

у некоторых коллег тут на форуме используется VLAN на абонента без opt.82, протянутый до BRAS'а по QinQ

Если абонентам надо еще и адреса выдавать, то опция 82 все равно нужна) Просто вставлять ее может уже сам BRAS.

Совсем без опции 82, это, наверное, только PPPoE =)

Share this post


Link to post
Share on other sites

P.S. Да, забыл, еще можно так:

 

В 03.12.2017 в 01:57, vurd сказал:

Нормальная схема с влан пер юзер работает так, что службу дхцп реализует брас, а ему ип-адреса и остальные параметры дает уже радиус, который посмотрит в биллинг. Это вроде как у всех вендоров работает.

Но у меня так не взлетело - кошак не захотел в запрос к радиусу вставлять svid/cvid, только MAC.

Share this post


Link to post
Share on other sites
9 часов назад, xcme сказал:

Если абонентам надо еще и адреса выдавать, то опция 82 все равно нужна) Просто вставлять ее может уже сам BRAS.

Совсем без опции 82, это, наверное, только PPPoE =)

Адреса брасы выдают, зачем опция? Нужен постоянный адрес -- RADIUS выдаёт Framed-IP-Address атрибут, так делается в серьёзных ISP.

Share this post


Link to post
Share on other sites
29 минут назад, buckethead сказал:

Адреса брасы выдают, зачем опция? Нужен постоянный адрес -- RADIUS выдаёт Framed-IP-Address атрибут, так делается в серьёзных ISP.

В следующем посте как раз ответ: в моем случае NAS не умеет svid/cvid в RADIUS.

Если умеет, то согласен, можно и без опции 82 и без дхцп вообще. Я забыл про этот вариант :)

Share this post


Link to post
Share on other sites

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

 

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

P.S. Да, забыл, еще можно так:

 

Но у меня так не взлетело - кошак не захотел в запрос к радиусу вставлять svid/cvid, только MAC.

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

Edited by buckethead

Share this post


Link to post
Share on other sites
В 02.12.2017 в 00:23, kayot сказал:

У нас подобная схема используется. Все значительно проще.

Каждый свич нумеруется, если он один на доме - имеет номер 1 и вланы 1100-1148.

Если их 2 - второй имеет вланы 1201-1248 и т.д.

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

Я правильно понимаю, что свитч доступа (где вланы 1100-1148) не имеет никакого отношения к QinQ?

Т.е. на нём только VLAN управления (тегом на аплинк-порту) и CVLAN-ы 1100... (на аплинке тегом, клиентские антегом).

А SVLAN существует только на "агрегации", дальше транзитом до BRAS, на котором сконфигурён интерфейс "шлюза", вида eth0.2519 (где 2519 - это VID SVLAN)

с IP шлюза и "клиентские" интерфейсы вида eth0.2519.1100 (без IP).

Так?

Share this post


Link to post
Share on other sites
1 час назад, AlKov сказал:

Так?

Я тоже так понял эту конструкцию.

 

Далее BRAS (например SE100) посылает RADIUS запрос в биллинг с атрибутом NAS-Port-ID вида "vlan-id 1005:1148", а биллинг разрешает и выдаёт адрес - либо через DHCP-ответ, либо через Framed-IP-Address атрибут

Share this post


Link to post
Share on other sites
1 час назад, AlKov сказал:

Я правильно понимаю, что свитч доступа (где вланы 1100-1148) не имеет никакого отношения к QinQ?

Т.е. на нём только VLAN управления (тегом на аплинк-порту) и CVLAN-ы 1100... (на аплинке тегом, клиентские антегом).

А SVLAN существует только на "агрегации", дальше транзитом до BRAS, на котором сконфигурён интерфейс "шлюза", вида eth0.2519 (где 2519 - это VID SVLAN)

с IP шлюза и "клиентские" интерфейсы вида eth0.2519.1100 (без IP).

Так?

Абсолютно верно.

На доступе только управление и клиентские вланы, никакого интеллекта от свичей не нужно.

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

Весь мозг на БРАСе, тут dhcp с opt82 и терминация вланов. В linux-софт-брасе будут интерфейсы eth0.2519.1101 без IP, на них с помощью IP Unnumbered маршрутизируется нужный IP или подсеть.

Share this post


Link to post
Share on other sites

kayot , спасибо. С этим всё понятно.

Ещё понадоедаю малость? ;-)

1. У меня на данный момент "агрегаторами" являются D-Link DGS-3120-24SC, сейчас на них настроены только "обычные домовые" влан(PPPoE, vlan-на дом).

Вопрос в следующем - как на них параллельно поднять QinQ, не повалив действующую схему?

Насколько я в курсе, в дилинках есть какие-то специфичные хитрости при настройке QinQ, вплоть до определённого порядка введения команд.

Поделитесь опытом, пожалуйста.

2. Я так понимаю, для авторизации и полисинга Вы используете accel-ppp. Если "да", то пару слов о том, какую схему авторизации используете?

3. Вкратце, как выглядит конфиг dhcpd? Он "статический" (создаётся один раз при запуске нового доступа)?

4. Чем создаются интерфейсы и маршруты на BRASе при ребуте?

 

 

Share this post


Link to post
Share on other sites
21 минуту назад, AlKov сказал:

kayot , спасибо. С этим всё понятно.

Ещё понадоедаю малость? ;-)

1. У меня на данный момент "агрегаторами" являются D-Link DGS-3120-24SC, сейчас на них настроены только "обычные домовые" влан(PPPoE, vlan-на дом).

Вопрос в следующем - как на них параллельно поднять QinQ, не повалив действующую схему?

Насколько я в курсе, в дилинках есть какие-то специфичные хитрости при настройке QinQ, вплоть до определённого порядка введения команд.

Поделитесь опытом, пожалуйста.

2. Я так понимаю, для авторизации и полисинга Вы используете accel-ppp. Если "да", то пару слов о том, какую схему авторизации используете?

3. Вкратце, как выглядит конфиг dhcpd? Он "статический" (создаётся один раз при запуске нового доступа)?

4. Чем создаются интерфейсы и маршруты на BRASе при ребуте?

 

 

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

Точно помню читал ftp://ftp.dlink.ru/pub/Trainings/SwitchWhitePapers/Q-in-Q_Port-Based_and_Selective.pdf

Точно помню была загвоздка с ревизиями длинков. какие то не умели во vlan_translation (на 3200 только С умели, А и В нет. Даже в саппорт звонил сказали менять. Но это было давно.)

а так если нужно не поломать существующий влан то делаем create vlan_translation ports 1 cvid 100 replace svid 100 (то есть оставляем vlanid без изменений)

если нужно навесить метку то create vlan_translation ports 1 cvid 100 add svid 200

если конечно ничего не напутал.

Share this post


Link to post
Share on other sites
2 часа назад, AlKov сказал:

Насколько я в курсе, в дилинках есть какие-то специфичные хитрости при настройке QinQ, вплоть до определённого порядка введения команд.

На старый сериях (3120 не относится к ним) после включения QinQ меняется outer_tpid на 0x88a8 и коммутатор становится недоступным. Нам нужно значение 0x8100

Проверить так:

config qinq ports 1-28 outer_tpid 0x8100

Если скажет "You should enable QinQ at first!" - это проблемный коммутатор. В этом случае надо позаботиться о том, как вернуть эти значения на 0x8100 после включения QinQ. Очевидный вариант - техник с консолью на месте. Либо инкрементный конфиг с соответствующими командами.

Если дает ставить любые значения без проблем, можно делать enable qinq.

 

P.S. Пока разбирался с QinQ написал для себя пару заметок чтобы не забыть.

 

7 часов назад, buckethead сказал:

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

А вот этот самый ASR1K и есть. Я пробовал через DHCP Server Radius Proxy и еще вариант с, кажется, initiator. Ни в том ни в том случае s-tag, c-tag не отправляются.

Можно пример настроек и версию ПО? Ну и что за колхоз, тоже интересно. :)

Share this post


Link to post
Share on other sites
1 час назад, xcme сказал:

Если скажет "You should enable QinQ at first!" - это проблемный коммутатор. В этом случае надо позаботиться о том, как вернуть эти значения на 0x8100 после включения QinQ. Очевидный вариант - техник с консолью на месте. Либо инкрементный конфиг с соответствующими командами.

Говорят с веб-интерфейса настройки изменяются в один заход.

Share this post


Link to post
Share on other sites
14 часов назад, xcme сказал:

Можно пример настроек и версию ПО? Ну и что за колхоз, тоже интересно. :)

Версии разные использовали. Сейчас 03.13.04.S

 

Вот пример порта кастомера

interface Port-channel1.400
 encapsulation dot1Q 400 second-dot1q any
 ip unnumbered Loopback1
 ip helper-address 192.168.100.27
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1500
 ip verify unicast source reachable-via rx l2-src
 ip access-group Bogons in
 shutdown
 service-policy type control Customers
 ip subscriber l2-connected
  initiator dhcp
  arp ignore local
end

 

Вот пример политики

 

policy-map type control Customers
 class type control Unauth event timed-policy-expiry
  1 service disconnect
 !
 class type control always event session-start
  1 authorize aaa password cisco identifier remote-id (здесь ещё можно попробовать nas-port-id)
  3 set-timer Unauth 1
 !
 class type control always event session-restart
  1 authorize aaa password cisco identifier remote-id 
  3 set-timer Unauth 1
 !
 class type control always event access-reject
  1 service-policy type service name OpenGarden
  2 service-policy type service name L4R
  3 set-timer Unauth 3
 !
!
class-map type traffic match-any L4R
 match access-group input name WebRedirectIn
 match access-group output name WebRedirectOut
!
class-map type traffic match-any OpenGarden
 match access-group output name OpenGardenOut
 match access-group input name OpenGardenIn
!
class-map type control match-all Unauth
 match timer Unauth 
 match authen-status unauthenticated 
!
policy-map type service L4R
 class type traffic L4R
  redirect to group Enclosure
 !
 class type traffic default in-out
  drop
 !
!
policy-map type service OpenGarden
 class type traffic OpenGarden
  police input 5000000 937500 1875000
  police output 5000000 937500 1875000
 !
 class type traffic default in-out
  drop
 !
!

 

Где remote-id, там порт кастомера работает как DHCP-Relay, где nas-port-id работает как DHCP-Server.

 

Колхоз заключается в парсинге того, что приходит на радиус, на предмет stag/ctag, они там в хексе могут быть, могут быть в аски.

Share this post


Link to post
Share on other sites
19 часов назад, AlKov сказал:

kayot , спасибо. С этим всё понятно.

Ещё понадоедаю малость? ;-)

1. У меня на данный момент "агрегаторами" являются D-Link DGS-3120-24SC, сейчас на них настроены только "обычные домовые" влан(PPPoE, vlan-на дом).

Вопрос в следующем - как на них параллельно поднять QinQ, не повалив действующую схему?

Насколько я в курсе, в дилинках есть какие-то специфичные хитрости при настройке QinQ, вплоть до определённого порядка введения команд.

Поделитесь опытом, пожалуйста.

2. Я так понимаю, для авторизации и полисинга Вы используете accel-ppp. Если "да", то пару слов о том, какую схему авторизации используете?

3. Вкратце, как выглядит конфиг dhcpd? Он "статический" (создаётся один раз при запуске нового доступа)?

4. Чем создаются интерфейсы и маршруты на BRASе при ребуте?

1. Старые вланы и управление пропускаются мимо qinq с помощью функционала selective qinq, выше давали верную команду для пропуска vid100 без изменений

create vlan_translation ports 1 cvid 100 replace svid 100

Сам qinq на 3120 включается в веб-морде или консоли, ничего сложного там нет.

2. В качестве БРАСа linux с accel. Авторизация по номеру порта, на радиус приходит запрос вида svid.cvid, при положительном ответе клиент получает IP и стартует сессия

3. Dhcp отдельный разговор. В принципе он не нужен вообще, accel умеет запрашивать IP у радиуса и выдавать его клиенту как нормальные БРАСы.

У меня используется perl-dhcp от Ivan83, биллинг заполняет табличку соответствий svid.cvid - ip, dhcp выдает адреса клиентам.

4. Это все проблемы accel, для этого он и нужен.

Share this post


Link to post
Share on other sites

QinQ сконфигурил без потерь в действующем PPPoE сегменте.

А вот в сегменте IPoE обнаружилась проблема - не доходят dhcp запросы от клиентов.

Смотрел tcpdump-ом непосредственно на интерфейсе BRAS(CentOS) - пусто..

Если клиенту назначить IP статикой, всё работает.

На доступе DES-3200-26 с включённым dhcp_local_relay в клиентких влан.

Где ещё поискать?

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now