[ne-vlezay80]

ne-vlezay80

ну это вырожденный случай PE, GRT-only, смысла от такого PE-роутера не видно от слова совсем

 

Интересно было бы узнать, почему VPLS есть только на коммерчиском ПО, а также в OpenBSD?

 

OVS умеет пушить до 3ёх меток. С точки зрения датаплейна, на ovs есть vpls

 

Open vSwitch version 2.4 can match, push, or pop up to 3 MPLS labels and look past the MPLS label into the encapsulated packet.

А кстати, у меня идея: далаем VPLS на разных OVS мостах, и тем самым обойти огланичение на 3 метки.

[ne-vlezay80]

Видимо, речь идет об этом расширении:

 

https://tools.ietf.org/html/draft-ietf-mpls-icmp-01

ICMP Extensions for MultiProtocol Label Switching

 

Если расширение поддерживается, то, логично предположить, что должно отвечать. Я бы в коде полазил.

Кстати, у меня есть какая-то заброшанная сборка, на ядре 4.8.6, где данные тесты mpls проваливаются с треском. iperf выдаёт не больше 11Mbps, хотя должен 17-16Gbps. Как я понял, в той сборке был баг.

 

Каким образом вы связали трейс в mpls с тем, что на каком-то ядре у вас была медленная скорость?

 

Вам же сказали причину - для того чтобы трейс отображался нужна реализация этого в коде, которой, вероятно, нет в ядре linux

Вот на 4.8.6. Вот результаты тестирования с этой системы:

sysctl -w net.mpls.conf.lo.input=1
sysctl -w net.mpls.platform_labels=1048575
ip link add veth0 type veth peer name veth1
ip link add veth2 type veth peer name veth3
sysctl -w net.mpls.conf.veth0.input=1
sysctl -w net.mpls.conf.veth2.input=1
ifconfig veth0 10.3.3.1 netmask 255.255.255.0
ifconfig veth2 10.4.4.1 netmask 255.255.255.0
ip netns add host1
ip netns add host2
ip link set veth1 netns host1
ip link set veth3 netns host2
ip netns exec host1 ifconfig veth1 10.3.3.2 netmask 255.255.255.0 up
ip netns exec host2 ifconfig veth3 10.4.4.2 netmask 255.255.255.0 up
ip netns exec host1 ip route add 10.10.10.2/32 encap mpls 112 via inet 10.3.3.1
ip netns exec host2 ip route add 10.10.10.1/32 encap mpls 111 via inet 10.4.4.1
ip -f mpls route add 111 via inet 10.3.3.2
ip -f mpls route add 112 via inet 10.4.4.2

 

Вот результаты тестов:

tcp по mpls:
~ # ip netns exec host2 iperf3 -c 10.10.10.1 -B 10.10.10.2
Connecting to host 10.10.10.1, port 5201
[ 4] local 10.10.10.2 port 34021 connected to 10.10.10.1 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 912 KBytes 7.46 Mbits/sec 0 636 KBytes
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 912 KBytes 747 Kbits/sec 0 sender
[ 4] 0.00-10.00 sec 21.3 KBytes 17.5 Kbits/sec receiver

iperf Done.
~ #
udp по mpls:
~ # ip netns exec host2 iperf3 -c 10.10.10.1 -B 10.10.10.2 -u -b 10g
Connecting to host 10.10.10.1, port 5201
[ 4] local 10.10.10.2 port 56901 connected to 10.10.10.1 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 438 MBytes 3.67 Gbits/sec 56049
[ 4] 1.00-2.00 sec 491 MBytes 4.12 Gbits/sec 62829
[ 4] 2.00-3.00 sec 492 MBytes 4.12 Gbits/sec 62919
[ 4] 3.00-4.00 sec 490 MBytes 4.11 Gbits/sec 62762
[ 4] 4.00-5.00 sec 491 MBytes 4.12 Gbits/sec 62891
[ 4] 5.00-6.00 sec 492 MBytes 4.13 Gbits/sec 62994
[ 4] 6.00-7.00 sec 503 MBytes 4.22 Gbits/sec 64322
[ 4] 7.00-8.00 sec 503 MBytes 4.22 Gbits/sec 64321
[ 4] 8.00-9.00 sec 502 MBytes 4.21 Gbits/sec 64279
[ 4] 9.00-10.00 sec 511 MBytes 4.28 Gbits/sec 65352

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 4.80 GBytes 4.12 Gbits/sec 0.001 ms 0/628718 (0%)
[ 4] Sent 628718 datagrams

