TPG Community

Get online support

Dropped packets on AU-NS-1889-IPE-01-Eth-Trunk21.tpgi.com.au [203.220.35.38]

mikesheen
Level 2

Hi,

 

I'm experiencing dropped packets - suspect is AU-NS-1889-IPE-01-Eth-Trunk21.tpgi.com.au [203.220.35.38].

 

I'm in Perth, WA and I am trying to RDP to a customer in NSW and the dropped packets mixed with latency is making this experience unusable.

A traceroute to the customer from me shows about every second trace with dropped packets at AU-NS-1889-IPE-01-Eth-Trunk21.tpgi.com.au [203.220.35.38].

I also asked a work collegue who is in NSW to perform a tracert to the customer, and they too see intermittent dropped packets to the same hop - AU-NS-1889-IPE-01-Eth-Trunk21.tpgi.com.au [203.220.35.38]

 

A sample of two consecutive tracerts - one dropping and the next not is shown below:

Tracing route to 60-242-21-182.static.tpgi.com.au [60.242.21.182]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  ARCHER_VR1600V [192.168.1.1]
  2    12 ms    12 ms    12 ms  10.20.25.183
  3    62 ms    62 ms    61 ms  per-pow-stg-crt4-be200.tpgi.com.au [203.29.134.194]
  4    61 ms    62 ms    62 ms  nme-sot-dry-crt2-Be40.tpgi.com.au [203.219.107.229]
  5    61 ms    61 ms    61 ms  203-26-22-121.static.tpgi.com.au [203.26.22.121]
  6    62 ms    61 ms    61 ms  AU-NS-1889-IPG-02-Eth-Trunk3.tpgi.com.au [203.29.134.122]
  7    62 ms    62 ms    61 ms  AU-NS-1889-IPG-221-BE9.tpgi.com.au [203.220.35.201]
  8     *        *       62 ms  AU-NS-1889-IPE-01-Eth-Trunk21.tpgi.com.au [203.220.35.38]
  9    62 ms    61 ms    61 ms  60-242-21-182.static.tpgi.com.au [60.242.21.182]
 10    62 ms    62 ms    62 ms  60-242-21-182.static.tpgi.com.au [60.242.21.182]

Trace complete.

c:\Users\mike>tracert 60.242.21.182

Tracing route to 60-242-21-182.static.tpgi.com.au [60.242.21.182]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  ARCHER_VR1600V [192.168.1.1]
  2    12 ms    12 ms    12 ms  10.20.25.183
  3    62 ms    62 ms    61 ms  per-pow-stg-crt4-be200.tpgi.com.au [203.29.134.194]
  4    61 ms    61 ms    61 ms  nme-sot-dry-crt2-Be40.tpgi.com.au [203.219.107.229]
  5    61 ms    61 ms    61 ms  203-26-22-121.static.tpgi.com.au [203.26.22.121]
  6    61 ms    62 ms    61 ms  AU-NS-1889-IPG-02-Eth-Trunk3.tpgi.com.au [203.29.134.122]
  7    62 ms    62 ms    62 ms  AU-NS-1889-IPG-221-BE9.tpgi.com.au [203.220.35.201]
  8    61 ms    71 ms    61 ms  AU-NS-1889-IPE-01-Eth-Trunk21.tpgi.com.au [203.220.35.38]
  9    62 ms    62 ms    62 ms  60-242-21-182.static.tpgi.com.au [60.242.21.182]
 10    62 ms    61 ms    62 ms  60-242-21-182.static.tpgi.com.au [60.242.21.182]

Trace complete.

It looks like that hop is experiencing some sort of failure or overload, causing intermittent but frequent packet loss.

9 REPLIES 9
Anonymous
Not applicable

Hi @mikesheen ,

 

Let me help check the status of the connection. Could you shoot me a PM with your details so we can rectify this packet loss issue ASAP.

 

How to send a PM? 

 

Regards,

 

 

david64
Master

