ksg222 Oct 14 2015 at 10:53

Сетевые оверлейные технологии: OTV, LISP и итоги. Часть 3

7 min

28K

CBS corporate blogCisco*Network technologies*

+10

Comments 10

Alaniyatm Oct 14 2015 at 13:33

Забыли про классику — VPLS.

ksg222 Oct 14 2015 at 13:45

Оверлейных технологий очень много (SPB, PBB, VPLS, EVPN и т.д.). Описать сразу всё — сложно. Поэтому я сделал выбор в пользу некоторых из них.

Alaniyatm Oct 14 2015 at 19:51

Мы например используем FP внутри площадки, а DCI реализован на VPLS. Получилось очень удобно, но пришлось крутить еще mcLAG.

ksg222 Oct 15 2015 at 10:50

Хороший вариант. Действительно VPLS и A-VPLS достаточно распространённые технологии DCI в случае использования MPLS. Правда сейчас уже на смену VPLS приходит EVPN.

Alaniyatm Oct 15 2015 at 11:02

Согласен, EVPN тема благая, но надо собирать POC и так тестировать что и как. На практике DCI я столкнулся с большими ограничениями в части MPLS DCI, но намеренно ушел от LISP и DNS based DR. В двух словах не описать, целый проект написан по нашему DCI.

amarao Oct 15 2015 at 02:37

Во всем этом нет важного уточнения — какие из этих технологий будут работать на не-цисках. Чтобы не усложнять задачу — одна циска и все остальные участники сети — софтовые роутеры на фре/линуксе.

Вот тут-то картинка сильно портится. А закладываться на моностек… Ну, бывают такие безрассудные, смелые и готовые рискнуть (чужим кошельком).

Alaniyatm Oct 15 2015 at 11:05

Я не могу даже представить себе смелость человека который базирует огромную инфраструктуру на фре/линуксе, без поддержки крупных производителей.

amarao Oct 16 2015 at 03:30

bfy.tw/2JLI

htol Oct 18 2015 at 00:52

Гугл/фейсбук сам себе крупный производитель, так что не считается. Нет ни чего плохо в том чтобы использовать «моностек» с соответствующей поддержкой при правильном планировании и проектировании. Да, тут конечно надо работать головой, потому что цена ошибки на этапе проектирования высока. Думаю эти требования относятся и к проектам базирующимся на опенсоурсе. Более того есть случаи, когда ни какой сервер не обеспечит вам нужную производительности в сети. «Свежий» пример в виде решения NSX с его попыткой программного гейтования vxlan…
Я понимаю вас как евангелиста опенсоурса, но не понимаю как человека у которого должен быть здравый смысл и понимание, что к разным задачам подходят разные инструменты.
Если не нравится моновендорность можно использовать нескольких. Знаю оператора у которого в регламенте записано требование в виде использование разных вендоров на резервируемых линках.
С таким подходом использование опенсоурса так же можно назвать моностеком. Ведь реально решений которые можно запустить в продакшен без страха не так уж и много.

ksg222 Oct 15 2015 at 11:50

Безусловно, проприетарный FabricPath или OTV требует использования только железок Cisco. Но технология VXLAN многовендорная. VXLAN поддерживается Vmware, Open vSwitch, Juniper, Huawei и другими. Причём в одной сети могут работать устройства разных вендоров. Это справедливо для реализации VXLAN не только в режиме multicast, но и в режиме unicast. Например, поддержка MP-BGP EVPN есть и на Cisco, и на Juniper. Правда, ручаться за 100% совместимость, конечно, не могу.
Если мы говорим про Linux, то поддержка VXLAN там есть. Например, в виртуальном коммутаторе Open vSwitch, в Cumulus Linux, Linux Debian и пр. Есть реализации SDN на базе программных продуктов (построенных на Linux), где для связи между теми же виртуальными коммутаторами Open vSwitch используется VXLAN.
В целом VXLAN и интересен в первую очередь тем, что он разработан и дорабатывается группой различных производителей.
Что касается технологии LISP, это стандарт IETF. Поддерживается не только на Cisco. Есть поддержка и в Open vSwitch. Но тут всё не просто, так как есть вопросы к самой технологии. Не все компании считают её нужной.