Hello,

So at night I usually have really bad packet loss, I really don't know the reason, folks at terranet say that the "centrale" is congested but after hearing this bullshit so many times I decided to just figure out what's wrong myself.
The reason I do not believe what they tell me is that my neighbor, who is subscribed to a different ISP, has great ping and little loss on all the games he plays, and since he lives next to me, he must be linked to the same centrale (correct me if I am wrong). So I ran a tracert to google public DNS to see what's happening and I got this: 
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *       38 ms    24 ms  100.74.0.1
  3     *        *       16 ms  172.20.1.10
  4    19 ms    20 ms     *     10.40.40.8
  5     *        *       21 ms  corp-212-98-135-125.terra.net.lb [212.98.135.125]
  6    18 ms    20 ms    18 ms  172.16.41.17
  7     *        *       56 ms  ix-ae-11-0.tcore2.WYN-Marseille.as6453.net [80.231.200.45]
  8     *        *       56 ms  if-ae-2-2.tcore1.WYN-Marseille.as6453.net [80.231.217.1]
  9    57 ms    56 ms    56 ms  72.14.204.63
 10     *        *        *     Request timed out.
 11    57 ms     *       57 ms  google-public-dns-a.google.com [8.8.8.8]
Now, notice the terrible packet loss, as you can see on the second hop there is this IP which is causing problems: 100.74.0.1
My neighbor does not have this hop when they run a tracert to 8.8.8.8, what could this IP be? Is this the centrale? Does this explain why he has good pings and I don't? Or is this something else entirely?

Here's a ping to 100.74.0.1: Terrible packet loss, at just the first hop. 
Pinging 100.74.0.1 with 32 bytes of data:
Request timed out.
Reply from 100.74.0.1: bytes=32 time=16ms TTL=254
Reply from 100.74.0.1: bytes=32 time=16ms TTL=254
Request timed out.
Reply from 100.74.0.1: bytes=32 time=19ms TTL=254
Reply from 100.74.0.1: bytes=32 time=15ms TTL=254
Reply from 100.74.0.1: bytes=32 time=15ms TTL=254
Reply from 100.74.0.1: bytes=32 time=15ms TTL=254
Reply from 100.74.0.1: bytes=32 time=16ms TTL=254
Reply from 100.74.0.1: bytes=32 time=16ms TTL=254
Reply from 100.74.0.1: bytes=32 time=15ms TTL=254
Reply from 100.74.0.1: bytes=32 time=15ms TTL=254
Request timed out.
Reply from 100.74.0.1: bytes=32 time=15ms TTL=254

