The traffic patterns show that the LTE based service paths were being used instead of the service paths configured with the broadband links leading to a high utilization of the LTE based links
High utilization of LTE based links
The service paths were configured for using broadband and LTE links with higher priority being given to the broadband based links and the configuration is as below.
config authority service-policy Policy-Broadband-LTE name Policy-Broadband-LTE
config authority service-policy Policy-Broadband-LTE lb-strategy hunt
config authority service-policy Policy-Broadband-LTE vector broadband name broadband
config authority service-policy Policy-Broadband-LTE vector broadband priority 10
config authority service-policy Policy-Broadband-LTE vector lte name lte
config authority service-policy Policy-Broadband-LTE vector lte priority 15
config authority service-policy Policy-Broadband-LTE required-qp 0
config authority service-policy Policy-Broadband-LTE qp-preference highest
config authority service-policy Policy-Broadband-LTE session-resiliency revertible-failover
As we can see in the above configuration, the broadband vector is given a lower priority than the lte vector and based on the configuration, SSR should be taking the broadband based vector for the service-policy.
However, the "show events" tab contained a lot of events wherein the broadband based service-path gets taken out of service for the services.
2026-02-01T19:58:45.651Z Service path on node node0 with key A+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:58:45.65Z Service path on node node0 with key A+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:58:45.649Z Service path on node node0 with key B+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:58:45.648Z Service path on node node0 with key B+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:58:25.623Z Service path on node node0 with key A+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:58:25.622Z Service path on node node0 with key A+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:58:25.621Z Service path on node node0 with key B+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:51:35.606Z Service path on node node0 with key A+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:51:35.589Z Service path on node node0 with key B+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:51:35.542Z Service path on node node0 with key A+Broadband+0.0.0.0 is taken out of service
2026-02-01T19:51:35.526Z Service path on node node0 with key B+Broadband+0.0.0.0 is taken out of service
Whenever the service path related to the Broadband interface gets taken out of service, the next available option for the service is to use the lte path. The reason why the service path for the Broadband interface was taken out of service, is because the peer path via the Broadband interface went down. The information regarding the peer paths via the broadband interface can be seen in the "show events" output as below.
2026-02-01T19:58:40.863Z Peer peer-node1 path is down (PeerName: peer-node1 | Destination: 1.1.1.1 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:58:40.417Z Peer peer-node2 path is down (PeerName: peer-node2 | Destination: 2.2.2.2 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:58:40.358Z Peer peer-node3 path is down (PeerName: peer-node3 | Destination: 3.3.3.3 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:58:25.848Z Peer peer-node1 path is down (PeerName: peer-node1 | Destination: 1.1.1.1 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:58:25.445Z Peer peer-node2 path is down (PeerName: peer-node2 | Destination: 2.2.2.2 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:58:25.397Z Peer peer-node3 path is down (PeerName: peer-node3 | Destination: 3.3.3.3 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:58:25.061Z Peer peer-node4 path is down (PeerName: peer-node4 | Destination: 4.4.4.4 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:50:29.981Z Peer peer-node1 path is down (PeerName: peer-node1 | Destination: 1.1.1.1 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:50:29.855Z Peer peer-node3 path is down (PeerName: peer-node3 | Destination: 3.3.3.3 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:50:29.808Z Peer peer-node2 path is down (PeerName: peer-node2 | Destination: 2.2.2.2 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:50:29.746Z Peer peer-node3 path is down (PeerName: peer-node3 | Destination: 3.3.3.3 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:50:29.686Z Peer peer-node2 path is down (PeerName: peer-node2 | Destination: 2.2.2.2 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:50:29.402Z Peer peer-node4 path is down (PeerName: peer-node4 | Destination: 4.4.4.4 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
2026-02-01T19:49:42.583Z Peer peer-node3 path is down (PeerName: peer-node3 | Destination: 3.3.3.3 | NodeName: node0 | DeviceName: 4 | Vlan: 0)
Once the peer paths to the other SSR nodes came up, the service paths via the Broadband interface were given priority over the service paths via the LTE interface. The reason for the same is that the service-policy is configured with the "revertible-failover" parameter which is a session resiliency setting that automatically switches traffic to a backup path during a failure and reverts to the primary path once it restores. It ensures service optimization by returning to the best path, though it may cause session flapping.