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

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

Добрый день.

 

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

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

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

 

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

post-73868-1281006199_thumb.jpg

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


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

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

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

 

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


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

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

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

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


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

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

думаю при таких масштабах кольцо надо строить 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мс.

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

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

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


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

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

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


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

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

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

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


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

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

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

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

 

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


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

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

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

 

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

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


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

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

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

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

 

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

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


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

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

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

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


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

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

 

 

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

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


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

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

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

 

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

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

 

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

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

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

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

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


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

Хотелось бы услышать предложения по низкоуровневому дизайну сети, особенно интересует уровень агрегации (текущая схема, основанная на 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 знаком - там все гораздо проще:)

 

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


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

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

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

 

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

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

 

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

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

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

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

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

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

 

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


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

почему ресурсы мимо брасов?

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

 

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

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

 

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

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

 

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

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

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

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

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

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

 

 

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

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


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

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

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

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


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

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

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

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

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


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

Никогда не верьте Хуавейцам - каждое их слово нужно перепроверять.

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

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

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

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


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

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

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

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


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

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 :-)

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


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

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

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

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

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


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

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

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

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


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

Главная проблема - это 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 агрегацию, с переносом на неё функционала терминирования абонентов.

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


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

Join the conversation

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

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

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

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

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

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

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