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

Metro ethernet network design Вопросы и рекомендации по дизайну сети

Добрый день.

 

Возникла необходимость в разработки дизайна сети Metro ethernet с полной избыточностью на 65000 абонентов и временем downtime при выходе из строя любого оборудования не более 500мс.

На уровне агрегации используются коммутаторы Huawei S9300 (2 шт.). На сервисном уровне Huawei BRAS ME60. На уровне доступа сеть построена с использованием кольцевых топологий. Схема сети во вложении.

Хотелось бы услышать предложения по низкоуровневому дизайну сети, особенно интересует уровень агрегации (текущая схема, основанная на VRRP+MSTP+SuperVLAN+ProxyARP, оказалась не действующей при расширении сети - оборудование не справляется).

 

Заранее спасибо за помощь.

post-73868-1281006199_thumb.jpg

Share this post


Link to post
Share on other sites

мои мысли такие:

думаю при таких масштабах кольцо надо строить L3(MPLS TE+FRR) и кольца на аксессе L2(STP). как минимум 2 апстрима и в разных местах. брасы можно как на сегмент по штуке, так и 2 на апстрим по штуке с резервированием.

 

Share this post


Link to post
Share on other sites
временем downtime при выходе из строя любого оборудования не более 500мс.

Звучит как утопия.

Share this post


Link to post
Share on other sites
мои мысли такие:

думаю при таких масштабах кольцо надо строить L3(MPLS TE+FRR) и кольца на аксессе L2(STP). как минимум 2 апстрима и в разных местах. брасы можно как на сегмент по штуке, так и 2 на апстрим по штуке с резервированием.

 

Не совсем понял где Вы предлагаете строить L3(MPLS TE+FRR) на уровне агрегации на текущий момент всего два коммутатора S9300 и колец там не наблюдается. Построения L3(MPLS TE+FRR) между коммутаторами агрегации и BRAS позволит уменьшить время сходимости (на текущий момент используется протокол OSPF без MPLS). При таких масштабах Layer3 сети сходимость будет занимать доли милисекунд.

Касательно апстримов используется 2 апстрима подключенных в разных местах. Каждый BRAS держит BGP сессии с кажды апстримом.

Главная проблема - это как и где стерминироваьт Layer2?

 

временем downtime при выходе из строя любого оборудования не более 500мс.

Звучит как утопия.

 

Надо стремится к лучшему:) А что по Вашему мнению делает это утопией? Какие протоколы в данной сети не отвечают таким параметрам сходимости?

 

временем downtime при выходе из строя любого оборудования не более 500мс.

Звучит как утопия.

Надо стремится к лучшему:) А что по Вашему мнению делает это утопией? Какие протоколы в данной сети не отвечают таким параметрам сходимости?

Share this post


Link to post
Share on other sites

Очень похоже на очередной курсовой или дипломный проект...

Share this post


Link to post
Share on other sites

Главная проблема - это как и где стерминироваьт Layer2?

Агрегация...

Share this post


Link to post
Share on other sites
используются коммутаторы Huawei

Уже смешно. :)

А Вы не пробовали обратиться к вендору со своей просьбой? У них же должен быть солюшн под ваши требования.

 

Share this post


Link to post
Share on other sites
Хотелось бы услышать предложения по низкоуровневому дизайну сети, особенно интересует уровень агрегации (текущая схема, основанная на VRRP+MSTP+SuperVLAN+ProxyARP, оказалась не действующей при расширении сети - оборудование не справляется).

Что именно не справляется?

 

На сколько я помню у 93-х 16к ARP-ов на шасси соответственно на 64к юзеров может двух свитчей и не хватать

Share this post


Link to post
Share on other sites
Надо стремится к лучшему:) А что по Вашему мнению делает это утопией? Какие протоколы в данной сети не отвечают таким параметрам сходимости?
Сходимость зависит не только от используемых протоколов, а от топологии сети, характера нагрузки, кривизны реализации протоколов на конкретном железе и правильности их настройки инженером :)

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

