IDNet maintenance - Saturday, January 12, 2008

[Rik]

I wonder if a traceroute from a UNIX/Linux machine would be different then, as they use UDP datagrams instead of ICMP echo requests.

Can you try it?

[psp83]

IDnet still working on routing problems? Noticing some sites are sluggish now and pings are high again. Google for one is loading slow

[Arthix]

Well I'm not happy.  I've just been kicked off and reconnected at a synch rate of 6688.. I was at 8096.  I do hope this isn't going to be permanent.

I seem to have gone from a sync of 8128 to 7616 today aswell, could be because I just changed to the 2700hgv though .

[Rik]

IDnet still working on routing problems? Noticing some sites are sluggish now and pings are high again. Google for one is loading slow

I don't know, Paul. I've got an email in to support, so I'm waiting to hear back.

[Adam]

Can you try it?

From a wireless device, the pings are high but lowish latency between the devices.

traceroute to www.bbc.co.uk (212.58.224.125), 30 hops max, 40 byte packets
1  home (192.168.1.254)  37.955 ms  39.268 ms  39.533 ms
2  telehouse-gw2.idnet.net (212.69.63.55)  155.577 ms  158.728 ms  158.997 ms
3  telehouse-gw3-gi0-1-400.idnet.net (212.69.63.243)  151.377 ms  151.580 ms  152.023 ms
4  rt-lonap-b.thdo.bbc.co.uk (193.203.5.91)  153.162 ms  153.532 ms  154.932 ms
5  212.58.238.133 (212.58.238.133)  163.846 ms  164.089 ms  164.290 ms
6  www25.thdo.bbc.co.uk (212.58.224.125)  165.013 ms  169.587 ms  188.103 ms

[Rik]

Which, presumably, supports the low priority theory?

[Ted]

Traceroute from a Linux box

[ted@localhost ~]$ su
Password:
[root@localhost ted]# traceroute
Version 1.4a12
Usage: traceroute [-dFInrvx] [-g gateway] [-i iface] [-f first_ttl]
        [-m max_ttl] [ -p port] [-q nqueries] [-s src_addr] [-t tos]
        [-w waittime] [-z pausemsecs] host [packetlen]
[root@localhost ted]# traceroute 82.133.85.65
traceroute to 82.133.85.65 (82.133.85.65), 30 hops max, 38 byte packets
1  home (192.168.1.254)  1.551 ms  1.421 ms  1.382 ms
2  telehouse-gw2-msdp.idnet.net (212.69.63.51)  45.648 ms  64.861 ms  49.279 ms
3  telehouse-gw3-gi0-1-400.idnet.net (212.69.63.243)  47.666 ms  48.797 ms  47.                          256 ms
4  g3-35-501.cr05.hx2.bb.pipex.net (193.203.5.14)  49.158 ms  78.251 ms  51.642                           ms
5  v3952.cr05.tn5.bb.pipex.net (62.72.137.9)  48.485 ms v3953.cr05.tn5.bb.pipex                          .net (62.72.137.29)  53.863 ms  48.982 ms
6  g1-1-6.ar01.tn5.bb.pipex.net (62.72.140.142)  47.301 ms  50.509 ms  47.326 m                          s
7  ge-0-0-0-3801.jolt-gw.cust.pipex.net (212.241.241.14)  47.135 ms  46.942 ms                            51.091 ms
8  secure.jolt.co.uk (82.133.85.65)  48.993 ms  48.792 ms  49.376 ms
[root@localhost ted]#

[Rik]

Who let Pipex in??

[Adam]

Which, presumably, supports the low priority theory?

Yes, that'd be correct. Though I see no real reason why ICMP Echo should have a lower priority.

[Simon_idnet]

Cisco devices give ICMP echo-reply packets that are aimed directly to their interfaces (as happens in traceroute but not ping (to a destination i.e. *through* the cisco device)) a low priority.

From my DSL line at home I'm seeing normal ping times but I'll keep an eye on it.
Simon

simons-mac-pro:~ simon$ ping 82.133.85.65
PING 82.133.85.65 (82.133.85.65): 56 data bytes
64 bytes from 82.133.85.65: icmp_seq=0 ttl=56 time=11.729 ms
64 bytes from 82.133.85.65: icmp_seq=1 ttl=56 time=12.294 ms
64 bytes from 82.133.85.65: icmp_seq=2 ttl=56 time=12.856 ms
64 bytes from 82.133.85.65: icmp_seq=3 ttl=56 time=12.175 ms
64 bytes from 82.133.85.65: icmp_seq=4 ttl=56 time=13.752 ms
64 bytes from 82.133.85.65: icmp_seq=5 ttl=56 time=12.324 ms
64 bytes from 82.133.85.65: icmp_seq=6 ttl=56 time=12.647 ms
64 bytes from 82.133.85.65: icmp_seq=7 ttl=56 time=12.203 ms
^C
--- 82.133.85.65 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 11.729/12.498/13.752/0.568 ms
simons-mac-pro:~ simon$ ping www.bbc.co.uk
PING www.bbc.net.uk (212.58.253.74): 56 data bytes
64 bytes from 212.58.253.74: icmp_seq=0 ttl=248 time=12.460 ms
64 bytes from 212.58.253.74: icmp_seq=1 ttl=248 time=12.777 ms
64 bytes from 212.58.253.74: icmp_seq=2 ttl=248 time=12.584 ms
64 bytes from 212.58.253.74: icmp_seq=3 ttl=248 time=12.904 ms
64 bytes from 212.58.253.74: icmp_seq=4 ttl=248 time=13.215 ms
64 bytes from 212.58.253.74: icmp_seq=5 ttl=248 time=12.545 ms
64 bytes from 212.58.253.74: icmp_seq=6 ttl=248 time=13.106 ms
64 bytes from 212.58.253.74: icmp_seq=7 ttl=248 time=12.673 ms
^C
--- www.bbc.net.uk ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.460/12.783/13.215/0.255 ms
simons-mac-pro:~ simon$

