Как справиться с ухудшением производительности в сети вашего провайдера?

9

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

Я видел две проблемы с использованием IP SLA. Во-первых, то, что нужно измерить, это, по крайней мере, несколько прыжков (далеко за их одноранговым узлом BGP), поэтому мониторинг чего-либо глубоко в сети провайдера не является статичным предложением, например, мониторинг наших связей с ними (которые были стабильными); если ссылки этого провайдера отключены, соглашения об уровне обслуживания все равно будут доступны по пути другого провайдера. Во-вторых, использование монитора типа ICMP не определяет уровень потери пакетов, который обычно наблюдается при использовании пакетов гораздо больших размеров, и задержка, по-видимому, не изменяется значительно.

Является ли Performance Routing (PfR) лучшим вариантом здесь и влияет на локальный префикс BGP? Кажется, что главный контроллер - это SPoF (единая точка отказа), поэтому, если PfR - это путь, как граничные маршрутизаторы не могут зависеть от одного главного контроллера? Какие два или три других жизнеспособных варианта?

Большая часть и наиболее критичная часть нашего трафика связана с нашими исходящими HTTP-ответами.

cisco bgp performance

— generalnetworkerror
источник

Вам помог какой-нибудь ответ? если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.

— Рон Мопин

6

PfR действительно один вариант.

Вариант, с которым у меня лично нет опыта, но я знаю, что люди, использующие их, являются оптимизаторами BGP, которые не зависят от поставщика, поскольку они просто смотрят на BGP, измеряют сеть и вводят маршруты для изменения маршрутизации.

Варианты пары

— ytti
источник

Спасибо за опцию InterNAP FCP и напоминание. У нас есть INAP, подключенный к этим маршрутизаторам, поэтому мы уже имеем с ними отношения.

— generalnetworkerror

7

Если использовать Cisco на периферии, то PfR действительно будет лучшим вариантом по указанным вами причинам. Вы можете настроить резервирование главного контроллера, и Cisco показывает, как по этой ссылке: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/Transport_diversity/PfR_Master_Controller_Redundancy.html

— mellowd
источник

Просто прочитайте эту ссылку: у вас может не быть резервного контроллера в другом месте, или это единственная топология с HSRP между контроллерами? И это, кажется, противоречит тому, что PfR пытается выполнить, если ваш путь от границы к контроллеру ухудшается: «В случае, если пограничный маршрутизатор PfR теряет связь с главным контроллером, пограничный маршрутизатор прекращает управление префиксами или приложениями. Другими словами, Отказоустойчивый режим PfR - удалить любые маршруты, введенные в таблицу IP-маршрутизации или таблицу BGP, и остановить политику маршрутизации приложений, если главный контроллер недоступен. "

— generalnetworkerror

Похоже, HSRP это единственный способ. Это немного глупо в моих книгах, так как Cisco должна быть в состоянии спроектировать PfR для поддержки двух главных контроллеров в двух отдельных подсетях. Вы можете получить VLL / VPLS в другом месте и запустить HSRP через это. Не идеально, но это работает. Любой «растянутый L2» будет работать здесь. Опять же, не идеально, но это будет работать, пока Cisco не соберет свои действия и не разрешит два отдельных контроллера.

— Сладкий