На вскидку - у VRRP по стандарту advertisement interval - секунда. Да, Cisco и кажется Juniper могут быстрее. Может-ли быстрее Huawei, это как раз тот вопрос 'реализации протоколов на конкретном железе'. Отдельный вопрос - сколько групп сможет вытянуть Huawei если надо будет 'быстрее'.

 

Очень похоже на очередной курсовой или дипломный проект...
Ага :)

Share this post


Link to post
Share on other sites
мои мысли такие:

думаю при таких масштабах кольцо надо строить L3(MPLS TE+FRR) и кольца на аксессе L2(STP). как минимум 2 апстрима и в разных местах. брасы можно как на сегмент по штуке, так и 2 на апстрим по штуке с резервированием.

 

Не совсем понял где Вы предлагаете строить L3(MPLS TE+FRR) на уровне агрегации на текущий момент всего два коммутатора S9300 и колец там не наблюдается. Построения L3(MPLS TE+FRR) между коммутаторами агрегации и BRAS позволит уменьшить время сходимости (на текущий момент используется протокол OSPF без MPLS). При таких масштабах Layer3 сети сходимость будет занимать доли милисекунд.

Касательно апстримов используется 2 апстрима подключенных в разных местах. Каждый BRAS держит BGP сессии с кажды апстримом.

Главная проблема - это как и где стерминироваьт Layer2?

FRR не уменьшает сходимость, а позволяет защищать потоки трафика переключая в случае падения LSP на резервный LSP. система не будет ждать пока сойдется ваш IGP.

 

в вашем случае я понимаю есть только один узел в который сходятся все L2 кольца. в таком случае у вас этот центральный узел является уязвимым местом. отключение питания, вышибание пробок, пажар, потоп, метеоритный дождь и все ваши абоненты сидят без инета. а их 64 тыщи, этож целая армия...могут и камнями закидать. потому я и говорю, что в таких масштабах нужно иметь как минимум 2 узла в которых есть инет и с каждого аксесс кольца можно было попасть в инет через оба этих узла.

Share this post


Link to post
Share on other sites

Huawei - это диагноз. :D

 

 

PS: а не МТТ ли это, со своим чудо-проектом ? :-)

Share this post


Link to post
Share on other sites
Очень похоже на очередной курсовой или дипломный проект...

К сожалению нет - .то реальная сеть, которая была построена и на этапе расширения, оказалась что дизайн не оптимален

 

Главная проблема - это как и где стерминироваьт Layer2?
Агрегация...

Агрегация- понятие абстрактное. Возможно терминировать всех пользователей несколькими Layer3 интерфейсами с маской к примеру в 20. При этом изолировать домен бродкаста для каждого кольца с помощью супер влана. Для избыточности использовать VRRP на Layer3 Интерфейсах. Можно прокидывать с помощбю QinQ до BRAS и терменировать там. Можно еще использовать другие решения. Вопрос в том что наиболее оптимально

 

используются коммутаторы Huawei

Уже смешно. :)

А Вы не пробовали обратиться к вендору со своей просьбой? У них же должен быть солюшн под ваши требования.

