[Tooreagen]

Всем привет!
Ребят подскажите смогу ли я и как правильно организовать переход с красной схемы на зеленую (на скрине)?

Задача закинуть все те VLAN которые сейчас бегают, в QinQ.
Запаковать нужно на первом CRS317. А распаковать на втором CRS317 и только три нужных VLAN. VLAN на первом коммутаторе настроены как Bridge - VLANs. MTU на комутаторах провайдера 9000. 
Проблема в том что все VLAN подаються в сеть не подконтрольную мне, там некоторые VLAN приходят на одни объекты, некоторые на другие. 
Если это нереально, то как сделать, не обращаясь за переделкой к транзитному провайдеру? Спасибо!

 

[jffulcrum]

Без помощи транзитного провайдера вам будет трудно, его железо должно понимать, что это QinQ от вас пришел, и на выходе его отдать. Можно попытаться сделать L2 туннель между CRS317, и уже на нём делать QinQ, транспорт вроде EOIP или MPLS, но там опять же нужна помощь от транзитного провайдера по увеличению MTU, иначе у вас будет большая фрагментация пакетов. Ну и про HW offload можно будет забыть.

[Tooreagen]

Цитата

HW offload можно будет забыть

Это точно уже? Потому что одни пишут одно, другие другое. Какой выход есть? Может возле первого микротика еще что-то поставить для упаковки? 

[tcup]

32 minutes ago, jffulcrum said:

Без помощи транзитного провайдера вам будет трудно, его железо должно понимать, что это QinQ от вас пришел, и на выходе его отдать. Можно попытаться сделать L2 туннель между CRS317, и уже на нём делать QinQ, транспорт вроде EOIP или MPLS, но там опять же нужна помощь от транзитного провайдера по увеличению MTU, иначе у вас будет большая фрагментация пакетов. Ну и про HW offload можно будет забыть.

А сколько надо MTU в случае с EoIP, чтобы не было фрагментации?

[Morty]

1 час назад, Tooreagen сказал:

Это точно уже?

Точно

Микроты не умеют QinQ HW.

[jffulcrum]

1 час назад, tcup сказал:

А сколько надо MTU в случае с EoIP, чтобы не было фрагментации?

Если с IPSec - 1620

[Tooreagen]

У меня вот есть Микротик, у которого QinQ и работает HW offload

 

 

p.s. Как вы тут цитируете? На какую кнопку не нажму просто скачет страница вверх.

[tcup]

1 hour ago, jffulcrum said:

Если с IPSec - 1620

А без него если?

 

21 minutes ago, Tooreagen said:

 

p.s. Как вы тут цитируете? На какую кнопку не нажму просто скачет страница вверх.

Дефолтную тему форума выбери

[jffulcrum]

54 минуты назад, Tooreagen сказал:

У меня вот есть Микротик, у которого QinQ и работает HW offload

У вас немного другое, tag stacking (ether-type=0x8100). Тоже, в принципе, вариант, но не все железки по пути могут быть способны такое переварить, у некоторых отбрасывает из-за ошибок CRC, т.к. они не в состоянии отделить второй тэг от payload 

 

36 минут назад, tcup сказал:

А без него если?

1592

[MrNv]

делайте eoip туннель и поверх него гоняйте вланы, с mtu не заморачивайтесь, все будет работать

[tcup]

3 hours ago, jffulcrum said:

1592

 Благодарю!

 

3 hours ago, MrNv said:

делайте eoip туннель и поверх него гоняйте вланы, с mtu не заморачивайтесь, все будет работать

Ну вот у нас что-то беда со скоростью туннеля, в 200 Мбит упирается

[Negator]

Посмотрите какой MTU дает транзитный оператор, часто его можно без проблем увеличить

Далее стройте EOIP туннель через любой влан и внутри гоняйте нужные вам вланы до клиента.

Если MTU на транзите пропустит (а оно должно по идее, т.к. провайдер уже дает QinQ) то сразу ставьте повышенное MTU на интерфейсах туннеля с тем учетом чтобы 1500 было внутри туннеля.

Если не пропустит - все то же самое, MTU не трогать, микротик сам соберет пакеты, но будет фрагментация.

На всех нужных интерфейсах есть смысл повесить тестовые сети и посмотреть какой размер пакета пролетит без фрагментации.

 

[sirmax]

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

