[dazgluk]

Коллеги, добрый день.

 

Столкнулись с необходимостью развернуть MPLS-TE

Суть следующая:

1. Есть сеть (в приложении)

2. На линке между NE40 и 7600 RSP-720-3CXL возникла перегрузка

3. Необходимо развернуть часть трафика от Internet до CGNAT минуя данный линк.

4. На сети развернут MPLS, сигнализация LDP

5. Запустили два резервных LAGа, пытаюсь наполнить их траффиком.

 

Что сделали:

1. Включили MPLS-TE и RSVP-TE, прописали на всех линках стоимость

2. запустили на Huawei NE40E два MPLS-TE туннеля

3. На туннелях прописал Bandwidth 10G на основном, 3G на резервном, в таблицу роутинга запихал с помощью igp shortcut (autoroute announce в терминологии Cisco)

 

У Cisco, данных действий вроде как было бы достаточно, однако в случае Huawei балансировка какая то совсем не равномерная.

 

interface Tunnel8/1/78
description to_7606_Border_via_transport
bandwidth 3000
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 89.221.193.12
mpls te tunnel-id 78
mpls te primary-lsp-constraint lsp-attribute to_7606_via_transport
mpls te record-route
mpls te bandwidth ct0 3000000
mpls te igp shortcut
mpls te igp metric relative -1
mpls te commit
mpls
statistic enable

interface Tunnel8/1/178
description to_SPB_7606_Border_direct
bandwidth 10000
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 89.221.193.12
mpls te tunnel-id 178
mpls te primary-lsp-constraint dynamic
mpls te record-route label
mpls te bandwidth ct0 10000000
mpls te fast-reroute
mpls te igp shortcut ospf
mpls te igp metric relative -1
mpls te commit
statistic enable

 

Tunnel8/1/178 current state : UP
300 seconds output rate 4279306016 bits/sec, 566447 packets/sec

Tunnel8/1/78 current state : UP
300 seconds output rate 406598368 bits/sec, 51870 packets/sec

 

<SPB-NE40E-IXR01>display ip routing-table 89.221.193.12
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 2
Destination/Mask    Proto  Pre  Cost       Flags NextHop         Interface

 89.221.193.12/32  OSPF   10   10           D   89.221.193.1    Tunnel8/1/178
                   OSPF   10   10           D   89.221.193.1    Tunnel8/1/78

 

Подскажите пожалуйста, что забыл? данный функционал вообще поддерживается? До сегодняшнего времени на Huawei MPLS-TE настраивать не приходилось

[dazgluk]

Нашел еще кое что.

 

Большая часть трафика у нас это VRF bgp-internet - так вот, по каким то причинам трафик внутри этого VRF попадает только в один туннель

<SPB-NE40E-IXR01>display ip routing-table vpn-instance bgp-internet 89.221.207.2
19
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : bgp-internet
Summary Count : 1
Destination/Mask    Proto  Pre  Cost       Flags NextHop         Interface

89.221.207.219/32  BGP    255  1           RD   89.221.193.12   Tunnel8/1/178

Huawei вообще умеет Multipath до одного и того-же next-hop в VRF?

[dazgluk]

Ну чтож, поскольку просмотров > 100, сам отвечу на свой вопрос :)

 

Как я уже сказал, большая часть трафика - это vpn-instance bgp-internet. То есть то, что мы увидели в туннеле 8/1/78 это трафик, где указанный маршрутизатор выступает P роутером (там дальше еще есть MPLS). Для того, чтобы внутри VRF появилось два Nexthop-а нужна такая конструкция:

tunnel-policy load-balance
tunnel select-seq lsp load-balance-number 2

и внутри VPN-instance

tnl-policy load-balance

После этого заработал ECMP, и трафик поровну растекся по двум туннелям.

SPB-NE40E-IXR01>dis interface Tunnel 8/1/178 | i rate
   300 seconds output rate 1847002080 bits/sec, 237151 packets/sec
<SPB-NE40E-IXR01>dis interface Tunnel 8/1/78 | i rate
   300 seconds output rate 1506499920 bits/sec, 215025 packets/sec

