[user_145]

Добрый день.

Есть в даный момент такая схема:

 

 

Схема предусматривает использование операторского ВЛАНа.

 

Хочется пробросить через оператор свои ВЛАНы, но оператор слышать не хочет о QinQ.

Как я понимаю для классичекой реализации нужно сделать так:

 

 

Вопрос следующий - возможно ли как-то пробросить свои ВЛАны через оператора не используя PE-свичи?

Типа так:

 

 

Понимаю , что вопрос полуглупый, но ...

Свичи Core-Switch1 и Core-Switch2 также поддерживают QinQ.

Возможно тут нужна какая-то другая технология ?

Edited August 21, 2012 by user_145

[dazgluk]

Если оператор выдаст вам MTU>1500 можно либо отправлять ему уже double tagged кадры либо вообще MPLS.

 

Если оператор дает 1500 максимум - можно поднять l2tp/OpenVPN/EoIP, однако это вызовет фрагментацию, и уменьшит итоговую пропускную способность линка.

Так же для MPLS или VPNа в любом случае нужны маршрутизаторы (можно програмные на PC)

[Saab95]

Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель.

 

 

[user_145]

Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель.

Вариант.

Прошу прощения, но насколько EoIP на Микротике будет "взрослым" решением?

[sol]

EoIP есть не "взрослое" а единственное решение в данной ситуации. Вернее, не EoIP а любой тоннель с фрагментацией.

 

Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут.

 

Выходов два:

1. На ВСЕХ устройствах сети ограничить MTU до 1496 байт. Как правило, не вариант совершенно.

2. Завернуть это в тоннель, транспортные (внешние) пакеты которого можно фрагментировать. Примеры - микротиковский EoIP, цисковский xconnect ...

 

А микротик - он как линукс. Работает... Хоть и решение не от Крупной Корпорации С Мировым Именем. Дешево и сердито.

Edited August 22, 2012 by sol

[dazgluk]

Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут.

 

Не всегда верно.

Возможно оконечное оборудование оператора вроде бы Jumbo фреймы пропускает, но режима dot1q-tunnel не имеет, и тогда проблема вовсе не в MTU, а всего лишь в "тупом" доступе

[Saab95]

Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель.

Вариант.

Прошу прощения, но насколько EoIP на Микротике будет "взрослым" решением?

 

Решение на микротике вполне взрослое и зря его не дооценивают. По функционалу он иногда и циску переплевывает, а по отношению цена/возможности - любого производителя сетевого оборудования.

 

Конкретно по RB2011L - в EoIP туннеле он может пропустить порядка 400 мегабит трафика. Пакетная производительность около 200 000 пакетов.

[sol]

Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут.

 

Не всегда верно.

Возможно оконечное оборудование оператора вроде бы Jumbo фреймы пропускает, но режима dot1q-tunnel не имеет, и тогда проблема вовсе не в MTU, а всего лишь в "тупом" доступе

 

Это как? И причем тут чисто гиговое явление Jumbo Frame? И зачем на железе dot1q-tunnel, если большие пакеты пролезают? Чем Double Tagget пакет отличается от простого пакета? Предлагаю скурить формат такого пакета из педивикии.

[Ivan_83]

Почитайте вику.

Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно.

Другое дело как оно настроено.

[dazgluk]

 

Это как? И причем тут чисто гиговое явление Jumbo Frame? И зачем на железе dot1q-tunnel, если большие пакеты пролезают? Чем Double Tagget пакет отличается от простого пакета? Предлагаю скурить формат такого пакета из педивикии.

Под Jumbo frame я имел ввиду фрейм размером размером более 1500Байт.

Double tagged пакет отличается от обычного ровно одним, вторым тегом 802.1q. Класисеческая схема предоставления сервиса QinQ как раз таки предполагает, что сеть оператора абсолютно прозрачна для абонента и абонент обычным транком отдается оператору. Оператор же в свою очередь, на своем PE навешивает второй тег. В терминологиии Cisco, это режим работы порта dot1q-tunnel, есть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег. Соответственно user_145 я предложил сначала узнать а в MTU ли дело, вот и все.

Надеюсь так понятнее.

Edited August 22, 2012 by dazgluk

[Ivan_83]

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

 

