user_145 Опубликовано 21 августа, 2012 (изменено) · Жалоба Добрый день. Есть в даный момент такая схема: Схема предусматривает использование операторского ВЛАНа. Хочется пробросить через оператор свои ВЛАНы, но оператор слышать не хочет о QinQ. Как я понимаю для классичекой реализации нужно сделать так: Вопрос следующий - возможно ли как-то пробросить свои ВЛАны через оператора не используя PE-свичи? Типа так: Понимаю , что вопрос полуглупый, но ... Свичи Core-Switch1 и Core-Switch2 также поддерживают QinQ. Возможно тут нужна какая-то другая технология ? Изменено 21 августа, 2012 пользователем user_145 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 21 августа, 2012 · Жалоба Если оператор выдаст вам MTU>1500 можно либо отправлять ему уже double tagged кадры либо вообще MPLS. Если оператор дает 1500 максимум - можно поднять l2tp/OpenVPN/EoIP, однако это вызовет фрагментацию, и уменьшит итоговую пропускную способность линка. Так же для MPLS или VPNа в любом случае нужны маршрутизаторы (можно програмные на PC) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 21 августа, 2012 · Жалоба Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_145 Опубликовано 22 августа, 2012 · Жалоба Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель. Вариант. Прошу прощения, но насколько EoIP на Микротике будет "взрослым" решением? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 22 августа, 2012 (изменено) · Жалоба EoIP есть не "взрослое" а единственное решение в данной ситуации. Вернее, не EoIP а любой тоннель с фрагментацией. Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут. Выходов два: 1. На ВСЕХ устройствах сети ограничить MTU до 1496 байт. Как правило, не вариант совершенно. 2. Завернуть это в тоннель, транспортные (внешние) пакеты которого можно фрагментировать. Примеры - микротиковский EoIP, цисковский xconnect ... А микротик - он как линукс. Работает... Хоть и решение не от Крупной Корпорации С Мировым Именем. Дешево и сердито. Изменено 22 августа, 2012 пользователем sol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 22 августа, 2012 · Жалоба Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут. Не всегда верно. Возможно оконечное оборудование оператора вроде бы Jumbo фреймы пропускает, но режима dot1q-tunnel не имеет, и тогда проблема вовсе не в MTU, а всего лишь в "тупом" доступе Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 22 августа, 2012 · Жалоба Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель. Вариант. Прошу прощения, но насколько EoIP на Микротике будет "взрослым" решением? Решение на микротике вполне взрослое и зря его не дооценивают. По функционалу он иногда и циску переплевывает, а по отношению цена/возможности - любого производителя сетевого оборудования. Конкретно по RB2011L - в EoIP туннеле он может пропустить порядка 400 мегабит трафика. Пакетная производительность около 200 000 пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 22 августа, 2012 · Жалоба Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут. Не всегда верно. Возможно оконечное оборудование оператора вроде бы Jumbo фреймы пропускает, но режима dot1q-tunnel не имеет, и тогда проблема вовсе не в MTU, а всего лишь в "тупом" доступе Это как? И причем тут чисто гиговое явление Jumbo Frame? И зачем на железе dot1q-tunnel, если большие пакеты пролезают? Чем Double Tagget пакет отличается от простого пакета? Предлагаю скурить формат такого пакета из педивикии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 августа, 2012 · Жалоба Почитайте вику. Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно. Другое дело как оно настроено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 22 августа, 2012 (изменено) · Жалоба Это как? И причем тут чисто гиговое явление Jumbo Frame? И зачем на железе dot1q-tunnel, если большие пакеты пролезают? Чем Double Tagget пакет отличается от простого пакета? Предлагаю скурить формат такого пакета из педивикии. Под Jumbo frame я имел ввиду фрейм размером размером более 1500Байт. Double tagged пакет отличается от обычного ровно одним, вторым тегом 802.1q. Класисеческая схема предоставления сервиса QinQ как раз таки предполагает, что сеть оператора абсолютно прозрачна для абонента и абонент обычным транком отдается оператору. Оператор же в свою очередь, на своем PE навешивает второй тег. В терминологиии Cisco, это режим работы порта dot1q-tunnel, есть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег. Соответственно user_145 я предложил сначала узнать а в MTU ли дело, вот и все. Надеюсь так понятнее. Изменено 22 августа, 2012 пользователем dazgluk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 августа, 2012 · Жалоба 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). Вся это микротиковская и прочая хрень - это крайний случай, костыль, если большие пакеты не пролазят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 22 августа, 2012 · Жалоба Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно. А можно ссылочку на источник или полную цитату? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 22 августа, 2012 · Жалоба сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег. Так не бывает. . Вот предлагаемый к скуриванию формат кадра при навеске первого тега и второго. Коммутатор НЕ ЛЕЗЕТ дальше заголовка. Это ему незачем. А _заголовки_ у всех этих трех видов пакетов совершенно одинаковые. Преамбула, МАК назначения, МАК источника, Тип энкапсулированного протокола (Эзертайп)/размер, Полезная нагрузка переменной длинны, Контрольная сумма. С точки зрения любого коммутатора, пакет с эзертайпом 0х8100 - это просто пакет. И только с точки зрения коммутатора, который ХОЧЕТ разобрать виланы - за полем Тип протокола = 0х8100 идет не Полезная Нагрузка, в два волшебных байта, в которых 3 бита - тип сервиса, 1 бит - легаси и 12 бит - тег. Для всех остальных коммутаторов - это просто пакет-переросток со странным типом протокола не привычный IP = 0х0800 а какой-то странный _НО_ВПОЛНЕ_ДОПУСТИМЫЙ 0х8100. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 22 августа, 2012 · Жалоба сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег. Так не бывает. Cisco 2960 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 августа, 2012 · Жалоба Так не бывает. Вполне себе бывает. Есть куча железа с поддержкой JF (т.е. фреймы до 9К) но неумеющего принятый траффик с тегом упаковывать в еще один влан. Хотя если ему на порт уже подать qinq - оно прекрасно пережует трафик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 августа, 2012 · Жалоба Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно. А можно ссылочку на источник или полную цитату? он теоретик. да, почти всё современное управляемое сетевое оборудование МОЖЕТ пропустить 1536(само значение 1536(или около того) это max mtu для cisco 2950 или подобных "старичков"), но по умолчанию(что весьма важно) современное оборудование пропускает 1500 на L3 (1514/1518 на L2) и (опять же) по умолчанию фрейм с 1500 на L3 и двумя vlan-тегами не проходит автору - договориваться не на Q-in-Q(когда оператор заворачивает во свой теги ваши(или делает тунель порт-порт)), а на поднятие mtu, при этом навешивать вторую метку самому Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 августа, 2012 · Жалоба А можно ссылочку на источник или полную цитату? Про размер: MAC_CFG Address: 0x00817: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. В остальном, это либо недоработка прошивки/чипа либо так оно настроено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eill Опубликовано 22 августа, 2012 · Жалоба джамбо фрейм относится к сугубо гигабитным линкам? Это как? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 августа, 2012 · Жалоба джамбо фрейм относится к сугубо гигабитным линкам? Это как? это попытка навязать свою терминологию, игнорирую общепризнанную 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) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 23 августа, 2012 · Жалоба Не видел ни одного такого свитча, хотя 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 это гигантский :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OlegStr Опубликовано 23 августа, 2012 · Жалоба как вариант, можно попробовать настроить Selective QinQ для передачи нескольких VLAN поверх transit VLAN , при этом транзитный провайдер не будет знать о клиентских VLAN , но ,скорее всего, будут недоступны по управлению в management VLAN клиентские коммутаторы (можно попробовать настроить управление в transit VLAN) или ,действительно, EoIP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 23 августа, 2012 · Жалоба Не видел ни одного такого свитча, хотя 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) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...