LDP session stuck in Active-Connect/Throttled — SYN never transmitted despite state claiming connection attempt (confirmed via packet capture, CCR2116, 7.11.2→7.23.3, RouterOS 6↔7 peering)

RouterOS Forwarding Protocols
1

Environment

  • Core routers: rt-a32 and rt-a31, both CCR2116-12G-4S+
  • Edge router: rt0.edm, RouterBOARD 750Gr2
  • Versions tested on rt-a32/rt-a31: 7.11.2, 7.21.5 (long-term), 7.23.3 (stable) — identical LDP behavior across all three
  • rt0.edm: RouterOS 6.47.10 (unchanged throughout)
  • Topology: rt0.edm — (VLAN 810, direct) — rt-a32 — (sfp-sfpplus2, direct, single hop, /31) — rt-a31
  • rt-a32's link to rt0.edm rides on bonding1 (active-backup, 2x SFP+); the link to rt-a31 is a raw physical port, no bonding
  • Goal: bring up LDP end-to-end so a VPLS pseudowire can carry customer bridged traffic from rt0.edm across rt-a32/rt-a31 into an existing, otherwise-unrelated MPLS core

Problem 1 — SOLVED: rt-a32 ↔ rt-a31

Symptom: OSPF Full, UDP hello discovery healthy and bidirectional (packet-capture confirmed), but the active-connect side never sent a TCP SYN. Neighbor stuck permanently Throttled/Passive-Wait.

Root cause 1 (necessary but not sufficient alone): accept-dynamic-neighbors=yes was missing from one of the two /mpls/ldp/interface entries on rt-a32 (present on one interface, absent on the other — an asymmetry we'd introduced without noticing). Set explicitly on all interfaces, both routers.

Root cause 2 (the actual blocker): Once accept-dynamic-neighbors was set, packet capture showed rt-a32 genuinely sending TCP SYNs — but rt-a31 received them and sent back nothing at all, not even a RST. Traced to the input-chain firewall's LDP-session accept rule (protocol=tcp dst-port=646), which was scoped to a src-address-list that had only ever been populated with the physical link IP addresses used by OSPF — never the loopback/transport addresses LDP's TCP session actually sources from. The UDP hello rule worked because it matched via a different, already-correct mechanism; the TCP rule silently never matched and fell through to a default-drop with no logging.

Fix: Added both routers' loopback addresses to the relevant firewall address-list on both ends.

Result: Confirmed DO (dynamic, operational) on both sides, stable across multiple forced restart cycles, both before and after a full RouterOS upgrade on both routers.

Problem 2 — UNSOLVED: rt-a32 ↔ rt0.edm

Symptom: Identical starting symptom to Problem 1 — OSPF Full, UDP hello healthy and bidirectional — but applying the exact same fix that solved Problem 1 (firewall address-list correction — confirmed rt0.edm has zero firewall rules of any kind, so nothing to fix there) did not resolve it. This is a distinct issue, not a repeat of the same root cause.

Everything ruled out, each verified directly, not assumed:

Area Test Result
Firewall (both routers) Full filter and mangle table dump on rt0.edm Both completely empty — zero rules
Firewall (rt-a32) accept-filter/advertise-filter Both empty; advertise-filter later added to match a known-working pattern elsewhere on the network — no change
IGP routing Direct /32 OSPF route to both loopbacks Confirmed, no recursion, no default-route fallback
Reachability Sourced ping (src-address= set to the actual transport address) Clean, sub-100µs RTT, both directions
Transport address Explicit at both /mpls ldp instance and /mpls ldp interface level Confirmed correct via print detail
Connection tracking notrack rules added for port 646; FastTrack Confirmed FastTrack already disabled; notrack made no difference
VRF /ip vrf print on rt-a32 Default main, confirmed
AFI / preferred-AFI Forced afi=ip preferred-afi=ip at instance and interface level Already default; explicit setting made no difference
Loop-detect Set loop-detect=no on both rt-a32 and rt0.edm No change
MPLS fast-path /mpls/settings/set allow-fast-path=no No change
VLAN-interface acceptance Created a throwaway test VLAN on the working raw physical port (sfp-sfpplus2), added to /mpls/ldp/interface Accepted identically to the real interface — rules out flat VLAN rejection
Bond stability /interface bonding monitor Stable, single active slave, zero link-downs since last-up
MTU l2mtu/mpls-mtu relationship on the bonded interface Consistent with the working link, ample headroom
ARP/neighbor resolution /ip arp print showed stale status; cleared and forced fresh reachable entry immediately before restart Neighbor briefly reached active-connect (C) for the first time following this, but still fell back to Throttled within seconds
Version Full upgrade both routers: 7.11.2 → 7.21.5 (long-term) → 7.23.3 (stable) Identical behavior at every version

Final, most precise data point: With a simultaneous packet capture running on rt0.edm's side of this link, we forced a fresh ARP resolution and LDP restart on rt-a32. The neighbor state transitioned through Throttled → Active-Connect → Throttled on rt-a32's side (confirmed via repeated /mpls/ldp/neighbor/print detail) — but zero TCP packets, in either direction, appeared in the capture at any point during this transition. This indicates the LDP state machine believes it is attempting the connection, but no SYN is actually being generated onto the wire — a failure occurring internally on rt-a32, prior to any transmission, not a firewall/receiver-side rejection.

Structural difference from the working link (Problem 1), not yet isolated as cause or coincidence:

  • The working link (rt-a32↔rt-a31) is a raw physical SFP+ port
  • The non-working link (rt-a32↔rt0.edm) is a VLAN interface (vlan810-edm-fibre) riding on an active-backup bond (bonding1) of two SFP+ ports
  • The remote peer in the working case is another RouterOS 7.21.5+ router; in the non-working case it's RouterOS 6.47.10

Question: given active-connect is reached but no SYN is ever transmitted (confirmed via capture, not inferred), is there a known interaction between LDP's TCP session sourcing and (a) VLAN interfaces layered on active-backup bonds, or (b) RouterOS 6↔7 LDP peering specifically, that would explain a SYN being internally "attempted" per the neighbor table but never actually generated at the interface? Happy to provide full config exports, /log output with ldp debug topics enabled, or run any additional live diagnostic.

2

Hi,

Thank you for joining the forum but please give the AI three evening and write the post in a human readable form. Not too many of us has PhD to analyze all that wordy text that should look professional but is so unrreadable to analyze. Assumptions + suggestions that sth. was tested/eleminated/checked.

Who "confirmed" and what and where? You or any "clever" AI that did not managed to untangle the problem but had time to prepare semi-soluution? Any configuration examples provided?

3

Hello!
I am jonas and I understand your concerns.
I have to manage a small ISP, that I inherited and I am new to all of this. I am using AI to help me learn what I am up against here and it help me to solve many of the problems I encounter and teaches me a lot of fundamentals. We have a wireless system based on about 20 switches and 15 routers spanning through let's say 8 towers in the valley.
All the routers are v6 mikrotiks. There is also a newer fibre part to the network, only 2 years old and it is pretty much fully seperated from the wireless network, only 2 connections in the NOC. I need to change that and make the network more interchangable, so I can hook up fibre to the towers and go wireless from there. All the wireless routers use MPLS. When trying to connect the tower (EDM) to the fibre, some traffic comes through, but other aspects don't. I identified , that it is an issue with the MPLS handshake and neighboors not showing up properly, and investigating online, it seams it is an issue relating to v6 and v7 discrepencies. The whole MPLS stack got changed in v7 according to Mikrotik.
I have been working on this for days and yes, I am using AI to help me solve the issue I have at the moment.
With it's instructions I have done many tests and package sniffing on varfies routers, trying to pinpoint to the issue. From not being able to see any neighbors to only not seeing certain ones even the settings seem correct.
enough for now, thank you for reading and trying to help, this is the first post I have ever made, so forgive me if it was to AI like to you.
cheers jonas

4

We even do not know how these devices are physically connected and it's hard to decipher it from the description. Verbatim copy of cOnfig would help a lot. Please follow advices from: Forum rules

5

BTW. There was a BIG "mental" change in ROS7 vs ROS6 that denies all not allowed trafic on 7 while ROS6 accepts it blindly, so in ROS7 you have explicity enable incoming traffic. That is why you could see no packets on ROS7 side.

6

hello
thank you for your responds, I added 4 firewall rules to accept tcp and udp traffic, like so:

/ip/firewall/filter/add action=accept chain=output comment="Explicit allow LDP output" protocol=tcp dst-port=646

but I still have this cycle through DC and DT, never DO

[esis@rt-a32.noc.esis.network] > /mpls/ldp/neighbor/print
Flags: D - DYNAMIC; O - OPERATIONAL, T - THROTTLED
Columns: TRANSPORT, LOCAL-TRANSPORT, PEER, ADDRESSES

TRANSPORT LOCAL-TRANSPORT PEER ADDRESSES

0 DO 100.105.255.1 100.105.255.2 100.105.255.1:0 100.105.252.0
100.105.252.4
100.105.255.1
1 DT 10.255.255.136 100.105.255.2 10.255.255.136:0

as a new user I cannot upload the config file, If you are precise in what information you need, I'd like to pass it on to you, so far it looks like a bug, but I would love to know that it is a settings issue and how to fix it.
I checked the forum rules, but I don't know how to apply this here
thank you

7

You can paste config directly as a text and use < / > code tag for it.
Have checked this? LDP | RouterOS Manual and this Moving from ROSv6 to ROSv7 | RouterOS Manual ?

I do not use MPLS but for BGP there is a need to create accept rule not in firewall but in BGP configuration to enable BGP deamon to accept packets. If you do not apply it for BGP's in-filter then there are no packets processed by deamon even if they come in. Same for BFD. You have to enable outgoing traffic for BFD to make it work in ROS7. Without it, packets do not leave the router. Maybe it's the same situation for LDP? Do not know.

8

@jonas I haven’t read the whole thread, so take this with a grain of salt:

At this point the key fact is that LDP discovery works, but the TCP/646 session never reaches rt0.edm. I’d do a simultaneous capture on rt-a32 on VLAN 810, bonding1, and the active bond slave to see if the SYN actually leaves the router. If it doesn’t, I’d look at output firewall rules, LDP/TCP handling, or routing/transport-address selection. If it does leave but never reaches rt0.edm, I’d suspect the VLAN, bonding, or L2 path.

9

thank you this helped a lot, reading through those documents helped to find the issue

Solved — root cause found, not a MikroTik bug.

Both routers were routing to each other's loopback address via a long, indirect path instead of the direct physical link between them — even though that link was up and working fine. Since LDP's TCP session specifically uses the loopback addresses (not the link's own subnet), every SYN was built for a destination the routing table sent the wrong way, so it never actually left either router. That's why nothing ever showed up in packet captures, no matter which interface we watched.

Cause: we'd set this link's OSPF cost high on purpose (to keep it backup behind another path), which had a side effect we didn't expect — it also made each router prefer the indirect route to the other's loopback specifically, not just to general traffic.

Fix — one static route on each side, just for the two loopbacks:

# router A
/ip/route/add dst-address=<peer loopback>/32 gateway=<direct link IP> distance=1

# router B
/ip route add dst-address=<peer loopback>/32 gateway=<direct link IP> distance=1

Confirmed operational on both sides right after. Thanks all for the help narrowing it down — every check you suggested got ruled out correctly, which is what made it possible to keep looking until this turned up.

10

Nice to hear that problem solved

11

Just curious, why are you using loopback interfaces for OSPF?