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

QinQ - как реализовать фантазия на тему

Добрый день.

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

 

post-42673-028367500 1345554189_thumb.jpg

 

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

 

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

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

 

post-42673-024688500 1345554300_thumb.jpg

 

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

Типа так:

 

post-42673-008038800 1345554362_thumb.jpg

 

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

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

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

Edited by user_145

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

Вариант.

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

Share this post


Link to post
Share on other sites

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

 

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

 

Выходов два:

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

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

 

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

Edited by sol

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

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

Вариант.

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

 

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

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

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

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

Edited by dazgluk

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег.

 

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

.TCPIP_802.1ad_DoubleTag.jpg

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

Share this post


Link to post
Share on other sites
сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег.

 

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

 

Cisco 2960

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
А можно ссылочку на источник или полную цитату?

Про размер:

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.

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

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)

Share this post


Link to post
Share on other sites
Не видел ни одного такого свитча, хотя 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 это гигантский :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Не видел ни одного такого свитча, хотя 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)

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
Sign in to follow this