Далее включение в System-view команды

load-balance unequal-cost enable

Сделало все как нужно

<SPB-NE40E-IXR01>display interface Tunnel 8/1/178 | i rate
   300 seconds output rate 2517282520 bits/sec, 339933 packets/sec
<SPB-NE40E-IXR01>display interface Tunnel 8/1/78 | i rate
   300 seconds output rate 829380280 bits/sec, 115192 packets/sec

 

Возможно кому-то это будет интересно :)

 

P.S. чтобы трафик в TE туннеле балансировался по LAGу нужно не забыть load-balance packet all на исходящей стороне

[g3fox]

Тут, в основном, представители операторов уровня "колхоз-телеком", в т.ч. и я. А тема у вас достаточно сложная, да ещё и на довольно не популярном вендоре.

[dmvy]

а разве вообще может один mpls тоннель ходить по разным путям? разве lable switching не предусматривает смену одной метки на другую и уход в определенный интерфейс? и как в вашем случае будет решаться проблема нарушения очередности пакетов? на сколько мне известно RSVP-TE используется для горячего резервирования с FRR и учетом занятости линков для недопущения перегрузки каналов.

 

Для балансировки в L3VPN используют для каждого маршрута отдельную метку - вот тогда балансировка выравнивается за счет большого количества тоннелей.

[dazgluk]

а разве вообще может один mpls тоннель ходить по разным путям? разве lable switching не предусматривает смену одной метки на другую и уход в определенный интерфейс?

Все верно, для конкретного туннеля устанавливается конкретный LSP и данный LSP идет по кокретным интерфейсам. Поэтому и подняли два туннеля 8/1/78 и 8/1/178 - по разным путям. Основной вопрос был, как оба занисталить в FIB

и как в вашем случае будет решаться проблема нарушения очередности пакетов?

Данной проблемы нет. Балансировка выполняется Per-flow, на основании 5 tuple hash, железо должно быть достаточно умным чтобы это делать.

С используемыми у нас 6500/SUP720 7600/RSP720 CX600 NE40E проблем не было, единственное что нужно сделать - включить 5 tuple hash для MPLS

на сколько мне известно RSVP-TE используется для горячего резервирования с FRR и учетом занятости линков для недопущения перегрузки каналов.

Fast Reroute это олна из фич MPLS-TE, Unequal Cost load-balancing - другая, еще как минимум есть фича, QoS aware MPLS-TE, которая вообще позволяет гнать трафик с разнымы QoS метками, по разным MPLS-TE путям (например дешевый и дорогой линки)

Для балансировки в L3VPN используют для каждого маршрута отдельную метку - вот тогда балансировка выравнивается за счет большого количества тоннелей.

Заворачивать трафик в туннель MPLS-TE для балансировки можно несколькими способами:

1. Целиком до конкретного PE, как будто у вас просто два Equal cost маршрута в OSPF, посмотрите на вывод комманды display ip routing-table, это просто два OSPF маршрута

2. Прилеплять туннели к конкретному L3VPN, да, так делать можно, через специфические BGP-Nexthop, в данном случае label-per-route просто поможет балансировать трафик по нескольким путям, если железка не умеет 5 tuple hash для меченых пакетов. У нас FullView в VRFе, для label-per-route TCAMа не хватает :)

3. Прилеплять туннели к Псевдопроводам и VPLSам

4. PBRом на основании ACL

 

g3fox, мы сами не мегателеком, а простой оператор средней руки :) И много решений внедренно именно с НАГа, чего стоят ИБП60-12, ipt-netflow, и nfq_filter для РКН.

Что касается хуавея, к сожалению коммунити у них весьма скудное, видимо все мегателекомы сидят только в CRM системе саппорта, а если саппорт не оплачен, то и спросить негде. Hedex к сожалению так же не всеобъемлящий

[s.lobanov]

dazgluk

Я бы не стал делать MPLS-TE на хуавее без оплаченного саппорта. Обычный mpls(одна метка, l2vpn, l3vpn) ещё можно, но если возникнут мутные проблемы с TE, то log.dblg вы сами не разгребёте...