Ospf/is-is + mpls issue

RouterOS Forwarding Protocols
1

Hi everyone,

I am managing a multi-vendor network consisting of Cisco, Huawei, and MikroTik devices. The core uses IS-IS and MPLS across most of the infrastructure. We still have several MikroTik units running ROS v6 using OSPF and MPLS, most of which terminate on a Huawei PE/P router.

The issue arises when we upgrade these ROS v6 devices to ROS v7. We immediately experience reachability issues, suggesting a conflict or interoperability problem between MPLS and the IGP (we tested both OSPF and IS-IS, but the result is the same).

The problem specifically occurs in the following topology:

New draw.io Diagram-102575.drawio
New draw.io Diagram-102575.drawio570×745 24.2 KB

The first MikroTik directly connected to the Huawei router appears stable. However, the second MikroTik connected in series (daisy-chained) to the first one loses reachability. If we disable MPLS, routing recovers and the device becomes reachable again.

One anomaly I’ve noticed on the first MikroTik is that the monitoring route is flagged as invalid in /mpls ldp local-mapping. This is the only technical detail that seems out of place. Below is an example from a lab environment reproducing the issue:

[networkers@test-MK1] /mpls/ldp/local-mapping> print where dst-address=172.25.255.240/28
Flags: I - INACTIVE; D - DYNAMIC; G - GATEWAY
Columns: VRF, DST-ADDRESS, LABEL, PEERS
  #      VRF   DST-ADDRESS        LABEL  PEERS          
138 IDG main  172.25.255.240/28    151   172.25.1.112:0
                                         172.25.0.10:0 
[networkers@test-MK1] /mpls/ldp/local-mapping>

P.S. This issue does not occur when the MikroTik is connected to a Cisco device instead of a Huawei.
P.P.S. The issue is also observable from other devices within the network.
However, everything becomes reachable again if I specify the Loopback IP as the source IP when performing connectivity checks (pings/traceroutes).

OSPF or MPLS issue after upgrading from ROS v6 to ROS v7
2

Here

Huawei and Mikrotik configurations:

Huawei

isis 1
is-level level-2
cost-style wide
ldp-sync enable
mpls ldp auto-config
network-entity 49.2015.1720.2500.0010.00
adjacency-strict-check enable
is-name rme2-isi0
import-route direct route-policy rm-red-conn
import-route static
frr
loop-free-alternate level-2

ipv6 enable topology standard
ipv6 import-route direct





interface GigabitEthernet0/5/12
 mtu 1546
 description To Mikrotik test1
 undo shutdown
 ip address 172.25.5.1 255.255.255.252
 isis enable 1
 isis circuit-type p2p
 isis circuit-level level-2
 isis cost 10
 mpls
 mpls ldp
 undo dcn

Mikrotik 1

/routing isis instance
add afi=ip areas=49.2098 areas-max=3 disabled=no name=isis-instance system-id=1720.2500.1111
/routing isis interface-template
add instance=isis-instance interfaces=sfp1 levels=l2 ptp
add instance=isis-instance interfaces=lobridge0 levels=l2 passive
add instance=isis-instance interfaces=sfp2 levels=l2 ptp
/mpls interface
add interface=all
/mpls ldp
add disabled=no lsr-id=172.25.1.111 transport-addresses=172.25.1.111
/mpls ldp interface
add disabled=no interface=sfp1
add disabled=no interface=sfp2
add disabled=no interface=lobridge0

#SFP1 go to Huawei
#SFP2 go to Mikrotik 2

Mikrotik 2

/routing isis instance
add afi=ip areas=49.2099 areas-max=3 name=isis-instance system-id=1720.2500.1112
/routing isis interface-template
add instance=isis-instance interfaces=lobridge0 levels=l2 passive
add instance=isis-instance interfaces=sfp-sfpplus1 levels=l2 ptp
/mpls interface
add interface=all
/mpls ldp
add disabled=no lsr-id=172.25.1.112 transport-addresses=172.25.1.112
/mpls ldp interface
add disabled=no interface=lobridge0
add disabled=no interface=sfp-sfpplus1

#SFP-PLUS1 go to Mikrotik 1

