Comments 40
Смерть всех этих протоколов мы можем увидеть уже совсем в ближайшем будущем. Все плюсы в пользу SDN и OpenFlow протокола. А поверх последнего что хотите надстраивайте хоть стандартные BGP с OSPF хоть собственную версию МегаНавороченногоOSPFMPLSотВасиСидорова.
Вы уже трогали своими руками рабочую сетку на SDN?
да вот трогаю… ласкаю…
все минусы упираются в современные контролеры, большинство из которых, ученые мужи, отцы-создали пользуют для своих личных научных целей.
Сложные интерфейсы (в основном я имею ввиду самописный код на какомлибо из языков програмирования).
Проблемы с многопоточной обработки запросов.
Отказоустойчивость контролеров, бекапы, феиловер, high availability.
Но всему свое время. Циско уже выпускает свой аналог для разработки SDN на базе своего контролера, + поддержка стандартного открытого общедоступного протокола OpenFlow. Да и без циски как всегда появятся великие опен сорс проекты, помогающие творить SDNовские чудеса, со всякими гуями, свистелками и перделками.
все минусы упираются в современные контролеры, большинство из которых, ученые мужи, отцы-создали пользуют для своих личных научных целей.
Сложные интерфейсы (в основном я имею ввиду самописный код на какомлибо из языков програмирования).
Проблемы с многопоточной обработки запросов.
Отказоустойчивость контролеров, бекапы, феиловер, high availability.
Но всему свое время. Циско уже выпускает свой аналог для разработки SDN на базе своего контролера, + поддержка стандартного открытого общедоступного протокола OpenFlow. Да и без циски как всегда появятся великие опен сорс проекты, помогающие творить SDNовские чудеса, со всякими гуями, свистелками и перделками.
Вы не могли бы про свои опыты написать? Можно в отдельном топике. Пожалуйста.
А то я когда в январе спрашивал наших менеджеров в Cisco и Junpier, они ответили, что да, есть, но у каждого своё представление о SDN, все несовместимо, не развито, по секрету является выдумкой маркетологов и упоминается только, потому что модно. Juniper предлагает свою Сферу, называя её SDN. Но она существует уже много лет и внедрение с помощью неё новых динамических протоколов маршрутизации невозможно.
А то я когда в январе спрашивал наших менеджеров в Cisco и Junpier, они ответили, что да, есть, но у каждого своё представление о SDN, все несовместимо, не развито, по секрету является выдумкой маркетологов и упоминается только, потому что модно. Juniper предлагает свою Сферу, называя её SDN. Но она существует уже много лет и внедрение с помощью неё новых динамических протоколов маршрутизации невозможно.
Все с этой идеей носятся, и никто не может показать ни одной рабочей инсталляции хотя бы на 1000-2000 портов с трафиком > 10 гигабит.
И я даже могу сказать почему. Потому что подохнувший контроллер в условиях SDN (совсем SDN а не «пущать/непущать» на порту) означает полный п. сети.
И контроллер в этом случае должен быть надёжный, кластеризованный и т.д. и т.п. Наверное, кто-то пишет проприентарщину с прицелом на это прямо сейчас. Но в открытом доступе готовых сейчас нет.
И я даже могу сказать почему. Потому что подохнувший контроллер в условиях SDN (совсем SDN а не «пущать/непущать» на порту) означает полный п. сети.
И контроллер в этом случае должен быть надёжный, кластеризованный и т.д. и т.п. Наверное, кто-то пишет проприентарщину с прицелом на это прямо сейчас. Но в открытом доступе готовых сейчас нет.
EIGRP по дизайну не возможен для MPLS TE, посему малопригоден в эпоху все на свете over MPLS.
Пока что не возможен. Я думаю это дело времени.
Переделать протокол что бы нестю всю link state информацию? Это будет уже не EIGRP, да и в этом нет смысла, IS-IS и OSPF — отлично справляются с этой задачей. Преимущества EIGRP были актуальны лет 20 назад, на сегодня этот протокол представляет только исторический интерес.
Пока что не возможен. Я думаю это дело времени.
EIGRP не умеет TE, а нужно использовать именно EIGRP? Да не вопрос, RSVP+verbatim path и TE начинает работать :)
PS: Кто в интеграторе работал, тот в цирке не смеется :))
Возможен. С ограничениями. Можно, но лучше не надо.
Вот только применения MPLS не исчерпываются TE…
Вот только применения MPLS не исчерпываются TE…
Вот только TE это одна из вкусных фич MPLS, особенно для магистральщиков. И потерять его ради сомнительных плюсов EIGRP мало кто захочет.
Ну а внедрять EIGRP в паралель с OSPF крайне глупо, ибо иметь в сети несколько IGP протоколов мало того что бессмысленно, так и еще и чревато (все, надеюсь, помнят как из-за кривого редистрибута лежал яндекс)
Ну а внедрять EIGRP в паралель с OSPF крайне глупо, ибо иметь в сети несколько IGP протоколов мало того что бессмысленно, так и еще и чревато (все, надеюсь, помнят как из-за кривого редистрибута лежал яндекс)
1) Лично мне TE не нужен совсем. А VPN — очень нужен.
2) Глупость какая-то… Яндекс в параллель держал BGP и IGP — тут уж извиняйте, BGP обычно by design полагается на наличие IGP.
3) От Epic Fail'а Яндекс мог застраховаться ровно одной командой, введенной заранее.
2) Глупость какая-то… Яндекс в параллель держал BGP и IGP — тут уж извиняйте, BGP обычно by design полагается на наличие IGP.
3) От Epic Fail'а Яндекс мог застраховаться ровно одной командой, введенной заранее.
Магисральщикам никакой ТЕ не нужен, у них совсем другие проблемы.
Это не так. MPLS TE возможен и с EIGRP.
Интересно, много ли более-менее крупных сетей используют EIGRP в принципе? За все свое время я имел счастье наблюдать EIGRP только в лабах.
И основная причина — отсутствие совместимости с другими вендрами (зачем связывать себя привязкой к Cisco? Если, конечно, вы не гос.учереждение связанное откатами..). Даже работая в Cisco-ориентированном интеграторе — я не видел массивных деплоев EIGRP.
Есть подозрение, что протокол умирает и это попытка реабилитации.
И основная причина — отсутствие совместимости с другими вендрами (зачем связывать себя привязкой к Cisco? Если, конечно, вы не гос.учереждение связанное откатами..). Даже работая в Cisco-ориентированном интеграторе — я не видел массивных деплоев EIGRP.
Есть подозрение, что протокол умирает и это попытка реабилитации.
Очень не плохая попытка, по-моему. Лучше поздно, чем никогда.
Да, походе Циска наконец-то осознала, что путь закрытого протокола маршрутизации — это путь в никуда. Но по моему, слишком поздно началось это движение. Навряд ли кто то из крупных вендоров захочет создавать и поддерживать еще один протокол. С OSPF то регулярно возникают проблемы совместимости или какие-то тонкости реализации.
Это похоже на то, что Циска теряет позиции и пытается остановить этот процесс любыми способами.
Это похоже на то, что Циска теряет позиции и пытается остановить этот процесс любыми способами.
много ли более-менее крупных сетей используют EIGRP в принципе?
Что за вопрос? Более-менее крупные компании используют несколько разных IGP вместе, каждый на свой участок (ага, я даже RIP как-то видел в боевой среде).
EIGRP кладет OSPF на лопатки там, где топология похожа на hub and spoke, причем с большим числом соседств. Т.е. сотни/тысячи мелких филиалов цепляются к паре хабов — как пример. И кстати, там наверняка будет задействован и проприетарный механизм связности по VPN, ибо хороших стандартных под это дело — нету.
По-моему несколько разных IGP используются либо от плохого дизайна, либо после поглощения не успели привести сетку в порядок. Ну либо какой-то исключительный случай, который правилом не является. Ну а то что где-то есть и RIP — я не сомневаюсь, только это не значит же, что это хорошо или правильно.
А насчет EIGRP vs OSPF при hub-and-spoke, а в чем преимущество будет в такой топологии? Допустим, по сравнению с OSPF если каждый спок загнать в свою totally stub зону?
А насчет EIGRP vs OSPF при hub-and-spoke, а в чем преимущество будет в такой топологии? Допустим, по сравнению с OSPF если каждый спок загнать в свою totally stub зону?
А насчет EIGRP vs OSPF при hub-and-spoke, а в чем преимущество будет в такой топологии? Допустим, по сравнению с OSPF если каждый спок загнать в свою totally stub зону?
1) А теперь давайте вспомним, что у OSPF апдейты идут по расписанию, а у EIGRP по событиям. Учитывая, что у вас сотни мелких филиалов (банкоматов), местами на весьма дорогих каналах, то предлагаю вам посчитать сколько вам обойдется обслуживание протокола OSPF
2) Когда мы говорим про сотни филиалов, то очень удобно использовать DMVPN у которого все IP адреса должны быть в одной подсети. А так как OSFP это link-state протокол, то это означает что ВСЕ споки должны иметь полную LSDB. предлагаю вам подсчитать, во сколо раз дороже железо вам нужно будет ставить во всех споках, чтобы они могли обрабатывать огромные LSDB/
Первое — не правда.
У OSPF апдейты тоже по событиям. Периодический LSA flood раз в полчаса можно отключить.
У OSPF апдейты тоже по событиям. Периодический LSA flood раз в полчаса можно отключить.
Rel1cto уже ответил, что первое не верно. Обслуживание OSPF будет не дороже чем EIGRP.
Спокам не нужно держать всю LSDB, я изначально написал, что они будут в totally stub зонах и нагрузка на них будет минимальная.
Насчет второго, если вы завязываетесь на DMVPN, то наверное, в этом случае, уже не проблема подвязываться и на EIGRP.
Спокам не нужно держать всю LSDB, я изначально написал, что они будут в totally stub зонах и нагрузка на них будет минимальная.
Насчет второго, если вы завязываетесь на DMVPN, то наверное, в этом случае, уже не проблема подвязываться и на EIGRP.
Несколько IGP используются как раз при оптимальном дизайне. Нет ничего страшного в redistribute, если делать это правильно.
По второму — ниже уже один пример привели. Вы засунете один point-to-multipoint интерфейс на хабе сразу в несколько сотен зон? :)
В таких сценариях OSPF вообще никто не использует. Только EIGRP и BGP (то есть distance vector протоколы). Второй — очень неповоротливый.
По второму — ниже уже один пример привели. Вы засунете один point-to-multipoint интерфейс на хабе сразу в несколько сотен зон? :)
В таких сценариях OSPF вообще никто не использует. Только EIGRP и BGP (то есть distance vector протоколы). Второй — очень неповоротливый.
Ну и да, «каждый спок на свою зону» при point-to-point дизайне — значит невыносимой длины и сложности конфиг на хабе, вручную — практически неподдерживаемый, и с лишним различием в конфигурации каждого спока. А чем больше таких различий, тем хуже.
C p-t-m сценарием согласен, тут EIGRP должен хорошо сыграть.
Где в наше время используется RIP в боевой среде? За последние лет 5 я RIP видел только у некоторых небольших операторов, которые его используют в качестве доставки маршрутов конечным пользователям-физикам (sic!) для того, чтобы не гнать локалку в туннель, по которому дают интернет.
Я работал в одной конторе, где в коре использовался IS-IS и RIP. Это был спутниковый провайдер, работали с хабами iDirect, а они из динамики ничего кроме RIPа не умеют. Рано ещё хоронить этот протокол.
Я знаю один банк, в котором основной IGP — IS-IS. В их топологии OSPF работает хуже.
Ну а про RIP — есть люди, нарушающие все заповеди и позволяющие серверам принимать участие в динамическом роутинге… Если маршрутов мало и быстрая сходимость вдруг не требуется — RIP идеален, так как можно легко применить фильтрацию по префиксам и при этом не раздуть конфиг до астрономических масштабов.
Ну а про RIP — есть люди, нарушающие все заповеди и позволяющие серверам принимать участие в динамическом роутинге… Если маршрутов мало и быстрая сходимость вдруг не требуется — RIP идеален, так как можно легко применить фильтрацию по префиксам и при этом не раздуть конфиг до астрономических масштабов.
UFO just landed and posted this here
Cisco решила отдать своё детище IETF как Informational RFC
Без стабов.
В тех топологиях, где превосходство EIGRP над OSPF становится видимым невооруженным взглядом, запускать EIGRP без поддержки стабов — самоубийство.
Ну и кому оно надо в таком виде?
Господа… я не понимаю ни слова. Может кто то сможет сделать статью об этом? Ну мол что такое EIGRP, при чем тут OSPF, SDN, BGP, MPLS… а то так много красивых аббревиатур, а читаешь их как китайскую грамоту.
Это не статья нужна, а целая книга. Причём по каждому пункту. :)
Если вкратце, EIGRP, OSPF и BGP — протоколы динамической маршрутизации. Первый — Cisco-проприетарный, частичному открытию его спецификаций и посвящён данный пост.
SDN — технология вынесения всей логики работы сети в отдельное контролирующее устройство, эдакий супермозг. Все о ней говорят, очень модная, но рабочих реализаций пока не видно. Особенно учитывая, что каждый вендор вкладывает в слова «SDN» какой-то свой смысл.
MPLS — технология коммутации пакетов c помощью меток. Используется, в основном, у провайдеров.
Если вкратце, EIGRP, OSPF и BGP — протоколы динамической маршрутизации. Первый — Cisco-проприетарный, частичному открытию его спецификаций и посвящён данный пост.
SDN — технология вынесения всей логики работы сети в отдельное контролирующее устройство, эдакий супермозг. Все о ней говорят, очень модная, но рабочих реализаций пока не видно. Особенно учитывая, что каждый вендор вкладывает в слова «SDN» какой-то свой смысл.
MPLS — технология коммутации пакетов c помощью меток. Используется, в основном, у провайдеров.
Вот и славно, вот и хорошо. EIGRP вообще очень приятный протокол, надо отдать должное цыске, в свое время они его сделали хорошо. Но вот пока другие вендоры смогут получить у себя достаточно стабильную имплементацию поезд уедет уже так далеко, что будет не догнать.
Поезд едет уже 20 лет как. Лишний год-два ничего ровным счётом не изменит.
Для тех, кто много с ним работал, он вовсе не настолько приятен, как хотелось бы. Из плюсов — суммаризация и дистрибьют-листы где угодно, оффсет-листы (а возможность метриками придушить канал, трогая лишь одну сторону — бесценно), чертовски быстрое переключение на резерв в определенных случаях. Минус — иногда возникает всякая НЁХ, связанная с порядком расхождения query, и обычно заканчивающаяся SIA. Ну и время схождения может быть жестоким при непопадании в feasible condition. Ну и всяких мелочей вроде LDP-IGP sync нету.
Отличная новость.
Sign up to leave a comment.
Cisco открывает EIGRP для сторонних производителей