Superhub bouncing

[pip08456]

No.No,No!

You got it wrong! It should be "wine, wine, wine!

Hic!

[foxtrot_yankee]

Okay, attenuator back on:

Downstream
Power: +3dB
SNR: +44dB

Upstream
Power: +42dB

...so it seems fine for now. Except for the new packet loss symptom.

[craigj2k12]

make sure the firewall and ip flood detection are turned off on the superhub

go on advanced settings and on services and untick the two boxes, click apply, run pingtest and you will have 0% packet loss

[foxtrot_yankee]

Originally Posted by craigj2k11

make sure the firewall and ip flood detection are turned off on the superhub

go on advanced settings and on services and untick the two boxes, click apply, run pingtest and you will have 0% packet loss

Already had them turned off. Should've said.

[pabscars]

Can I refer you back to post #27

[craigj2k12]

Good shout

[foxtrot_yankee]

C:\Users\root>tracert bbc.co.uk

Tracing route to bbc.co.uk [212.58.224.138]
over a maximum of 30 hops:

  1     *        7 ms     *     cpc3-ersk3-2-0-gw.14-1.cable.virginmedia.com [21
3.106.6.1]
  2     8 ms     7 ms     7 ms  renf-core-1a-ae3-1750.network.virginmedia.net [6
2.254.191.93]
  3    12 ms    11 ms    16 ms  manc-bb-1a-as4-0.network.virginmedia.net [213.10
5.175.221]
  4    18 ms    19 ms     *     glfd-bb-1b-ae1-0.network.virginmedia.net [213.10
5.175.146]
  5    18 ms    20 ms    19 ms  glfd-tmr-1-ae5-0.network.virginmedia.net [213.10
5.159.46]
  6    19 ms    36 ms    20 ms  redb-ic-1-as0-0.network.virginmedia.net [62.253.
185.78]
  7    21 ms    19 ms    19 ms  212.58.239.249
  8    35 ms    27 ms     *     212.58.238.149
  9     *       21 ms    19 ms  virtual-vip.thdo.bbc.co.uk [212.58.224.138]

Trace complete.

Connected with wires.

[pabscars]

That's a bit more like it, now hopefully the peeps that understand these things can make a more informed opinion.

From the little I know, I believe T4 timeouts are indicative of a problem and would cause interruption in your service.

A quick google found

T3 and T4 Timeouts

I wanted to close this topic with a discussion on T3 and T4 timeouts as I have received many questions on “what causes T3 and T4 timeouts?� Fundamentally, a T3 timeout occurs when the cable modem fails to receive a RNG-RSP from the CMTS within 200 msec (after sending a RNG-REQ). A T4 timeout occurs when a cable modem fails to receive a RNG-REQ transmit grant MAP from the CMTS within 35 sec on the downstream channel (after receiving the previous RNG-RSP). There are number of reasons that these could occur and I will list a couple below for each and help guide you the root cause, but understand this is not and exhaustive list.

T3 Timeout No RNG-RSP in 200 msec – Typically an Upstream Problem

Most likely cause is upstream impairments preventing the RNG-REQ from reaching the CMTS, therefore the CMTS never transmits a RNG-RSP
May occur because the RNG-REQs from multiple cable modems collided, again the CMTS does not receive the RNG-REQ (now from multiple modems) and fails to process multiple RNG-RSP messages resulting in multiple T3 timeouts
CMTS over-utilization – unable to process RNG-REQ and/or RNG-RSP within T3 time frame (200 msec)
Can also be a downstream problem due to plant impairments – i.e. RNG-RSP is transmitted, but corrupted in route and the cable modem never receives the message
Look for low MER at the cable modem
T4 Timeout No RNG-REQ Grant MAP Received by Cable Modem in 35 sec – Typically a Downstream Problem

T4 timeouts can usually be identified with downstream impairments causing the cable modem to miss receiving the RNG-REQ grant MAP transmitted to it
If T4 errors are impacting many modems off of a common leg, trouble shoot that leg
If T4 errors are just associated with one modem, look for low MER/level at that modem
T4 timeouts can also be associated with a CMTS that has extremely high utilization i.e. >95% depending on the vendor and firmware version
Rule of thumb for CMTS utilization is 80% to allow for peak usage periods
It is highly unlikely that T4 timeouts are associated with any upstream impairments
A final note, T3 and T4 impairments are always within the DOCSIS network inclusive of the CMTS and cable modems. In fact it is the cable modems themselves that are doing the counting and alerting of T3 and T4 timeouts. This is one time that the IP network behind the CMTS is not to blame for any of these errors. No finger pointing on this one!

[pip08456]

All very well for the explanation. T3's can occur naturally and can be discounted unless of course there are many within a short space of time.

Looking at the logs 1 T3 9hrs before the post does not a problem make.

I also notice the OP doesn't mind anyone seeing his modem MAC. NOT recommened!

[boroboi]

I just gave his MAC to my neighbour to clone! Cheers!

















joking

[qasdfdsaq]

You can't clone DOCSIS 3 modems with just the MAC anyway. There's no harm in MAC addresses being posted.

[foxtrot_yankee]

Gotta love peak times: