In reply to a post by Geordish:

Dropping a PPP session makes even less sense (from a traffic management perspective). You're just going to reconnect and continue your UDP transfer.

While it does sound like something is going in, I would doubt it is intentionally malicious.

Not really, not when they had DSL gateways that were confirmed as being overloaded and they manually moved 6,000 odd connections from one. Also from research this is how Zen load balance, quite often having to manually terminate the PPP session to force/hope it connects to another gateway.

I don't recall saying it was malicious, I'd just like it to stop. I suspect, but cannot confirm, it is a very rudimentary load balancing metric, one that I can exacerbate due to the nature of my traffic (again as I said earlier in this thread).

Edited by deleted (Tue 14-Jul-15 17:54:54)

In reply to a post by iMiMiMx:

In reply to a post by Geordish:

Dropping a PPP session makes even less sense (from a traffic management perspective). You're just going to reconnect and continue your UDP transfer.

While it does sound like something is going in, I would doubt it is intentionally malicious.

Not really, not when they had DSL gateways that were confirmed as being overloaded and they manually moved 6,000 odd connections from one. Also from research this is how Zen load balance, quite often having to manually terminate the PPP session to force/hope it connects to another gateway.

I don't recall saying it was malicious, I'd just like it to stop. I suspect, but cannot confirm, it is a very rudimentary load balancing metric, one that I can exacerbate due to the nature of my traffic (again as I said earlier in this thread).

Not routinely during the middle of the day.

While I do think you should get Zen to investigate, and fix whatever the problem is you're having, I am certain that you are barking up the wrong tree with your load balancing theory.

Did you find out what Zen see as the termination cause?

In reply to a post by Geordish:

In reply to a post by iMiMiMx:

In reply to a post by Geordish:

Dropping a PPP session makes even less sense (from a traffic management perspective). You're just going to reconnect and continue your UDP transfer.

While it does sound like something is going in, I would doubt it is intentionally malicious.

Not really, not when they had DSL gateways that were confirmed as being overloaded and they manually moved 6,000 odd connections from one. Also from research this is how Zen load balance, quite often having to manually terminate the PPP session to force/hope it connects to another gateway.

I don't recall saying it was malicious, I'd just like it to stop. I suspect, but cannot confirm, it is a very rudimentary load balancing metric, one that I can exacerbate due to the nature of my traffic (again as I said earlier in this thread).

Did you find out what Zen see as the termination cause?

That is not as simple as you may think, despite multiple escalations - but yes, that was the very first question I asked that they cannot answer.

I'm going to duck out of this for now, unless I have something else to add and/or a response from them.

Edited by deleted (Tue 14-Jul-15 18:12:03)

Was advised today that it had been escalated to 'one of the main NOC guys' - just checking a few things now, LCP echo requests seem to be coming every 10 seconds (this matches my BT FTTC line), checking my earlier dumps/captures they were every 3 seconds...

Now, from the logs the term-req was sent around 4 seconds after the last echo LCP request/response - could this be the problem? One going missing at 3 seconds, then resetting at 4 - either some loss somewhere (but modem sync remains), or an overloaded device generating the echo requests, or simply a little to frequent for real world use?

Will see what Zen come back with tomorrow and I'll raise it with them then.

Post deleted by iMiMiMx

Nope - LCP echo request interval still seems to be 10 seconds this morning, but I've had 3 term-reqs in the last few minutes from around 08:30 - modem sync still rock solid.

LCP echo interval going to down to 3 seconds is apparently expected behaviour, if the previous LCP echo request on the 10 second interval did not receive a response - the interval is lowered temporarily - so currently, Zen advise the term-req is being sent because the Zen end doesn't think that mine responded. However from my dumps earlier it did, these dumps are as late in the process/flow as I can take them so they're 'on the wire' up to the modem. No real data on why I could reproduce the issues at certain times, almost on-demand, with UDP traffic/tunnels but not TCP.

Interesting/confusing aspect, even though I receive and reply to the 10 second interval LCP echo request which is shown by the tcpdump, the Zen end thinks mine didn't respond and so lowers the interval to 3, my end receives again and responds. If the link were dead, then surely I would not expect to receive the LCP echo on the 3 second interval, twice, and respond to it both times? Or, if there is a fault the fault only sometimes impacts the upstream - to allow me to receive and see their echo request, even after the remote end thinks my end did not respond. Whilst coincidences do happen, the problem starting from the word go on the migration should add some weight against it being a line fault (and no sync drop, ever).

After a bit of a slow start investigating at the required low level, finally, Zen are hopefully coming into their own and showing why they have the reputation they do. The last few days/week I've certainly been more encouraged by the technical updates coming back and their desire to continue investigating.