Cisco PfR - Loss Rate Bytes vs. Loss Rate Packets

[Jarett Weber]

Can someone explain to me how I can have byte loss that is crossing a PfR policy threshold (causing a TCA), but zero packet loss?  I tried to search for documentation, but just found 1000 configuration guides instead.

When defining a custom policy or using a built-in template, packet loss and byte loss share the same threshold (defined by the "loss" keyword).  So I can't modify just one side of the "loss" thresholds.  Kind of stupid, but it is what it is.  Is it possible to shut off the byte loss rate portion?

Output from "sh domain default master channels summary"

Channel Id: 47520 Dst Site-Id: 10.x.x.72 Link Name: mpls DSCP: af21 [18] pfr-label: 0:0 | 0:1 [0x1] TCs: 0 BackupTCs: 5
Channel Created: 20:30:52 ago
Provisional State: Initiated and open
Operational state: Available
Channel to hub: FALSE
Interface Id: 14
Supports Zero-SLA: Yes
Muted by Zero-SLA: No
Estimated Channel Egress Bandwidth: 0 Kbps
Immitigable Events Summary:
Total Performance Count: 0, Total BW Count: 0
ODE Statistics:
Received: 3
ODE Stats Bucket Number: 1
Last Updated : 00:18:52 ago
Packet Count : 498
Byte Count : 64717
One Way Delay : 52 msec*
Loss Rate Pkts: 0.0 %
Loss Rate Byte: 66.27 %
Jitter Mean : 193 usec
Unreachable : FALSE
ODE Stats Bucket Number: 2
Last Updated : 00:19:22 ago
Packet Count : 575
Byte Count : 203188
One Way Delay : 52 msec*
Loss Rate Pkts: 0.0 %
Loss Rate Byte: 89.49 %
Jitter Mean : 194 usec
Unreachable : FALSE
TCA Statistics:
Received: 4 ; Processed: 2 ; Unreach_rcvd: 0 ; Local Unreach_rcvd: 0
TCA lost byte rate: 4
TCA lost packet rate: 0
TCA one-way-delay: 0
TCA network-delay: 0
TCA jitter mean: 0
Latest TCA Bucket
Last Updated : 00:18:52 ago
One Way Delay : NA
Loss Rate Pkts: NA
Loss Rate Byte: 66.27 %
Jitter Mean : NA
Unreachability: FALSE

[damienpicard]

Same issue here on a recent IWAN 2.1 deployment. Please let us know if you managed to get any information that could help solving this issue.

[Jarett Weber]

Never got this figured out and we actually disabled PfR altogether.  The TAC resources were less than helpful in our case.

Just seems like nobody knows anything about PfR at TAC and just ended up blaming another team or feature, like DMVPN, for the problems.

Having the connections bounce back and forth made performance worse than just using CoS policies with single, but redundant paths.  So we opted for the latter.

[Vasilii Mikhailovskii]

Hello, Jarrett.

I'm sorry to hear this.

I don't see any active tickets on PFR bound to your account.

Could you please let me know the ticket number and I'll take over the ticket to improve your experience. If the ticket is closed - please let me know the number and I'll review the ticket.

Best regards,

[Vasilii Mikhailovskii]

Hello.

1. Byte loss is calculated on TCP flow only (based on gaps in sequence numbers) with tolerance of 3 packets reordered.
2. Packet loss is calculated on RTP UDP packets only, based on gaps in packet sequence numbers. Only flows longer than 15 packets are taken into account.
3. PFR smart-probes are RTP packets as well.
4. "Loss" metric is calculated as maximum of these two.
5. Calculation is an average on all flows matching a channel for the monitoring interval specified for the DSCP.

So, if you see byte loss, but no packet loss - most probably means you are running TCP flows only on the channel.

There might be a lot of reasons for loss detection:

• loss in transit on WAN;
• loss on LAN (PFR does not distinguish between loss on LAN and WAN);
• QoS drops (or incorrect QoS);
• incorrect marking (expected a flow to have same DSCP on all packets);
• unsupported design;
• bug.

[richterw81]

We are experiencing this exact same issue.  I'm going to try PfR custom policies that mirror the built-in ones, minus the byte-loss as it's incorrectly causing a ton of TCAs.

Update: Scratch that idea, while the default templates separate packet loss and byte loss into two different values, that's not something the user is allowed to configure apparently.

[Vasilii Mikhailovskii]

Hello.

As I mentioned, there are a lot of possible reasons for the issue.

Please open a ticket in TAC and let me know the number - I'll try to help you with the issue.

Best regards,

PS: troubleshooting on public forum is not really possible for PFRv3, as RCA requires tons of outputs to share (that have a lot of confidential data).

PS2: if you decide to go on your own and running iWAN 2.1, I would recommend to start with design review; and here is a video you may find useful for this - https://www.youtube.com/watch?v=mUv2X-bdMBo

[richterw81]

Thanks watching the video now.  We've pretty well followed the prescriptive design in the CVD, other than not using iBlock for a brownfield deployment.

Here is the TAC case. SR 682713198