3

Another similar thread (I think so)

4

I don’t believe it is the same issue, the problem in the other thread is almost certainly the neighbor=0.0.0.0 setting in the advertise-filter, which gets incorrectly set by the upgrade process from v6 to v7 for any entries where this was unset. We had to correct this on all of our devices, because unfortunately neighbor=0.0.0.0 doesn’t seem to match any neighbor like you would expect but only an exact match for 0.0.0.0.

5

You are right, the two threads were unrelated.

In the meantime, I have identified the issue. It appears that between ROS 6 and ROS 7, local LSPs are no longer generated regardless of what is sent by the peer. Instead, they perform a check based on what is received from the peer; if it doesn't match, they mark the prefix as invalid.

Below is the same prefix in ROS 6 and ROS 7:

ROS 6:


[admin@mikrotik] /mpls remote-bindings> print where dst-address =172.25.255.240/28
Flags: X - disabled, A - active, D - dynamic

DST-ADDRESS        NEXTHOP         LABEL                                                                                                                                                                                       PEER

0  D 172.25.255.240/28                  13704                                                                                                                                                                                       
[admin@mikrotik] /mpls remote-bindings> print
[admin@mikrotik] /mpls remote-bindings> ..
[admin@mikrotik] /mpls local-bindings> print where dst-address =172.25.255.240/28
Flags: X - disabled, A - advertised, D - dynamic, L - local-route, G - gateway-route, e - egress 
 #      DST-ADDRESS        LABEL                                                                                                                                                                                                     PEERS                     
 0 ADG  172.25.255.240/28  275                                                                                                                                                                                                                  
[admin@mikrotik] /mpls local-bindings> ..

ROS 7:

[admin@mikrotik] /mpls/ldp> remote-mapping/
< print where dst-address =172.25.255.240/28
Flags: X - DISABLED, I - INACTIVE; D - DYNAMIC; V - VPLS

VRF      DST-ADDRESS   NEXTHOP   LABEL        PEER

0 ID  main     172.25.255...           158          
<mikrotik] /mpls/ldp/remote-mapping> ..
[networkers@mikrotik] /mpls/ldp> local-mapping/
 print where dst-address =172.25.255.240/28
Flags: I - INACTIVE; D - DYNAMIC; G - GATEWAY
Columns: VRF, DST-ADDRESS, LABEL, PEERS

VRF   DST-ADDRESS        LABEL  PEERS

0 IDG main  172.25.255.240/28    153  
<mikrotik] /mpls/ldp/local-mapping> .,.

Additionally, there is a difference between Cisco and Huawei: by default, Huawei only generates LSPs for /32 prefixes. By configuring Huawei to generate LSPs for all prefixes, the issue mentioned in the thread disappears, and the prefixes are correctly utilized by MikroTik devices running ROS 7.

The command on Huawei is:

mpls lsp-trigger all

After putting this command, local and remote bindings looks good and they works correctly:

ROS 7:


[admin@mikrotik] /mpls/ldp> local-mapping/
 print where dst-address =172.25.255.240/28
Flags: D - DYNAMIC; G - GATEWAY
Columns: VRF, DST-ADDRESS, LABEL, PEERS

VRF   DST-ADDRESS        LABEL  PEERS

0 DG main  172.25.255.240/28    153  
[admin@mikrotik] /mpls/ldp/local-mapping>
[admin@mikrotik] /mpls/ldp> remote-mapping/                                                                                                                                 
<apping> print where dst-address =172.25.255.240/28                                                                                                                                     
Flags: X - DISABLED, I - INACTIVE; D - DYNAMIC; V - VPLS 
 #     VRF                              DST-ADDRESS                              NEXTHOP                              LABEL                                   PEER                      
 0 ID  main                             172.25.255.240/28                                                             158                                                  
 1 ID  main                             172.25.255.240/28                                                             impl-null                                             
 2 ID  main                             172.25.255.240/28                                                             50409                                                
 3 ID  main                             172.25.255.240/28                                                             1560                                                 
 4  D  main                             172.25.255.240/28                                                  1385                                    1              
[admin@mikrotik] /mpls/ldp/remote-mapping>
1 Like