Когда оператор отдаёт клиенту влан, то подразумевается что отдаётся эзернет порт в 2 и более точках и они типа воткнуты в один свич (типа виртуальный, вообщем пакеты ходят между всеми портами).

Что посылает в эти порты клиент - его личное дело.

Если туда идёт тэгированный клиентский трафик то он таким же и должен появляться на всех остальных портах купленных у оператора.

Технически, для коммутаторов, тэгированный пакет от IP (и прочих) отличается только номером в заголовке, и коммутатор не должен вдаватся в подробности содержимого а просто заменяет его на номер инкапсуляции, дописывает номер влана и сохраняет оригинал и шлёт дальше.

 

Те я бы на месте клиента:

- поигрался с mtu и выяснил насколько большие пакеты проходят;

- попробовал просто пропустить свой тэгированный трафик;

- если пакеты достаточного размера проходят а тэгированный трафик нет - поставил бы другой номер инкапсуляции для тэгов (это умеют коммутаторы и freebsd + ng_patch либо обновлённой ng_vlan: http://www.netlab.linkpc.net/forum/index.php?topic=781.0 (либо в 10 ветке)).

 

1500 данные + 6*2+2+4 = 1518

+ 4 = 1522 (ваша инкапсуляция)

+ 4 = 1526 (операторская инкапсуляция)

и остаётся на ещё один тэг и ещё немного (до 1536).

 

Вся это микротиковская и прочая хрень - это крайний случай, костыль, если большие пакеты не пролазят.

[nnm]

Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно.

 

А можно ссылочку на источник или полную цитату?

[sol]

сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег.

 

Так не бывает.

.

Вот предлагаемый к скуриванию формат кадра при навеске первого тега и второго. Коммутатор НЕ ЛЕЗЕТ дальше заголовка. Это ему незачем. А _заголовки_ у всех этих трех видов пакетов совершенно одинаковые. Преамбула, МАК назначения, МАК источника, Тип энкапсулированного протокола (Эзертайп)/размер, Полезная нагрузка переменной длинны, Контрольная сумма. С точки зрения любого коммутатора, пакет с эзертайпом 0х8100 - это просто пакет. И только с точки зрения коммутатора, который ХОЧЕТ разобрать виланы - за полем Тип протокола = 0х8100 идет не Полезная Нагрузка, в два волшебных байта, в которых 3 бита - тип сервиса, 1 бит - легаси и 12 бит - тег. Для всех остальных коммутаторов - это просто пакет-переросток со странным типом протокола не привычный IP = 0х0800 а какой-то странный _НО_ВПОЛНЕ_ДОПУСТИМЫЙ 0х8100.

[nnm]

сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег.

 

Так не бывает.

 

Cisco 2960

[NiTr0]

Так не бывает.

Вполне себе бывает. Есть куча железа с поддержкой JF (т.е. фреймы до 9К) но неумеющего принятый траффик с тегом упаковывать в еще один влан. Хотя если ему на порт уже подать qinq - оно прекрасно пережует трафик.

[s.lobanov]

Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно.

 

А можно ссылочку на источник или полную цитату?

 

он теоретик. да, почти всё современное управляемое сетевое оборудование МОЖЕТ пропустить 1536(само значение 1536(или около того) это max mtu для cisco 2950 или подобных "старичков"), но по умолчанию(что весьма важно) современное оборудование пропускает 1500 на L3 (1514/1518 на L2) и (опять же) по умолчанию фрейм с 1500 на L3 и двумя vlan-тегами не проходит

 

автору - договориваться не на Q-in-Q(когда оператор заворачивает во свой теги ваши(или делает тунель порт-порт)), а на поднятие mtu, при этом навешивать вторую метку самому

[Ivan_83]

А можно ссылочку на источник или полную цитату?

Про размер:

MAC_CFG Address: 0x008

17:16 RW max_len

Maximum Packet Length.

0: 1518 bytes.

1: 1522 bytes.

2: 1536 bytes

Из доки на Equuleus: CNS213X/CNS218X (STR813X/STR818X)

Аналогичные значения для размера пакета у ралинк RT3050/52 в датащите.

 

он теоретик.

Я меньше с железом (свчичами) вожусь и больше в потрохах ОС и протоколов.

 

да, почти всё современное управляемое сетевое оборудование МОЖЕТ пропустить 1536(само значение 1536(или около того) это max mtu для cisco 2950 или подобных "старичков"), но по умолчанию(что весьма важно) современное оборудование пропускает 1500 на L3 (1514/1518 на L2) и (опять же) по умолчанию фрейм с 1500 на L3 и двумя vlan-тегами не проходит

Не у всех железок mtu тюнится, соответственно у тех что не тюнится, подозреваю что, стоит максимум из датащита на чип.

 

Вполне себе бывает. Есть куча железа с поддержкой JF (т.е. фреймы до 9К) но неумеющего принятый траффик с тегом упаковывать в еще один влан. Хотя если ему на порт уже подать qinq - оно прекрасно пережует трафик.

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

В остальном, это либо недоработка прошивки/чипа либо так оно настроено.

[eill]

джамбо фрейм относится к сугубо гигабитным линкам? Это как?

[s.lobanov]

джамбо фрейм относится к сугубо гигабитным линкам? Это как?

 

это попытка навязать свою терминологию, игнорирую общепризнанную

 

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml#backinfo1

Jumbo frames are frames that are bigger than the standard Ethernet frame size, which is 1518 bytes (including Layer 2 (L2) header and FCS).

 

http://en.wikipedia.org/wiki/Jumbo_frame

jumbo frames are Ethernet frames with more than 1500 bytes of payload.

 

да, почти всё современное управляемое сетевое оборудование МОЖЕТ пропустить 1536(само значение 1536(или около того) это max mtu для cisco 2950 или подобных "старичков"), но по умолчанию(что весьма важно) современное оборудование пропускает 1500 на L3 (1514/1518 на L2) и (опять же) по умолчанию фрейм с 1500 на L3 и двумя vlan-тегами не проходит

Не у всех железок mtu тюнится, соответственно у тех что не тюнится, подозреваю что, стоит максимум из датащита на чип.

 

Не видел ни одного такого свитча, хотя L2(+) барахла различного повидал ОЧЕНЬ много.

 

Всё что видел - либо mtu конфигурируется, либо 1518(L2)

[Ivan_83]

Не видел ни одного такого свитча, хотя L2(+) барахла различного повидал ОЧЕНЬ много. Всё что видел - либо mtu конфигурируется, либо 1518(L2)

Из мануалов

DES-3526: 1522

DES-1228ME: 1522

DES-3200: 1536

DGS-1210: 1536

D-Link Gigabit Web Smart Switches support jumbo frames (frames larger than the Ethernet frame size of

1536 bytes) of up to 10,000 bytes (tagged)

Это к вопросу об общепринятой терминологии - не я один такой.

Не знал что 1522 обычный а 1536 это гигантский :)

