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

Интересная техника управления mpls-трафиком а кто использует?

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


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

Я использую в радиоканале 20 км с Mikrotik RB-800 с другой стороны Mikrotik RB435 при трафике на 800-й (с него идет трафик на сервер) 100 Мб/с и 50 Мб/с от него акцентирую загрузка процессора 50-60%, в 435-го 80-90%, без MPLS в два-три раза меньше нагрузка на процессор, но падает "прокачка", если по Микротику могу подсказать, хотя принцип один и тот же везде. Есть вариант настройки MPLS точка-точка и есть точка-многоточка. Вот варианты настройки микротика которые я использую: Настройка MPLS в Mikrotik

В "живую" єто выглядит в приложеном файле, а в тесте во втором файле, реально отличаются показатели, у меня есть ассиметрия.

Transparently Bridge two Networks using MPLS

 

Applies to RouterOS: v3, v4+

Содержание [убрать]

1 Overview

2 Configuration

3 MTU

[править]Overview

This a very basic example how to enable MPLS, establish VPLS tunnel between two wireless links and use it to transparently bridge two networks.

 

There are several other ways to create this type of setup:

 

Bridge using WDS

Bridge using EoIP

The MPLS/VPLS approach has some advantages:

 

VPLS tunnel is about 60% faster and less overhead than EoIP tunnel

802.11n speed is limited over WDS bridges, this method doesn't have such limitations

[править] Configuration

Let us assume the following network setup:

 

 

 

Note: For this setup to work in RouterOS 3.x, routing and mpls-test package must be installed. These features are included by default in 4.x.

 

AP

 

# --configure wireless access point--

/interface wireless

set wlan1 disabled=no ssid=MPLS frequency=5180 band=5ghz mode=bridge

 

# --configure IP--

/ip address

add address=172.16.0.1/30 interface=wlan1

 

# --enable LDP--

/mpls ldp

set enabled=yes lsr-id=172.16.0.1 transport-address=172.16.0.1

/mpls ldp interface

add interface=wlan1

 

# --configure VPLS tunnel--

/interface vpls

add name=vpls1 remote-peer=172.16.0.2 vpls-id=1:1 disabled=no

 

# --add bridge and bridge ports --

/interface bridge add name=bridge1

/interface bridge port

add bridge=bridge1 interface=ether1

add bridge=bridge1 interface=vpls1

station

 

# --configure wireless access point--

/interface wireless

set wlan1 disabled=no ssid=MPLS band=5ghz mode=station

 

# --configure IP--

/ip address

add address=172.16.0.2/30 interface=wlan1

 

# --enable LDP--

/mpls ldp

set enabled=yes lsr-id=172.16.0.2 transport-address=172.16.0.2

/mpls ldp interface

add interface=wlan1

 

# --configure VPLS tunnel--

/interface vpls

add name=vpls1 remote-peer=172.16.0.1 vpls-id=1:1 disabled=no

 

# --add bridge and bridge ports --

/interface bridge add name=bridge1

/interface bridge port

add bridge=bridge1 interface=ether1

add bridge=bridge1 interface=vpls1

Confirm that LDP is running

 

[admin@MikroTik] /mpls ldp neighbor> print

Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello, V - vpls

# TRANSPORT LOCAL-TRANSPORT PEER SEND-TARGETED ADDRESSES

0 DOTV 172.16.0.2 172.16.0.1 172.16.0.2:0 no 172.16.0.2

 

[admin@MikroTik] /mpls ldp neighbor> .. .. forwarding-table print

Flags: L - ldp, V - vpls, T - traffic-eng

# IN-LABEL OUT-LABELS DESTINATION INTERFACE NEXTHOP

0 expl-null

1 V 18 vpls1

 

Confirm that VPLS tunnel is established:

 

[admin@MikroTik] /interface vpls> monitor vpls1 once

remote-label: 17

local-label: 18

remote-status:

transport-nexthop: 172.16.0.2

imposed-labels: 17

 

Connect more stations to the same Bridge

 

