Traffic engineering: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
м
 
(не показано 55 промежуточных версий этого же участника)
Строка 1: Строка 1:
==CSPF==
{{#description2:CSPF алгоритм. LSP Metrics. Link coloring. Losse, Strict LSP hops. LSP Bandwidth. LSP Install, active. IGP shortcuts. Traffic-engineering bgp. Policy-based LSP. LSP TTL. Информация для подготовки к экзаменам Juniper.}}
'''TED''' содержит в себе:
* топологию
* bandwidth
* colors


=CSPF=
'''CSPF''' - способ автоматически рассчитать explicit path.
'''CSPF''' - способ автоматически рассчитать explicit path.
*Модифицированный shortest-path-first алгоритм.
*Интегрирует TED данные: IGP топология, доступная полоса, административные группы. Определяет оптимальный путь и порядок настройки в зависимости от ограничений юзера.
*Убирает из пути неподходящие линки, а на основании подходящих линков производит поиск кратчайшего пути.


Без CSPF туннель будет построен по кратчайшему пути IGP.
==Без CSPF==
(просто задаем все параметры руками):
*Запрашивает резервирование ресурсов у нижестоящих роутеров и оповещение этих роутеров как и где будет установлена сессия.
*Некоторые объекты используются для определения что требуется зарезервировать:
:*Label object: резервирует MPLS label
:*Sender Tspec Object: запрашивает зарезервированную полосу
*ERO:
:*Когда ERO не задан руками, path message оправляется с пустым ERO по кратчайшему пути IGP.
:*Чтобы ERO не передавался пустым, его требуется задать руками.
*Bandwidt reservation (Сигнализируется Sender Tspec объектом):
:* Каждый роутер по пути определяет сможет ли он выделить нужную полосу. Если нет возможности, то LSP не устанавливается.
:* По умолчанию, LSR не полисит трафик, а просто выделяет требуемую полосу. Можно включить:
[protocols mpls]
'''auto-policing class all drop'''
либо
[protocols mpls label-switched-path lagavulin-to-oban]
to 10.200.86.3
bandwidth 35m
no-cspf
'''policing filter 35m'''


TE работает в рамках одной area. Чтобы не нарушать само понятие area. Но есть функции, которые дают возможность строить туннели между area (но при этом все-равно не будут работать функции защиты трафика).
==При включенном CSPF==
На ''ingress router'' с включенным CSPF будет воспроизведен следующий алгоритм:
На ''ingress router'' с включенным CSPF будет воспроизведен следующий алгоритм:
#За актуальной топологией сети следит IGP и передает информацию в TED через расширение IGP
#За актуальной топологией сети следит IGP и передает информацию в TED через расширение IGP (для ISIS - TLV tuples, для OSPF LSA Type 10)
#Топология сети хранится в TED
#Топология сети хранится в TED
#Инженер задает условия для построения туннеля
#Инженер задает условия для построения туннеля
Строка 16: Строка 38:
#Роутер создает ERO
#Роутер создает ERO
#Роутер передает ERO в RSVP, чтобы построить туннель
#Роутер передает ERO в RSVP, чтобы построить туннель
'''TED''' содержит в себе:
* топологию
* bandwidth
* colors
* link priority info
  show ted database extensive
  show ted database extensive


===CSPF алгоритм===
'''Какие ограничения может задать инженер''':
#Отбрасываем линки в недостаточной полосой
*bandiwdth
*hop count
*administrative groups (colors)
*priority
*explicit route
 
==CSPF алгоритм==
#Отбрасываем линки с недостаточной полосой
#Отбрасываем линки, не содержащие ''include color''
#Отбрасываем линки, не содержащие ''include color''
#Отбрасываем линки, содержащие ''exclude color''
#Отбрасываем линки, содержащие ''exclude color''
Строка 27: Строка 62:
#Роутер передает рассчитанный ERO к RSVP
#Роутер передает рассчитанный ERO к RSVP


==LSP Metrics==
=LSP Metrics=
Есть возможность задавать статически метки для LSP, аналогично как и для IGP.
По дефолту CSPF использует метрики кратчайшего IGP пути (или te-metric в случае с IS-IS).


Но эти значения можно переписать с помощью статических метрик.
Есть возможность задавать статические метки для LSP, аналогично как и для IGP. Можно использовать для разделения основная/резервная LSP.
Также есть возможность задать метрику и для LSP в рамках IGP протокола. Но лучше использовать метрику только в одном месте, во избежание неверного форвардинга.
  [edit protocols mpls]
  [edit protocols mpls]
     label-switched-path dalwhinnie-to-oban
     label-switched-path dalwhinnie-to-oban
Строка 36: Строка 76:
     link-protection;
     link-protection;


==Link coloring==
=Link coloring=
Поддерживается 32 административных группы. Admin groups хранятся в TED.
 
Можно ''раскрашивать'' линки в разные цвета и задавать path таким образом, чтобы он шел либо через конкретные цвета или исключая конкретные цвета.
Можно ''раскрашивать'' линки в разные цвета и задавать path таким образом, чтобы он шел либо через конкретные цвета или исключая конкретные цвета.


Цвета задаются и назначаются на интерфейсы через ''admin-groups'' внутри ''protocols mpls''.  
Цвета задаются и назначаются на интерфейсы через ''admin-groups'' внутри ''protocols mpls''.  
Интерфейс без настроенной admin-group - не принадлежит ни к одной из групп. '''[не используется для LSP как с include, так и с exclude параметрами]'''


Если не будет возможности построить LSP с заданными ограничениями по цветам, то LSP не построится =).
Если не будет возможности построить LSP с заданными ограничениями по цветам, то LSP не построится =).
Строка 47: Строка 91:


