Kitz Forum
Computers & Hardware => Networking => Topic started by: Weaver on January 23, 2020, 11:39:38 AM
-
Last night my beloved plugged a network cable into port 7 of my ZyXEL GS1900-8 VLAN MUX switch and connected the other end to my main LAN switch. At the same time, she unplugged my Firebrick from my main LAN switch.
Now at approximately the same time, so Janet thinks, AA reported a loss of carrier event on each of my four lines. Was this real ? Somehow synchronised across four lines? Or was it something fake connected to what Janet did ? But if the latter, how?
(Unless she unplugged the wrong <something> but then she would have told me and asked for help, and all that does not give me any answer.)
The Johnson stats-logging graph of SNRM over 24 hours shows that there was no resynch / retrain in the modems. I could tell because the SNRM would be seen to reset immediately straight back to the target SNRM at the time of the retrain. So the absence of such evidence suggests that something external / upstream misled AA. There was a very small amount of packet loss shown in the AA CQM graphs after the so-called disconnection came back up. The lines were ‘down’ for 10 min.
How does AA know that the link has dropped? Because the DSLAM reports loss of the link, in some informational message? Or by a time-out in their PPP LCP ping mechanism? If the latter then it could be misnamed when there’s a failure upstream in BT-Land.
-
I had a loss of carrier email a week or two back, and my sync did "not" drop, so it might be related to a connection loss between exchange and aaisp's network, possibly aaisp simply see this as loss of carrier.
-
So I’m thinking it was some BT thing (or AA thing). Seem to be plausible ?
-
I strongly suspect an A&A thing. Their software making an invalid assumption (based on the loss of your PPP session).
Having re-read the opening post and also considered the further information provided, I can now see that your PPP session to A&A-land should not have dropped. So I'm happy to "book-end" the above two sentences with [s][/s] tags.
Logically, the event must have had its origin with an inadvertent cable disconnection by Mrs. Weaver's hand. (https://www.centos.toracat.org/ajb/tmp/oops2.gif) (b*cat now goes to hide from the Senior Management's view. :paperbag: )
-
Hello,
Lost carrier is when our LCP echoes are not getting replied to. It doesn't explain why LCP was lost, it could be a drop in sync, or something else causing the line to drop. Our tech support would use these messages as one data point of many when investigating a fault.
Some info here
https://support.aa.net.uk/Line_State_Colours
Hope this helps a bit!
-
Thank you Andrew, much appreciated.
So the question remains then, why did it happen? Was it something we did or a coincidence and something happening within BT or AA ?
@burakkucat - I think we were slightly at cross purposes because I didn’t properly explain what I was thinking. I meant an outage within AA-land or BT-land causing the loss of PPP LCP packets.
-
All lines dropped at the same second, and then reconnected 10 minutes later within 15 seconds of each other.
Another line on the same exchange did not drop - so likely the drop was caused (inadvertently) by Janet moving cables around...
Without knowing exactly what was done it's hard to say. Perhaps a network loop was caused on the switch with the modems on? (I'm not exactly sure of the detail of your setup and how the modems connect physically to the FireBrick - I can only guess :-) )
-
There are four ZyXEL VMG 1312-B10A modems connected to a ZyXEL GS1900-8 VLAN MUX/DEMUX switch connected to the FB2900 which is then connected to the main LAN switch. The modems are VLAN 101, 102, 103, 104; all muxed into port 4 on the Firebrick. Firebrick port 1 is connected to the main LAN switch. I asked Janet to unplug the latter.
I can’t really believe here was an incident within BT or AA. I agree with Andrew - something must have happened, by accident.
-
Unplugging the 'LAN' side of the FireBrick should not have affected PPP on the FireBrick - I'd guess that port 4 on the FireBrick was unplugged by mistake as that would cause LCP to stop.
-
That would explain it! I told Janet to unplug the Firebrick from the main lan switch at the switch end, not at the Firebrick end, but oerhaos that got forgotten.
Thanks, that has to be the solution to the mystery.