For context:
CCR2116 running 7.17.2
I was reading the documentation, but I am not sure if this is a normal behavior. We have a CCR2116 with about 1300 pppoe customer connections. All of these have simple queues with bursts generated by the pppoe profile. As soon as we enable FastTrack (not fastpath) by marking connections in the firewall, the queues are bypassed.
You can see a little bit of traffic in the queue, but it does not correlate to the traffic on the matching pppoe-client interface, it is significantly lower on the queue, just some Kbit/s the most, and the customer gets unlimited speed. I understand that queues make the device not FastPath elegible, for which I can confirm that FastPath is not running because of the queues. But there is no mention for FastTrack, and it does get enabled (observed enabled and packets counting on ip->settings FastTrack counter), and CPU drops accordingly, but all simple queues break.
CCR2116 running 7.17.2
I was reading the documentation, but I am not sure if this is a normal behavior. We have a CCR2116 with about 1300 pppoe customer connections. All of these have simple queues with bursts generated by the pppoe profile. As soon as we enable FastTrack (not fastpath) by marking connections in the firewall, the queues are bypassed.
You can see a little bit of traffic in the queue, but it does not correlate to the traffic on the matching pppoe-client interface, it is significantly lower on the queue, just some Kbit/s the most, and the customer gets unlimited speed. I understand that queues make the device not FastPath elegible, for which I can confirm that FastPath is not running because of the queues. But there is no mention for FastTrack, and it does get enabled (observed enabled and packets counting on ip->settings FastTrack counter), and CPU drops accordingly, but all simple queues break.
Statistics: Posted by elcano89 — Tue Mar 11, 2025 8:08 pm