Для корректной работы требуется, чтобы ''admin-groups'' были заданы на всех роутерах в MPLS домене одинаково.
Для корректной работы требуется, чтобы ''admin-groups'' были заданы на всех роутерах в MPLS домене одинаково.
===Configuration===


При изменении admin group на интерфейсе, идущие через него LSP не будут из-за этого сразу же перестроены. Но новые LSP будут естественно строится в соответствие с этими настройками.
При изменении admin group для LSP, она сразу же перестроится.
==Configuration==
Можно настроить как на LSP, так и на path (primary или secondary)
  dalwhinnie> show configuration protocols mpls
  dalwhinnie> show configuration protocols mpls
     '''admin-groups {
     '''admin-groups {
Строка 60: Строка 109:
       '''admin-group gold;'''
       '''admin-group gold;'''


==Losse, Strict LSP hops==
Логика при использовании нескольких цветов:
Параметры поля ERO (explicit rote object). '''Ручной TE'''.
'''между строками - Logical AND'''
[edit protocols mpls label-switched-path test to 10.200.86.3]
set admin-group include-all [gold bronze] - '''Logical AND'''
set admin-group include-any [customer premium] - '''Logical OR'''
set admin-group exclude [red green] - '''Logical OR'''
 
=Losse, Strict LSP hops=
Параметры поля ERO (explicit route object). '''Ручной TE'''.


Для primary и secondary LSP можно задавать ''loose'' и ''strict'' хопы. Порядок имеет значение.
Для primary и secondary LSP можно задавать ''loose'' и ''strict'' хопы. Порядок имеет значение.
Строка 67: Строка 123:
Также эти параметры можно задавать и для bypass LSP (внутри protocols rsvp).
Также эти параметры можно задавать и для bypass LSP (внутри protocols rsvp).


'''Strict''' - роутер, чей ip мы указываем, должен быть подключен напрямую. Ищем среди direct адресов нашего роутера. Указываем ip из p2p сети с соседом (на некоторых прошивках можно и Lo, но лучше не рисковать).
'''Strict''' - роутер, чей ip мы указываем, должен быть подключен напрямую. Ищем среди direct адресов нашего роутера. Указываем ip из p2p сети с соседом (на некоторых версиях софта можно и Lo, но лучше не рисковать).


'''Loose''' - существует где-то в сети, без разницы как маршрут дойдёт до него, как пойдёт после него, важно, чтобы путь построился через него. Lo этого роутера будет доступен через IGP. В ERO до loose туннель будет построен по метрикам, после loose - тоже по метрикам. Указываем Lo желаемого роутера.
'''Loose''' - существует где-то в сети, без разницы как маршрут дойдёт до него, как пойдёт после него, важно, чтобы путь построился через него. Lo этого роутера будет доступен через IGP. В ERO до loose туннель будет построен по метрикам, после loose - тоже по метрикам. Указываем Lo желаемого роутера.
Строка 73: Строка 129:
Если задаём ''path'' с помощью strict, то лучше указать полностью все хопы пути.
Если задаём ''path'' с помощью strict, то лучше указать полностью все хопы пути.


===Configuration===
Если в path для хопов явно не указываем loos/strict и т.п., то по дефолту хоп будет использоваться как strict.
 
==Configuration==
  dalwhinnie> show configuration protocols mpls
  dalwhinnie> show configuration protocols mpls
  label-switched-path dalwhinnie-to-oban {
  label-switched-path dalwhinnie-to-oban {
Строка 94: Строка 152:
       192.168.86.46 strict;
       192.168.86.46 strict;


==Route Table and LSP Integration==
=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;    - min полоса для LSP
      maximum-bandwidth 150m; - max полоса для LSP
}
 
*adjust-interval - по окончанию интервала - процесс вычисления полосы и перестроение LSP
*adjust-threshold 20 - процентное значение отклонения от настроенной static bandwidth на LSP. Если после перерасчета полосы разница между статик bandwidth и рассчитанной >= adjust-threshold, то LSP переустанавливается.
 
MPLS statistics обязательно должна быть включена, чтобы работала auto-bandwidth.
 
 
Для того, чтобы вручную обновить и подогнать 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)}}
 