iperf Done.

UDP как видим, проходит нормально.

Вот параметры интерфейсов:

P:
veth0 Link encap:Ethernet HWaddr 72:0D:9E:D7:BC:B3
inet addr:10.3.3.1 Bcast:10.3.3.255 Mask:255.255.255.0
inet6 addr: fe80::700d:9eff:fed7:bcb3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:65535 Metric:1
RX packets:126 errors:0 dropped:0 overruns:0 frame:0
TX packets:629026 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9592 (9.3 KiB) TX bytes:5178498619 (4.8 GiB)

veth2 Link encap:Ethernet HWaddr CE:24:F8:1F:99:C1
inet addr:10.4.4.1 Bcast:10.4.4.255 Mask:255.255.255.0
inet6 addr: fe80::cc24:f8ff:fe1f:99c1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:65535 Metric:1
RX packets:629015 errors:0 dropped:0 overruns:0 frame:0
TX packets:135 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5181014123 (4.8 GiB) TX bytes:9564 (9.3 KiB)
PE1:
~ # ip netns exec host2 ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

veth3 Link encap:Ethernet HWaddr 36:00:C2:29:0D:F9
inet addr:10.4.4.2 Bcast:10.4.4.255 Mask:255.255.255.0
inet6 addr: fe80::3400:c2ff:fe29:df9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:65200 Metric:1
RX packets:136 errors:0 dropped:0 overruns:0 frame:0
TX packets:629015 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9596 (9.3 KiB) TX bytes:5181014123 (4.8 GiB)
PE2:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

veth1 Link encap:Ethernet HWaddr DA:B2:AD:31:68:77
inet addr:10.3.3.2 Bcast:10.3.3.255 Mask:255.255.255.0
inet6 addr: fe80::d8b2:adff:fe31:6877/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:65200 Metric:1
RX packets:629027 errors:0 dropped:0 overruns:0 frame:0
TX packets:126 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5178498651 (4.8 GiB) TX bytes:9592 (9.3 KiB)

Если хотите знать что на более свежом ядре - прокрутите тему в самое начало.

Конфиг ядра:

https://pastebin.com/raw/EE1k05cT

 

Вот результаты.

[ne-vlezay80]

ne-vlezay80

ну это вырожденный случай PE, GRT-only, смысла от такого PE-роутера не видно от слова совсем

 

Интересно было бы узнать, почему VPLS есть только на коммерчиском ПО, а также в OpenBSD?

 

OVS умеет пушить до 3ёх меток. С точки зрения датаплейна, на ovs есть vpls

 

Open vSwitch version 2.4 can match, push, or pop up to 3 MPLS labels and look past the MPLS label into the encapsulated packet.

А кстати, если #define FLOW_MAX_MPLS_LABELS увиличить до нужного значения. Наприпер:

#define FLOW_MAX_MPLS_LABELS 255

в файле:

include/openvswitch/flow.h

и

datapath-windows/ovsext/Mpls.h

[Merridius]

Коллеги, кто-нибудь может внятно объяснить зачем вообще на линуксе MPLS, ну кроме, возможно, разборки пакетов, и то сомнительно.

В любом нормальном операторе, у которого в сети присутсвует mpls, транспортная сеть построена на Cisco/Juniper/Alcatel/Huawei (может забыл кого).