Пробовали. На єтапе дизайна вендор подтверждал работоспособность. Когда возникли проблемы вендор начел сообщать что VRRP и супервлан не рекомендуется использовать, также не рекомендуется использовать VRRP и DHCP Relay. На текущий момент вендор затрудняется сообщить что же можно использовать. Корме єтого по многим проблемам на текущий момент не получено никаких вменяемых объяснений от вендора(

Share this post


Link to post
Share on other sites
Хотелось бы услышать предложения по низкоуровневому дизайну сети, особенно интересует уровень агрегации (текущая схема, основанная на VRRP+MSTP+SuperVLAN+ProxyARP, оказалась не действующей при расширении сети - оборудование не справляется).

Что именно не справляется?

 

На сколько я помню у 93-х 16к ARP-ов на шасси соответственно на 64к юзеров может двух свитчей и не хватать

На текущий момент пользователей не более 500 и оборудования доступа не более 250 единиц - 48 колец.

Существует два Layer3 интерфейса с маской 20 для терминации Layer2. При этом изользуется изоляция домен бродкаста для каждого кольца с помощью супер влана. Для избыточности использовать VRRP на Layer3 Интерфейсах.

Главная проблема - это ARP. Так как при приходе пакета на неизвестный адрес (арп отсутствует) арп запрос рассылается во все sub-Vlan которіе пренадлежат данному super vlan. Плюс на все интерфесы на которых настроены эти sub-vlan. Итого для 1 арпа - 48 арпов (так как 48 колец в данный момент, в будущем 512) + 140 арпов (интерфейс между двумя 93 так как в нем прокинуты все sub-vlan для обеспечения доступности VRRP мастера в случаи разріва кольца). Соответственно при запуске одно из коммутаторов огромное кол-во арпов пораждает высокую загрузку процессора (так как при использовании супер влан как оказалась арпі обрабатіваются процессором), что приводит к отказу STP или flap VRRP, которій в свою очередь усугубляет проблему с арпами (так как только VRRP мастер изучает арпы).

Раньше еще имелась проблема с MSTP - при любом измении топологии приходили TCN, который приводил к очистке всех арпов и маков. Это попоролось - теперь при приходе арп не удаляется сразу, а время жизни просто збрасывается в 0. При этом выполняется перезапрос арпа только в нужный интерфейс и лишь в случаи не удачи арп перезапрашивается во всех вланах. Отголоском проблемы отсалась ситуация когда при приходе большого кол-ва TCN в короткое время арпі не успеваю перезапрасится и все таки клирятся(

 

На этапе дизайна вендор подтверждал работоспособность. Когда возникли проблемы вендор начел сообщать что VRRP и супервлан не рекомендуется использовать, также не рекомендуется использовать VRRP и DHCP Relay и даже просто супер влан. На текущий момент вендор затрудняется сообщить что же можно использовать. Корме этого по многим проблемам на текущий момент не получено никаких вменяемых объяснений от вендора(

 

 

 

 

 

Надо стремится к лучшему:) А что по Вашему мнению делает это утопией? Какие протоколы в данной сети не отвечают таким параметрам сходимости?
Сходимость зависит не только от используемых протоколов, а от топологии сети, характера нагрузки, кривизны реализации протоколов на конкретном железе и правильности их настройки инженером :)

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

На вскидку - у VRRP по стандарту advertisement interval - секунда. Да, Cisco и кажется Juniper могут быстрее. Может-ли быстрее Huawei, это как раз тот вопрос 'реализации протоколов на конкретном железе'. Отдельный вопрос - сколько групп сможет вытянуть Huawei если надо будет 'быстрее'.

 

Очень похоже на очередной курсовой или дипломный проект...
Ага :)

На Хуавей существует потдержка VRRP + BFD c времнем сходимости, которое біло оттестировано (конечно же не под нагрузкой:)) в 50 мс. Кол-во возможный VRRP Групп - 16

 

мои мысли такие:

думаю при таких масштабах кольцо надо строить L3(MPLS TE+FRR) и кольца на аксессе L2(STP). как минимум 2 апстрима и в разных местах. брасы можно как на сегмент по штуке, так и 2 на апстрим по штуке с резервированием.

 

Не совсем понял где Вы предлагаете строить L3(MPLS TE+FRR) на уровне агрегации на текущий момент всего два коммутатора S9300 и колец там не наблюдается. Построения L3(MPLS TE+FRR) между коммутаторами агрегации и BRAS позволит уменьшить время сходимости (на текущий момент используется протокол OSPF без MPLS). При таких масштабах Layer3 сети сходимость будет занимать доли милисекунд.

