...
For instructions on how to set up properly IGP refer to appropriate documentation sections:
LDP supports ECMP routes.
...
Verify that IP connectivity and routing are working properly
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R4] /ip/address> /tool traceroute 111.111.111.1 src-address=111.111.111.4 Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV 1 111.13.0.1 0% 4 0.6ms 0.6 0.6 0.6 0 2 111.12.0.1 0% 4 0.5ms 0.6 0.5 0.6 0.1 3 111.111.111.1 0% 4 0.6ms 0.6 0.6 0.6 0 |
...
After LDP sessions are established, R2 should have two LDP neighbors:
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R2] /mpls/ldp/neighbor> print Flags: D, I - INACTIVE; O, T - THROTTLED; p - PASSIVE Columns: TRANSPORT, LOCAL-TRANSPORT, PEER, ADDRESSES # TRANSPORT LOCAL-TRANSPORT PEER ADDRESSES 0 DO 111.111.111.1 111.111.111.2 111.111.111.1:0 111.11.0.1 111.111.111.1 1 DOp 111.111.111.3 111.111.111.2 111.111.111.3:0 111.12.0.2 111.13.0.1 111.111.111.3 |
...
The local mappings table shows what label is assigned to what route and peers the router have distributed labels to.
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R2] /mpls/ldp/local-mapping> print Flags: I - INACTIVE; D - DYNAMIC; E - EGRESS; G - GATEWAY; L - LOCAL Columns: VRF, DST-ADDRESS, LABEL, PEERS # VRF DST-ADDRESS LABEL PEERS 0 D G main 10.0.0.0/8 16 111.111.111.1:0 111.111.111.3:0 1 IDE L main 10.155.130.0/25 impl-null 111.111.111.1:0 111.111.111.3:0 2 IDE L main 111.11.0.0/24 impl-null 111.111.111.1:0 111.111.111.3:0 3 IDE L main 111.12.0.0/24 impl-null 111.111.111.1:0 111.111.111.3:0 4 IDE L main 111.111.111.2 impl-null 111.111.111.1:0 111.111.111.3:0 5 D G main 111.111.111.1 17 111.111.111.1:0 111.111.111.3:0 6 D G main 111.111.111.3 18 111.111.111.1:0 111.111.111.3:0 7 D G main 111.111.111.4 19 111.111.111.1:0 111.111.111.3:0 8 D G main 111.13.0.0/24 20 111.111.111.1:0 111.111.111.3:0 |
...
Remote mappings table on the other hand shows labels that are allocated for routes by neighboring LDP routers and advertised to this router:
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R2] /mpls/ldp/remote-mapping> print Flags: I - INACTIVE; D - DYNAMIC Columns: VRF, DST-ADDRESS, NEXTHOP, LABEL, PEER # VRF DST-ADDRESS NEXTHOP LABEL PEER 0 ID main 10.0.0.0/8 16 111.111.111.1:0 1 ID main 10.155.130.0/25 impl-null 111.111.111.1:0 2 ID main 111.11.0.0/24 impl-null 111.111.111.1:0 3 ID main 111.12.0.0/24 17 111.111.111.1:0 4 D main 111.111.111.1 111.11.0.1 impl-null 111.111.111.1:0 5 ID main 111.111.111.2 19 111.111.111.1:0 6 ID main 111.111.111.3 20 111.111.111.1:0 7 ID main 111.111.111.4 21 111.111.111.1:0 8 ID main 111.13.0.0/24 18 111.111.111.1:0 9 ID main 0.0.0.0/0 impl-null 111.111.111.3:0 10 ID main 111.111.111.2 16 111.111.111.3:0 11 ID main 111.111.111.1 18 111.111.111.3:0 12 D main 111.111.111.3 111.12.0.2 impl-null 111.111.111.3:0 13 D main 111.111.111.4 111.12.0.2 19 111.111.111.3:0 14 ID main 10.155.130.0/25 impl-null 111.111.111.3:0 15 ID main 111.11.0.0/24 17 111.111.111.3:0 16 ID main 111.12.0.0/24 impl-null 111.111.111.3:0 17 D main 111.13.0.0/24 111.12.0.2 impl-null 111.111.111.3:0 |
...
The remote mapping table will have active mappings only for the destinations that have direct next-hop, for example, let's take a closer look at 111.111.111.4 mappings. The routing table indicates that the network 111.111.111.4 is reachable via 111.12.0.2 (R3):
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R2] /ip/route> print where dst-address=111.111.111.4 Flags: D - DYNAMIC; A - ACTIVE; o, y - COPY Columns: DST-ADDRESS, GATEWAY, DISTANCE DST-ADDRESS GATEWAY DISTANCE DAo 111.111.111.4/32 111.12.0.2%ether3 110 |
And if we look again at the remote mapping table, the only active mapping is the one received from R3 with assigned label 19. This implies that when R2 when routing traffic to this network, will impose label 19.
Code Block | ||||
---|---|---|---|---|
| ||||
17 D main 111.111.111.4 111.12.0.2 19 111.111.111.3:0 |
...
Label switching rules can be seen in the forwarding table:
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R2] /mpls/forwarding-table> print Flags: L, V - VPLS Columns: LABEL, VRF, PREFIX, NEXTHOPS # LABEL VRF PREFIX NEXTHOPS 0 L 16 main 10.0.0.0/8 { nh=10.155.130.1; interface=ether1 } 1 L 18 main 111.111.111.3 { label=impl-null; nh=111.12.0.2; interface=ether3 } 2 L 19 main 111.111.111.4 { label=19; nh=111.12.0.2; interface=ether3 } 3 L 20 main 111.13.0.0/24 { label=impl-null; nh=111.12.0.2; interface=ether3 } 4 L 17 main 111.111.111.1 { label=impl-null; nh=111.11.0.1; interface=ether2 } |
...
Now if we look at the forwarding table of R3:
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R3] /mpls/forwarding-table> print Flags: L, V - VPLS Columns: LABEL, VRF, PREFIX, NEXTHOPS # LA VRF PREFIX NEXTHOPS 0 L 19 main 111.111.111.4 { label=impl-null; nh=111.13.0.2; interface=ether3 } 1 L 17 main 111.11.0.0/24 { label=impl-null; nh=111.12.0.1; interface=ether2 } 2 L 16 main 111.111.111.2 { label=impl-null; nh=111.12.0.1; interface=ether2 } 3 L 18 main 111.111.111.1 { label=17; nh=111.12.0.1; interface=ether2 } |
...
RFC4950 introduces extensions to the ICMP protocol for MPLS. The basic idea is that some ICMP messages may carry an MPLS "label stack object" (a list of labels that were on the packet when it caused a 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 a label on an IP packet, MPLS TTL is set to value in the IP header, when the last label is removed from the IP packet, IP TTL is set to value in MPLS TTL. Therefore MPLS switching network can be diagnosed by means of a traceroute tool that supports MPLS extension.
For example, the traceroute from R4 to R1 looks like this:
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R1] /mpls/ldp/neighbor> /tool traceroute 111.111.111.4 src-address=111.111.111.1 Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV, STATUS # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 111.11.0.2 0% 2 0.7ms 0.7 0.7 0.7 0 <MPLS:L=19,E=0> 2 111.12.0.2 0% 2 0.4ms 0.4 0.4 0.4 0 <MPLS:L=19,E=0> 3 111.111.111.4 0% 2 0.5ms 0.5 0.5 0.5 0 |
...
Traceroute results show MPLS labels on the packet when it produced ICMP Time Exceeded. The above means: that when R3 received a packet with MPLS TTL 1, it had label 18 on it. This match advertised label advertised by R3 for 111.111.111.4. In the same way, R2 observed label 17 on the packet on the next traceroute iteration - R3 switched label 17 to label 17, as explained above. R1 received packet without labels - R2 did penultimate hop popping as explained above.
...
The reason why the first traceroute does not get a response from R3 is that by default traceroute on R5 uses source address 4.4.4.5 for its probes , because it is the preferred source for a route over which next-hop to 9.9.9.1/32 is reachable:
...
So on R2, for example, we get:
Code Block | ||||
---|---|---|---|---|
| ||||
[admin@R2] /mpls/ldp/remote-mapping> print Flags: I - INACTIVE; D - DYNAMIC Columns: VRF, DST-ADDRESS, NEXTHOP, LABEL, PEER # VRF DST-ADDRESS NEXTHOP LABEL PEER 0 ID main 111.111.111.2 17 111.111.111.3:0 1 ID main 111.111.111.1 16 111.111.111.3:0 2 D main 111.111.111.3 111.12.0.2 impl-null 111.111.111.3:0 3 D main 111.111.111.4 111.12.0.2 18 111.111.111.3:0 4 ID main 111.111.111.2 16 111.111.111.1:0 5 D main 111.111.111.1 111.11.0.1 impl-null 111.111.111.1:0 6 ID main 111.111.111.3 17 111.111.111.1:0 7 ID main 111.111.111.4 18 111.111.111.1:0 |
...
RouterOS implements RFC 7552 to support LDP on dual-stack links.
Supported AFIs can be selected by LDP instance, as well as explicitly configured per LDP interface.
Code Block | ||
---|---|---|
| ||
/mpls ldp add afi=ip,ipv6 lsr-id=111.111.111.1 preferred-afi=ipv6 /mpls ldp interface add interface=ether2 afi=ip add interface=ether3 afi=ipv6 |
Example The example above enables LDP instance to use IPv4 and IPv6 address families and sets the preference to IPv6 with preferred-afi
parameter. LDP interface configuration on the other hand explicitly sets that ether2 supports only IPv4 and ether3 supports only IPv6.
...
The main question occurs how AFI is selected when there are a mix of different AFIs and what if one of the supported AFIs flaps.
The logic behind sending hellos is as follows:
- if an interface has only one AFI:
- dual-stack element is not sent
- sends hello only if there is an IP address on the interface from the corresponding AFI.
- If an interface has both AFIs:
- dual-stack element is always sent and contains the value from preferred-afi
- sends hellos on each AFI if a corresponding address is present on the interface.
...
From all received hellos peer determines which AFI to use for connection and for which AFIs to bind and send labels. For LDP to be able to use a specific AFI, received receiving hello for that specific AFI is mandatory. Hello packet contains the transport - address necessary for proper LDP operation. By comparing received AFI addresses, is determined active/passive role.
The logic behind receiving and processing hellos is as follows:
- if the LDP instance has only one AFI (it means that all interfaces can have only that specific AFI operational):
- drop hellos from not supported AFI
- ignore/forget the dual-stack element for the hello packet
- the role is determined only for this one specific AFI
- labels are sent only for this one specific AFI
- if the LDP instance has both AFIs (interfaces can have different combinations of supported AFIs):
- drop hellos from AFI that is are not configured as supported on the interface.
- ignore/forget the dual-stack element (preference is not taken into account) for hello packets, if an interface has only one supported AFI.
- drop hello if received preference in dual-stack element does not match configured
preferred-afi
.
...
If there are changes in hello packets, the existing session is terminated only in case if address family used by labels is changed, otherwise, the session is preserved.
Dual-stack element in hello packets is set only if an interface is determined to be dual-stack compatible:
- Normally such an interface should be able to receive hellos from both AFIs,
- Before proceeding LDP should wait for hello from the preferred AFI.
- if hello is received only from one AFI:
- if hello from preferred AFI is not received then it is considered an error.
- otherwise, wait for missing hello for x seconds (x = 3 * hello-interval)
- if missing hello appears within a time interval consider peer to be dual-stack
- if missing hello did not appear, then consider peer to be single-stack
- if missing hello appeared after the time interval then restart the session.
- the dual-stack element indicates that LDP wants to distribute labels for both AFIs.
In summary, the following combinations of AFIs and dual-stack element (ds6) are possible assuming that preferred-afi=ipv6:
- ipv4 - wait X seconds, if no changes, then use the IPv4 LDP session and distribute IPv4 labels
- ipv4+ds6 - wait for IPv6 hello, dual-stack element indicates that there should be IPv6
- ipv6 - wait X seconds, if no changes, then use the IPv6 LDP session and distribute IPv6 labels
- ipv6+ds6 - use IPv6 LDP session and distribute IPv6 labels
- ipv4,ipv6 - use IPv6 LDP session and distribute IPv4 and IPv6 labels
- ipv4,ipv6+ds6 - use IPv6 LDP session and distribute IPv4 and IPv6 labels
...
Property | Description |
---|---|
afi (ip | ipv6; Default: ) | Determines supported address families by the instance. |
comments (string; Default: ) | Short description of the entry |
disabled (yes | no; Default: no) | |
distribute-for-default (yes | no; Default: no) | Defines whether to map label for the default route. |
hop-limit (integer[0..255]; Default: ) | Max hop limit used for loop detection. Works in combination with the loop-detectproperty. |
loop-detect (yes | no; Default: ) | Defines whether to run LSP loop detection. Will not work correctly if not enabled on all LSRs. Should be used only on non-TTL networks such as ATMs. |
lsr-id (IP; Default: ) | Unique label switching router's ID. |
path-vector-limit (IP; Default: ) | Max path vector limit used for loop detection. Works in combination with the loop-detectproperty. |
preferred-afi (ip | ipv6; Default: ipv6) | Determines Determining which address family connection is preferred. Value is also set in dual-stack element (if used). |
transport-addresses (IP; Default: ) | Specifies LDP session connections origin addresses and also advertises these addresses as transport addresses to LDP neighbors. |
use-explicit-null (yes | no; Default: no) | Whether to distribute explicit-null label bindings. |
vrf (name; Default: main) | Name of the VRF table this instance will operate on. |
...
Property | Description |
---|---|
afi (ip | ipv6; Default: ) | Determines interface address family. Only AFIs that are configured as supported by the instance are is taken into account. If the value is not explicitly specified then it is considered to be equal to the instance-supported AFIs. |
accept-dynamic-neighbors (yes | no; Default:) | Defines whether to discover neighbors dynamically or use only statically configured in LDP neighbors menu |
comments (string; Default: ) | Short description of the entry |
disabled (yes | no; Default: no) | |
hello-interval (string; Default: ) | The interval between hello packets that the router sends out on specified interface/s. The default value is 5s. |
hold-time (string; Default: ) | Specifies the interval after which a neighbor discovered on the interface is declared as not reachable. The default value is 15s. |
interface (string; Default: ) | Name of the interface or interface list where LDP will be listening. |
transport-addresses (List of IPs; Default: ) | Used transport addresses if differs from LDP Instance settings. |
...
Sub-menu: /mpls ldp neighbor
This
Accept Filter
Sub-menu: /mpls ldp accept-filter
...
List of discovered and statically configured LDP neighbors.
Properties
Property | Description |
---|---|
comments (string; Default: ) | Short description of the entry |
disabled (yes | no; Default: no) | |
send-targeted (yes | no; Default: ) | Specifies whether to try to send targeted hellos, used for targeted (not directly connected) LDP sessions. |
transport (IP; Default: ) | Remote transport address. |
Read-only Properties
Property | Description |
---|---|
active-connect (yes | no) | Indicates that active role have been selected and the router is trying to establish the session. |
addresses (list of IPs) | List of discovered addresses on the neighbor |
inactive (yes | no) | Whether binding is active and can be selected as a candidate for forwarding. |
dynamic (yes | no) | Whether entry was dynamically added |
local-transport (IP) | Selected local transport address. |
on-demand (yes | no) | Downstream On Demand label distribution |
operational (yes | no) | Indicates whether the peer is operational. |
passive (yes | no) | Indicates whether the peer is in a passive role. |
passive-wait (yes | no) | Indicates whether the peer is in a passive role and currently is waiting for the session to be initialized. |
path-vector-limit (integer) | |
peer (IP:integer) | LSR-ID and label space of the neighbor |
sending-targeted-hello(yes | no) | Whether targeted hellos are being sent to the neighbor. |
throttled (yes | no) | Indicates whether session is in throttled state. Session is throttled after initialization failure, max throttle time 120s. |
used-afi (yes | no) | Used transport AFI |
vpls (yes | no) | Whether neighbor is used by VPLS tunnel |
Accept Filter
Sub-menu: /mpls ldp accept-filter
List of label bindings that should be accepted from LDP neighbors.
Property | Description |
---|---|
accept (yes | no; Default: no) | Whether to accept label bindings from the neighbors for the specified prefix. |
comments (string; Default: ) | Short description of the entry |
disabled (yes | no; Default: no) | |
neighbor(string; Default: ) | Neighbor to which this filter applies. |
prefix (IP/mask; Default: ) | Prefix to match. |
vrf (name; Default: ) |
Advertise Filter
Sub-menu: /mpls ldp advertise-filter
List of label bindings that should be advertised to LDP neighbors.
Property | Description |
---|---|
advertise (yes | no; Default: no ) | Whether to advertise label bindings to the neighbors for the specified prefix. |
comments (string; Default: ) | Short description of the entry |
disabled (yes | no; Default: no) | |
neighbor(string; Default: ) | Neighbor to which this filter applies. |
prefix (IP/mask; Default: ) | Prefix to match. |
vrf (name; Default: ) |
Advertise Filter
Sub-menu: /mpls ldp advertise-filter
...
Local Mapping
Sub-menu: /mpls local-mapping
This sub-menu shows labels bound to the routes locally in the router. In this menu also static mappings can be configured if there is no intention to use LDP dynamically.
Properties
Property | Description |
---|---|
comments (string; Default: ) | Short description of the entry |
disabled (yes | no; Default: no) | |
dst-address (IP/Mask; Default: ) | Destination prefix the label is assigned to. |
label (integer[0..1048576] | alert | expl-null | expl-null6 | impl-null | none; Default: ) | Label number assigned to destination. |
vrf (name; Default: main) | Name of the VRF table this mapping belongs to. |
Read-only Properties
Property | Description |
---|---|
adv-path () | |
inactive (yes | no) | Whether binding is active and can be selected as a candidate for forwarding. |
dynamic (yes | no) | Whether entry was dynamically added |
egress (yes | no) | |
gateway (yes | no) | Whether the destination is reachable through the gateway. |
local (yes | no) | Whether the destination is locally reachable on the router |
peers (IP:label_space) | IP address and label space of the peer to which this entry was advertised. |
Remote Mapping
Sub-menu: /mpls remote-mapping
Sub-menu shows label bindings for routes received from other routers. Static mapping can be configured if there is no intention to use LDP dynamically. This table is used to build Forwarding Table
Properties
Property | Description |
---|---|
comments (string; Default: ) | Short description of the entry |
disabled (yes | no; Default: no) | |
dst-address (IP/Mask; Default: ) | Destination prefix the label is assigned to. |
label (integer[0..1048576] | alert | expl-null | expl-null6 | impl-null | none; Default: ) | Label number assigned to destination. |
nexthop (IP; Default:) | |
vrf (name; Default: main) | Name of the VRF table this mapping belongs to. |
Read-only Properties
Property | Description |
---|---|
inactive (yes | no) | Whether binding is active and can be selected as a candidate for forwarding. |
dynamic (yes | no) | Whether entry was dynamically added |
path (string) |