Traffic engineering: различия между версиями
Строка 168: | Строка 168: | ||
forwarding-table { | forwarding-table { | ||
export to-oban-lsps; | export to-oban-lsps; | ||
==LSP Bandwidth management== | |||
===Static LSP bandwidth=== | |||
Задаем для static LSP полосу в ручном режиме. При построении LSP заданная полоса будет резервироваться => если где-то на пути не будет хватить пропускной способности, то LSP не построится. Не самый удобный способ, но все же.. | |||
[edit protocols mpls] | |||
lagavulin# show | |||
label-switched-path lagavulin-to-oban { | |||
to 10.200.86.3; | |||
'''bandwidth 150m;''' | |||
primary via-blair; | |||
===Automatic Bandwidth Allocation=== | |||
Позволяет маршрутизатору мониторить актуальный трафик, проходящий по LSP и изменять конфигурацию этого LSP для поддержания нужного кол-ва трафика. Роутер мониторит пики загрузки за определенный период времени. По истечению данного времени LSP резервирует нужную полосу. Используется make-before-brake и SE-style. | |||
Обычно, даже при использовании дефолтных значений для autobandwidth, конфигурация делается полностью, чтобы иметь понимание по каким правилам работает. | |||
[edit protocols mpls] | |||
lagavulin# show | |||
statistics { | |||
file auto-bw; | |||
interval 600; | |||
auto-bandwidth; | |||
} | |||
label-switched-path lagavulin-to-oban { | |||
to 10.200.86.3; | |||
auto-bandwidth { | |||
adjust-interval 7200; | |||
adjust-threshold 20; | |||
minimum-bandwidth 64k; | |||
maximum-bandwidth 150m; | |||
} | |||
Для того, чтобы вручную обновить и подогнать bandwidth: | |||
request mpls lsp adjust-autobandwidth name lagavulin-to-oban-prime | |||
===Monitor-only=== | |||
Если требуется только мониторинг используемой полосы LSP, без изменения настроек. | |||
[edit protocols mpls] | |||
lagavulin# | |||
show label-switched-path lagavulin-to-oban-prime to 10.200.86.3; | |||
bandwidth 150m; | |||
auto-bandwidth { | |||
adjust-interval 86400; | |||
'''monitor-bandwidth;''' | |||
'''Полезные команды''' | |||
> show ted database 10.200.86.3 | |||
> show mpls lsp name lagavulin-to-oban extensive | |||
10.200.86.3 | |||
From: 10.200.86.7, State: Up, ActiveRoute: 0, LSP name: lagavulin-to-oban ActivePath: via-blair (primary) | |||
'''Max AvgBW util: 111.402Mbps''', Bandwidth Adjustment in 6302 second(s). | |||
*Primary via-blair State:Up Priorities: 7 0 | |||
'''Bandwidth: 90.4322Mbps’’’ | |||
> request mpls lsp adjust-autobandwidth name "lagavulin-to-oban" | |||
> show log messages | match "bandwidth changed" | |||
> show rsvp interface | |||
Обычно ''adjust-interval'' выставляется достаточно большим, из-за этого в случае аварии на сети и увеличении трафика в LSP не сразу происходит подстройка ''bandwidth''. Можно исправить с помощью ''adjust-threshold-overflow-limit''. Позволяет задать лимит на число последовательных переполнений. Когда лимит исчерпан, LSP настраивает bandwidth и таймер adjust-interval обнуляется. | |||
Когда исчерпан лимит: | |||
# Max AvgBW util > LSP bandwidth ? | |||
# Max AvgBW util увеличилось больше чем adjust-threshold? | |||
'''В итоге:''' ''adjust-interval'' - позволяет более точно вручную управлять bandwidth, а ''adjust- threshold-overflow-limit'' - в автоматическом режиме. | |||
{{note|text=''adjust-threshold-overflow-limit'' может только увеличивать полосу, но не уменьшать ее. =)}} | |||
===Most-fill/least-fill/random=== | |||
Определяем относительную разгруженность линка. | |||
{{note|text=available bandwidth ratio = (available bandwidth)/(reservable bandwidth)}} | |||
'''Most fill''' - предпочтительны LSP с наибольшей загрузкой (мало свободной полосы). С низким ''available bandwidth ratio'' | |||
'''Least-fill''' - предпочтительны LSP с наименьшей загрузкой (более свобдны). С высоким ''available bandwidth ratio'' | |||
'''Random''' - поведение по умолчанию. | |||
Хорошим тоном является использование одинакового поведения для всех LSP. | |||
[edit protocols mpls] | |||
lagavulin# show | |||
label-switched-path lagavulin-to-oban { | |||
to 10.200.86.3; | |||
'''most-fill;''' | |||
primary via-blair; | |||
} |
Версия 23:48, 3 ноября 2016
LSP Metrics
Есть возможность задавать статически метки для LSP, аналогично как и для IGP.
[edit protocols mpls] label-switched-path dalwhinnie-to-oban to 10.200.86.3; metric 20; link-protection;
Link coloring
Можно раскрашивать линки в разные цвета и задавать path таким образом, чтобы он шел либо через конкретные цвета или исключая конкретные цвета.
Цвета задаются и назначаются на интерфейсы через admin-groups внутри protocols mpls.
Если не будет возможности построить LSP с заданными ограничениями по цветам, то LSP не построится =).
При построении link protection bypass, выбор пути не будет учитывать предпочтение по цветам, т.к. bypass LSP могут служить резервом для нескольких LPS. Однако, при использовании FRR, цвета будут учитываться.
Если нет требований по цветам, то LSP будет построен без учета этого параметра, вне зависимости от того какими цветами будут раскрашены интерфейсы.
Для корректной работы требуется, чтобы admin-groups были заданы на всех роутерах в MPLS домене одинаково.
Configuration
dalwhinnie> show configuration protocols mpls admin-groups { gold 1; } label-switched-path dalwhinnie-to-oban { to 10.200.86.3; admin-group <include-all|include-any|exclude> gold; } path via-tormore; interface ge-0/0/2.0 { admin-group gold;
Losse, Strict LSP hops
Для primary и secondary LSP можно задавать loose и strict хопы.
Также эти параметры можно задавать и для bypass LSP (внутри protocols rsvp).
Strict - роутер, чей ip мы указываем, должен быть подключен напрямую.
Loose - роутер не должен быть подключен напрямую, между роутерами может быть несколько хопов.
Configuration
dalwhinnie> show configuration protocols mpls label-switched-path dalwhinnie-to-oban { to 10.200.86.3; link-protection; primary via-blair; } path via-blair { 192.168.86.5 strict; 192.168.86.9 strict; 192.168.86.25 strict;
dalwhinnie> show configuration protocols rsvp interface ge-0/0/2.0 { link-protection { path { 192.168.86.29 strict; 192.168.86.1 strict; 192.168.86.41 strict; 192.168.86.46 strict;
Route Table and LSP Integration
Если PE использует next-hop self и т.о. рассылает анонсы внешних сетей, где в качестве next-hop указан его Lo, то проблемы с передачей трафика до внешних сетей через LSP не будет. Т.к. в inet.3 присутствуют туннели до всех Lo внутри нашего домена.
Но если на PE не производится процедур типа next-hop self, то другие роутеры будут посылать трафик до внешних сетей, опираясь на IGP.
Install, active
Насильно указываем сеть, которой принадлежит next-hop, как доступную через LSP.
Пример: CE анонсирует 5.5/16, PE принимает префикс, в качестве next-hop указан ip из p2p сети между PE<>CE - 192.168.90.12/30. Анонс разлетается по всей сети, но про 192.168.90.12/30 другие роутеры знают через IGP.
Чтобы направить трафик до 5.5/16 через LSP, включаем:
[edit protocols mpls] label-switched-path dalwhinnie-to-oban { to 10.200.86.3; install 192.168.90.12/30;
Теперь трафик до 5.5/16 будет идти по LSP, но трафик до 192.168.90.12/30 все-равно пойдет по IGP, из-за того, что BGP только производит resolve next-hop внутри inet.3.
Добавляем active чтобы запись о 192.168.90.12/30, доступная через LSP, переместилась из inet.3 в inet.0, тогда и трафик до 192.168.90.12/30 пойдет через LSP.
[edit protocols mpls] label-switched-path dalwhinnie-to-oban { to 10.200.86.3; install 192.168.90.12/30 active;
Traffic-engineering bgp-igp
Перенесет все маршруты из inet.3 в inet.0. Новые маршруты из inet.3 перекроют старые маршруты из inet.0, т.к. протоколы LDP и RSVP имеют лучший преференс. Этот делается в целях обеспечения всей маршрутизации в сети по mpls-lsp (LDP и RSVP signalled). Но в этом варианте не работают VPN, основанные на MPLS, потому, что таблица Inet3 останется пуста. Применяется не к отдельным LSP, а глобально.
Traffic-engineering bgp-igp-both-ribs
Скопирует маршруты из inet.3 в inet.0. Новые маршруты из inet.3, опять же, перекроют старые маршруты из inet.0, но старые маршруты в inet3 останутся, поэтому этот способ годится, если в сети нужны VPN-сервисы.
Traffic-engineering mpls-forwarding
Скопирует все маршруты из inet.3 в inet.0, но и старые маршруты в inet.0 оставит для совместимости с некоторыми политиками маршрутизации. Однако, фактически, форвардинг будет происходить по новым маршрутам. Для индикации итого, какие маршруты в inet.0 для форвардинга трафика, а какие чисто инфомративные, есть дополнительные обозначения (#|@) в выводе show route:
> show route 10.200.86.3 inet.0: 29 destinations, 38 routes (29 active, 1 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 10.200.86.3/32 @[OSPF/10] 00:25:58, metric 3 > to 192.168.86.5 via ge-0/0/0.20 #[RSVP/7/1] 00:20:06, metric 3 > to 192.168.86.5 via ge-0/0/0.20, label-switched-path dalwhinnie-to-oban [LDP/9] 00:02:30, metric 1 > to 192.168.86.5 via ge-0/0/0.20, Push 300288
IGP shortcuts
Благодаря настройкам выше трафик до Lo идет через LSP, но трафик где next-hop = ip p2p линка, все еще используется IGP.
[edit protocols ospf] set traffic-engineering shotcuts
[edit protocols isis] set traffic-engineering family inet shortcuts
Минусы:
- Нет контроля, в отличие от install, active.
- Требуется настройка на всех роутеров в домене.
Advertising LSPs directly into the IGP
Внутри протокола IGP задаем LSP, аналогично интерфейсам, с определенной метрикой. Не забываем, что LSP однонаправленные => требуется аналогичные LSP построить в обратном направлении.
IGP будет распространять маршрут как: LSA 1 Type / ISIS TLVs.
[edit protocols ospf] lagavulin# show traffic-engineering; area 0.0.0.0 { interface lo0.0; label-switched-path lagavulin-to-oban { metric 2; } label-switched-path lagavulin-to-tormore { metric 2; } }
Обычно одновременно не используют IGP shotcuts и LSP advertisment into IGP.
Policy-based LSP
Назначаем конкретным префиксам next-hop в качестве конкретной LSP. Хорошо подходит для случаев, когда на сет между двумя хостами есть несколько LSP и нужно распределить трафик между ними.
Может метод не очень масштабируемый, но для определенных задач подходит идеально.
[edit policy-options] lagavulin# show policy-statement to-oban-lsps { term 1 { from { protocol bgp; route-filter 172.16.0.0/24 orlonger; route-filter 172.16.1.0/24 orlonger; } then { install-nexthop lsp lagavulin-to-oban-1; accept; } } term 2 { from { protocol bgp; route-filter 172.16.2.0/24 orlonger; route-filter 172.16.3.0/24 orlonger; } then { install-nexthop lsp lagavulin-to-oban-2; accept; } [edit routing-options] lagavulin# show forwarding-table { export to-oban-lsps;
LSP Bandwidth management
Static LSP bandwidth
Задаем для static LSP полосу в ручном режиме. При построении LSP заданная полоса будет резервироваться => если где-то на пути не будет хватить пропускной способности, то LSP не построится. Не самый удобный способ, но все же..
[edit protocols mpls] lagavulin# show label-switched-path lagavulin-to-oban { to 10.200.86.3; bandwidth 150m; primary via-blair;
Automatic Bandwidth Allocation
Позволяет маршрутизатору мониторить актуальный трафик, проходящий по LSP и изменять конфигурацию этого LSP для поддержания нужного кол-ва трафика. Роутер мониторит пики загрузки за определенный период времени. По истечению данного времени LSP резервирует нужную полосу. Используется make-before-brake и SE-style.
Обычно, даже при использовании дефолтных значений для autobandwidth, конфигурация делается полностью, чтобы иметь понимание по каким правилам работает.
[edit protocols mpls] lagavulin# show statistics { file auto-bw; interval 600; auto-bandwidth; } label-switched-path lagavulin-to-oban { to 10.200.86.3; auto-bandwidth { adjust-interval 7200; adjust-threshold 20; minimum-bandwidth 64k; maximum-bandwidth 150m; }
Для того, чтобы вручную обновить и подогнать bandwidth:
request mpls lsp adjust-autobandwidth name lagavulin-to-oban-prime
Monitor-only
Если требуется только мониторинг используемой полосы LSP, без изменения настроек.
[edit protocols mpls] lagavulin# show label-switched-path lagavulin-to-oban-prime to 10.200.86.3; bandwidth 150m; auto-bandwidth { adjust-interval 86400; monitor-bandwidth;
Полезные команды
> show ted database 10.200.86.3 > show mpls lsp name lagavulin-to-oban extensive 10.200.86.3 From: 10.200.86.7, State: Up, ActiveRoute: 0, LSP name: lagavulin-to-oban ActivePath: via-blair (primary) Max AvgBW util: 111.402Mbps, Bandwidth Adjustment in 6302 second(s). *Primary via-blair State:Up Priorities: 7 0 Bandwidth: 90.4322Mbps’’’ > request mpls lsp adjust-autobandwidth name "lagavulin-to-oban" > show log messages | match "bandwidth changed" > show rsvp interface
Обычно adjust-interval выставляется достаточно большим, из-за этого в случае аварии на сети и увеличении трафика в LSP не сразу происходит подстройка bandwidth. Можно исправить с помощью adjust-threshold-overflow-limit. Позволяет задать лимит на число последовательных переполнений. Когда лимит исчерпан, LSP настраивает bandwidth и таймер adjust-interval обнуляется.
Когда исчерпан лимит:
- Max AvgBW util > LSP bandwidth ?
- Max AvgBW util увеличилось больше чем adjust-threshold?
В итоге: adjust-interval - позволяет более точно вручную управлять bandwidth, а adjust- threshold-overflow-limit - в автоматическом режиме.
adjust-threshold-overflow-limit может только увеличивать полосу, но не уменьшать ее. =)
Most-fill/least-fill/random
Определяем относительную разгруженность линка.
available bandwidth ratio = (available bandwidth)/(reservable bandwidth)
Most fill - предпочтительны LSP с наибольшей загрузкой (мало свободной полосы). С низким available bandwidth ratio
Least-fill - предпочтительны LSP с наименьшей загрузкой (более свобдны). С высоким available bandwidth ratio
Random - поведение по умолчанию.
Хорошим тоном является использование одинакового поведения для всех LSP.
[edit protocols mpls] lagavulin# show label-switched-path lagavulin-to-oban { to 10.200.86.3; most-fill; primary via-blair; }