@Anonymous . There is something wrong with device 60.242.21.182.

My tracert:

CSmiley Embarassedtracert 60.242.21.182

Tracing route to 60-242-21-182.static.tpgi.com.au [60.242.21.182]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms ARCHER_VR1600V [192.168.1.1]
2 5 ms 4 ms 4 ms 10.20.26.113
3 4 ms 5 ms 5 ms AU-NS-1813-IPG-01-Eth-Trunk1.tpgi.com.au [203.221.3.58]
4 5 ms 5 ms 4 ms AU-NS-1813-IPG-221-BE9.tpgi.com.au [203.220.35.205]
5 12 ms 5 ms 4 ms AU-NS-1889-IPE-01-Eth-Trunk22.tpgi.com.au [203.220.35.42]
6 5 ms 4 ms 4 ms 60-242-21-182.static.tpgi.com.au [60.242.21.182]
7 6 ms 6 ms 6 ms 60-242-21-182.static.tpgi.com.au [60.242.21.182]

Trace complete.

 

The target address shouldn't be repeated like that. (Hop 6 and 7)

The attached jpeg shows the Wireshark trace of the end sequence of my tracert.

It shows ping requests sent with ttl=5 being returned as exceeded by 203.220.35.42. Correct.

Then, ping requests sent with ttl=6 being returned as exceeded by 60.242.21.182. Incorrect.

Then, ping requests sent with ttl=7. This time, 60.242.21.182 makes correct reply.

Anonymous
Not applicable

Thanks for the input, @david64 

 

I am still awaiting response from @mikesheen Smiley Very Happy

 

 

mikesheen
Level 2

@Anonymous wrote:

Thanks for the input, @david64 

 

I am still awaiting response from @mikesheenSmiley Very Happy

 

 


Nah, I PM'd you like you asked.

EDIT: Sorry I didn't see you since PM'd me again for the account details (NOT THAT YOU NEED THEM TO RECOGNISE THE ISSUE)

mikesheen
Level 2

So Shane has PM'd me and said that because the account is in my Wife's name that they can't proceed with any further action.

 

What a load of BS.

 

The problem is not related to the home broadband connection, it's some upstream equipment far away - so I guess that's where they draw the line - not a problem they need to worry about - even though it's a problem within the TPG network.

 

I would have thought most ISP's would be interested in faults within their network.

 

Not a good look, TPG.

david64
Master

Hi @mikesheen . What type of NBN connection do you have?    And what plan speed?

Did you use ethernet computer or wifi computer for these tracert displays?

You should find out why there is that size delay to the second address. This is your router's default gateway.

(I think it's the first bit of TPG's network on the other side of NBN network.)

And why the large delay to the third address.

I presume there are more hops before reaching the RDP target. What extra delay getting there?

 

You can test the address in line 8 of your tracert.

ping -n 50 -l 1000 203.220.35.38

 

david64
Master

@Anonymous . In light of mikesheen's last comment, will the problem with 60.242.21.182 still be investigated, as it is a separate problem?

BasilDV
Moderator

Hi @david64

 

Our tech team needs to run real-time testing as well before we able to raise the case to our Engineers.

 

We've already advised him to contact our Technical team for further support.

 

BasilDV

mikesheen
Level 2

@BasilDV wrote:

Hi @david64

 

Our tech team needs to run real-time testing as well before we able to raise the case to our Engineers.

 

We've already advised him to contact our Technical team for further support.

 

BasilDV


It's not a problem with my connection, I already established that by getting a work colleague in a different state, who is with a different ISP to test and had the same problem.  I don't want to be put on hold for an unkown amount of time explaining to someone over the telephone what my post already explains in an accurate and detailed way.

 

If you've ever tried to talk to anyone on your own telephone support line, you'll understand that me trying to report this to your first level support is going to be futile.

 

I'm trying to inform you of a problem with your network - nothing to do with my connection.

 

If you choose to ignore the report, then so be it - not my problem.