Посмотрите какой MTU дает транзитный оператор, часто его можно без проблем увеличить

Далее стройте EOIP туннель через любой влан и внутри гоняйте нужные вам вланы до клиента.

Если MTU на транзите пропустит (а оно должно по идее, т.к. провайдер уже дает QinQ) то сразу ставьте повышенное MTU на интерфейсах туннеля с тем учетом чтобы 1500 было внутри туннеля.

Если не пропустит - все то же самое, MTU не трогать, микротик сам соберет пакеты, но будет фрагментация.

На всех нужных интерфейсах есть смысл повесить тестовые сети и посмотреть какой размер пакета пролетит без фрагментации.

 

Возможно тут имеет смысл заморочиться и каждый vlan засунуть в vxlan в отдельный vni растегировав до засовывания и заново тегируя после получения что б сэкономить немного мту 

 

но я не тестировал 

[Saab95]

Поставьте перед каждым клиентом в транзитной сети (после облачка) по маленькому микротику, и собирайте абонентские данные на нем. Тогда не понадобится использование QinQ.

[Tooreagen]

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

Поставьте перед каждым клиентом в транзитной сети (после облачка) по маленькому микротику, и собирайте абонентские данные на нем. Тогда не понадобится использование QinQ.

Честно не совсем понял. Что именно настроить на том маленьком микротике? Как это поможет добавить еще один VLAN клиенту? 

 

Может я немного перефразирую необходимую задачу. Сейчас клиент получает VLAN, гоняет там свой трафик. Теперь нужно этому же клиенту сделать так: ставим новую железяку, на одном порту выдаем ему тот же VLAN, чтобы все работало как и раньше, а на другом порту ему нужно забрать интернет. Т.е. мы дадим еще помимо его служебной сети, интернет. Вот как его туда перегнать из нашей сети? 

 

Ну и еще момент, на железке которая будет на стороне клиента нужно управление, т.е. VLAN с нашей служебной сетью. Наверное все таки без QINQ никак. 

Edited November 18 by Tooreagen
дописал задачу

[Saab95]

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

Ну и еще момент, на железке которая будет на стороне клиента нужно управление, т.е. VLAN с нашей служебной сетью. Наверное все таки без QINQ никак.

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

 

На своей сети ставите где-то микротик и заводите на него влан абонента (что бы не трогать настройки транспорта вланов). У абонента так же ставите микротик и заводите абонентский влан на нем.

 

Далее вешаете IP адресацию свою внутри этого влана и роутингом передаете интернет на свободный порт удаленного микротика.

Можно на эти IP повесить EoIP туннель и прогнать дополнительный L2 канал, сбриджевав его со свободным портом.

Можно вообще внутри абонентского влана передавать свои данные (например влан абонента и еще влан через QinQ с меньшим МТУ), а на удаленном микротике просто разбираете вланы и выдаете в соответствующие порты.

 

Если та сеть в облачке чужая и некий оператор просто предоставляет транспорт вланов, например выдает их штук 100 в центре, и эти 100 вланов потом уходят на разные адреса, где подключены абоненты. То достаточно в этих вланах установить IP адресацию, поставить 100 микротиков, по одному у каждого абонента. И уже на них передавать данные, L2 внутри EoIP туннелей, L3 просто поверх сети. Сразу будет и удаленный доступ с управлением на все устройства.

[Tooreagen]

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

Можно вообще внутри абонентского влана передавать свои данные (например влан абонента и еще влан через QinQ с меньшим МТУ), а на удаленном микротике просто разбираете вланы и выдаете в соответствующие порты.

 

Как это можно сделать, при условии что VLAN проходят через чужую сеть (в облачке)?

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

То достаточно в этих вланах установить IP адресацию

Кстати клиент категорически против того чтобы в его VLAN висели какие-то МАС адреса, а повесив на этот VLAN IP там появятся новые МАС адреса. 

[Saab95]

11 часов назад, Tooreagen сказал:

Как это можно сделать, при условии что VLAN проходят через чужую сеть (в облачке)?

1. У себя на стыке с этой чужой сетью устанавливаете микротик необходимой производительности.

2. Заводите на нем все вланы, которые предоставляются через транспорт чужой сети. Устанавливаете на них серую адресацию /30 или /29, вдруг один влан будет прокидываться на несколько точек клиентов. Например для пропуска своего трафика напрямую, а не от вашего центра.