Я, лично, не вижу никакого смысла в этом, все равно все останутся на железе от вендоров.

Изменено 18 мая, 2017 пользователем Merridius

[vop]

Еще есть образовательные цели. Кому нужен был ka9q? (это позывной такой)

[ne-vlezay80]

Коллеги, кто-нибудь может внятно объяснить зачем вообще на линуксе MPLS, ну кроме, возможно, разборки пакетов, и то сомнительно.

Во первых, для создания mesh сети на базе MPLS. (Пока он правда двухметочный, но эта проблема будет скоро решина) Также он может быть полезным, если большая сеть, которые построенна на СПО.

 

В любом нормальном операторе, у которого в сети присутсвует mpls, транспортная сеть построена на Cisco/Juniper/Alcatel/Huawei (может забыл кого).

Если этот оператор согласен платить за лицензию 100-200k с каждого роутера, то пожалуйста. А как быть, например школвм, больницам, и тд, тп.

 

Я, лично, не вижу никакого смысла в этом, все равно все останутся на железе от вендоров.

Если тебе это не надо - не используй!!!!! Только лицензиями не забудь закупиться))))

Кстати, у нас транспортная сеть построенна на роутерах с операционной системой linux. Всё пока устраивает. mpls пока не планируется.

Вся проблема в том, что MPLS на железе надо лицензировать. А это удовольствие неиздешовых.

[zhenya`]

не везде лицензии реально нужны, но вот в суппорт не выйдет по мплс вопрос задать, если железка на эту фичу имеет лицуху (пусть даже просто бумажка).

нахер школам и больницам мплс ?

 

п.с. лейбл стэк в две метки достаточно для l3vpn/l2vpn/vpls.

[ne-vlezay80]

не везде лицензии реально нужны, но вот в суппорт не выйдет по мплс вопрос задать, если железка на эту фичу имеет лицуху (пусть даже просто бумажка).

нахер школам и больницам мплс ?

 

п.с. лейбл стэк в две метки достаточно для l3vpn/l2vpn/vpls.

Надеюсь не на стороне CE? 2 метки умеет OpenBSD и openvswitch. Linux скоро будет уметь 30 меток в стеке. (правда только L3vpn,mpls l3 mesh)

Кстати, в obsd тормазнутый сетевой стек. OVS гонять лучше с DPDK.

[zhenya`]

И? Что вам даст такой лейблстэк? Еще раз повторю достаточно 2ух. 3 и более для это экзотики так csc и sr

[ne-vlezay80]

И? Что вам даст такой лейблстэк? Еще раз повторю достаточно 2ух. 3 и более для это экзотики так csc и sr

А какой лайбелстек у магистральщиков?

[ne-vlezay80]

У меня есть информация о том, что в linux будет реализована поддержка VPLS.

Цитата

Hi all,

 

this is an update on the earlier "[RFC net-next] VPLS support".  Note
I've changed the subject lines on some of the patches to better reflect
what they really do (tbh the earlier subject lines were crap.)