Касательно апстримов используется 2 апстрима подключенных в разных местах. Каждый BRAS держит BGP сессии с кажды апстримом.

Главная проблема - это как и где стерминироваьт Layer2?

FRR не уменьшает сходимость, а позволяет защищать потоки трафика переключая в случае падения LSP на резервный LSP. система не будет ждать пока сойдется ваш IGP.

 

в вашем случае я понимаю есть только один узел в который сходятся все L2 кольца. в таком случае у вас этот центральный узел является уязвимым местом. отключение питания, вышибание пробок, пажар, потоп, метеоритный дождь и все ваши абоненты сидят без инета. а их 64 тыщи, этож целая армия...могут и камнями закидать. потому я и говорю, что в таких масштабах нужно иметь как минимум 2 узла в которых есть инет и с каждого аксесс кольца можно было попасть в инет через оба этих узла.

 

Так как система не будет ждать пока сойдется IGP - то єто привидет к ускорению сходимости. Но в данном случаи на сходимость IGP нареканий нет.

 

По второму вопросу согласен - выход из строя одного узла привидет к полной потере сервиса, но в данном случаи следует рассматривать еще финансовую сторону построения второй площадки. Может быть в будущем:)

 

Huawei - это диагноз. :D

Отчасти да:)

 

PS: а не МТТ ли это, со своим чудо-проектом ? :-)

Нет не MTT - но с дизайном MTT знаком - там все гораздо проще:)

 

Share this post


Link to post
Share on other sites
Очень похоже на очередной курсовой или дипломный проект...

К сожалению нет - .то реальная сеть, которая была построена и на этапе расширения, оказалась что дизайн не оптимален

 

Главная проблема - это как и где стерминироваьт Layer2?
Агрегация...

Агрегация- понятие абстрактное. Возможно терминировать всех пользователей несколькими Layer3 интерфейсами с маской к примеру в 20. При этом изолировать домен бродкаста для каждого кольца с помощью супер влана. Для избыточности использовать VRRP на Layer3 Интерфейсах. Можно прокидывать с помощбю QinQ до BRAS и терменировать там. Можно еще использовать другие решения. Вопрос в том что наиболее оптимально

 

используются коммутаторы Huawei

Уже смешно. :)

А Вы не пробовали обратиться к вендору со своей просьбой? У них же должен быть солюшн под ваши требования.

Пробовали. На єтапе дизайна вендор подтверждал работоспособность. Когда возникли проблемы вендор начел сообщать что VRRP и супервлан не рекомендуется использовать, также не рекомендуется использовать VRRP и DHCP Relay. На текущий момент вендор затрудняется сообщить что же можно использовать. Корме єтого по многим проблемам на текущий момент не получено никаких вменяемых объяснений от вендора(

Ахахаха узнаю Хуавейщиков))))

Ну а по чесному и cisco и juniper тоже попадали в просак.. нет идеально работающего оборудования под все задачи..

 

Share this post


Link to post
Share on other sites
почему ресурсы мимо брасов?

Потому что нет необходимоси в подсчете траффика к ресурсам и ограничения скорости к ним. К тому же на BRAS сейчас имееися в наличии только 1 плата содним 10 G интерфейсом для терминации пользовательских сесий - и очень не хочется нагружать ее трафиком к ресурсам, который по задумке является довольно существенным. Пропуск трафика к ресурсам через брас имеет смысл только в том случаии если 93 работает в режиме L2. При єтом все функции агрегации переходят на BRAS. Это черевато огромным кол-вом проблем.

 

Очень похоже на очередной курсовой или дипломный проект...

К сожалению нет - .то реальная сеть, которая была построена и на этапе расширения, оказалась что дизайн не оптимален

 

Главная проблема - это как и где стерминироваьт Layer2?
Агрегация...