It is possibile to connect more than one Station to the same Bridge, simply creating more VPLS tunnels (one for Station, and don't forget to increase subnet size from /30 to /24 for example, dependig how much clients you need):

 

AP

 

# --change wireless access point mode to AP Bridge--

/interface wireless

set wlan1 mode=ap-bridge

 

# --configure second VPLS tunnel--

/interface vpls

add name=vpls2 remote-peer=172.16.0.3 vpls-id=2:2 disabled=no

 

# --add vpls2 to bridge --

 

/interface bridge port

add bridge=bridge1 interface=vpls2

2nd Station

 

# --configure wireless access point--

/interface wireless

set wlan1 disabled=no ssid=MPLS band=5ghz mode=station

 

# --configure IP--

/ip address

add address=172.16.0.3/30 interface=wlan1

 

# --enable LDP--

/mpls ldp

set enabled=yes lsr-id=172.16.0.3 transport-address=172.16.0.3

/mpls ldp interface

add interface=wlan1

 

# --configure VPLS tunnel--

/interface vpls

add name=vpls1 remote-peer=172.16.0.1 vpls-id=2:2 disabled=no

 

# --add bridge and bridge ports --

/interface bridge add name=bridge1

/interface bridge port

add bridge=bridge1 interface=ether1

add bridge=bridge1 interface=vpls1

[править]MTU

When router encapsulates Ethernet frame to forward over VPLS pseudowire, it checks if packet size + VPLS CW + MPLS labels exceeds MPLS MTU of outgoing interface. If it does, VPLS will fragment frame. In this example 1514byte layer2 packets are forwarded over VPLS, router adds CW (4bytes) and one MPLS tag (4bytes) it means that to avoid fragmentation MPLS MTU must be increased to 1522

 

/mpls interface set 0 mpls-mtu=1522

For more information and supported L2MTU values on RouterBoards refer to Maximum_Transmission_Unit_on_RouterBoards

 

 

Note: If interface does not support L2MTU specified as mpls-mtu, then packets will be silently dropped

post-77579-017733900 1370162876_thumb.png

post-77579-060029400 1370163563_thumb.png

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


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

 

Обычный TE. Это напоминает "установил nginx - отпишись на хабре", "собрал openwrt - отпишись на хабре" и т.д. Теперь вот "поднял mpls - отпишись на хабре". Жду статью из серии "поменял ospf на is-is - отписался на хабре"

 

Скоро очередной хабродрочер узнает что есть ещё FRR и CSC и запилит очередную говностатью для офисных хомячков-плюсомётов. Всё равно 99.9% хаброэлектората никогда не притронется к TE

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


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

Идея весьма интересная, но:

1. Нужно чтобы стоимость своих магистралей была существенно дешевле апстрима, то есть арендованные лямбды/L2VPN скорее всего мимо

2. Latency - не ключевое требование, использовать локальных аплинков как бекап и гнать все в IXP - возможен далеко не best-path

3. В каждом PoP нужно брать оператора под backup, причем с минимальной предоплаченной полосой

4. Конфига всего этого весьма мудреная + не понятно как предоставлять классические сервисы IP транзит с Community и классификацией кастомеров.

5. И да, эта схема подходит только для управления исходящим трафиком.

 

В целом, мне кажется оно идеально подходит для контент генераторов:

1. Им дешевле IXы

2. Если это http - лишние 10мс пинга не сделают много проблем

3. Не нужно предоставлять услуги на своей сети

4. Трафик - приемущественно исходняк.

Для оператора, мне кажется схема немного не подходит.

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


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

 

Обычный TE. Это напоминает "установил nginx - отпишись на хабре", "собрал openwrt - отпишись на хабре" и т.д. Теперь вот "поднял mpls - отпишись на хабре". Жду статью из серии "поменял ospf на is-is - отписался на хабре"

 

Скоро очередной хабродрочер узнает что есть ещё FRR и CSC и запилит очередную говностатью для офисных хомячков-плюсомётов. Всё равно 99.9% хаброэлектората никогда не притронется к TE

Она необычна тем, что MPLS-TE используется не для того чтобы доставить трафик от PE1 к PE2 а для того чтобы доставить трафик от PE1 в апстрим. ИМХО

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


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

 

Обычный TE. Это напоминает "установил nginx - отпишись на хабре", "собрал openwrt - отпишись на хабре" и т.д. Теперь вот "поднял mpls - отпишись на хабре". Жду статью из серии "поменял ospf на is-is - отписался на хабре"

 

Скоро очередной хабродрочер узнает что есть ещё FRR и CSC и запилит очередную говностатью для офисных хомячков-плюсомётов. Всё равно 99.9% хаброэлектората никогда не притронется к TE

 

Категорически согласен.

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


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

ux0qt, спасибо конечно, но vpls умею настраивать (да и вендор у нас другой)

 

 

Скоро очередной хабродрочер узнает что есть ещё FRR и CSC и запилит очередную говностатью для офисных хомячков-плюсомётов. Всё равно 99.9% хаброэлектората никогда не притронется к TE

 

 

=)

В следующий раз в новой теме напишу развернутое описание (а то srg555 опять переволнуется :)

 

Не являюсь поклонником хабра и хабраюзером, но такой статьи/темы тут не видел.

 

 

Обычный TE.

 

 

Да, эт понятно. Как тут уже заметили, "необычна тем, что MPLS-TE используется не для того чтобы доставить трафик от PE1 к PE2 а для того чтобы доставить трафик от PE1 в апстрим".

Собственно, создал я эту тему, потому что мне стало интересно: какая доля операторов заморачивается с таким монструозным конфигом ТЕ?

 

Сейчас то что описано в статье у нас рулится в общем-то традиционно: ospf+bgp, если ospf может перегрузить 1 из линков в регион - на некоторые клиентские префиксы этого региона вешается комьюнити, которое бордер заменяет в анонсе наверх на бэкапное комьюнити апстрима => входящий трафик для этого префикса валит через другой линк.

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


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

Join the conversation

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

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

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

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

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

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

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