As previously, iproute2 / FRR patches are at:
- https://github.com/eqvinox/vpls-iproute2
- https://github.com/opensourcerouting/frr/commits/vpls
while this patchset is also available at:
- https://github.com/eqvinox/vpls-linux-kernel
(but please be aware that I'm amending and rebasing commits)

The NVGRE implementation in the 3rd patch in this series is actually an
accident - I was just wiring up gretap as a reference;  only after I was
done I noticed that that sums up to NVGRE, more or less.  IMHO, it does
serve well to demonstrate the bridge changes are not VPLS-specific.

To refer some notes from the first announce mail:
> I've tested some basic setups, the chain from LDP down into the kernel
> works at least in these.  FRR has some testcases around from OpenBSD
> VPLS support, I haven't wired that up to run against Linux / this
> patchset yet.

Same as before (API didn't change).

> The patchset needs a lot of polishing (yes I left my TODO notes in the
> commit messages), for now my primary concern is overall design
> feedback.  Roopa has already provided a lot of input (Thanks!);  the
> major topic I'm expecting to get discussion on is the bridge FDB
> changes.

Got some useful input;  but still need feedback on the bridge FDB
changes (first 2 patches).  I don't believe it to have a significant
impact on existing bridge operation, and I believe a multipoint tunnel
driver without its own FDB (e.g. NVGRE in this set) should perform
better than one with its own FDB (e.g. existing VXLAN).

> P.S.: For a little context on the bridge FDB changes - I'm hoping to
> find some time to extend this to the MDB to allow aggregating dst
> metadata and handing down a list of dst metas on TX.  This isn't
> specifically for VPLS but rather to give sufficient information to the
> 802.11 stack to allow it to optimize selecting rates (or unicasting)
> for multicast traffic by having the multicast subscriber list known.
> This is done by major commercial wifi solutions (e.g. google "dynamic
> multicast optimization".)

You can find hacks at this on:
https://github.com/eqvinox/vpls-linux-kernel/tree/mdb-hack
Please note that the patches in that branch are not at an acceptable
quality level, but you can see the semantic relation to 802.11.

I would, however, like to point out that this branch has pseudo-working
IGMP/MLD snooping for VPLS, and it'd be 20-ish lines to add it to NVGRE
(I'll do that as soon as I get to it, it'll pop up on that branch too.)

This is relevant to the discussion because it's a feature which is
non-obvious (to me) on how to do with the VXLAN model of having an
entirely separate FDB.  Meanwhile, with this architecture, the proof of
concept / hack is coming in at a measly cost of:
8 files changed, 176 insertions(+), 15 deletions(-)


Cheers,

-David


--- diffstat:
include/linux/netdevice.h      |  18 ++++++
include/net/dst_metadata.h     |  51 ++++++++++++++---
include/net/ip_tunnels.h       |   5 ++
include/uapi/linux/lwtunnel.h  |   8 +++
include/uapi/linux/neighbour.h |   2 +
include/uapi/linux/rtnetlink.h |   5 ++
net/bridge/br.c                |   2 +-
net/bridge/br_device.c         |   4 ++
net/bridge/br_fdb.c            | 119 ++++++++++++++++++++++++++++++++--------
net/bridge/br_input.c          |   6 +-
net/bridge/br_private.h        |   6 +-
net/core/lwtunnel.c            |   1 +
net/ipv4/ip_gre.c              |  40 ++++++++++++--
net/ipv4/ip_tunnel.c           |   1 +
net/ipv4/ip_tunnel_core.c      |  87 +++++++++++++++++++++++------
net/mpls/Kconfig               |  11 ++++
net/mpls/Makefile              |   1 +
net/mpls/af_mpls.c             | 113 ++++++++++++++++++++++++++++++++------
net/mpls/internal.h            |  44 +++++++++++++--
net/mpls/vpls.c                | 550 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
20 files changed, 990 insertions(+), 84 deletions(-)

Источник: https://www.linux.org.ru/forum/admin/13712281

Изменено 28 сентября, 2017 пользователем ne-vlezay80

[EShirokiy]

@ne-vlezay80 инфы про добавление патчей в ядро нет?

[ne-vlezay80]

17 часов назад, EShirokiy сказал:

@ne-vlezay80 инфы про добавление патчей в ядро нет?

Нет

 

Но, есть: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200515&id=f66b53fdbb22ced1a323b22b9de84a61aacd8d18

Не знаю, относится ли оно к этому?

[ne-vlezay80]

В 15.05.2020 в 01:05, EShirokiy сказал:

@ne-vlezay80 инфы про добавление патчей в ядро нет?

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20201006&id=ef743c0990337f3ed2648b6c6847eddc593241db