stingerrr Опубликовано 25 августа, 2009 · Жалоба Коллеги есть небольшой субпровайдер у которого не везде есть свой транспорт. Там где нет своего транспорта у другова провайдера берется услуга VPLS. Задача предоставлять клиентам услугу VPLS даже там где нет своего транспорта. Возможно ли в принципе построить VPLS over VPLS? Если да какие требования нужно предъявить к провайдеру верхнего уровня. У меня еще будут несколько вопросов по оборудованию, но к ним я вернусь позже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 25 августа, 2009 (изменено) · Жалоба Коллеги есть небольшой субпровайдер у которого не везде есть свой транспорт. Там где нет своего транспорта у другова провайдера берется услуга VPLS. Задача предоставлять клиентам услугу VPLS даже там где нет своего транспорта. Возможно ли в принципе построить VPLS over VPLS? Если да какие требования нужно предъявить к провайдеру верхнего уровня. У меня еще будут несколько вопросов по оборудованию, но к ним я вернусь позже. А можно поинтересоваться - что Вы вкладываете в понятие "VPLS over VPLS", только без умных теоретических терминов, а по рабоче-крестьянски, т.е. на пальцах? Типа "для того-то, того-то и того-то....". Просто про "предоставлять клиентам услугу VPLS" мне не совсем понятно, что б вам что-то присоветовать. ЗЫ. у нас vpls. Изменено 25 августа, 2009 пользователем Konstantin Klimchev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 25 августа, 2009 · Жалоба Можно, потенциальные проблемы: - mtu - параллельные в сети этого провайдера - при их наличии весь (ну или не весь, зависит от топологии вашей сети) ваш трафик будет ложиться только в один из них - QoS - возможно несоответствие вашего и ихнего Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stingerrr Опубликовано 25 августа, 2009 · Жалоба А можно поинтересоваться - что Вы вкладываете в понятие "VPLS over VPLS", только без умных теоретических терминов, а по рабоче-крестьянски, т.е. на пальцах? ЗЫ. у нас vpls. Попробую объяснить представьте, вы маленький провайдер у вас нет своего транспорта и вы покупаете L2 транспорт не физику, не лямбды ... а попросту говоря ethernet у другова провайдера. Допустим у вас есть 7 городов A, D, C , D , E , F, G ... Через сеть верхнего провайдера все ваши точки без проблем видят друг друга, т.е. вы купили услугу vpls. Далее вы находи клиента, который просит, а нука соедини мне точки в городах A,B,C,F да так что бы они были как будто подключены в один свитч ... Вот из этого и родился термин VPLS over VPLS … Можно, потенциальные проблемы: - mtu - параллельные в сети этого провайдера - при их наличии весь (ну или не весь, зависит от топологии вашей сети) ваш трафик будет ложиться только в один из них - QoS - возможно несоответствие вашего и ихнего Насчет проблем согласен. QoS в принципе несамая большая, можно продовать услугу качеством похуже чем покупаеш ... Но вот с mtu дела похуже ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 25 августа, 2009 (изменено) · Жалоба А можно поинтересоваться - что Вы вкладываете в понятие "VPLS over VPLS", только без умных теоретических терминов, а по рабоче-крестьянски, т.е. на пальцах? ЗЫ. у нас vpls. Попробую объяснить представьте, вы маленький провайдер у вас нет своего транспорта и вы покупаете L2 транспорт не физику, не лямбды ... а попросту говоря ethernet у другова провайдера. Допустим у вас есть 7 городов A, D, C , D , E , F, G ... Через сеть верхнего провайдера все ваши точки без проблем видят друг друга, т.е. вы купили услугу vpls. Далее вы находи клиента, который просит, а нука соедини мне точки в городах A,B,C,F да так что бы они были как будто подключены в один свитч ... Вот из этого и родился термин VPLS over VPLS … 1) Выскажу лично мнение - VPLS это MEN-услуга. Раз у вас разговор про "есть 7 городов" - это правильнее MPLS L3 VPN. 2) Второй момент: вам все таки нужен VPLS over VPLS (если все-таки вы на L2 решили остаться). Возьмите у оператора Ethernet Multipoint Service (EMS). EMS для этого и придуман на мой взгляд (Субпровайдерство). Если первичный вам не может предложить EMS (дает только ERMS) - тогда п.1 Либо горсть ERMS'ов: для каждого абонента своя. PS. я говорю в терминологии cisco (я про расширенную трактовку MEF), у jun'а она может отличаться - я тут не знаю. PPS. про услуги было тут: http://www.nag.ru/2005/0212/0212.shtml Так сказать: простенько и со вкусом Изменено 25 августа, 2009 пользователем Konstantin Klimchev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stingerrr Опубликовано 25 августа, 2009 · Жалоба А можно поинтересоваться - что Вы вкладываете в понятие "VPLS over VPLS", только без умных теоретических терминов, а по рабоче-крестьянски, т.е. на пальцах? ЗЫ. у нас vpls. Попробую объяснить представьте, вы маленький провайдер у вас нет своего транспорта и вы покупаете L2 транспорт не физику, не лямбды ... а попросту говоря ethernet у другова провайдера. Допустим у вас есть 7 городов A, D, C , D , E , F, G ... Через сеть верхнего провайдера все ваши точки без проблем видят друг друга, т.е. вы купили услугу vpls. Далее вы находи клиента, который просит, а нука соедини мне точки в городах A,B,C,F да так что бы они были как будто подключены в один свитч ... Вот из этого и родился термин VPLS over VPLS … 1) Выскажу лично мнение - VPLS это MEN-услуга. Раз у вас разговор про "есть 7 городов" - это правильнее MPLS L3 VPN. 2) Второй момент: вам все таки нужен VPLS over VPLS (если все-таки вы на L2 решили остаться). Возьмите у оператора Ethernet Multipoint Service (EMS). EMS для этого и придуман на мой взгляд (Субпровайдерство). Если первичный вам не может предложить EMS (дает только ERMS) - тогда п.1 Либо горсть ERMS'ов: для каждого абонента своя. PS. я говорю в терминологии cisco (я про расширенную трактовку MEF), у jun'а она может отличаться - я тут не знаю. PPS. про услуги было тут: http://www.nag.ru/2005/0212/0212.shtml Так сказать: простенько и со вкусом Что я не совсем понял... 7 городов это я так для примера Нужен L2 сервис. Я в этой области не силен поэтому попрошу вас на пальцах обьяснить разницу между EMS и ERMS. Наверно глупый вопрос... Чисто визуально port-based E-LAN --- VLAN-based E-LAN .... •Ethernet Multipoint Service (EMS)—A multipoint-to-multipoint port-based E-LAN service that is used for transparent LAN applications. •Ethernet Relay Multipoint Service (ERMS)—A multipoint-to-multipoint VLAN-based E-LAN service that is used primarily for establishing a multipoint-to-multipoint connection between customer routers. Если я правильно понял, берем услугу EMS и далие поверх нее строим все что душе угодно ... Тут появилась еще одна мысль через EMS 802.1q можно прокинуть прокинуть?? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 25 августа, 2009 (изменено) · Жалоба Я в этой области не силен поэтому попрошу вас на пальцах обьяснить разницу между EMS и ERMS. Наверно глупый вопрос... Ну если на пальцах: в EMS провайдер даст вам тегированный трафик гонять + BPDUшки, а в ERMS - нет. Если я правильно понял, берем услугу EMS и далие поверх нее строим все что душе угодно ... не поверх, в внутри, но это дело вкуса как говорить.... Тут появилась еще одна мысль через EMS 802.1q можно прокинуть прокинуть?? Ну дык для этого оно и придумано - чтоб vlan'ы гонять. А по правильному оно и еще и твои BPDUшки "прокидывать" должно. Но тут - а даст ли провайдер такое? Нужно не умными фразами к нему, а просто спросить: а дадите QinQшные порты? а как оно будет у него реализовано - не должно вас волновать. Изменено 25 августа, 2009 пользователем Konstantin Klimchev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 26 августа, 2009 · Жалоба Если даст вам JumboFrame гонять, то сделаете все что угодно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 26 августа, 2009 · Жалоба stingerrr, если фраза "нет своего транспорта", означает физическое отсутствие вас в данном регионе, то не имеет большого смысла думать над вопросом vpls over vpls, т.к. вам придется размещать дорогостоящее оборудование рядом с клиентами, запускать на нем vpls, и, по сути, пробрасывать свой mpls через его mpls. (туннелировать можно и не только через mpls, но это не суть) Кроме этого, как тут уже сказали, jumbo фреймы вас конечно спасут, вот только цискины гайды пестрят примерами выставления mtu на пределе, т.е. закладывают свои метки, теги и все, чужих не пущать. Экономически выгоднее состыковаться с нужным вам провайдером транковым портом в точке присутствия вас обоих и затем у этого провайдера заказывать отдельный vpls под каждого клиента. Еще более выгодно, заказать у провайдера один vpls, и расставить в нужных точках присутствия свитчи умеющие q-in-q. Тогда платить будете за один vpls, а клиентов в точке стыковки разделять по верхнему тегу в пакете. Минусом, понятно идет некое влияние одних на других в этом случае. Важный вопрос, это количество мак адресов предоставляемых провайдером в точке подключения и во всем vpls. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stingerrr Опубликовано 26 августа, 2009 · Жалоба stingerrr, если фраза "нет своего транспорта", означает физическое отсутствие вас в данном регионе, то не имеет большого смысла думать над вопросом vpls over vpls, т.к. вам придется размещать дорогостоящее оборудование рядом с клиентами, запускать на нем vpls, и, по сути, пробрасывать свой mpls через его mpls. (туннелировать можно и не только через mpls, но это не суть)Кроме этого, как тут уже сказали, jumbo фреймы вас конечно спасут, вот только цискины гайды пестрят примерами выставления mtu на пределе, т.е. закладывают свои метки, теги и все, чужих не пущать. Экономически выгоднее состыковаться с нужным вам провайдером транковым портом в точке присутствия вас обоих и затем у этого провайдера заказывать отдельный vpls под каждого клиента. Еще более выгодно, заказать у провайдера один vpls, и расставить в нужных точках присутствия свитчи умеющие q-in-q. Тогда платить будете за один vpls, а клиентов в точке стыковки разделять по верхнему тегу в пакете. Минусом, понятно идет некое влияние одних на других в этом случае. Важный вопрос, это количество мак адресов предоставляемых провайдером в точке подключения и во всем vpls. Спасибо за совет. Мне тоже нравится идея с q-in-q. Но в голове есть не большой сумбур по поводу данной технологии (q-in-q) . Может быть, дите ссылку, где по подробней описан q-in-q. И еще вопрос какие свичи с поддержкой q-in-q порекомендуете. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nikolaicheg Опубликовано 26 августа, 2009 · Жалоба И еще вопрос какие свичи с поддержкой q-in-q порекомендуете. это не вам надо оборудование такое, а оператору, у которого вы будете брать каналы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 26 августа, 2009 · Жалоба ЗЫ. у нас vpls. ES10 в ядре? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 26 августа, 2009 · Жалоба ЗЫ. у нас vpls. ES10 в ядре? ES20, 10-х на сколько я знаю не бывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 26 августа, 2009 · Жалоба ЗЫ. у нас vpls. ES10 в ядре? ES20, 10-х на сколько я знаю не бывает. ага точно склероз - а вниз в сторону клиентов что стоит если не секрет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ghost Опубликовано 26 августа, 2009 · Жалоба 1. L2 over IP вам может помочь. По ресурсам эт конечно накладно, но выход. 2. Если оборудование вышестоящего пропустит - для etherneta Q-in-Q специально придумали. 3. если сеть вышестоящего прова НЕ MPLS - то можете попробовать у себя MPLS поднять и AToM (в терминах cisco) в него запихать. Итого: вариант 1 - большая нагрузка на железо и высокий оверхед (для проброса 2-х мегабит потребуется от 2,1Мбит и более, чем меньше размеры фреймов - тем большая разница скоростей), но проблем с MTU нет, т.к. (если только DF бит на свои пакеты не поставите) подобные проблемы отработает IP протокол. вариант 2 - вышестоящий пров уже может использовать Q-in-Q, можете упереться в MTU и еще что - нить. Вариант 3 - может оказаться тяжеловесным решением для небольшого прова. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stingerrr Опубликовано 26 августа, 2009 · Жалоба И еще вопрос какие свичи с поддержкой q-in-q порекомендуете.это не вам надо оборудование такое, а оператору, у которого вы будете брать каналы Это понятно что у оператора, такие свичи должны быть, но и себе нужно чето на вырост подобрать, что посоветуете. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 26 августа, 2009 · Жалоба ЗЫ. у нас vpls. ES10 в ядре? ES20, 10-х на сколько я знаю не бывает. ага точно склероз - а вниз в сторону клиентов что стоит если не секрет :) агрегация cat3560, доступ dlink3526 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 26 августа, 2009 (изменено) · Жалоба stingerr, про q-in-q лучше вам самостоятельно, т.к. только так в голове уложится по полкам. Свой коммутатор лучше ставить рядом с клиентами, а не втыкать клиента напрямую в провайдера т.к. в случае проблем у клиента, сможете провести первичную диагностику. Не обязательно городить огород с q-in-q, можно ограничиться одним тегом. Вариант с q-in-q позволяет арендовать у провайдера не физический порт, а верхний тег, это дешевле. А если тип подключения dot.1q, то и не просить для каждого нового клиента прописать новую "сущность". Все это очень взаимоувязанные вопросы и решать их надо в комплексе с провайдером. Часто то что хочется не умеет железо. q-in-q из самых дешевых умеют Zyxel 3124, Edge-Core 3528. Тут есть комментарии про q-in-q у провайдера, но вы в первом посте написали что он умеет vpls, это автоматически означает что уровень q-in-q он перерос и его сетка предоставляет сервисы на mpls. Это к тому что заставить его пропустить голые q-in-q фреймы через свою сеть вряд ли получиться. Изменено 26 августа, 2009 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stingerrr Опубликовано 26 августа, 2009 · Жалоба stingerr, про q-in-q лучше вам самостоятельно, т.к. только так в голове уложится по полкам.Свой коммутатор лучше ставить рядом с клиентами, а не втыкать клиента напрямую в провайдера т.к. в случае проблем у клиента, сможете провести первичную диагностику. Не обязательно городить огород с q-in-q, можно ограничиться одним тегом. Вариант с q-in-q позволяет арендовать у провайдера не физический порт, а верхний тег, это дешевле. А если тип подключения dot.1q, то и не просить для каждого нового клиента прописать новую "сущность". Все это очень взаимоувязанные вопросы и решать их надо в комплексе с провайдером. Часто то что хочется не умеет железо. q-in-q из самых дешевых умеют Zyxel 3124, Edge-Core 3528. Тут есть комментарии про q-in-q у провайдера, но вы в первом посте написали что он умеет vpls, это автоматически означает что уровень q-in-q он перерос и его сетка предоставляет сервисы на mpls. Это к тому что заставить его пропустить голые q-in-q фреймы через свою сеть вряд ли получиться. Вроде бы уже ясная картина развалилась как карточный домик. Я правильно понял, что через сеть организованную с применением технологии VPLS нельзя прокидывать тегированный трафик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 26 августа, 2009 (изменено) · Жалоба stingerr, про q-in-q лучше вам самостоятельно, т.к. только так в голове уложится по полкам.Свой коммутатор лучше ставить рядом с клиентами, а не втыкать клиента напрямую в провайдера т.к. в случае проблем у клиента, сможете провести первичную диагностику. Не обязательно городить огород с q-in-q, можно ограничиться одним тегом. Вариант с q-in-q позволяет арендовать у провайдера не физический порт, а верхний тег, это дешевле. А если тип подключения dot.1q, то и не просить для каждого нового клиента прописать новую "сущность". Все это очень взаимоувязанные вопросы и решать их надо в комплексе с провайдером. Часто то что хочется не умеет железо. q-in-q из самых дешевых умеют Zyxel 3124, Edge-Core 3528. Тут есть комментарии про q-in-q у провайдера, но вы в первом посте написали что он умеет vpls, это автоматически означает что уровень q-in-q он перерос и его сетка предоставляет сервисы на mpls. Это к тому что заставить его пропустить голые q-in-q фреймы через свою сеть вряд ли получиться. Вроде бы уже ясная картина развалилась как карточный домик. Я правильно понял, что через сеть организованную с применением технологии VPLS нельзя прокидывать тегированный трафик? Можно. Для этого на своем порту провайдер на ваши теги навесит свои (получится QinQ). Но vpls это будет или не vpls.... при условии, что захочет/сможет. Изменено 26 августа, 2009 пользователем Konstantin Klimchev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 26 августа, 2009 · Жалоба А вы набросайте на листочке какие пакеты идут от клиента, что будет делать ваш коммутатор и что будет делать циска провайдера. Гляньте конфигурацию мультипойн сервиса от циски и поймите как она воспримет клиентский пакет после вашего коммутатора, и что-бы вы хотели чтоб она сделала с ним. Чтобы на стороне циски что-то навесить, нужно сначала клиента идентифицировать, варианов немного, порт, влан, влан.влан. Вланы конечно можно пробросить. Лучше пообщаться с провайдером у которого берете услугу, а то придумаете, а он вам откажет, мотивируя коммерческой ненадобностью наворотов и предложит тупо vpls на каждого клиента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...