user_145 Posted August 21, 2012 (edited) · Report post Добрый день. Есть в даный момент такая схема: Схема предусматривает использование операторского ВЛАНа. Хочется пробросить через оператор свои ВЛАНы, но оператор слышать не хочет о QinQ. Как я понимаю для классичекой реализации нужно сделать так: Вопрос следующий - возможно ли как-то пробросить свои ВЛАны через оператора не используя PE-свичи? Типа так: Понимаю , что вопрос полуглупый, но ... Свичи Core-Switch1 и Core-Switch2 также поддерживают QinQ. Возможно тут нужна какая-то другая технология ? Edited August 21, 2012 by user_145 Share this post Link to post Share on other sites
dazgluk Posted August 21, 2012 · Report post Если оператор выдаст вам MTU>1500 можно либо отправлять ему уже double tagged кадры либо вообще MPLS. Если оператор дает 1500 максимум - можно поднять l2tp/OpenVPN/EoIP, однако это вызовет фрагментацию, и уменьшит итоговую пропускную способность линка. Так же для MPLS или VPNа в любом случае нужны маршрутизаторы (можно програмные на PC) Share this post Link to post Share on other sites
Saab95 Posted August 21, 2012 · Report post Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель. Share this post Link to post Share on other sites
user_145 Posted August 22, 2012 · Report post Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель. Вариант. Прошу прощения, но насколько EoIP на Микротике будет "взрослым" решением? Share this post Link to post Share on other sites
sol Posted August 22, 2012 (edited) · Report post EoIP есть не "взрослое" а единственное решение в данной ситуации. Вернее, не EoIP а любой тоннель с фрагментацией. Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут. Выходов два: 1. На ВСЕХ устройствах сети ограничить MTU до 1496 байт. Как правило, не вариант совершенно. 2. Завернуть это в тоннель, транспортные (внешние) пакеты которого можно фрагментировать. Примеры - микротиковский EoIP, цисковский xconnect ... А микротик - он как линукс. Работает... Хоть и решение не от Крупной Корпорации С Мировым Именем. Дешево и сердито. Edited August 22, 2012 by sol Share this post Link to post Share on other sites
dazgluk Posted August 22, 2012 · Report post Отказ "дать QinQ" _технически_ означает отказ пропускать пакеты больше, чем 1500 октетов. Пакет-же с dot1Q внутри имеет размер +4 октета. Т.е. минимальный размер пакета не 64 октета, а 68 и максимальный не 1500 а 1504 октета. Вот самые большие и не пролезут. Не всегда верно. Возможно оконечное оборудование оператора вроде бы Jumbo фреймы пропускает, но режима dot1q-tunnel не имеет, и тогда проблема вовсе не в MTU, а всего лишь в "тупом" доступе Share this post Link to post Share on other sites
Saab95 Posted August 22, 2012 · Report post Очень удобно подойдут 2 микротика RB2011LS-IN, оптическим портом подключите к провайдеру, и прогоните сколько вам надо вланов через EoIP или MPLS/VPLS туннель. Вариант. Прошу прощения, но насколько EoIP на Микротике будет "взрослым" решением? Решение на микротике вполне взрослое и зря его не дооценивают. По функционалу он иногда и циску переплевывает, а по отношению цена/возможности - любого производителя сетевого оборудования. Конкретно по RB2011L - в EoIP туннеле он может пропустить порядка 400 мегабит трафика. Пакетная производительность около 200 000 пакетов. Share this post Link to post Share on other sites
sol Posted August 22, 2012 · Report post Отказ "дать 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
Ivan_83 Posted August 22, 2012 · Report post Почитайте вику. Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно. Другое дело как оно настроено. Share this post Link to post Share on other sites
dazgluk Posted August 22, 2012 (edited) · Report post Это как? И причем тут чисто гиговое явление 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 Share this post Link to post Share on other sites
Ivan_83 Posted August 22, 2012 · Report post 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
nnm Posted August 22, 2012 · Report post Современное оборудование должно пропускать по 1536 байт кадры (это с црц и заголовком), места для инкапсуляции там полно. А можно ссылочку на источник или полную цитату? Share this post Link to post Share on other sites
sol Posted August 22, 2012 · Report post сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег. Так не бывает. . Вот предлагаемый к скуриванию формат кадра при навеске первого тега и второго. Коммутатор НЕ ЛЕЗЕТ дальше заголовка. Это ему незачем. А _заголовки_ у всех этих трех видов пакетов совершенно одинаковые. Преамбула, МАК назначения, МАК источника, Тип энкапсулированного протокола (Эзертайп)/размер, Полезная нагрузка переменной длинны, Контрольная сумма. С точки зрения любого коммутатора, пакет с эзертайпом 0х8100 - это просто пакет. И только с точки зрения коммутатора, который ХОЧЕТ разобрать виланы - за полем Тип протокола = 0х8100 идет не Полезная Нагрузка, в два волшебных байта, в которых 3 бита - тип сервиса, 1 бит - легаси и 12 бит - тег. Для всех остальных коммутаторов - это просто пакет-переросток со странным типом протокола не привычный IP = 0х0800 а какой-то странный _НО_ВПОЛНЕ_ДОПУСТИМЫЙ 0х8100. Share this post Link to post Share on other sites
nnm Posted August 22, 2012 · Report post сть оборудование которое умеет фреймы >1500 но не умеет паковать транки во второй тег. Так не бывает. Cisco 2960 Share this post Link to post Share on other sites
NiTr0 Posted August 22, 2012 · Report post Так не бывает. Вполне себе бывает. Есть куча железа с поддержкой JF (т.е. фреймы до 9К) но неумеющего принятый траффик с тегом упаковывать в еще один влан. Хотя если ему на порт уже подать qinq - оно прекрасно пережует трафик. Share this post Link to post Share on other sites
s.lobanov Posted August 22, 2012 · Report post Современное оборудование должно пропускать по 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
Ivan_83 Posted August 22, 2012 · Report post А можно ссылочку на источник или полную цитату? Про размер: 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. В остальном, это либо недоработка прошивки/чипа либо так оно настроено. Share this post Link to post Share on other sites
eill Posted August 22, 2012 · Report post джамбо фрейм относится к сугубо гигабитным линкам? Это как? Share this post Link to post Share on other sites
s.lobanov Posted August 22, 2012 · Report post джамбо фрейм относится к сугубо гигабитным линкам? Это как? это попытка навязать свою терминологию, игнорирую общепризнанную 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
Ivan_83 Posted August 23, 2012 · Report post Не видел ни одного такого свитча, хотя 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
OlegStr Posted August 23, 2012 · Report post как вариант, можно попробовать настроить Selective QinQ для передачи нескольких VLAN поверх transit VLAN , при этом транзитный провайдер не будет знать о клиентских VLAN , но ,скорее всего, будут недоступны по управлению в management VLAN клиентские коммутаторы (можно попробовать настроить управление в transit VLAN) или ,действительно, EoIP Share this post Link to post Share on other sites
s.lobanov Posted August 23, 2012 · Report post Не видел ни одного такого свитча, хотя 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