[Den]

Hi You all, OK so I jumped in this morning thinking the fuss was all about the planed BT jobby. But my comments were still valid, I have never seen so many people slagging off Idnet and I was quite shocked. Things can go wrong and we all know that Idnet will sort it out as quick as they can and this once again proved the case. In this situation they obviously did not expect it to go wrong and did not feel a need to inform us, so what, the situation was soon in hand and they learned from their mistake.   Is it just me but I seem to be accessing page quicker than normal. 

[Rik]

Cisco devices give ICMP echo-reply packets that are aimed directly to their interfaces (as happens in traceroute but not ping (to a destination i.e. *through* the cisco device)) a low priority.

Can I have your line please, Simon.

I'm now seeing times that are consistent at ~25ms to the BBC, a bit slower than normal, but I don't often test pings - especially on a Saturday afternoon.

To IDNet, though, is markedly slower than usual:

ping www.idnet.net

Pinging www.idnet.net [212.69.36.10] with 32 bytes of data:

Reply from 212.69.36.10: bytes=32 time=37ms TTL=59
Reply from 212.69.36.10: bytes=32 time=41ms TTL=59
Reply from 212.69.36.10: bytes=32 time=45ms TTL=59
Reply from 212.69.36.10: bytes=32 time=44ms TTL=59

Ping statistics for 212.69.36.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 37ms, Maximum = 45ms, Average = 41ms

[Rik]

Is it just me but I seem to be accessing page quicker than normal. 

A number of people have reported a 'nippier' service, Den, though some of us do seem to be seeing slightly extended ping times.

As to your earlier comments, I agree that some people seemed to react very strongly to this morning's problems. Perhaps it's a sign that we now regard a 'net connection in the same way as any other utility, eg if we turn on the lights, we expect them to work - if we open the tap, we expect water to flow. People 'need' the net nowadays as never before.

[Adam]

Cisco devices give ICMP echo-reply packets that are aimed directly to their interfaces (as happens in traceroute but not ping (to a destination i.e. *through* the cisco device)) a low priority.

That makes sense. It isn't really an issue as UNIX/Linux uses UDP packets unless specified, just somewhat confusing when comparing it to a Windows traceroute.

[Philip]

something been going on today then ?

[Rik]

 

It has, Philip, it has.

[Philip]

It has, Philip, it has.

being serious, we've not noticed any problems in Penzance, Meg has been on her lappy most of the morning and she usually lets me know if there's a problem. 

Hope everything is OK for everyone now. 

[Sebby]

It's very coincidental.

Sync is not related to the ISP, Ann.

[Rik]

Meg has been on her lappy most of the morning and she usually lets me know if there's a problem. 

Only usually??

[Ann]

Sync is not related to the ISP, Ann.

No but as I said before... oh never mind.

[Sebby]

Sorry, Sebby, missed this in the rush. How about the stats page, that has something about ISP connection establishment.

http://192.168.1.254/xslt?PAGE=J04&THISPAGE=J17&NEXTPAGE=J04

Thanks, Rik. In that case, it looks like I didn't lose the connection to IDNet after all.

[psp83]

ping times are back to normal. saying that.. every trace route i've done to my normal IP's/websites has an added 2ms to there time than it did last week.

eg, Jolt.co.uk, usual ping 15ms, Todays is 17ms.

but can't moan, wont notice that in games 

will try again at usual gaming times.

[Sebby]

No but as I said before... oh never mind.

I appreciate what you're saying - had you not been disconnected from the exchange, you wouldn't have sync'd lower. Obviouslu between the time you last sync'd (did you say around a month ago?) and now, more noise is around. Subsequently, your router has had to sync a bit lower to achieve the same target SNRM.

I understand how infuriating it can be, but any ISP - not just IDNet - do not control the connection between you and the exchange. Had you been disconnected from IDNet, your sync wouldn't have dropped, so this is a BT issue and not related to IDNet's maintenance.

[Philip]

Only usually??

sorry, always

[theop]

All seems fine to me but we've been unable to ping any of our routers from 11am that are on idnet. Every other service seems fine.

Thanks

Theo