packet loss, mansfield notts

blaupunkt · 19-02-2006, 13:30

im getting 100% PL on the 1st hop been like it for days now, any idea what the problem might be, is it a known problem etc ?

trace route to the bbc below.

Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-2001.

C:\DOCUME~1\G>pathping www.bbc.co.uk

Tracing route to www.bbc.net.uk [212.58.224.125]
over a maximum of 30 hops:
0 hope [82.5.**.***]
1 10.138.183.254
2 nott-t2cam1-b-v153.inet.ntl.com [80.4.47.25]
3 nott-t2core-b-ge-wan84.inet.ntl.com [80.1.79.225]
4 nth-bb-b-so-300-0.inet.ntl.com [62.253.188.37]
5 nth-bb-a-ae0-0.inet.ntl.com [62.253.185.117]
6 gfd-bb-b-so-400-0.inet.ntl.com [62.253.185.98]
7 redb-ic-1-as0-0.inet.ntl.com [213.105.174.138]
8 212.58.238.189
9 212.58.238.133
10 www25.thdo.bbc.co.uk [212.58.224.125]

Computing statistics for 250 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 hope [82.5.**.***]
0/ 100 = 0% |
1 --- 100/ 100 =100% 100/ 100 =100% 10.138.183.254
0/ 100 = 0% |
2 27ms 0/ 100 = 0% 0/ 100 = 0% nott-t2cam1-b-v153.inet.ntl.com [8
0.4.47.25]
0/ 100 = 0% |
3 22ms 1/ 100 = 1% 1/ 100 = 1% nott-t2core-b-ge-wan84.inet.ntl.co
m [80.1.79.225]
0/ 100 = 0% |
4 14ms 0/ 100 = 0% 0/ 100 = 0% nth-bb-b-so-300-0.inet.ntl.com [62
.253.188.37]
0/ 100 = 0% |
5 14ms 0/ 100 = 0% 0/ 100 = 0% nth-bb-a-ae0-0.inet.ntl.com [62.25
3.185.117]
0/ 100 = 0% |
6 17ms 0/ 100 = 0% 0/ 100 = 0% gfd-bb-b-so-400-0.inet.ntl.com [62
.253.185.98]
0/ 100 = 0% |
7 17ms 0/ 100 = 0% 0/ 100 = 0% redb-ic-1-as0-0.inet.ntl.com [213.
105.174.138]
0/ 100 = 0% |
8 19ms 0/ 100 = 0% 0/ 100 = 0% 212.58.238.189
0/ 100 = 0% |
9 19ms 0/ 100 = 0% 0/ 100 = 0% 212.58.238.133
0/ 100 = 0% |
10 16ms 0/ 100 = 0% 0/ 100 = 0% www25.thdo.bbc.co.uk [212.58.224.1
25]

Trace complete.

C:\DOCUME~1\G>

19-02-2006, 16:07

Your hop 1 is an internal address proberbly part of the NTL Network. This will not respond as it is part of a seperate private network and as such is unreachable via your public IP address.

Quote:

1 10.138.183.254

Basically this looks like an internal address of a device on the NTL network.

Ignition · 19-02-2006, 16:23

Quote:

Originally Posted by TW_BUS_DATA_TECH

Your hop 1 is an internal address proberbly the cable modem. This will not respond as it is part of a seperate private network and as such is unreachable via your public IP address.

Basically this is the internal address of the cable modem on the NTL network.

Ummmm.

Hop 1 the internal address is actually the cable modem's gateway. All traffic from PC goes across this link in order to reach the internet. If PC couldn't reach that address there'd be no internet access at all. The modem is actually a bridge that's transparent from the PC side. The uBR knows it has to send all traffic to the 82.5 address the PC has via the modem's MAC address and it's switched from the uBR side, however the PCs only see a public default gateway. This is there purely so that it doesn't upset the PCs which need a default gateway in their own subnet. The actual 'default gateway' is that 10.x address which is reached via the modem.

This is how the network is seen from uBR:

PC <--82.5.x.x------------ Modem <---10.x.x.x------> uBR (PC 82.5.x.x has a DHCP lease via Modem 10.x.x.x, to send to MAC address an.et.wo.rk.ca.rd I need to go via modem ub.er.am.bi.tn.ot (note not IP address 10.x.x.x, it uses the modem's IP address to talk to the modem only, it uses its' MAC address to switch through it to get to the PC behind, the modem sees that the traffic is intended for the PC behind it and passes it along.)

PC sees the network like this:

PC <--82.5.x.x--------------------------------------> uBR

It actually sends to an address in its' own network, and receives its' responses from the uBR's 10.x cable gateway.

This is actually simplifying things and staying at the IP / MAC address layer, it's actually a fair bit more complicated and involves service IDs, service flow IDs in both directions.

<end lesson and back on topic>

From what's been shown the rest of the trace is fine. The router might just be configured to not respond to pings.

If there's no packet loss to the end destination all should be fine sir, no point looking for faults if service is fine.

EDIT: Repeated edits due to trying to make what I was trying to say clearer