Use mpls mikrotik что это
Steinkäfer
воскресенье, 13 сентября 2015 г.
MPLS на MikroTik (VPLS)
Имеется стенд из 3-х микротиков и 2-х компьютеров. Компьютеры выполняют функцию клиентских устройств. Микротики 951G.
Схема:
PC1——PE1—P—RE2——PC2
Задача: пробросить vlan так чтобы PC1 и PC2 «думали» что они в одном бродкастном домене.
Между устройствами МикроТик должны быть подняты GRE-туннели.
Итак собираем схему, конфигурируем интерфейсы, Loopback-интерфейсы, GRE— туннели.
/ip address
add address=10.0.0.1/30 interface=ether1 network=10.0.0.0
/interface gre
add local-address=10.0.0.1 name=gre-tunnel1 remote-address=10.0.0.2
/ip address
add address=192.168.0.1/30 interface=gre-tunnel1 network=192.168.0.0
add address=192.168.0.201 interface=Loopback1 network=192.168.0.20
/ip address
add address=10.0.0.2/30 interface=ether1 network=10.0.0.0
add address=10.0.0.5/30 interface=ether2 network=10.0.0.4
/interface gre add local-address=10.0.0.2 name=gre-tunnel1 remote-address=10.0.0.1 add local-address=10.0.0.5 name=gre-tunnel2 remote-address=10.0.0.6
/ip address add address=192.168.0.2/30 interface=gre-tunnel1 network=192.168.0.0 add address=192.168.0.5/30 interface=gre-tunnel2 network=192.168.0.4 add address=192.168.0.202 interface=Loopback1 network=192.168.0.202
/ip address
add address=10.0.0.6/30 interface=ether2 network=10.0.0.4
/interface gre add local-address=10.0.0.6 name=gre-tunnel2 remote-address=10.0.0.5
/ip address add address=192.168.0.6/30 interface=gre-tunnel2 network=192.168.0.4 add address=192.168.0.203 interface=Loopback1 network=192.168.0.203
Снова начинаем с PE1
/routing ospf instance
set [ find default=yes ] router-id=192.168.0.201
/routing ospf interface
add interface=gre-tunnel1 network-type=point-to-point
add interface=Loopback1 network-type=broadcast
/routing ospf network add area=backbone network=192.168.0.0/30 add area=backbone network=192.168.0.201/32
/routing ospf instance
set [ find default=yes ] router-id=192.168.0.202
/routing ospf interface
add interface=gre-tunnel1 network-type=point-to-point
add interface=gre-tunnel2 network-type=point-to-point
add interface=Loopback1
/routing ospf network
add area=backbone network=192.168.0.0/30
add area=backbone network=192.168.0.4/30
add area=backbone network=192.168.0.202/32
/routing ospf instance
set [ find default=yes ] metric-bgp=0 metric-other-ospf=0 router-id=192.168.0.203
/routing ospf interface
add interface=gre-tunnel2 network-type=point-to-point
add interface=Loopback1 network-type=broadcast
/routing ospf network
add area=backbone network=192.168.0.4/30
add area=backbone network=192.168.0.203/32
MPLS & VPLS
/mpls interface
set [ find default=yes ] mpls-mtu=1526
/mpls ldp
set enabled=yes lsr-id=192.168.0.201 transport-address=192.168.0.201
/mpls ldp interface
add interface=gre-tunnel1
Настраиваем VPLS
/interface vpls
add advertised-l2mtu=1526 disabled=no l2mtu=1526 mac-address=02:FB:63:92:68:03 mtu=1526 name=vpls5 remote-peer=192.168.0.203 vpls-id=1:1
/interface bridge port
add bridge=bridge5 interface=ether5
add bridge=bridge5 interface=vpls5
/mpls interface
set [ find default=yes ] mpls-mtu=1526
/mpls ldp
set enabled=yes lsr-id=192.168.0.202 transport-address=192.168.0.202
/mpls ldp interface
add interface=gre-tunnel1
add interface=gre-tunnel2
/mpls interface
set [ find default=yes ] mpls-mtu=1526
/mpls ldp
set enabled=yes lsr-id=192.168.0.203 transport-address=192.168.0.203
/mpls ldp interface
add interface=gre-tunnel2
/interface vpls
add advertised-l2mtu=1526 disabled=no l2mtu=1526 mac-address=02:6E:22:36:7E:5F mtu=1526 name=vpls5 remote-peer=192.168.0.201 vpls-id=1:1
/interface bridge
add name=bridge5
/interface bridge port
add bridge=bridge5 interface=vpls5
add bridge=bridge5 interface=ether5
На этом настройки закончены. Теперь к портам Ethernet5 PE1 PE2 подключаем клиентские компьютеры PC1 и PC2. Настраиваем на них IP-адреса из одного сетевого сегмента, без шлюзов по умолчанию. Запускаем Ping, все должно пинговаться.
При замере скорости утилитой iperf, скорость достигала 320 Мбит/с, при почти 100% загрузке процессоров всех устройств.
MikroTik для Больших Дядей N5
MikroTik для Больших Дядей (Задание 5)
Освежим в памяти схему сети.
Подведём небольшой итог всего того, чего мы добились.
На данный момент у нас работает MPLS и прохождение пакета стало быстрее, из за того, что трафик не стал заходить в процесс обычной маршрутизации, а подвергается процессу маршрутизации с помощью протокола MPLS на основании меток.
Когда маршрутизатор добавляет метку к пакету, такая процедура называется push. Метка добавляется между заголовков IP и ethernet именно поэтому MPLS называют протоколов уровня L2.5 OSI.
Ниже анимация формирования пакета MPLS.
Нечего интересного в данном процессе нет, просто добавили к пакету метку, не более чем. А вот дальнейший процесс будет показывать нагляднее почему MPLS выигрывает у обычного процесса IP маршрутизации.
Взгляните на процес forward при работающим MPLS. Процесс IP маршрутизации не происходит как такового. Так как до него просто пакет не доходит. Из таблицы forward MPLS маршрутизатор сверил метку 5000, понял, что её надо поменять на 8888 сменил метку (SWAP) и отправил next-hop-у.
Снятие метку называется процедура POP, процесс сложнее о нём мы поговорим немного позже. Так как снятие происходит, не на последнем маршрутизаторе, а на предпоследним, и само сняти не всегда приводит конкретно к снятию метки, а к изменению метки на специальные номера, те самые которые зарезервированные от 0 до 15.
Скорее всего появился вопрос «что нам дал MPLS», ну в первую очередь конечно ускорение процесса маршрутизации и всё! Сам MPLS в чистом виде, не так очевиден и зачастую не используется в том виде как это сделано сейчас у нас. Но появляется возможность использовать такие технологии как PW он же VPLS, а также VPN4
Но мы же провайдер, поэтому ручной метод нам не подходит, мы бы хотели всё и вся оптимизировать.
Перед тем как начать, настраивать BGP нам надо осознать, что всё что мы до этого делали, необходимо было для работы в BGP между Loopback адресами.
Уточним задачу, у нас есть клиент под Котору необходимо предоставить услуги L2VPN, между двумя маршрутизаторами CE.
И так нам необходимо связать два маршрутизатора CE с помощь протокола BGP и указать чем будет заниматься BGP протокол. Напомню, что он может распространять не только маршрутную информацию но и распространять дополнительную информацию, именно эту дополнительную информацию мы будем распространять.
Точно также как и в OSPF у BGP маршрутизатора есть RouterID значение должно быть уникальным в пределах одной AS.
Для наших задач мы будем использовать отдельный instance и номер автономной системы 65000. Необходимо напомнить что диапазон номеров AS разделён на две части приватный и публичный, примерно также как и BOGON адреса, только есть одно серьёзное отличие, эти диапазоны намертво вшиты в протокол и его реализацию в RouterOS, поэтому вы ОБЯЗАНЫ использовать именно из приватного диапазона номера AS от 64512 до 65535. Публичный диапазон только если у вас есть своя AS либо на стендах когда вы делаете «один к одному».
И так сначала нам необходимо на CE маршрутизаторах создать BGP instance
Следующим шагом, нам необходимо связать два маршрутизатора, с помощью настроенных пиров BGP с двух сторон.
Давайте посмотрим на команду и распишем, какие параметры bgp Peer и для чего они нужны, не все, а только те который нам необходимы.
После того вы сделаете на всех маршрутизаторах, проверить то, что мы идём по верной дороге и всё у нас получается. Узнать состояние Peer
Состояние соединения должно быть Established, слево флаг E.
Когда мы строим VPLS то у пакета появляется не одна метка, а две (стек меток), первая метка обеспечивает прохождение трафика по MPLS сети, вторая метка указывает непосредственно на PW туннель.
Для того, чтобы запустить нашу «Трубу» или PW нам необходимо подготовить инфраструктуру. Надеюсь вы помните, что CE маршрутизатор, это тот маршрутизатор к которому подключается непосредственно клиенты.
Нам необходимо подготовить Bridge в порты которого будут присоединено оборудование клиента, также можно сделать и с vlan. Мы не будем добавлять интерфейсы нам достаточно для понимания самого принципа построения таких сетей.
И так необходимо создать Bridge c отключенным rstp\stp, мы не будем мешать нашему клиенту делать петли, если ему надо будет делает петли, пусть делает это его желание )), наша задача предоставить ему L2 туннель между точками включения на маршрутизаторах CE.
Название бриджа позаимствовано из вымышленного номера договора либо какого-то внутренного номера. Пусть будет клиент под номером 1.
Далее нам необходимо объявить через BGP на CE маршрутизаторах VPLS туннели.
А наверное самое главное.
MikroTik для Больших Дядей N4
MikroTik для Больших Дядей (Задание 4)
Освежим в памяти схему сети.
Подведём небольшой итог всего того, чего мы добились.
У нас есть топология сети, которая равноправна по всем интерфейсам, кроме интерфейса между маршрутизаторами P-2 и P-5. Данный интерфейс выступает в роли резервного, так как его пропускная способность заведомо меньше.
В данный момент все маршрутизаторы могу связаться с другими маршрутизаторами по их loopback адресам. И лучший маршрут до маршрутизаторов будет выбран с помощью протокола OSPF.
Нет повести печальнее на свете, чем повесть о BGP c MPLS-ом.
о MPLS
Настал тот час, когда мы уже должны каким то образом реализовать нашу сеть.
И конечно MPLS нам здесь поможет сам MPLS это всего лишь процесс маршрутизации пакетов на основании меток. Особое место занимает не процесс маршрутизации, а процесс распространения меток по маршрутизаторам. Все маршрутизаторы в сети должны знать какую метку надо ожидать с интерфейса и в какой интерфейс с какой меткой его необходимо перенаправить.
И для данного кейса в RouterOS есть два варианта, это протокол LDP и протокол Traffic-Engineering.
LDP протокол тупой как танк, его задача найти соседей обменяться с ним сетями и метками и создать таблицу forward. Особенность LDP заключается в том, что он полностью подчиняется маршрутизации. Как таблица маршрутизации решит куда отправлять трафик, туда LDP и будет отправлять трафик с метками. А так как у нас таблицей маршрутизацией заведует протокол OSPF, и часто его схождение требует приличного времени, полагаться на данный способ можно, но. мы пойдём другим путём.
Кто то из вас скажет «но ведь можно изменить Hello интервалы или использовать BFD», да можно, но при этом мы не сможем утилизировать резервный интерфейс. Данные настройки всего лишь могут способствовать уменьшению времени запуска процедуры калькуляции SPF и тем самым уменьшить простой, но не поможет утилизировать все интерфейсы.
А если посмотреть ещё глубже, каждый интерфейс между маршрутизаторами является бизнес активом, который стоит денег, обслуживание, интерфейсы ну и в конце концов Человеко-часы которые затрачены на настройку и подержанные такого стыка. Возможно вы арендуете некоторые интерфейсы. Если деньги потрачены, то нет смысла делать так, чтобы интерфейс простаивал, его необходимо загрузить, но обычной маршрутизацией этого сделать не получиться, так как пропускная способность резервного интерфейса 100Mbps. Если мы направим весь трафик в данный интерфейс то он будет заполнен на 100% и ещё куда-то надо будет деть 900Mbps.
Напоминание. Всегда когда рассчитываете нагрузку на сеть и failover, вы должны использовать подход худшего сценария. Т.е «всё упало», всё загруженно на максимум.
В первую очередь метки, диапазон возможных меток от 0 до 1048575, но притом надо учитывать, что первые 15 меток зарезервированы для специальных условий. Об этом позже.
Нам соответственно необходимо использовать от 16 до 1048575, кстати это два в двадцатой степени, а так как счёт идёт от нуля, то минус один.
Хорошим тоном считается выделить каждому маршрутизатору свой диапазон меток, чтобы вы понимали с какого маршрутизатора прилетела метка.
Я предлагаю выделить каждому маршрутизатору по 5000 меток, такого количества будет достаточно для наших целей. Если оставить как есть значения по умолчанию, то может получиться таким образом, что маршрутизаторов будут использовать одинаковые метки, что становиться не удобно при траблшутинге.
Не будем как-то привязывать к типам маршрутизаторов, а просто по порядку распишем номера меток на нашей схеме, последовательно по 5000 меток.
Для установки диапазона меток из которого будет выбирать маршрутизатор метки можно указать следующей командой.
По умолчанию LDP берёт таблицу маршрутизации и рассказывает всем соседям о всей своей таблице маршрутизации. Это не лучший кейс, лучше всего рассказать только о Loopback адресах.
Но для начало нам необходимо установить уникальный ID маршрутизатора.
Делается это командой
Естественно значение желательно чтобы было ожидаемым и мы для этих целей будем использовать адрес loopback интерфейса.
Далее необходимо установить адрес транспорта, т.е. С какого адреса будет происходить «вещание» поиск соседей и обмен с ними информацией.
Так же как и с lsr-id устанавливаем адрес loopback интерфейса.
Следующим шагом нам необходимо, указать какие сети мы будем опубликовывать c помощью LDP протокола. Наша задача рассказать всем соседям о наших адресах, в том числе connected и loopback и вот тут нам поможет, то что мы правильно спланировали адресацию, и можем описать все адреса одной префиксом 172.31.0.0/16 немного большой, но возможно он нам в дальнейшем еще пригодится.
Делается данная настройка следующим образом:
Следующим шагом настроить фильтр «на входе» какие префиксы мы можем ожидать.
Мы будем принимать только маршруты которые попадают под префиксы наших служебных IP адресов маршрутизаторов.
LDP интерфейсы
Ну последний момент который необходимо сделать, это непосредственно запустить процесс LDP на интерфейсах, которыми связаны между собой маршрутизаторы.
Обращаю ваше внимания ещё раз, указывать надо только те интерфейсы которыми между собой связанны маршрутизаторы.
Включение LDP
После всех манипуляций нам необходимо просто включить LDP и в нашей сети трафик между loopback интерфейсами будет маршрутизироваться на основании меток, т.е. У нас заработает MPLS.
Проверка
Проверить можно простой трассировкой с CE-1 до CE-2 естественно проверяйте именно до адреса loopback.
Обратите внимание, что хоп уже не loopback адрес, а транспортный адрес из 252 сети.
Так же можно посмотреть какие метке для каких маршрутов использует каждый маршрутизатор.
Когда необходимо будут переслать трафик по сети, будут использоваться следующие метки.
Manual:MPLSVPLS
Contents
MPLS Overview
For MPLS overview and MPLS features that RouterOS supports see MPLS Overview
Example network
Consider network service provider that is connecting 3 remote sites of Customer A (A1,A2 and A3) and 2 remote sites of Customer B (B1 and B2) using its routed IP network core, consisting of routers (R1-R5):
Customers require transparent ethernet segment connection between sites. So far it has been implemented by means of bridging EoIP tunnels with physical ethernet interfaces.
Note that there are no IP addresses configured on R1, R4 and R5 interfaces that face customer networks.
This guide gives step by step instructions that will lead to implementation of VPLS to achieve necessary service.
Prerequisites for MPLS
«Loopback» IP address
Although not a strict requirement, it is advisable to configure routers participating in MPLS network with «loopback» IP addresses (not attached to any real network interface) to be used by LDP to establish sessions.
This serves 2 purposes:
In RouterOS «loopback» IP address can be configured by creating dummy bridge interface without any ports and adding address to it. For example, on R1 it is done with the following commands:
The rest of routers are configured similar way.
IP connectivity
In given example setup OSPF is used to distribute routes. For example, on R5 OSPF is configured with the following commands:
On other routers OSPF is configured in similar way.
This yields routing table on R5 like this:
and traceroute from R5 to R1 like this:
Configuring LDP
In order to distribute labels for routes, LDP should get enabled. On R1 this is done by commands (interface ether3 is facing network 1.1.1.0/24):
Note that transport-address gets set to 9.9.9.1. This makes router originate LDP session connections with this address and also advertise this address as transport address to LDP neighbors.
After LDP sessions are established, on R5 there are 2 LDP neighbors:
/mpls remote-bindings shows labels that are allocated for routes by neighboring routers and advertised to this router:
From the above we see that R3, which is next hop for network 9.9.9.1/32 from R5 perspective, has assigned label 17 for traffic going to 9.9.9.1/32. This implies that when R5 will be routing traffic to this network, will impose label 17.
Label switching rules can be seen in /mpls forwarding-table. For example, on R3 it looks like this:
This rule says that R3 receiving packet with label 17 will change it to label 17 assigned by R2 for network 9.9.9.1/32 (R2 is next hop for 9.9.9.1/32 from R3 perspective):
R2 MPLS forwarding table tells:
Notice, that forwarding rule does not have any out-labels. The reason for this is that R2 is doing penultimate hop popping for this network. R1 does not assign any real label for 9.9.9.1/32 network, because it is known that R1 is egress point for 9.9.9.1/32 network (router is egress point for networks that are directly connected to it, because next hop for traffic is not MPLS router), therefore it advertises «implicit null» label for this route:
This tells R2 to forward traffic for 9.9.9.1/32 to R1 unlabelled, which is exactly what R2 mpls forwarding-table entry tells. Penultimate hop popping ensures that routers do not have to do unnecessary label lookup when it is known in advance that router will have to route packet.
Using traceroute in MPLS networks
RFC4950 introduces extensions to ICMP protocol for MPLS. The basic idea is that some ICMP messages may carry MPLS «label stack object» (list of labels that were on packet when it caused particular ICMP message). ICMP messages of interest for MPLS are Time Exceeded and Need Fragment.
MPLS label carries not only label value, but also TTL field. When imposing label on IP packet, MPLS TTL is set to value in IP header, when last label is removed from IP packet, IP TTL is set to value in MPLS TTL. Therefore MPLS switching network can be diagnosed by means of traceroute tool that supports MPLS extension.
For example, traceroute from R5 to R1 looks like this:
Drawbacks of using traceroute in MPLS network
Label switching ICMP errors
One of drawbacks of using traceroute in MPLS networks is the way MPLS handles produced ICMP errors. In IP networks ICMP errors are simply routed back to source of packet that caused the error. In MPLS network it is possible that router that produces error message does not even have route to source of IP packet (for example in case of assymetric label switching paths or some kind of MPLS tunneling, e.g. to transport MPLS VPN traffic).
Due to this produced ICMP errors are not routed to the source of packet that caused the error, but switched further along label switching path, assuming that when label switching path endpoint will receive ICMP error, it will know how to properly route it back to source.
Penultimate hop popping and traceroute source address
Thorough understanding of pen ultimate hop behaviour and routing is necessary to understand and avoid problems that penultimate hop popping causes to traceroute.
In the example setup, regular traceroute from R5 to R1 would yield the following results:
The reason why first traceroute does not get response from R3 is that by default traceroute on R5 uses source address 4.4.4.5 for its probes, because it is preferred source for route over which next hop to 9.9.9.1/32 is reachable:
R2 is penultimate hop popping router for network 4.4.4.0/24, because 4.4.4.0/24 is directly connected to R3. Therefore R2 removes last label and sends ICMP error to R3 unlabelled:
R3 drops received IP packet, because it receives packet with its own address as source address. ICMP errors produced by following probes come back correctly, because R3 receives unlabelled packets with source addresses 2.2.2.2 and 9.9.9.1, which are acceptable to route.
produces expected results, because source address of traceroute probes is 9.9.9.5. When ICMP errors are travelling back from R1 to R5, penultimate hop popping for 9.9.9.5/32 network happens at R3, therefore it never gets to route packet with its own address as source address.
Configuring VPLS
Configuring VPLS interfaces
VPLS interface can be considered tunnel interface just like EoIP interface. To achieve transparent ethernet segment forwarding between customer sites the following tunnels need to be established:
Note that each tunnel setup involves creating VPLS interfaces on both endpoints of tunnel.
VPLS tunnels are configured in /interface vpls menu. vpls-id parameter identifies VPLS tunnel and must be unique for every tunnel between this and remote peer.
The necessary setup:
Configuring VPLS tunnel causes dynamic LDP neighbor to be created and «targeted» LDP session to be established. Targeted LDP session is session that is established between two routers that are not direct neighbors. After this setup R1 LDP neighbors are:
Note that labels for IP routes are also exchanged between VPLS peers, although there is no chance any of them will be used. For example, without adding additional links, R4 will not become next hop for any route on R1, so labels learned from R4 are not likely to be ever used. Still routers maintain all labels exchanged so that they are ready for use immediately if needed. This default behaviour can be overridden by filtering which is discussed later.
By monitoring state of VPLS interface its related information can be viewed:
Here we can see that R1 has assigned label 27 for tunnel between R1 and R4. MPLS forwarding table shows that this label is recognized and instead of fowarding to some next hop, received over this tunnel:
In turn remote endpoint (R4) has assigned label 24.
Tunnel label imposed on packets will be as assigned by remote router (R4) for this tunnel.
imposed-labels reflect this setup: packets produced by tunnel will have 2 labels on them: 21 and 24.
Penultimate hop popping effects on VPLS tunnels
Another issue is having VPLS tunnel endpoints directly connected, as in case of R4 and R5. There are no transport labels they can use between themselves, because they both instruct other one to be penultimate hop popping router for their tunnel endpoint address. For example on R5:
This causes VPLS tunnel to use only tunnel label when sending packets:
Bridging ethernet segments with VPLS
VPLS tunnels provide virtual ethernet link between routers. To transparrently connect two physical ethernet segments, they must be bridged with VPLS tunnel. In general it gets done the same way as with EoIP interfaces.
So to transparently bridge customer B networks connected to R1 and R5 the following commands are used on R1:
Note that there is not need to run (R)STP protocol on bridge as there are links between segments B1 and B2 except single VPLS tunnel between R1 and R5.
Split horizon bridging
In the example setup there are 3 tunnels set up to connect segments A1, A2 and A3, establishing so called «full mesh» of tunnels between involved segments. If bridging without (R)STP was enabled, traffic loop would occur. There are a few solutions to this:
The basic idea of split horizon bridging is to make traffic arriving over some port never be sent out some set of ports. For VPLS purposes this would mean never sending packet that arrived over one VPLS tunnel over to other VPLS tunnel, as it is known in advance, that sender of packet has connection to target network itself.
For example, if device in A1 sent packet to broadcast or unknown MAC address (which causes bridges to flood all interfaces), it would get sent to both, R5 and R4 over VPLS tunnels. In regular setup e.g. R5 when receiving such packet over VPLS tunnel would send it in A2 connected to it and also over VPLS tunnel to R4. This way R4 would get 2 copies of the same packet and further cause traffic to loop.
Bridge horizon feature allows to configure bridge ports with horizon setting so that packet received over port with horizon value X is not forwarded or flooded to any port with the same horizon value X. So in case of full mesh of VPLS tunnels, each router must be configured with the same horizon value for VPLS tunnels that are bridged together.
For example, configuration commands for R1 to enable bridging for customer A are:
In similar way bridge should be configured on R4 and R5. Note that physical ethernet port is not configured with horizon value. If it was, that would disabled bridge forwarding data at all.
Optimizing label distribution
Label binding filtering
During implementation of given example setup, it has become clear that not all label bindings are necessary. For example, there is no need to exchange IP route label bindings between R1 and R5 or R1 and R4, as there is no chance they will ever be used. Also, if given network core is providing connectivity only for mentioned customer ethernet segments, there is no real use to distribute labels for networks that connect routers between themselves, the only routes that matter are /32 routes to endpoints of VPLS tunnels.
Label binding filtering can be used to distribute only specified sets of labels to reduce resource usage and network load.
There are 2 types of label binding filters:
Filters are organized in ordered list, specifying prefix that must include the prefix that is tested against filter and neighbor (or wildcard).
In given example setup all routers can be configured so that they advertise labels only for routes that allow to reach endpoints of tunnels. For this 2 advertise filters need to be configured on all routers:
This filter causes routers to advertise only bindings for routes that are included by 9.9.9.0/24 prefix which covers tunnel endpoints (9.9.9.1/32, 9.9.9.4/32, 9.9.9.5/32). The second rule is necessary because default filter result, when no rule matches is to allow action in question.
In given setup there is no need to set up accept filter, because by convention introduced by 2 abovementioned rules no LDP router will distribute unnecessary bindings.
Note that filter changes do not affect existing mappings, so to take filter into effect, connections between neighbors need to be reset. This can get done by removing them:
So on R1, for example we get:
To filter out those, we configure routers to not distribute any IP bindings to any of tunnel endpoint routers. For example on R1, filter table should look like this:
This causes routers to have minimal label binding tables, for example on R1:
Note that IP binding distribution should not be disabled between R4 and R5 although they are tunnel endpoints. Doing so would not harm regular case, because R4 and R5 does not need IP bindings to VPLS tunnel data, but in case link between R3 and R5 would go down, all traffic to R5 from R1 would have to be rerouted through R4. In such case R5 not distributing IP bindings to R4 would cause R4 to not be able to forward MPLS traffic to R5.
Effects of label binding filtering on data forwarding in network
But in case of traceroute using R1 address that faces network:
On the other hand, traceroute from R1 to R5 using their non-loopback addresses:
There is no label switching involved doing this traceroute and it works just like in network without MPLS at all.