Ping statistics for 100.74.0.1:
    Packets: Sent = 14, Received = 11, Lost = 3 (21% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 19ms, Average = 15ms
Please help me make sense of this.
Edit: I live in the metn area, if that's of any help.
Well the IP you pinged seems to be called Carrier Grade NAT so I'm guessing you're behind an ISP NAT.However that info is not related to your packet loss problem. It's either from your ISP or from you. I'm not sure if bad DSL stats could cause such disruptions (attenuation, SNR margin...).
Adnan wroteWell the IP you pinged seems to be called Carrier Grade NAT so I'm guessing you're behind an ISP NAT.However that info is not related to your packet loss problem. It's either from your ISP or from you. I'm not sure if bad DSL stats could cause such disruptions (attenuation, SNR margin...).
I don't get it, shouldn't me and my neighbor's traffic go through the same path to the centrale? Or does it not work this way?

Here are my DSL stats, not too bad tbh...

Downstream Upstream
SNR Margin
:
27.4 23.5 db
Line Attenuation
:
23.6 12.0 db
Data Rate
:
4095 1023 kbps
Max Rate
:
18468 1056 kbps
POWER
:
18.9 13.1 dbm
CRC
:
21 16
Maybe TerraNet have their own share of the centrale capacity ? Maybe the congestion is at some other place related to TerraNet (DSP for instance) ? At this point I'm just guessing, hopefully we get an answer from someone experienced.
To clear things:
- everything before the ISP is L2 tunneling and encapsulation
- pppoe which all fixed broadband ISPs use is runs over layer 2 (oE in the end stands for over Ethernet)
-your first hop will be the PPPoE termination called BRAS or BNG
- everything before it like the DSLAM, Ogero's LAC, the L2VPN metro backhaul won't appear over your traceroute

Moreover, you and your neighbor might have different service quality just because your DSL line has bad SNR while his is good

+ All ISPs use CG-NAT

Having big delays and timeout with an IP within your ISP's infrastructure (which you have) usually points to your DSL line having bad quality. Only other explanation would be that your ISP has made a huge screwup in their network infrastructure

And:
- the issue's not from Ogero's transport to the ISP or your neighbor would have suffered the same
- neither is the issue from the DSLAM (centrale congestion as you call it) because your neighbor would have suffered from it too.

Knowing that Ogero's terribly slow at fixing bad lines, i would advise you to look for a non-dsl option
jeansalim wroteTo clear things:
- everything before the ISP is L2 tunneling and encapsulation
- pppoe which all fixed broadband ISPs use is runs over layer 2 (oE in the end stands for over Ethernet)
-your first hop will be the PPPoE termination called BRAS or BNG
- everything before it like the DSLAM, Ogero's LAC, the L2VPN metro backhaul won't appear over your traceroute

Moreover, you and your neighbor might have different service quality just because your DSL line has bad SNR while his is good

+ All ISPs use CG-NAT

Having big delays and timeout with an IP within your ISP's infrastructure (which you have) usually points to your DSL line having bad quality. Only other explanation would be that your ISP has made a huge screwup in their network infrastructure

And:
- the issue's not from Ogero's transport to the ISP or your neighbor would have suffered the same
- neither is the issue from the DSLAM (centrale congestion as you call it) because your neighbor would have suffered from it too.

Knowing that Ogero's terribly slow at fixing bad lines, i would advise you to look for a non-dsl option
Thank you for clearing everything up! I think I understand now. Something however still confuses me, because the thing is that this only happens at night, during the morning and early afternoon I usually have minimal to no losses. If my DSL line really had problems, shouldn't the issue be always apparent?
Yes, issue consistently happening at night points to congestion (although DSL lines get affected by humidity and temperature if repaired badly, and they all are in Lebanon).
But your SNR, attenuation and CRC are very good. Check if they stay the same during the evening or if sudden drops happen.
Maybe your neighbor's on a less congested DSLAM. We're purely speculating here. I don't think we can know the root problem without knowledge of the centrale you're connected to.
jeansalim wroteYes, issue consistently happening at night points to congestion (although DSL lines get affected by humidity and temperature if repaired badly, and they all are in Lebanon).
But your SNR, attenuation and CRC are very good. Check if they stay the same during the evening or if sudden drops happen.
Maybe your neighbor's on a less congested DSLAM. We're purely speculating here. I don't think we can know the root problem without knowledge of the centrale you're connected to.
The DSL stats do indeed stay the same, I have been closely monitoring them lately. As to the centrale, all I know is that I am connected to "centrale el metn". I doubt this provides much information.
Since he's with another ISP, could it be that he's in a different "section" of the centrale? A "section" owned by his ISP? Is there anything such as that? Oh and he's with ogero btw.
Sorry for my messy terminology, really not a networking wizard.
Here's an early morning traceroute, things look much better, still high ping and some loss on the first hop but it smoothes itself out on later hops. 
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *       31 ms    14 ms  100.74.0.1
  3     8 ms     8 ms     9 ms  172.20.1.10
  4     7 ms     9 ms     7 ms  10.40.40.8
  5     *        9 ms    10 ms  corp-212-98-135-125.terra.net.lb [212.98.135.125]
  6     9 ms    10 ms     9 ms  172.16.41.17
  7    46 ms    46 ms    50 ms  ix-ae-11-0.tcore2.WYN-Marseille.as6453.net [80.231.200.45]
  8    45 ms    46 ms    45 ms  if-ae-2-2.tcore1.WYN-Marseille.as6453.net [80.231.217.1]
  9    47 ms    46 ms    58 ms  72.14.204.63
 10    46 ms    46 ms    46 ms  209.85.245.0
 11    48 ms    46 ms    46 ms  google-public-dns-a.google.com [8.8.8.8]

Trace complete.
Note that yesterday I had 30 % packet loss while pinging to google using terranet. ( I have several ISPs bonded) sodetel IDM and the local cable guy (distributing from terranet.)
Believe it or not I tried to troubleshoot the same thing. the link was unbearable. the connection was flawless between me and the local cable servers. but not between these servers and terranet.
Today i'll update you with the current situation.
15% packet loss. it is much better than yesterday
elserge82 wrote15% packet loss. it is much better than yesterday
May I ask, at what time exactly are you beginning to get the packet loss? And to what centrale are you connected? For me I start getting them from 6pm onwards, and it's always more than 20% packet loss.