Агрегация- понятие абстрактное. Возможно терминировать всех пользователей несколькими Layer3 интерфейсами с маской к примеру в 20. При этом изолировать домен бродкаста для каждого кольца с помощью супер влана. Для избыточности использовать VRRP на Layer3 Интерфейсах. Можно прокидывать с помощбю QinQ до BRAS и терменировать там. Можно еще использовать другие решения. Вопрос в том что наиболее оптимально

 

используются коммутаторы Huawei

Уже смешно. :)

А Вы не пробовали обратиться к вендору со своей просьбой? У них же должен быть солюшн под ваши требования.

Пробовали. На єтапе дизайна вендор подтверждал работоспособность. Когда возникли проблемы вендор начел сообщать что VRRP и супервлан не рекомендуется использовать, также не рекомендуется использовать VRRP и DHCP Relay. На текущий момент вендор затрудняется сообщить что же можно использовать. Корме єтого по многим проблемам на текущий момент не получено никаких вменяемых объяснений от вендора(

Ахахаха узнаю Хуавейщиков))))

Ну а по чесному и cisco и juniper тоже попадали в просак.. нет идеально работающего оборудования под все задачи..

 

 

Это действительно отчасти забавляет) - но сеть дорабатывать в любом случаи надо, независимо от вендора)

Share this post


Link to post
Share on other sites
На єтапе дизайна вендор подтверждал работоспособность. Когда возникли проблемы вендор начел сообщать что VRRP и супервлан не рекомендуется использовать, также не рекомендуется использовать VRRP и DHCP Relay. На текущий момент вендор затрудняется сообщить что же можно использовать. Корме єтого по многим проблемам на текущий момент не получено никаких вменяемых объяснений от вендора(
Никогда не верьте Хуавейцам - каждое их слово нужно перепроверять.

И не забывайте, что скупой платит дважды :D.

Share this post


Link to post
Share on other sites
На єтапе дизайна вендор подтверждал работоспособность. Когда возникли проблемы вендор начел сообщать что VRRP и супервлан не рекомендуется использовать, также не рекомендуется использовать VRRP и DHCP Relay. На текущий момент вендор затрудняется сообщить что же можно использовать. Корме єтого по многим проблемам на текущий момент не получено никаких вменяемых объяснений от вендора(
Никогда не верьте Хуавейцам - каждое их слово нужно перепроверять.

И не забывайте, что скупой платит дважды :D.

Проверить масштабируемость сети на этапе тестов довольно сложно(

Share this post


Link to post
Share on other sites
Никогда не верьте Хуавейцам - каждое их слово нужно перепроверять.

И не забывайте, что скупой платит дважды :D.

Более правильно сказать, что никогда не верьте всем вендорам, у которых R&D и топ-менеджмент находятся в Китае. Каждую(!) фичу, которую планируется использовать надо тщательно оттестировать.

Лично у меня складывается впечатление, что они(чисто китайские вендоры) либо вообще не тестируют прошивки, либо тратят на это полдня(при этом составляя говно-документацию). Из забавных случаев(без привязки к "личностям"): присылают прошивку, а там внезапно пропадает одна диагностическая команда(довольно полезная), на что приходит ответ, что да, косяк, в следущей версии исправим(про cvs/svn/прочее им неизветно?) или куда смешнее: мы сделали фичу, которую вы просили, вот прошивка, проверьте и скажите нам, за первые две минуты находятся 3 косяка, которые связаны к CLI(новые команды криво записываются в конфиг, не отображаются в диагностике и т.д.), после таких косяков этим новым функционалом страшно пользоваться.

Share this post


Link to post
Share on other sites

Более правильно сказать, что никогда не верьте всем вендорам, у которых R&D и топ-менеджмент находятся в Китае. Каждую(!) фичу, которую планируется использовать надо тщательно оттестировать.

когда мы тестировали хуавеевский брас по программе испытаний, предложенной самим хуавеем(!), половина тестов пройдена не была.

Share this post


Link to post
Share on other sites
me-60? давно это было?

В начале весны было желание купить, притащили его на тест, тест он не прошел.

 

Смотрели в сторону замены нескольких ma5200g-2 на один большой.

 

Функционал ma5200g-2 перенести на ME60 не удалось, но это даже хорошо :-)

Сейчас 2 сервера 1U по 900$ заменяют один ma5200g-2, и железная BRAS-ология нервно курит в сторонке

 

VAS + DAA с NAT-ом одновременно не работают, На vpn-instance-ы хуавей решил забить в этом BRAS-е совсем и у постепенно убирает из прошивок.

 

 

Huawei - это диагноз. :D

Отчасти да:)

 

PS: а не МТТ ли это, со своим чудо-проектом ? :-)