Пример рассчета available bandwidth ratio для 1G линка, при зарезервированной полосе 430 Мбит:
 
'''(1000-430)/1000 = 57'''
 
57 - процент свободной полосы линка.
 
'''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;}
 
=Route Table and LSP Integration=
Если PE использует next-hop self и т.о. рассылает анонсы внешних сетей, где в качестве next-hop указан его Lo, то проблемы с передачей трафика до внешних сетей через LSP не будет. Т.к. в inet.3 присутствуют туннели до всех Lo внутри нашего домена.
Если PE использует next-hop self и т.о. рассылает анонсы внешних сетей, где в качестве next-hop указан его Lo, то проблемы с передачей трафика до внешних сетей через LSP не будет. Т.к. в inet.3 присутствуют туннели до всех Lo внутри нашего домена.


Но если на PE не производится процедур типа next-hop self, то другие роутеры будут посылать трафик до внешних сетей, опираясь на IGP.
Но если на PE не производится процедур типа next-hop self, то другие роутеры будут посылать трафик до внешних сетей, опираясь на IGP.


===Install, active===
==Install, active==
Насильно указываем сеть, которой принадлежит next-hop, как доступную через LSP.
Насильно указываем сеть, которой принадлежит next-hop, как доступную через LSP.


Строка 109: Строка 263:
  to 10.200.86.3;
  to 10.200.86.3;
  '''install 192.168.90.12/30;'''
  '''install 192.168.90.12/30;'''
Теперь трафик до 5.5/16 будет идти по LSP, но трафик до 192.168.90.12/30 все-равно пойдет по IGP, из-за того, что BGP только производит resolve next-hop внутри inet.3.
Теперь трафик до 5.5/16 будет идти по LSP, но трафик до 192.168.90.12/30 все-равно пойдет по IGP, из-за того, что BGP производит только resolve next-hop внутри inet.3. То есть по сути ''Active'' дает возможность использовать LSP для форвардинга, используя inet.3.


Добавляем ''active'' чтобы запись о 192.168.90.12/30, доступная через LSP, переместилась из inet.3 в inet.0, тогда и трафик до 192.168.90.12/30 пойдет через LSP.
Добавляем ''active'' чтобы запись о 192.168.90.12/30, доступная через LSP, переместилась из inet.3 в inet.0, тогда и трафик до 192.168.90.12/30 пойдет через LSP.
Строка 117: Строка 271:
  '''install 192.168.90.12/30 active;'''
  '''install 192.168.90.12/30 active;'''


===Traffic-engineering bgp-igp===
==IGP shortcuts==
'''Перенесет''' все маршруты из inet.3 в inet.0. Новые маршруты из inet.3 перекроют старые маршруты из inet.0, т.к. протоколы LDP и RSVP имеют лучший преференс.
Благодаря настройкам выше трафик до Lo идет через LSP, но трафик где next-hop = ip p2p линка, все еще используется IGP.
Этот делается в целях обеспечения всей маршрутизации в сети по mpls-lsp (LDP и RSVP signalled). Но в этом варианте не работают VPN, основанные на MPLS,
[edit protocols ospf]
потому, что таблица Inet3 останется пуста. Применяется не к отдельным LSP, а глобально.
set traffic-engineering shotcuts
 
[edit protocols isis]
set traffic-engineering family inet shortcuts
 
Минусы:
# Нет контроля, в отличие от ''install'', ''active''.
# Требуется настройка на всех роутерах в домене.
 
==Traffic-engineering bgp==
Дефолтное поведение.


===Traffic-engineering bgp-igp-both-ribs===
==Traffic-engineering bgp-igp==
'''Скопирует''' маршруты из inet.3 в inet.0. Новые маршруты из inet.3, опять же, перекроют старые маршруты из inet.0,
'''Перенесет''' все маршруты из inet.3 в inet.0. Прилетевшие новые маршруты из inet.3 перекроют старые аналогичные маршруты из inet.0, т.к. протоколы LDP и RSVP имеют лучший preference.
но старые маршруты в inet3 останутся, поэтому этот способ годится, если в сети нужны VPN-сервисы.


===Traffic-engineering mpls-forwarding===
Этот метод используется в целях обеспечения всей маршрутизации в сети по mpls-lsp (LDP и RSVP signalled).
'''Скопирует''' все маршруты из inet.3 в inet.0, но и старые маршруты в inet.0 оставит для совместимости с некоторыми политиками маршрутизации. Однако, фактически, форвардинг будет происходить по новым маршрутам.
 
Для индикации итого, какие маршруты в inet.0 для форвардинга трафика, а какие чисто инфомративные, есть дополнительные обозначения (#|@) в выводе show route:
Но в этом варианте не работают VPN, основанные на MPLS [Inet.3 теперь пуста]. Применяется не к отдельным LSP, а глобально.
 
[edit protocols mpls]
traffic-engineering ?
    bgp
    '''bgp-igp'''
    bgp-igp-both-ribs
    mspl-forwarding
 
==Traffic-engineering bgp-igp-both-ribs==
'''Скопирует''' маршруты из inet.3 в inet.0.  Прилетевшие новые маршруты из inet.3, опять же, '''перекроют''' старые аналогичные маршруты из inet.0.
 
Но в inet.3 старые маршруты останутся, поэтому этот способ годится, если в сети нужны VPN-сервисы.
[edit protocols mpls]
traffic-engineering ?
    bgp
    bgp-igp
    '''bgp-igp-both-ribs'''
    mspl-forwarding
 
==Traffic-engineering mpls-forwarding==
'''Скопирует''' все маршруты из inet.3 в inet.0, но и старые маршруты в inet.0 оставит для совместимости с некоторыми политиками маршрутизации (то есть эта функция убирает "затмение IGP маршрутов"). Однако, фактически, форвардинг будет происходить по новым маршрутам.
Для индикации того, какие маршруты в inet.0 для форвардинга трафика, а какие чисто информативные, есть дополнительные обозначения (#|@) в выводе show route:
  > show route 10.200.86.3           
  > show route 10.200.86.3           
  inet.0: 29 destinations, 38 routes (29 active, 1 holddown, 0 hidden)
  inet.0: 29 destinations, 38 routes (29 active, 1 holddown, 0 hidden)
  @ = Routing Use Only, # = Forwarding Use Only
  @ = Routing Use Only, # = Forwarding Use Only
  + = Active Route, - = Last Active, * = Both
  + = Active Route, - = Last Active, * = Both
  10.200.86.3/32    @[OSPF/10] 00:25:58, metric 3
  10.200.86.3/32    @[OSPF/10] 00:25:58, metric 3
                     > to 192.168.86.5 via ge-0/0/0.20
                     > to 192.168.86.5 via ge-0/0/0.20
Строка 140: Строка 325:
                     [LDP/9] 00:02:30, metric 1
                     [LDP/9] 00:02:30, metric 1
                     > to 192.168.86.5 via ge-0/0/0.20, Push 300288
                     > 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


Минусы:
=Advertising LSPs directly into the IGP=
# Нет контроля, в отличие от ''install'', ''active''.
Позволяет передавать информацию об LSP, как о p2p интерфейсе. Это позволяет upstream роутеру использовать LSP для рассчета кратчайшего пути.
# Требуется настройка на всех роутеров в домене.


===Advertising LSPs directly into the IGP===
Внутри протокола IGP задаем LSP, аналогично интерфейсам, с определенной метрикой. Не забываем, что LSP однонаправленные  => требуется аналогичные LSP построить в обратном направлении.
Внутри протокола IGP задаем LSP, аналогично интерфейсам, с определенной метрикой. Не забываем, что LSP однонаправленные  => требуется аналогичные LSP построить в обратном направлении.


Строка 166: Строка 342:
{{note|text=Обычно одновременно не используют IGP shotcuts и LSP advertisment into IGP.}}
{{note|text=Обычно одновременно не используют IGP shotcuts и LSP advertisment into IGP.}}


===Policy-based LSP===
=Policy-based LSP=
Назначаем конкретным префиксам next-hop в качестве конкретной LSP. Хорошо подходит для случаев, когда на сет между двумя хостами есть несколько LSP и нужно распределить трафик между ними.
Назначаем конкретным префиксам next-hop конкретную LSP. Хорошо подходит для случаев, когда на сети между двумя хостами есть несколько LSP и нужно распределить трафик между ними.


Может метод не очень масштабируемый, но для определенных задач подходит идеально.
Может метод не очень масштабируемый, но для определенных задач подходит идеально.
Строка 177: Строка 353:
       from {
       from {
           protocol bgp;
           protocol bgp;
           route-filter 172.16.0.0/24 orlonger; route-filter 172.16.1.0/24 orlonger;
           route-filter 172.16.0.0/24 orlonger;  
          route-filter 172.16.1.0/24 orlonger;
       }  
       }  
       then {
       then {
Строка 187: Строка 364:
       from {
       from {
           protocol bgp;
           protocol bgp;
           route-filter 172.16.2.0/24 orlonger; route-filter 172.16.3.0/24 orlonger;
           route-filter 172.16.2.0/24 orlonger;  
          route-filter 172.16.3.0/24 orlonger;
       }  
       }  
       then {
       then {
Строка 198: Строка 376:
     export to-oban-lsps;
     export to-oban-lsps;


==LSP Bandwidth management==
=TTL=
По умолчанию передается физическая скорость интерфейса, но можно менять.
===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===
==default==
Позволяет маршрутизатору мониторить актуальный трафик, проходящий по LSP и изменять конфигурацию этого LSP для поддержания нужного кол-ва трафика. Роутер мониторит пики загрузки за определенный период времени. По истечению данного времени LSP резервирует нужную полосу. Используется make-before-brake и SE-style.
*По дефолту на каждом хопе (и внутри lsp тоже) значение ttl = 1.
*При этом не ingerss роутере IP TTL копируется в MPLS TTL, при прохождении через LSP -1, IP TTL остается неизменным. На egress роутере значение TTL копируется обратно из MPLS в IP.


Обычно, даже при использовании дефолтных значений для autobandwidth, конфигурация делается полностью, чтобы иметь понимание по каким правилам работает.
==no-decrement-ttl==
*Только для Juniper.
*Только на ingress роутере.
*Можно применять в разные иерархии (глобально mpls, lsp, path)
*IP TTL уменьшается только на egress роутере.
*MPLS TTL устанавливается в 255, значение MPLS TTL не перезаписывается в IP TTL.
*Работает только для RSVP.


[edit protocols mpls]
'''До'''
lagavulin# show
  P1-2> traceroute 172.21.2.1 source 10.12.0.1    
  statistics {
  traceroute to 172.21.2.1 (172.21.2.1) from 10.12.0.1, 30 hops max, 40 byte packets
    file auto-bw;
  1  192.168.0.37 (192.168.0.37)  20.150 ms  19.244 ms  14.906 ms
    interval 600;
2  172.30.0.45 (172.30.0.45)  20.139 ms  19.538 ms  14.947 ms
   auto-bandwidth;
    MPLS Label=300368 CoS=0 TTL=1 S=1
  }
  3  172.30.0.17 (172.30.0.17)  29.722 ms  29.692 ms  29.925 ms
  label-switched-path lagavulin-to-oban {
    MPLS Label=300624 CoS=0 TTL=1 S=1
    to 10.200.86.3;
4  172.30.0.14 (172.30.0.14)  34.978 ms  34.501 ms  30.472 ms
    auto-bandwidth {
  5  172.21.2.1 (172.21.2.1)  40.131 ms  45.097 ms  39.280 ms
      adjust-interval 7200;
      adjust-threshold 20;  
      minimum-bandwidth 64k;
      maximum-bandwidth 150m;
  }


Для того, чтобы вручную обновить и подогнать bandwidth:
'''После'''
  request mpls lsp adjust-autobandwidth name lagavulin-to-oban-prime
  P1-2> traceroute 172.21.2.1 source 10.12.0.1   
traceroute to 172.21.2.1 (172.21.2.1) from 10.12.0.1, 30 hops max, 40 byte packets
1  192.168.0.37 (192.168.0.37)  14.851 ms  15.075 ms  9.682 ms
2  172.30.0.14 (172.30.0.14)  35.521 ms  33.829 ms  29.991 ms
3  172.21.2.1 (172.21.2.1)  40.235 ms  29.352 ms  39.868 ms


===Monitor-only===
==no-propogate-ttl==
Если требуется только мониторинг используемой полосы LSP, без изменения настроек.
*Мультивендорная фича.
*Должна быть сконфигурирована на egress роутере, а т.к. им может стать любой роутер => конфигурируем на всех роутерах.
*Применяется только глобально в protocol mpls иерархии.
*Если LSP уже установлен, то после применения команды, то к нему не применится команда.
*Работает и для RSVP и для LDP.
==no-vrf-propogate-ttl==
*Включаем внутри VRF.
*В документации точно не нашла где включать, но у меня заработало при включении на ingress внутри VRF. На egress при этом не была включена эта функция.
set routing-instances ce1 no-vrf-propagate-ttl


[edit protocols mpls]
=Дополнительная информация=
lagavulin#
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
show label-switched-path lagavulin-to-oban-prime to 10.200.86.3;
*[[Отказоустойчивость и оптимизация в MPLS]]
    bandwidth 150m;
*[[Реализация MPLS в ядре сети]]
    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;
}

Текущая версия на 18:28, 15 июля 2021


CSPF

CSPF - способ автоматически рассчитать explicit path.

  • Модифицированный shortest-path-first алгоритм.
  • Интегрирует TED данные: IGP топология, доступная полоса, административные группы. Определяет оптимальный путь и порядок настройки в зависимости от ограничений юзера.
  • Убирает из пути неподходящие линки, а на основании подходящих линков производит поиск кратчайшего пути.

Без CSPF

(просто задаем все параметры руками):

  • Запрашивает резервирование ресурсов у нижестоящих роутеров и оповещение этих роутеров как и где будет установлена сессия.
  • Некоторые объекты используются для определения что требуется зарезервировать:
  • Label object: резервирует MPLS label
  • Sender Tspec Object: запрашивает зарезервированную полосу
  • ERO:
  • Когда ERO не задан руками, path message оправляется с пустым ERO по кратчайшему пути IGP.
  • Чтобы ERO не передавался пустым, его требуется задать руками.
  • Bandwidt reservation (Сигнализируется Sender Tspec объектом):
  • Каждый роутер по пути определяет сможет ли он выделить нужную полосу. Если нет возможности, то LSP не устанавливается.
  • По умолчанию, LSR не полисит трафик, а просто выделяет требуемую полосу. Можно включить:
[protocols mpls]
auto-policing class all drop

либо

[protocols mpls label-switched-path lagavulin-to-oban]
to 10.200.86.3
bandwidth 35m
no-cspf
policing filter 35m

TE работает в рамках одной area. Чтобы не нарушать само понятие area. Но есть функции, которые дают возможность строить туннели между area (но при этом все-равно не будут работать функции защиты трафика).

При включенном CSPF

На ingress router с включенным CSPF будет воспроизведен следующий алгоритм:

  1. За актуальной топологией сети следит IGP и передает информацию в TED через расширение IGP (для ISIS - TLV tuples, для OSPF LSA Type 10)
  2. Топология сети хранится в TED
  3. Инженер задает условия для построения туннеля
  4. CSPF рассчитывает кратчайший путь, учитывая заданные ограничения инженера
  5. Роутер создает ERO
  6. Роутер передает ERO в RSVP, чтобы построить туннель

TED содержит в себе:

  • топологию
  • bandwidth
  • colors
  • link priority info
show ted database extensive

Какие ограничения может задать инженер:

  • bandiwdth
  • hop count
  • administrative groups (colors)
  • priority
  • explicit route

CSPF алгоритм

  1. Отбрасываем линки с недостаточной полосой
  2. Отбрасываем линки, не содержащие include color
  3. Отбрасываем линки, содержащие exclude color
  4. Рассчитываем кратчайший путь по IGP, но с учетом ERO, если задан
  5. Если в результате получилось несколько path, то выбираем с наименьшим кол-вом хопов
  6. Если все-равно осталось несколько вариантов, то по дефолту path выбирается случайным образом. Не дефолт: most-fill/least-fill.
  7. Роутер передает рассчитанный ERO к RSVP

LSP Metrics

По дефолту CSPF использует метрики кратчайшего IGP пути (или te-metric в случае с IS-IS).

Но эти значения можно переписать с помощью статических метрик.

Есть возможность задавать статические метки для LSP, аналогично как и для IGP. Можно использовать для разделения основная/резервная LSP.

Также есть возможность задать метрику и для LSP в рамках IGP протокола. Но лучше использовать метрику только в одном месте, во избежание неверного форвардинга.

[edit protocols mpls]
   label-switched-path dalwhinnie-to-oban
   to 10.200.86.3;
   metric 20;
   link-protection;

Link coloring

Поддерживается 32 административных группы. Admin groups хранятся в TED.

Можно раскрашивать линки в разные цвета и задавать path таким образом, чтобы он шел либо через конкретные цвета или исключая конкретные цвета.

Цвета задаются и назначаются на интерфейсы через admin-groups внутри protocols mpls.

Интерфейс без настроенной admin-group - не принадлежит ни к одной из групп. [не используется для LSP как с include, так и с exclude параметрами]

Если не будет возможности построить LSP с заданными ограничениями по цветам, то LSP не построится =).

При построении link protection bypass, выбор пути не будет учитывать предпочтение по цветам, т.к. bypass LSP могут служить резервом для нескольких LPS. Однако, при использовании FRR, цвета будут учитываться.

Если нет требований по цветам, то LSP будет построен без учета этого параметра, вне зависимости от того какими цветами будут раскрашены интерфейсы.

Для корректной работы требуется, чтобы admin-groups были заданы на всех роутерах в MPLS домене одинаково.

При изменении admin group на интерфейсе, идущие через него LSP не будут из-за этого сразу же перестроены. Но новые LSP будут естественно строится в соответствие с этими настройками.

При изменении admin group для LSP, она сразу же перестроится.

Configuration

Можно настроить как на LSP, так и на path (primary или secondary)

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;
   }
   interface ge-0/0/2.0 {
      admin-group gold;

Логика при использовании нескольких цветов:

между строками - Logical AND
[edit protocols mpls label-switched-path test to 10.200.86.3]
set admin-group include-all [gold bronze] - Logical AND
set admin-group include-any [customer premium] - Logical OR
set admin-group exclude [red green] - Logical OR

Losse, Strict LSP hops

Параметры поля ERO (explicit route object). Ручной TE.

Для primary и secondary LSP можно задавать loose и strict хопы. Порядок имеет значение.

Также эти параметры можно задавать и для bypass LSP (внутри protocols rsvp).

Strict - роутер, чей ip мы указываем, должен быть подключен напрямую. Ищем среди direct адресов нашего роутера. Указываем ip из p2p сети с соседом (на некоторых версиях софта можно и Lo, но лучше не рисковать).

Loose - существует где-то в сети, без разницы как маршрут дойдёт до него, как пойдёт после него, важно, чтобы путь построился через него. Lo этого роутера будет доступен через IGP. В ERO до loose туннель будет построен по метрикам, после loose - тоже по метрикам. Указываем Lo желаемого роутера.

Если задаём path с помощью strict, то лучше указать полностью все хопы пути.

Если в path для хопов явно не указываем loos/strict и т.п., то по дефолту хоп будет использоваться как strict.

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;

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;    - min полоса для LSP
      maximum-bandwidth 150m; - max полоса для LSP
}
  • adjust-interval - по окончанию интервала - процесс вычисления полосы и перестроение LSP
  • adjust-threshold 20 - процентное значение отклонения от настроенной static bandwidth на LSP. Если после перерасчета полосы разница между статик bandwidth и рассчитанной >= adjust-threshold, то LSP переустанавливается.

MPLS statistics обязательно должна быть включена, чтобы работала auto-bandwidth.


Для того, чтобы вручную обновить и подогнать 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 обнуляется.

Когда исчерпан лимит:

  1. Max AvgBW util > LSP bandwidth ?
  2. 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)

Пример рассчета available bandwidth ratio для 1G линка, при зарезервированной полосе 430 Мбит:

(1000-430)/1000 = 57

57 - процент свободной полосы линка.

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;}

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 дает возможность использовать LSP для форвардинга, используя 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;

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

Минусы:

  1. Нет контроля, в отличие от install, active.
  2. Требуется настройка на всех роутерах в домене.

Traffic-engineering bgp

Дефолтное поведение.

Traffic-engineering bgp-igp

Перенесет все маршруты из inet.3 в inet.0. Прилетевшие новые маршруты из inet.3 перекроют старые аналогичные маршруты из inet.0, т.к. протоколы LDP и RSVP имеют лучший preference.

Этот метод используется в целях обеспечения всей маршрутизации в сети по mpls-lsp (LDP и RSVP signalled).

Но в этом варианте не работают VPN, основанные на MPLS [Inet.3 теперь пуста]. Применяется не к отдельным LSP, а глобально.

[edit protocols mpls]
traffic-engineering ?
   bgp
   bgp-igp
   bgp-igp-both-ribs
   mspl-forwarding

Traffic-engineering bgp-igp-both-ribs

Скопирует маршруты из inet.3 в inet.0. Прилетевшие новые маршруты из inet.3, опять же, перекроют старые аналогичные маршруты из inet.0.

Но в inet.3 старые маршруты останутся, поэтому этот способ годится, если в сети нужны VPN-сервисы.

[edit protocols mpls]
traffic-engineering ?
   bgp
   bgp-igp
   bgp-igp-both-ribs
   mspl-forwarding

Traffic-engineering mpls-forwarding

Скопирует все маршруты из inet.3 в inet.0, но и старые маршруты в inet.0 оставит для совместимости с некоторыми политиками маршрутизации (то есть эта функция убирает "затмение IGP маршрутов"). Однако, фактически, форвардинг будет происходить по новым маршрутам. Для индикации того, какие маршруты в 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

Advertising LSPs directly into the IGP

Позволяет передавать информацию об LSP, как о p2p интерфейсе. Это позволяет upstream роутеру использовать LSP для рассчета кратчайшего пути.

Внутри протокола 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;

TTL

default

  • По дефолту на каждом хопе (и внутри lsp тоже) значение ttl = 1.
  • При этом не ingerss роутере IP TTL копируется в MPLS TTL, при прохождении через LSP -1, IP TTL остается неизменным. На egress роутере значение TTL копируется обратно из MPLS в IP.

no-decrement-ttl

  • Только для Juniper.
  • Только на ingress роутере.
  • Можно применять в разные иерархии (глобально mpls, lsp, path)
  • IP TTL уменьшается только на egress роутере.
  • MPLS TTL устанавливается в 255, значение MPLS TTL не перезаписывается в IP TTL.
  • Работает только для RSVP.

До

P1-2> traceroute 172.21.2.1 source 10.12.0.1    
traceroute to 172.21.2.1 (172.21.2.1) from 10.12.0.1, 30 hops max, 40 byte packets
1  192.168.0.37 (192.168.0.37)  20.150 ms  19.244 ms  14.906 ms
2  172.30.0.45 (172.30.0.45)  20.139 ms  19.538 ms  14.947 ms
    MPLS Label=300368 CoS=0 TTL=1 S=1
3  172.30.0.17 (172.30.0.17)  29.722 ms  29.692 ms  29.925 ms
    MPLS Label=300624 CoS=0 TTL=1 S=1
4  172.30.0.14 (172.30.0.14)  34.978 ms  34.501 ms  30.472 ms
5  172.21.2.1 (172.21.2.1)  40.131 ms  45.097 ms  39.280 ms

После

P1-2> traceroute 172.21.2.1 source 10.12.0.1    
traceroute to 172.21.2.1 (172.21.2.1) from 10.12.0.1, 30 hops max, 40 byte packets
1  192.168.0.37 (192.168.0.37)  14.851 ms  15.075 ms  9.682 ms
2  172.30.0.14 (172.30.0.14)  35.521 ms  33.829 ms  29.991 ms
3  172.21.2.1 (172.21.2.1)  40.235 ms  29.352 ms  39.868 ms

no-propogate-ttl

  • Мультивендорная фича.
  • Должна быть сконфигурирована на egress роутере, а т.к. им может стать любой роутер => конфигурируем на всех роутерах.
  • Применяется только глобально в protocol mpls иерархии.
  • Если LSP уже установлен, то после применения команды, то к нему не применится команда.
  • Работает и для RSVP и для LDP.

no-vrf-propogate-ttl

  • Включаем внутри VRF.
  • В документации точно не нашла где включать, но у меня заработало при включении на ingress внутри VRF. На egress при этом не была включена эта функция.
set routing-instances ce1 no-vrf-propagate-ttl

Дополнительная информация