Horizon mikrotik что это
To achieve similar functionality to Cisco's private VLANS, where all ports are on the same L2 segment, but cannot exchange packets, you can use Mikrotik's Bridge Horizon feature.
Basically, every port in a bridge is assigned a horizon value, and RouterOS will only forward frames to other interfaces in the bridge that have different horizon values.
This means that you assign the same horizon value to the interfaces that you don't want to be able to communicate.
For example, you want to bridge all your customers and use a single /24 subnet and the same gateway. Typically this is bad and poses a huge security risk, not to mention performance issues. If you assign the same horizon value to the customer interfaces, then the router will not forward traffic between customers. Customer A will not be able to ping Customer B.
If you had a server, such as an IP-PBX that all customers needed to access, and you were lazy and added it to the bridge, then you would assign a different horizon value to that port.
Встречайте Bridge Controller
Без всяких слов, посмотрим как использовать сие чудо =)
Берём одну из железок из списка CRS309-1G-8S , CRS317-1G-16S , CRS312-4C+8XG , CRS326-24S+2Q , CRS354-48G-4S+2Q , CRS354-48P-4S+2Q+ . (список не окончательный и скорее всего будет расширяться). Устанавливаем последнюю testing версию RouterOS.
И на железке выполняем следующее:
Запускаем контроллер указанием, что у нас есть два порта к которому подключены другие устройства MikroTik.
Подключаем наши устройства именно в порты нашего контроллера, которые указали в параметре cascade-ports .
Оба коммутатора подключены своим sfp-sfpplus1 портом. Далее на каждом коммутаторе выполняем команду.
Тем самым указываем в каком порту находится контроллер. bridge создавать не нужно, всё будет сделано автоматически.
Если необходимо подключить устройства каскадом, то на проходных коммутаторах, необходимо указать дополнительный port-extender до следующего коммутатора.
Вы всегда можете посмотреть подключенные устройства на контроллере командой /interface bridge port-controller device print
Теперь на контроллере вам доступны все интерфейсы всех подключенных коммутаторов и вы можете их настраивать как вам вздумается.
MikroTik для Больших Дядей N5
Подведём небольшой итог всего того, чего мы добились.
На данный момент у нас работает 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
VPLS - это туннель, которые позволяет, пропустить через себя ethernet трафик, т.е для того чтобы предоставить услугу L2 VPN, по сути аналогичную роль в RouterOS выполняет EoIP туннель.
VPN4 - это способ доставки IP пакета, через MPLS сеть, т.е предоставление клиенту услуги L3 VPN, но самое главное, что клиент может использовать любые сети, и они не как не будут влиять на ваши сети и сети других ваших клиентов.
Но мы же провайдер, поэтому ручной метод нам не подходит, мы бы хотели всё и вся оптимизировать.
Перед тем как начать, настраивать BGP нам надо осознать, что всё что мы до этого делали, необходимо было для работы в BGP между Loopback адресами.
Уточним задачу, у нас есть клиент под Котору необходимо предоставить услуги L2VPN, между двумя маршрутизаторами CE.
И так нам необходимо связать два маршрутизатора CE с помощь протокола BGP и указать чем будет заниматься BGP протокол. Напомню, что он может распространять не только маршрутную информацию но и распространять дополнительную информацию, именно эту дополнительную информацию мы будем распространять.
Точно также как и в OSPF у BGP маршрутизатора есть RouterID значение должно быть уникальным в пределах одной AS.
AS - автономная система, помимо того что это номер 16 бит, а сейчас и все 32 бита, это ещё и политическая сущность, которая определяет, маршрутизаторы которые находятся в одной AS подчиняются одним правилам.
Для наших задач мы будем использовать отдельный instance и номер автономной системы 65000. Необходимо напомнить что диапазон номеров AS разделён на две части приватный и публичный, примерно также как и BOGON адреса, только есть одно серьёзное отличие, эти диапазоны намертво вшиты в протокол и его реализацию в RouterOS, поэтому вы ОБЯЗАНЫ использовать именно из приватного диапазона номера AS от 64512 до 65535. Публичный диапазон только если у вас есть своя AS либо на стендах когда вы делаете "один к одному".
И так сначала нам необходимо на CE маршрутизаторах создать BGP instance
Следующим шагом, нам необходимо связать два маршрутизатора, с помощью настроенных пиров BGP с двух сторон.
Давайте посмотрим на команду и распишем, какие параметры bgp Peer и для чего они нужны, не все, а только те который нам необходимы.
remote-address=172.31.243.2 - Указываем адрес противоположенного пира.
update-source=172.31.253.1 - Указываем адрес с которого будет строиться соединение, тут надо уточнить. Вы можете указать не адрес, а интерфейс, но если на интерфейс будет несколько IP адресов может произойти факап.
remote-as=65000 - Удалённая AS, если её номер совпадает с instance указанным в instance=bgp65000 то такое соединение считается как iBGP internal т.е. Внутренним. Если значения AS разные то такое поведение называется eBGP т.е. Внешнее соединение.
address-families=l2vpn,l2vpn-cisco,vpnv4 - так называемые типы данных которые будут передаваться с помощью данного пира BGP.
После того вы сделаете на всех маршрутизаторах, проверить то, что мы идём по верной дороге и всё у нас получается. Узнать состояние Peer
Состояние соединения должно быть Established, слево флаг E.
Когда мы строим VPLS то у пакета появляется не одна метка, а две (стек меток), первая метка обеспечивает прохождение трафика по MPLS сети, вторая метка указывает непосредственно на PW туннель.
Для того, чтобы запустить нашу "Трубу" или PW нам необходимо подготовить инфраструктуру. Надеюсь вы помните, что CE маршрутизатор, это тот маршрутизатор к которому подключается непосредственно клиенты.
Нам необходимо подготовить Bridge в порты которого будут присоединено оборудование клиента, также можно сделать и с vlan. Мы не будем добавлять интерфейсы нам достаточно для понимания самого принципа построения таких сетей.
И так необходимо создать Bridge c отключенным rstp\stp, мы не будем мешать нашему клиенту делать петли, если ему надо будет делает петли, пусть делает это его желание )), наша задача предоставить ему L2 туннель между точками включения на маршрутизаторах CE.
Название бриджа позаимствовано из вымышленного номера договора либо какого-то внутренного номера. Пусть будет клиент под номером 1.
Далее нам необходимо объявить через BGP на CE маршрутизаторах VPLS туннели.
route-distinguisher=172.31.253.1:0 - Уникальное значение для каждого маршрутизатора, и в некоторых случаях может быть для уникальное значение для разных ролей. С помощью данного значения создаётся уникальность информации которая передаётся средствами BGP. Лучше всего укажите адрес loopback и просто порядковый номер, пока это неважно.
bridge=bridge-C1 - Когда VPLS поднимется, то интерфейс добавится автоматически в Bridge нашего клиента.
bridge-horizon=10 - технология которая позволит нам поднять fullmesh связь между все маршрутизаторами и защититься от возможной петли, если не указать, то она будет 100% при подключении следующего маршрутизатора. Смысл технологии очень простой если фрейм придёт в интерфейс Bridge, и у интерфейса с которого пришло фрейм установлено значение horizon, такой фрейм не будет отправлен в интерфейсы у которых значение horizon аналогичное. Будте пределы аккуратны, если на Bridge будет отключен rstp/stp и вы не установите значение horizon у вас будет L2 Loop.
pw-type=raw-ethernet - указываем какого типа PW.
site-id=1001 - уникальное значение, для всей AS и для каждого маршрутизатора. Тут надо быть внимательным, необходимо найти такой способ, чтобы сделать это значение с двух стороны уникальным и это значение не должно больше использоваться. Лучше все использовать такой подход, берём номер маршрутизатора умножаем на 1000 и прибавляем номер клиента. Получается, что значение site-id на первом маршрутизаторе будет для первого клиента 1001, а для второго 1002, на маршрутизаторе CE-3 3001 и соответственно 3002. Уникальность значения требуется из за того, что значение site-id используется для расчёта номера метки MPLS, но просто давать порядковые номера не очень удобно, в виду того, что придёться вести где-то документацию. Я несколько не призываю отказываться от документации, но всегда можно упростить себе жизнь прибегая к определённым шаблонам.
А наверное самое главное.
export-route-targets=65000:1 - хорошим кейсом (Вообще так и задумывалось, но некоторые игнорируют даней аспект) считается указывать сначала номер AS, а далее через разделитель двоеточие, номер клиента. Чтобы понять для чего этот параметр необходим, это уникальный идентификатор данного туннеля. Ключевое слово export т.е. Данный маршрутизатор будет "вещать" раскатывать всем своим пирам, о том что у него есть такой туннель VPLS. На стороне клиента данное значение должно быть указанно в поле import-route-targets .
import-route-targets=65000:1 - тип записи который мы ожидаем для сопоставления с данным VPLS туннелем, часто мы должны указать значение которое указанно на противоположенной стороне в export-route-targets .
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:
- R1-R5 (customer A)
- R1-R4 (customer A)
- R4-R5 (customer A)
- R1-R5 (customer B)
Note that each tunnel setup involves creating VPLS interfaces on both endpoints of tunnel.
Negotiation of VPLS tunnels is done by LDP protocol - both endpoints of tunnel exchange labels they are going to use for tunnel. Data forwarding in tunnel then happens by imposing 2 labels on packets: tunnel label and transport label - label that ensures traffic delivery to the other endpoint 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:
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.
igp-prefix shows route that is used to get to remote endpoint of tunnel. This implies that when forwarding traffic to remote endpoint of tunnel this router will impose transport label - label distributed by next hop (which is shown as igp-nexthop) to 9.9.9.4/32 for 9.9.9.4/32 route. This can be confirmed on R2:
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
Penultimate hop popping of transport label causes packets to arrive at VPLS tunnel endpoint with just one tag - tunnel tag. This makes VPLS tunnel endpoint do just one label lookup to find out what to do with packet. Transport label behaviour can be observed by traceroute tool between tunnel endpoints. For example, traceroute from R1 to R4 looks like this:
traceroute output shows, that endpoint of tunnel is receiving probe without label. The same happens with VPLS tunnel traffic - at R3 transport label (18) is popped and packet is switched with just tunnel label on.
The requirement to deliver packet with tunnel label to endpoint of tunnel explains configuration advice to use "loopback" IP addresses as tunnel endpoints. If in this case R4 was establishing LDP sessions with its address 3.3.3.4, penultimate hop popping would happen not at R3, but at R2, because R3 has network 3.3.3.0/24 as its connected network (and therefore advertises implicit null label). This would cause R3 (and not R4) to receive packet with just tunnel label on, yielding unpredicted results - either dropping frame if R3 does not recognize the packet or forwarding it the wrong way.
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:
- enabling (R)STP to eliminate the loop. This approach has a drawback - (R)STP protocol would disable forwarding through one of tunnels and keep it just for backup purposes. That way traffic between 2 segments would have to go through 2 tunnels, making setup inefficent
- using bridge firewall to make sure that traffic does not get looped - involves firewall rule setup making bridging less efficent
- using bridge horizon feature
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.
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.
Note that horizon value has meaning only locally - it does not get transmitted over network, therefore it does not matter if the same value is configured in all routers participating in bridged network.
MikroTik Controller Bridge
. Естественно так как пока это тестирование, не о каком проде речи быть не может.
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:
- as there is only one LDP session between any 2 routers, no matter how many links connect them, loopback IP address ensures that LDP session is not affected by interface state or address changes
- use of loopback address as LDP transport address ensures proper penultimate hop popping behaviour when multiple labels are attached to packet as in case of VPLS
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
As LDP distributes labels for active routes, essential requirement is properly configured IP routing. LDP by default distributes labels for active IGP routes (that is - connected, static, and routing protocol learned routes, except BGP).
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:
Manual:MPLSVPLS
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.
Enabling MPLS forwarding can speed up packet forwarding process in such network. Using one of MPLS applications - VPLS can further increase efficency of ethernet frame forwarding by not having to encapsulate ethernet frames in IP frames, thus removing IP header overhead.
This guide gives step by step instructions that will lead to implementation of VPLS to achieve necessary service.
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.
Other routers are configured in similar way - LDP is enabled on interfaces that connect routers and not enabled on interfaces that connect customer networks. For example, on R5:
After LDP sessions are established, on R5 there are 2 LDP neighbors:
/mpls local-bindings shows labels that this router has assigned to routes and peers it has distributed the label to. It shows that R5 has distributed labels for all its routes to both of its neighbors - R3 and R4
/mpls remote-bindings shows labels that are allocated for routes by neighboring routers and advertised to this router:
Here we can observe that R5 has received label bindings for all routes from both its neighbors - R3 and R4, but only the ones for whom particular neighbor is next hop are active. For example:
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.
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:
- which label bindings should be advertised to LDP neighbors, configured in /mpls ldp advertise-filter
- which label bindings should be accepted from LDP neighbors, configured in /mpls ldp accept-filter
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:
There still are unnecessary bindings, this time - the bindings distributed due to establishing targeted LDP session with remote endpoints of VPLS tunnels (bindings from 9.9.9.5 and 9.9.9.4)
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
Note the traceroute results after these changes. Traceroute from R1 to R5 using R1 loopback address as source address still behaves the same - each hop reports received labels:
But in case of traceroute using R1 address that faces network:
Now all hops except the last one do not respond. The reason for this is the fact, that there is no label switching path back from R5 to R1 (which this time uses address 1.1.1.1) because there are no label bindings distributed - so ICMP response is routed and routers on the way back (R3 and R2) receive packets with their own source address and drop them right away without routing.
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.
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.
This causes the situation, that traceroute in MPLS network can not be used the same way as in IP network - to determine failure point in the network. If label switched path is broken anywhere in the middle, no ICMP replies will come back, because they will not make it to the far endpoint of label switching path.
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:
When first traceroute probe is transmitted (source: 4.4.4.5, destination 9.9.9.1), R3 drops it and produces ICMP error message (source 4.4.4.3 destination 4.4.4.5) that is switched all the way to R1. R1 then sends ICMP error back - it gets switched along label switching path to 4.4.4.5.
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.
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:
Traceroute results show MPLS labels on packet when it produced ICMP Time Exceeded. The above means: when R3 received packet with MPLS TTL 1, it had label 17 on. This matches label advertised by R3 for 9.9.9.1/32. The same way R2 observed label 17 on packet on next traceroute iteration - R3 switched label 17 to label 17, as explaned above. R1 received packet without labels - R2 did penultimate hop popping as explaned above.
Читайте также: