This article explains an issue with SRX series devices working in packet mode and configured with MPLS multicast routing.
In an environment using MPLS multicast routing, it is observed that SRX does not update it's TED database correctly after a topology change or a link failure scenario.
Sample topology:
Below are the TED database entries when everything is connected:
root@srx> show ted database 1.2.3.4
TED database: 0 ISIS nodes 6 INET nodes 0 INET6 nodes
ID Type Age(s) LnkIn LnkOut Protocol
1.2.3.4 Rtr 291 2 2 Exported OSPF(4)
To: 5.6.7.8, Local: 50.50.50.10, Remote: 50.50.50.9
Local interface index: 0, Remote interface index: 0
To: 5.6.7.9, Local: 50.50.50.14, Remote: 50.50.50.13
root@core-router-1> show ted database 1.2.3.4
root@core-router-2> show ted database 1.2.3.4
root@access-router> show ted database 1.2.3.4
**********************************************************************************************************************************
Now, if we disconnect the link between the access router and the core router-2, we see that TED databases on all routers do reflect this path change, but the TED database on the SRX does not.
In the traceoptions file, we do see that SRX does receive a 'delete' entry from the core routers, but does not actually delete the entry.
This issue can be seen if any or all of the below conditions are met:
The issue will surface every time the triggers are met. Any IGP (Interior Gateway Protocols) database update event triggered by changes on an IGMP enabled interface like flap or disconnections are not updated on the TED table, leaving unavailable routes that if used to route traffic causes blackholing. the database gets updated only after the affected link comes up. Both IGMP and BGP-LS are mandatory triggers as the IGMP floods the database, but BGP-LS is the responsible of updating the TED database.
The fix will be available in evo:25.2R2-EVO, evo:26.1R1-EVO, junos:23.4R2-S7, junos:25.2R2, junos:26.1R1.
2025-11-20 : Article Created
2026-06-15: Information updated