Перейти к содержимому
Калькуляторы

VPLS, H-VPLS Все о VPLS.

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

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

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

ЗЫ. у нас vpls.

Изменено пользователем Konstantin Klimchev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

- mtu

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем Konstantin Klimchev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

 

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

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

 

 

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

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

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

Изменено пользователем Konstantin Klimchev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 порекомендуете.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще вопрос какие свичи с поддержкой q-in-q порекомендуете.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ЗЫ. у нас vpls.

ES10 в ядре?

ES20,

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ЗЫ. у нас vpls.

ES10 в ядре?

ES20,

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ЗЫ. у нас vpls.

ES10 в ядре?

ES20,

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Изменено пользователем rus-p

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем Konstantin Klimchev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.