Нет не MTT - но с дизайном MTT знаком - там все гораздо проще:)

Судя по наличию украинских букв, 500 абонентов и 93-й хуавей - это Киев, и с большой долей вероятности это SumTEL :-)

Share this post


Link to post
Share on other sites
Потому что нет необходимоси в подсчете траффика к ресурсам и ограничения скорости к ним. К тому же на BRAS сейчас имееися в наличии только 1 плата содним 10 G интерфейсом для терминации пользовательских сесий - и очень не хочется нагружать ее трафиком к ресурсам, который по задумке является довольно существенным. Пропуск трафика к ресурсам через брас имеет смысл только в том случаии если 93 работает в режиме L2. При єтом все функции агрегации переходят на BRAS. Это черевато огромным кол-вом проблем.

А чем, собственно, чревато терминирование L2 на БРАСе?

К стати, о чем идет речь: PPPoE, IPoE?

Share this post


Link to post
Share on other sites
VAS + DAA с NAT-ом одновременно не работают, На vpn-instance-ы хуавей решил забить в этом BRAS-е совсем и у постепенно убирает из прошивок.
У меня ВАС+ДАА+НАТ работает на ME60 V100R006C05SPC600.

А вот с ВПНами действительно косяк, сейчас терзаю саппорт на эту тему.

Share this post


Link to post
Share on other sites
Главная проблема - это ARP. Так как при приходе пакета на неизвестный адрес (арп отсутствует) арп запрос рассылается во все sub-Vlan которіе пренадлежат данному super vlan. Плюс на все интерфесы на которых настроены эти sub-vlan. Итого для 1 арпа - 48 арпов (так как 48 колец в данный момент, в будущем 512) + 140 арпов (интерфейс между двумя 93 так как в нем прокинуты все sub-vlan для обеспечения доступности VRRP мастера в случаи разріва кольца). Соответственно при запуске одно из коммутаторов огромное кол-во арпов пораждает высокую загрузку процессора (так как при использовании супер влан как оказалась арпі обрабатіваются процессором), что приводит к отказу STP или flap VRRP, которій в свою очередь усугубляет проблему с арпами (так как только VRRP мастер изучает арпы).

Раньше еще имелась проблема с MSTP - при любом измении топологии приходили TCN, который приводил к очистке всех арпов и маков. Это попоролось - теперь при приходе арп не удаляется сразу, а время жизни просто збрасывается в 0. При этом выполняется перезапрос арпа только в нужный интерфейс и лишь в случаи не удачи арп перезапрашивается во всех вланах. Отголоском проблемы отсалась ситуация когда при приходе большого кол-ва TCN в короткое время арпі не успеваю перезапрасится и все таки клирятся(

Есть мнение, что это писец, который, как известно, не излечим...

Хотя можно попробовать увеличить число L3 интерфейсов на агрегации, до максимального значения (сколько групп VRRP поддерживается?). Это уменьшит число sub-Vlan в одном super vlan.

Можно также использовать эти чудо-свичи как L2, и всё терминировать на БРАСах. Вопрос - хватит ли их производительности...

Можно еще пересмотреть выбор вендора на агрегацию ;) Или добавить промежуточную L3 агрегацию, с переносом на неё функционала терминирования абонентов.

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