MWEB VOIP Down for 4 days?

[PeekNPoke]

Hi Formites,

I've been having connection issues with the MWEB VOIP server for the last 4 days. Does anybody else have this issue?

Check the pings below:

C:\Windows\System32>ping sip.mweb.net

Pinging sip.voip.mweb.net [196.28.95.12] with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 196.28.95.12: bytes=32 time=1578ms TTL=53
Reply from 196.28.95.12: bytes=32 time=1568ms TTL=53

Ping statistics for 196.28.95.12:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1568ms, Maximum = 1578ms, Average = 1573ms

C:\Windows\System32>

and this trace route:

C:\Windows\System32>tracert -d sip.mweb.net

Tracing route to sip.voip.mweb.net [196.28.95.12]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.0.1.1
  2     7 ms     6 ms     5 ms  105.236.4.1
  3    14 ms    14 ms    13 ms  41.181.178.77
  4    14 ms    14 ms    12 ms  196.44.31.120
  5    25 ms    25 ms    23 ms  196.44.0.42
  6    19 ms    17 ms    45 ms  41.181.165.115
  7    11 ms    12 ms    12 ms  196.44.0.222
  8    25 ms    25 ms    26 ms  196.22.161.133
  9    57 ms    69 ms    48 ms  197.80.7.1
 10    18 ms    12 ms    11 ms  197.80.5.237
 11    42 ms    34 ms    34 ms  197.80.96.54
 12    12 ms    26 ms    16 ms  197.81.229.2
 13    33 ms    22 ms    12 ms  197.81.229.17
 14  1561 ms     *        *     196.28.95.12

Trace complete.

C:\Windows\System32>

I even get these results from my server hosted within the MWEB datacenters. Can some of you please ping this address and post your results?

 

[MI HOST]

Hi PeekNPoke,

Here the results i got

C:\Windows\System32>ping sip.mweb.net

Pinging sip.voip.mweb.net [196.28.95.12] with 32 bytes of data:
Reply from 196.28.95.12: bytes=32 time=1582ms TTL=56
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 196.28.95.12:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 1582ms, Maximum = 1582ms, Average = 1582ms

C:\Windows\System32>

Regards

 

[PeekNPoke]

Hi MI HOST,

Thanks for the response. You have the exact issue I have, how can the MWEB tech guys not have picked this up?

Cheers ...

 

[bigx333]

The SBC there isn't having any issues AFAIK, the ICMP packets are always delayed on their network so they answer with high latency, what means virtually nothing.

 

[GoofySmurf]

The SBC there isn't having any issues AFAIK, the ICMP packets are always delayed on their network so they answer with high latency, what means virtually nothing.

Thats a load of crap, I have a few servers in the mweb nocs and none of the icmp packets is delayed. There is no need to limit or delay ICMP with traffic shaping as it doesnt even make up for 1% of the network overhead. Your routers will struggle under the load to shape ICMP as well and degrade other services.

Nowhere in the real world does it make sense to shape or delay ICMP.

That what you see is pure packet loss, this is due to a faulty cable, network port,faulty switch, faulty network adapter on the server etc ...

I can almost guarantee you that this is a issue with a router or switch in the datacenter or there is a peering issue between mweb and your isp.

 

[bigx333]

Thats a load of crap, I have a few servers in the mweb nocs and none of the icmp packets is delayed. There is no need to limit or delay ICMP with traffic shaping as it doesnt even make up for 1% of the network overhead. Your routers will struggle under the load to shape ICMP as well and degrade other services.

Nowhere in the real world does it make sense to shape or delay ICMP.

That what you see is pure packet loss, this is due to a faulty cable, network port,faulty switch, faulty network adapter on the server etc ...

I can almost guarantee you that this is a issue with a router or switch in the datacenter or there is a peering issue between mweb and your isp.

I have no strings attach to MWeb in any way (specially since I work in a competitor) and I don't even use them but I do know their Lead Engineer and know a bit about their voice network.

Yes they do delay ICMP, it doesn't make much sense but they actually do it (I even remember having a discussion with Andre about the reasoning behind it), I've actually this in an Email from him:

"Just on the latency, our SBC’s will always process voice traffic first. When the SBC gets busy, the ICMP packets will be either delayed or dropped by the SBC to process the voice traffic first. So by monitoring with ICMP pings you will get inaccurate statistics. You should rather use SIP OPTIONS or if you want to measure using ICMP, you should rather ping the default gateway on 196.28.95.1."

While I do agree with you that there's little sense to shape ICMP, they do it and that's not an issue on itself.

There isn't packet loss, there isn't any "fault" (at least on their network since my GW is plugged straight at CINX) and they are not having issues, here's a graph from a call I did 5 minutes ago on their SBC just to prove my point:

No loss, very low ping and almost non existent jitter.

 

[GoofySmurf]

I have no strings attach to MWeb in any way (specially since I work in a competitor) and I don't even use them but I do know their Lead Engineer and know a bit about their voice network.

Yes they do delay ICMP, it doesn't make much sense but they actually do it (I even remember having a discussion with Andre about the reasoning behind it), I've actually this in an Email from him:

"Just on the latency, our SBC’s will always process voice traffic first. When the SBC gets busy, the ICMP packets will be either delayed or dropped by the SBC to process the voice traffic first. So by monitoring with ICMP pings you will get inaccurate statistics. You should rather use SIP OPTIONS or if you want to measure using ICMP, you should rather ping the default gateway on 196.28.95.1."

While I do agree with you that there's little sense to shape ICMP, they do it and that's not an issue on itself.

There isn't packet loss, there isn't any "fault" (at least on their network since my GW is plugged straight at CINX) and they are not having issues, here's a graph from a call I did 5 minutes ago on their SBC just to prove my point:

No loss, very low ping and almost non existent jitter.

I stand corrected thank you, I have never experienced this with my personal servers in the premium datacenter but the explanation from Andre makes sense.

Thanks for the detailed explanation and the time you took to write it up.