ATT FNet and ROiP issues. Is FNet a sales tactic?

[GamecockSJ]

This is an issue on ATT and T-Mobile though I haven’t had this issue on Verizon. Set the MTU on your Cradlepoint modem to 1420. You may also have to lower the MTU on the Ethernet port on your repeater.

 

[70cutlass442]

Update# 2. We are able to pass packets later than 1472 BUT, we needed fragment them on the DCB box (encrypted tunnel that passes multicast over WAN.

We then tried a T-Mobile IoT card that seemed to work okay, but still had the same issues at times. My guess is jitter and inconsistent latency is causing the issue.

We have a cable internet connection being installed Monday so we will see if that corrects the issue. Latency is in the sub 50ms range for over the VPN tunnel to the remote device. This is better than the 150-200ms "ping"s that I got on cellular. Cellular would often jump to over 500 MS which exceedes the equipment's buffer capability resulting in discarded packets.
I think this in of itself points to jitter that is causing our issues. I question if the fragmentation was even the issue, but it was certainly not helping.

Will update next week when we try it again.

 

[GamecockSJ]

Unless you’re staying within the provider’s network, a routing or peer change down the line can still affect latency - although it should stay consistent. I normally see 38-40ms between sites connected via local cable provider and the fiber connected hub site that is on another provider. Randomly a route will change and it spikes to 80ms (but stays around 80 until it comes back to 40).

 

[70cutlass442]

Unless you’re staying within the provider’s network, a routing or peer change down the line can still affect latency - although it should stay consistent. I normally see 38-40ms between sites connected via local cable provider and the fiber connected hub site that is on another provider. Randomly a route will change and it spikes to 80ms (but stays around 80 until it comes back to 40).

I can certainly live with 80ms. The equipment will buffer for up to 480ms, with the ability to be set to 300ms, or 100ms. 300ms is probably a safe bet with cable. If I see favorable results there, I will try 100ms.

 

[Sprailer36]

Update# 2. We are able to pass packets later than 1472 BUT, we needed fragment them on the DCB box (encrypted tunnel that passes multicast over WAN.

We then tried a T-Mobile IoT card that seemed to work okay, but still had the same issues at times. My guess is jitter and inconsistent latency is causing the issue.

We have a cable internet connection being installed Monday so we will see if that corrects the issue. Latency is in the sub 50ms range for over the VPN tunnel to the remote device. This is better than the 150-200ms "ping"s that I got on cellular. Cellular would often jump to over 500 MS which exceedes the equipment's buffer capability resulting in discarded packets.
I think this in of itself points to jitter that is causing our issues. I question if the fragmentation was even the issue, but it was certainly not helping.

Will update next week when we try it again.

With DCB in my network, I had to tinker with the advanced settings to be able to pass the traffic correctly to maybe compensate for some packet issues. Otherwise, solid products for ROIP situations.

 

[70cutlass442]

With DCB in my network, I had to tinker with the advanced settings to be able to pass the traffic correctly to maybe compensate for some packet issues. Otherwise, solid products for ROIP situations.

Same here. The settings were actually good out of the box, I just adjusted the MTU so fragmentation would take place there instead of elsewhere in the network. The DCB product and support has been great.

 

[70cutlass442]

Final update:

FNet seemed to be a small portion of our problem. We found a bottleneck within our LAN. After some changes on the LAN, and switching to a different ISP, we seem to have resolved the issues.