3. На каждом удаленном стыке устанавливаете по маленькому микротику - RB750, Hex, RB760, RB4011 и т.п. Заводите на нем влан, или оператор его без тега отдает, вешаете второй адрес сети /30 или /29.

4. Между микротиками поднимаете EoIP туннель и передаете трафик абонентов в нем, собственно у себя в центре и на удаленных точках бриджуете вланы.

 

После этого можете передавать любой трафик по сети для абонентов, ведь ограничений на МТУ нет.

 

11 часов назад, Tooreagen сказал:

Кстати клиент категорически против того чтобы в его VLAN висели какие-то МАС адреса, а повесив на этот VLAN IP там появятся новые МАС адреса. 

Если опасаетесь что микротик на EoIP не выдаст нужной нагрузки, можно фильтрами бриджа заблокировать прохождение ваших внутренних мак адресов и IP в сторону абонентских портов, при использовании свич чипа можно на скорости порта лишнее обрезать.

 

Плюсами таких решений - контроль удаленной стороны (есть линк, доступ до микротика), можно проверить скорость, потерю пакетов, отследить состояние абонентского порта и т.п. Можно даже сразу 2-10 абонентов с одного канала подключить.

[Tooreagen]

Ребят, вернусь к своей теме. Вот типичная схема QinQ. Используя 4 микротика можно организовать упаковку, распаковку VLAN. Все ОК. Вопрос, а можно на Mikrotik3 принять QinQ на eth1 и на нем же отдать в SFP1 один VLAN без тега, и в SFP2 другие VLANы тегом? Если можно то как?  

[Saab95]

Можно. Создаете влан QinQ на интерфейсе Eth1, поверх этого влана другие вланы QinQ.

На порту SFP1 создаете нужный влан и снимаете с него метку, а в порт SFP2 отправляете остальные вланы.

 

Как именно это нужно знать что за модель микротика. Если это CRS317 то через настройки вланов на бридже.

[Tooreagen]

Что я делаю не так?

 

Схема: eth1 - SW1 - sfp4 <---QinQ---> sfp4 - SW2 - eth1

 

vlan33 - управление

vlan151 - канал клиента

 

По 33 VLAN проблем нет, доступ есть на оба коммутатора.

По 151 VLAN если поднять интерфейсом на SW2 то доступ есть.

Проблема если сделать на SW2 без тега на eth1 - не работает. 

Ну и соответственно помимо 151 VLAN будет еще несколько, которые нужно будет сделать тегом на другой порт. 

 

Коммутатор №1

# 1970-01-02 05:38:59 by RouterOS 7.14.2
# software id = XL41-YC7I
#
# model = CRS305-1G-4S+
# serial number = HGH09P7T36Q
/interface bridge
add ether-type=0x88a8 name=bridge1 pvid=100 vlan-filtering=yes
/interface vlan
add interface=bridge1 name=vlan33 vlan-id=33
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/interface bridge port
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=sfp-sfpplus4
add bridge=bridge1 interface=ether1 pvid=100 tag-stacking=yes
/interface bridge vlan
add bridge=bridge1 tagged=ether1,bridge1 vlan-ids=33
add bridge=bridge1 tagged=sfp-sfpplus4 vlan-ids=100
add bridge=bridge1 tagged=ether1 vlan-ids=151
/ip address
add address=172.16.16.41/24 interface=vlan33 network=172.16.16.0
/system identity
set name=SW1-QinQ

 

 

Коммутатор №2

# 1970-01-02 04:59:24 by RouterOS 7.14.2
# software id = DRX1-EAGK
#
# model = CRS305-1G-4S+
/interface bridge
add admin-mac=D4:01:C3:C2:F2:BD auto-mac=no ether-type=0x88a8 name=bridge pvid=100 vlan-filtering=yes
/interface vlan
add interface=bridge name=vlan33 vlan-id=33
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/interface bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether1 pvid=151
add bridge=bridge frame-types=admit-only-vlan-tagged interface=sfp-sfpplus4
/interface bridge vlan
add bridge=bridge untagged=ether1 vlan-ids=151
add bridge=bridge tagged=bridge vlan-ids=33
add bridge=bridge tagged=sfp-sfpplus4 vlan-ids=100
/ip address
add address=172.16.16.42/24 interface=vlan33 network=172.16.16.0
/system identity
set name=SW2-QinQ