[OlegStr]

как вариант, можно попробовать настроить Selective QinQ для передачи нескольких VLAN поверх transit VLAN , при этом транзитный провайдер не будет знать о клиентских VLAN , но ,скорее всего, будут недоступны по управлению в management VLAN клиентские коммутаторы (можно попробовать настроить управление в transit VLAN) или ,действительно, EoIP

[s.lobanov]

Не видел ни одного такого свитча, хотя L2(+) барахла различного повидал ОЧЕНЬ много. Всё что видел - либо mtu конфигурируется, либо 1518(L2)

Из мануалов

DES-3526: 1522

DES-1228ME: 1522

DES-3200: 1536

DGS-1210: 1536

D-Link Gigabit Web Smart Switches support jumbo frames (frames larger than the Ethernet frame size of

1536 bytes) of up to 10,000 bytes (tagged)

Это к вопросу об общепринятой терминологии - не я один такой.

Не знал что 1522 обычный а 1536 это гигантский :)

 

так не секрет, что d-link называет всё через 5ое место. один только dhcp screening чего стоит(ну не признают они устоявшиеся названия фич)

 

по поводу mtu решил посмотреть что они там навертели, в разных манах написано по разному(хотя может быть что у poe и non-poe свитчей оно действительно разное), т.е. надо смотреть что в самом, в любом случае у них 2 режима (jumbo enable/disable), т.е. эта опция конфигурится

 

и да, 1522 это тоже jumbo, точнее baby giant frame(разновидность jumbo)