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

VPLS, H-VPLS Все о VPLS.

Коллеги есть небольшой субпровайдер у которого не везде есть свой транспорт. Там где нет своего транспорта у другова провайдера берется услуга VPLS.

Задача предоставлять клиентам услугу VPLS даже там где нет своего транспорта.

Возможно ли в принципе построить VPLS over VPLS? Если да какие требования нужно предъявить к провайдеру верхнего уровня.

 

У меня еще будут несколько вопросов по оборудованию, но к ним я вернусь позже.

 

Share this post


Link to post
Share on other sites
Коллеги есть небольшой субпровайдер у которого не везде есть свой транспорт. Там где нет своего транспорта у другова провайдера берется услуга VPLS.

Задача предоставлять клиентам услугу VPLS даже там где нет своего транспорта.

Возможно ли в принципе построить VPLS over VPLS? Если да какие требования нужно предъявить к провайдеру верхнего уровня.

 

У меня еще будут несколько вопросов по оборудованию, но к ним я вернусь позже.

А можно поинтересоваться - что Вы вкладываете в понятие "VPLS over VPLS", только без умных теоретических терминов, а по рабоче-крестьянски, т.е. на пальцах? Типа "для того-то, того-то и того-то....". Просто про "предоставлять клиентам услугу VPLS" мне не совсем понятно, что б вам что-то присоветовать.

 

ЗЫ. у нас vpls.

Edited by Konstantin Klimchev

Share this post


Link to post
Share on other sites

Можно, потенциальные проблемы:

- mtu

- параллельные в сети этого провайдера - при их наличии весь (ну или не весь, зависит от топологии вашей сети) ваш трафик будет ложиться только в один из них

- QoS - возможно несоответствие вашего и ихнего

 

Share this post


Link to post
Share on other sites
А можно поинтересоваться - что Вы вкладываете в понятие "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 дела похуже ...

Share this post


Link to post
Share on other sites
А можно поинтересоваться - что Вы вкладываете в понятие "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 Так сказать: простенько и со вкусом

Edited by Konstantin Klimchev

Share this post


Link to post
Share on other sites
А можно поинтересоваться - что Вы вкладываете в понятие "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 можно прокинуть прокинуть??

 

 

 

Share this post


Link to post
Share on other sites
Я в этой области не силен поэтому попрошу вас на пальцах обьяснить разницу между EMS и ERMS. Наверно глупый вопрос...

Ну если на пальцах:

в EMS провайдер даст вам тегированный трафик гонять + BPDUшки, а в ERMS - нет.

 

 

Если я правильно понял, берем услугу EMS и далие поверх нее строим все что душе угодно ...

не поверх, в внутри, но это дело вкуса как говорить....

 

 

Тут появилась еще одна мысль через EMS 802.1q можно прокинуть прокинуть??

Ну дык для этого оно и придумано - чтоб vlan'ы гонять. А по правильному оно и еще и твои BPDUшки "прокидывать" должно.

Но тут - а даст ли провайдер такое? Нужно не умными фразами к нему, а просто спросить: а дадите QinQшные порты? а как оно будет у него реализовано - не должно вас волновать.

Edited by Konstantin Klimchev

Share this post


Link to post
Share on other sites

Если даст вам JumboFrame гонять, то сделаете все что угодно.

Share this post


Link to post
Share on other sites

stingerrr, если фраза "нет своего транспорта", означает физическое отсутствие вас в данном регионе, то не имеет большого смысла думать над вопросом vpls over vpls, т.к. вам придется размещать дорогостоящее оборудование рядом с клиентами, запускать на нем vpls, и, по сути, пробрасывать свой mpls через его mpls. (туннелировать можно и не только через mpls, но это не суть)

Кроме этого, как тут уже сказали, jumbo фреймы вас конечно спасут, вот только цискины гайды пестрят примерами выставления mtu на пределе, т.е. закладывают свои метки, теги и все, чужих не пущать.

Экономически выгоднее состыковаться с нужным вам провайдером транковым портом в точке присутствия вас обоих и затем у этого провайдера заказывать отдельный vpls под каждого клиента.

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

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

Минусом, понятно идет некое влияние одних на других в этом случае.

Важный вопрос, это количество мак адресов предоставляемых провайдером в точке подключения и во всем vpls.

 

 

 

Share this post


Link to post
Share on other sites
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 порекомендуете.

 

Share this post


Link to post
Share on other sites
И еще вопрос какие свичи с поддержкой q-in-q порекомендуете.

это не вам надо оборудование такое, а оператору, у которого вы будете брать каналы

Share this post


Link to post
Share on other sites
ЗЫ. у нас vpls.

ES10 в ядре?

ES20,

10-х на сколько я знаю не бывает.

ага точно склероз - а вниз в сторону клиентов что стоит если не секрет :)

Share this post


Link to post
Share on other sites

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 - может оказаться тяжеловесным решением для небольшого прова.

Share this post


Link to post
Share on other sites
И еще вопрос какие свичи с поддержкой q-in-q порекомендуете.
это не вам надо оборудование такое, а оператору, у которого вы будете брать каналы

Это понятно что у оператора, такие свичи должны быть, но и себе нужно чето на вырост подобрать, что посоветуете.

Share this post


Link to post
Share on other sites
ЗЫ. у нас vpls.

ES10 в ядре?

ES20,

10-х на сколько я знаю не бывает.

ага точно склероз - а вниз в сторону клиентов что стоит если не секрет :)

агрегация cat3560, доступ dlink3526

Share this post


Link to post
Share on other sites

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 фреймы через свою сеть вряд ли получиться.

 

Edited by rus-p

Share this post


Link to post
Share on other sites
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 нельзя прокидывать тегированный трафик?

Share this post


Link to post
Share on other sites
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....

при условии, что захочет/сможет.

Edited by Konstantin Klimchev

Share this post


Link to post
Share on other sites

А вы набросайте на листочке какие пакеты идут от клиента, что будет делать ваш коммутатор и что будет делать циска провайдера. Гляньте конфигурацию мультипойн сервиса от циски и поймите как она воспримет клиентский пакет после вашего коммутатора, и что-бы вы хотели чтоб она сделала с ним.

Чтобы на стороне циски что-то навесить, нужно сначала клиента идентифицировать, варианов немного, порт, влан, влан.влан.

Вланы конечно можно пробросить. Лучше пообщаться с провайдером у которого берете услугу, а то придумаете, а он вам откажет, мотивируя коммерческой ненадобностью наворотов и предложит тупо vpls на каждого клиента.

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