Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

[James M Taylor]

Thought I’d throw this out to the user group to see if I need to go completely bald or bonkers…

 

I have a client that runs an accounting package (Maxim) from New Plymouth to a Terminal Server in Hamilton.  They run the package from two companies in New Plymouth (Cambrian and Amtec) 15km apart on two different broadband connections (both with telecom Xtra).  There is likely about 15 users on the package all day at Cambrian and maybe ½ dozen on part time at the Amtec.  Over the last few weeks, they have experienced a lot of disconnected RDP sessions at Cambrian and occasional ones at Amtec.  I started performing some tests to see if there were any drop outs of the internet, dropped packets, significant errors, etc.  Satisfied that the ADSL routers at both ends have never dropped their connections, the errors appear to be small on Cambrian and though Larger on Amtec, it is experiencing as many disconnects and no failures through Telecoms Gateway.

 

I have run some test using Look@LAN (now OutlookFing – can’t seem to download Look@LAN anymore – let me know if anyone needs a copy) which allows me to connect to, scan and do a graphical ping on other PCs on the network and across Internet.  Amtec and Cambrian are connected to each other via VPN across the internet.  I used 5 PCs in the test (P4 (192.168.1.4) and Surfcam (192.168.1.127) at Cambrian, DFE-4 (192.168.0.4) and DFE-7W (192.168.0.157)  at Amtec and CES-7750 (14.x.x.x) at my office).  This allows me to test throughput on the same LAN, through the internet and through the internet via VPN (More overhead).

 

Excerpt from Report that I’m doing for the client (only a few of the tests are included below).

While performing the Trace Route tests further down, one of Telecoms Global-Gateway Infrastructure (Switch IP 202.50.238.50) started faulting intermittently.  Even though the connection between Cambrian and Amtec is via the internet, a VPN tunnel connection has already been established which makes it appear to be only 2 hops between the two but it will also likely have 8 or more hops hidden by the tunnel.  The fact that it is a constant connection could easily mean the 202.50.238.50 was not in the mix when the connection was first established.  202.50.238.50 has the significant delay throughout all the tests but started failing altogether or for lengthy periods while testing from Cambrian (P4 and Surfcam).  This could be the source of the problem for Cambrian.  The VPN tunnel 10.8.0.x is also suffering delays and is likely using the 202.50.238.50 Gateway.

 

What can make a Telecom Gateway treat one client different than others?  Could it be something on the local network that makes a gateway 4 hops away act the way it does in the tests below?

 

IP Address Lookup - Whois by IP Address : 
202.50.238.50

 

                                         [Querying whois.apnic.net]

[whois.apnic.net]

% [whois.apnic.net node-3]

% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:        202.50.236.0 - 202.50.239.255

netname:        INFRA-GGIS-NZ

descr:          Global-Gateway Infrastructure

country:        NZ

admin-c:        IA42-AP

tech-c:         IA42-AP

notify:         n...@netgate.net.nz

mnt-by:         NZTELECOM

changed:        db...@netgate.net.nz 20060418

status:         ASSIGNED NON-PORTABLE

source:         APNIC

person:         IP Administrator

address:        Telecom Internet Registry

address:        Level 9, Mayoral Drive BLDG

address:        Private Bag 92028

address:        Auckland

country:        NZ

phone:          +64-9-355-4052

e-mail:         t...@telecom.co.nz

nic-hdl:        IA42-AP

mnt-by:         NZTELECOM

changed:        db...@netgate.net.nz 20070911

source:         APNIC 

 

 

 

After performing the above test and noticing there seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50,

I re-tested the Trace route to CES-7750 from both Amtec’s DFE-4 and Cambrian’s Surfcam simultaneously and 202.50.238.50 appears to only be failing when Cambrian uses it???

 

To see if this is specific to Cambrian only, I remoted into yet another client who uses Xtra and tested from one of their PCs to my PC.

 

Amtec’s DFE-4 to CES-7750 (My PC) Graphical Ping:

 

SURFCAM to CES-7750 Graphical Ping (8 Hops)

 

HospitalPC at Maida Vale to CES-7750 Graphical Ping (8 Hops): Sorry, Look@LAN comes in English and Italian, it sometimes looses its language setting and needs a registry setting or re-installing to set it back…

 

Amtec’s DFE-4 to CES-7750 (My PC) Traceroute: the 4^th hop202.50.238.50 is good, the 6^th has a good average but has a max that is 63ms

 

Surfcam to CES-7750 Traceroute: the 4^th hop202.50.238.50 fails, the 5^th thru 8^th have good averages but some high maximums

 

HospitalPC at Maida Vale to CES-7750 Traceroute (8 Hops):

 

Amtec’s DFE-4 to CES-7750 (My PC) Graphical Traceroute:

 

Surfcam to CES-7750 Graphical Traceroute:

 

HospitalPC at Maida Vale to CES-7750 Graphical Traceroute (8 Hops):

 

 

Amtec’s ADSL has been up for 61 & ½ days…

Amtec ADSL:

 

It has pumped a lot of data thru but with some errors.  They are low proportionally but more than Cambrian’s line…

Traffic Statistics

PPPoA RoutedVPI / VCI: 0 / 100              Rx:         622,831,793/ 111

Tx:          522,439,216/ 342,243

Ethernet Connection                                Rx :        532,203,801/ 80138

Tx :         629,589,041/ 0

Wireless Connection                                Rx :                   2,644/ 0

Tx :                    7148/ 0

 

 

Cambrian ADSL Info & Statistics

Cambrian’s ADSL has been up for 169 days…

 

 

 

 

 

 

Because of the errors below, I have since disabled the DNS server in both ADSL routers and fixed them to:

 

…

 

Amtec:

 

Cambrian:

 

 

 

[James Gray]

Nodes on the internet drop packets all the time if they're overloaded. The type of service you're using is a best effort service, have you considered telecom oneoffice? Alternatively, primo wireless offers point to point data, though I'm not sure cambrian is in their coverage area

--
You received this message because you are subscribed to the Google Groups "Taranaki Linux Users Group" group.
To post to this group, send email to taranaki-linu...@googlegroups.com.
To unsubscribe from this group, send email to taranaki-linux-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/taranaki-linux-users-group?hl=en.

[Matthew Harrison]

Perhaps an upgrade to a business class connection like VDSL would be of benefit to them.

 

Regards,

 

Matthew Harrison

Managing Director

PrimoWireless

www.primowireless.co.nz

Phone: 06 7566620

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2195 / Virus Database: 2437/5131 - Release Date: 07/14/12

[Vince Martin-Smith]

something to keep in mind with diagnostics like this ... ping traffic is
first to get dropped especially around core nodes like nzgate and ape...
so dropped pings aren't necessarily indicative of a fault (as James Gray
mentioned).

pings *should* pass through to other consumer addresses ok though as
that is client traffic so they try to deliver it - this will show up as
in a traceroute or mtr as failed hops if nodes are under heavy load.


What I would do it run an adaptive flood ping end to end... this loads
up every hop in the path with data and if there are any
mis-configurations in the core network this will show up.

(Try it from each end too as the return route is not necesarily the
same)

Occasionally dslams and the like get mis-configured and rather than
start throttling TCP data they just discard packets (not good especially
for terminal server - it doesn't like that). Under overload conditions,
again as James indicates, any datagram traffic (icmp/udp) can be shed as
there is no flow control protocol around that kind of data. TCP on the
other hand manages slow delivery reasonably well.

I've never looked for a flood-ping tool under Windoze but under Linux
you use ping -Afs1024 <destination node>

Every ping sent out draws a . and everyone that comes back erases one...
so to start with you get a row of .....s which should in theory all
disappear but the first once the buffers are loaded up through the
network. If you see frequent .s appearing then it's dropping more
traffic than it should.

Another thing... depending on what type of router you are using.. try
rebooting those at each end before re-running tests. (and check that the
errors you saw in the diagnostic display are not increasing as you watch
- once in a while you will often get one or two - but they should be few
and far between).

I have seen versions of firmware (even from the big guys) on routers
which have been running for some time - get all confused ... something
to do with internal garbage collect maybe. but they start intermittently
reporting errors and dropping packets. This can happen more frequently
the longer they have been running without restart. Restart and away it
goes for another few weeks.

A classic symptom of this is DNS starts intermittently misreporting
addresses as being non existent or times out frequently.


anyhow - my 2.3c worth.

Cheers
Vince


p.s. If it does become too much of a problem then some form of
guaranteed service (aka CIR - committed information rate) is the answer
otherwise you'll always suffer from intermittent loading on public
networks (especially from the big telcos who always "over-sell" their
network capacity).

> SURFCAM to CES-7750 Graphical Ping (8 Hops)
>
>
>
>
>

> HospitalPC at Maida Vale to CES-7750 Graphical Ping (8 Hops): Sorry,
> Look@LAN comes in English and Italian, it sometimes looses its
> language setting and needs a registry setting or re-installing to set
> it back…
>
>
>
>
>

> Amtec’s DFE-4 to CES-7750 (My PC) Traceroute: the 4th hop202.50.238.50
> is good, the 6th has a good average but has a max that is 63ms
>
>
>
>
>

> Surfcam to CES-7750 Traceroute: the 4th hop202.50.238.50 fails, the
> 5th thru 8th have good averages but some high maximums
>
>
>
>
>

> HospitalPC at Maida Vale to CES-7750 Traceroute (8 Hops):
>
>
>
>
>

> Amtec’s DFE-4 to CES-7750 (My PC) Graphical Traceroute:
>
>
>
>
>

> Surfcam to CES-7750 Graphical Traceroute:
>
>
>
>
>

> HospitalPC at Maida Vale to CES-7750 Graphical Traceroute (8 Hops):
>
>
>
>
>
>
>

> Amtec’s ADSL has been up for 61 & ½ days…
>
> Amtec ADSL:
>
>
>
>
>

> It has pumped a lot of data thru but with some errors. They are low
> proportionally but more than Cambrian’s line…
>
> Traffic Statistics
>
> PPPoA RoutedVPI / VCI: 0 / 100 Rx: 622,831,793/
> 111
>
> Tx: 522,439,216/ 342,243
>
> Ethernet Connection Rx :
> 532,203,801/ 80138
>
> Tx : 629,589,041/ 0
>
> Wireless Connection Rx :
> 2,644/ 0
>
> Tx : 7148/ 0
>
>
>
>
>
> Cambrian ADSL Info & Statistics
>
> Cambrian’s ADSL has been up for 169 days…
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

> Because of the errors below, I have since disabled the DNS server in
> both ADSL routers and fixed them to:
>
>
>
>
>
>
>

> …
>
>
>
>
>
> Amtec:
>
>
>
>
>
> Cambrian:

Vince Martin-Smith
Director
TISEC Limited
1548 Carrington Rd
RD1
New Plymouth
ph: +64 6 824 8113
mo: +64 21 0232 6846
skype: vincemartinsmith

[James M Taylor]

Thanks James,

 

Primo can’t supply the point to point between Amtec & Cambrian but that does not appear to be the problem.  They are running their phone system thru the VPN and it is operating well, it is just their subscription to the Hamilton outfit that seems to be affected.  I’m sure that their regular internet browsing, etc are also having delays but aren’t dropping out before retrying.  The query is “Why does 202.50.238.50 seem to stop responding only from Cambrian when access the internet?”

 

 

Best Regards

James Taylor

Computer & Electronic Service 
(  +64 6 753-2616 or 021 043-5212
2 Fax +64 6 753-2616
63A Ballance Street, Vogeltown, NEW PLYMOUTH 4310, NZ
* Email j...@cesnz.co.nz
7 Web www.cesnz.co.nz

The above message was sent to you as a customer, friend or associate.  Any pricing discussed excludes Freight and GST unless otherwise stated.  To be removed from this mailing, please click reply  and put "REMOVE" as the subject

P Please consider the environment before printing this e-mail.

 

----- Original Message -----
Subject: Re: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 07:22:35 +0930
From: James Gray <jame...@gmail.com>

Nodes on the internet drop packets all the time if they're overloaded. The
type of service you're using is a best effort service, have you considered
telecom oneoffice? Alternatively, primo wireless offers point to point
data, though I'm not sure cambrian is in their coverage area
On 14/07/2012 5:53 PM, "James M Taylor" <j...@world-net.co.nz> wrote:

> ** ** ** **

>
> Thought I’d throw this out to the user group to see if I need to go

> completely bald or bonkers…****
>
> ** **

>
> I have a client that runs an accounting package (Maxim) from New Plymouth

> to a Terminal Server in ****Hamilton****.  They run the package from two

> companies in New Plymouth (Cambrian and Amtec) 15km apart on two different
> broadband connections (both with telecom Xtra).  There is likely about 15
> users on the package all day at Cambrian and maybe ½ dozen on part time at
> the Amtec.  Over the last few weeks, they have experienced a lot of
> disconnected RDP sessions at Cambrian and occasional ones at Amtec.  I
> started performing some tests to see if there were any drop outs of the
> internet, dropped packets, significant errors, etc.  Satisfied that the
> ADSL routers at both ends have never dropped their connections, the errors
> appear to be small on Cambrian and though Larger on Amtec, it is
> experiencing as many disconnects and no failures through Telecoms Gateway.

> ****
>
> ** **

>
> I have run some test using Look@LAN (now OutlookFing – can’t seem to
> download Look@LAN anymore – let me know if anyone needs a copy) which
> allows me to connect to, scan and do a graphical ping on other PCs on the
> network and across Internet.  Amtec and Cambrian are connected to each
> other via VPN across the internet.  I used 5 PCs in the test (P4
> (192.168.1.4) and Surfcam (192.168.1.127) at Cambrian, DFE-4 (192.168.0.4)
> and DFE-7W (192.168.0.157)  at Amtec and CES-7750 (14.x.x.x) at my office).
>  This allows me to test throughput on the same LAN, through the internet

> and through the internet via VPN (More overhead).****
>
> ** **
>
> *Excerpt from Report that I’m doing for the client* (only a few of the
> tests are included below).****
>
> While performing the ****Trace Route**** tests further down, one of Telecoms

> Global-Gateway Infrastructure (Switch IP 202.50.238.50) started faulting
> intermittently.  Even though the connection between Cambrian and Amtec is
> via the internet, a VPN tunnel connection has already been established
> which makes it appear to be only 2 hops between the two but it will also
> likely have 8 or more hops hidden by the tunnel.  The fact that it is a
> constant connection could easily mean the 202.50.238.50 was not in the
> mix when the connection was first established.  202.50.238.50 has the
> significant delay throughout all the tests but started failing altogether
> or for lengthy periods while testing from Cambrian (P4 and Surfcam).  This
> could be the source of the problem for Cambrian.  The VPN tunnel 10.8.0.x

> is also suffering delays and is likely using the 202.50.238.50 Gateway. **
> **
>
> ** **

>
> What can make a Telecom Gateway treat one client different than others?
>  Could it be something on the local network that makes a gateway 4 hops

> away act the way it does in the tests below?****
>
> ** **
> *IP Address Lookup - Whois by IP Address :
> 202.50.238.50*
>
> ** **
>
>                                          [Querying whois.apnic.net]****
>
> [whois.apnic.net]****
>
> % [whois.apnic.net node-3]****
>
> % Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html****
>
> ** **
>
> inetnum:        202.50.236.0 - 202.50.239.255****
>
> netname:        INFRA-GGIS-NZ****
>
> descr:          Global-Gateway Infrastructure****
>
> country:        NZ****
>
> admin-c:        IA42-AP****
>
> tech-c:         IA42-AP****
>
> notify:         n...@netgate.net.nz****
>
> mnt-by:         NZTELECOM****
>
> changed:        db...@netgate.net.nz 20060418****
>
> status:         ASSIGNED NON-PORTABLE****
>
> source:         APNIC****
>
> ** **
>
> person:         IP Administrator****
>
> address:        Telecom Internet Registry****
>
> address:        Level 9, Mayoral Drive BLDG****
>
> address:        Private Bag 92028****
>
> address:        ****Auckland********
>
> country:        NZ****
>
> phone:          +64-9-355-4052****
>
> e-mail:         t...@telecom.co.nz****
>
> nic-hdl:        IA42-AP****
>
> mnt-by:         NZTELECOM****
>
> changed:        db...@netgate.net.nz 20070911****
>
> source:         APNIC ****
>
> ** **
>
> ** **
>
> ** **
>
> After performing the above test and noticing there *seems to be a faulty
> Telecom Global-Gateway Infrastructure at 202.50.238.50*, ****

>
> I re-tested the Trace route to CES-7750 from both Amtec’s DFE-4 and
> Cambrian’s Surfcam simultaneously and 202.50.238.50 appears to only be

> failing when Cambrian uses it???****
>
> ** **

>
> To see if this is specific to Cambrian only, I remoted into yet another

> client who uses Xtra and tested from one of their PCs to my PC.****
>
> ** **
>
> Amtec’s DFE-4 to CES-7750 (My PC) Graphical Ping:****
>
> ****
>
> ** **
>
> SURFCAM to CES-7750 Graphical Ping (8 Hops)****
>
> ****
>
> ** **

>
> HospitalPC at Maida Vale to CES-7750 Graphical Ping (8 Hops): Sorry,
> Look@LAN comes in English and Italian, it sometimes looses its language

> setting and needs a registry setting or re-installing to set it back…****
>
> ****
>
> ** **
>
> Amtec’s DFE-4 to CES-7750 (My PC) Traceroute: *the 4th hop202.50.238.50is good, the 6
> th has a good average but has a max that is 63ms*
>
> ****
>
> ** **
>
> Surfcam to CES-7750 Traceroute: *the 4th hop202.50.238.50 fails, the 5ththru 8
> th have good averages but some high maximums*****
>
> ****
>
> ** **
>
> HospitalPC at Maida Vale to CES-7750 Traceroute (8 Hops):****
>
> ****
>
> ** **
>
> Amtec’s DFE-4 to CES-7750 (My PC) Graphical Traceroute:****
>
> ****
>
> ** **
>
> Surfcam to CES-7750 Graphical Traceroute:****
>
> ****
>
> ** **
>
> HospitalPC at Maida Vale to CES-7750 Graphical Traceroute (8 Hops):****
>
> ****
>
> ** **
>
> ** **
>
> Amtec’s ADSL has been up for 61 & ½ days…****
>
> *Amtec ADSL:*
>
> ****
>
> ** **

>
> It has pumped a lot of data thru but with some errors.  They are low

> proportionally but more than Cambrian’s line…****
>
> *Traffic Statistics*
>
> *PPPoA Routed*VPI / VCI: 0 / 100              Rx:         622,831,793/ 111
> ****
>
> Tx:          522,439,216/ 342,243****
>
> *Ethernet Connection*                                Rx :
> 532,203,801/ 80138****
>
> Tx :         629,589,041/ 0****
>
> *Wireless Connection*                                Rx :
>            2,644/ 0****
>
> Tx :                    7148/ 0****
>
> ** **
>
> ** **
>
> *Cambrian ADSL Info & Statistics*
>
> Cambrian’s ADSL has been up for 169 days…****
>
> ** **
>
> ****
>
> ** **
>
> ****
>
> ** **
>
> ****
>
> ** **
>
> ****
>
> ** **
>
> ****
>
> ** **

>
> Because of the errors below, I have since disabled the DNS server in both

> ADSL routers and fixed them to:****
>
> ****
>
> ** **
>
> ****
>
> …****
>
> ****
>
> ** **
>
> *Amtec:*
>
> ****
>
> ** **
>
> *Cambrian:*
>
> ****
>
> ** **
>
> ** **
>
> ** **

>
> --
> You received this message because you are subscribed to the Google Groups
> "Taranaki Linux Users Group" group.
> To post to this group, send email to
> taranaki-linu...@googlegroups.com.
> To unsubscribe from this group, send email to
> taranaki-linux-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/taranaki-linux-users-group?hl=en.
>

[James M Taylor]

This has been working fine for years, just started the regular disconnections within the last few weeks.  It could be coincidental that Amtec suffered a few disconnections while Cambrian was/is getting constant disconnections and may not be related.  Since it is the more serious problem on Cambrian and the only significant thing I could find was the losses/delays via the Telecom Gateway (202.50.238.50) that seems to only appear when access something over the internet from Cambrian, then the question is “How and why does 202.50.238.50 seem to stop responding only from Cambrian when accessing the internet?”

 

 

Best Regards

James Taylor

Computer & Electronic Service 
(  +64 6 753-2616 or 021 043-5212
2 Fax +64 6 753-2616
63A Ballance Street, Vogeltown, NEW PLYMOUTH 4310, NZ
* Email j...@cesnz.co.nz
7 Web www.cesnz.co.nz

The above message was sent to you as a customer, friend or associate.  Any pricing discussed excludes Freight and GST unless otherwise stated.  To be removed from this mailing, please click reply  and put "REMOVE" as the subject

P Please consider the environment before printing this e-mail.

 

 

----- Original Message -----
Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 10:01:30 +1200
From: "Matthew Harrison" <mat...@primowireless.co.nz>

Perhaps an upgrade to a business class connection like VDSL would be of
benefit to them.

 

Regards,

 

Matthew Harrison

Managing Director

PrimoWireless

www.primowireless.co.nz <http://www.primowireless.co.nz/>

Phone: 06 7566620

 

From: taranaki-linu...@googlegroups.com
[mailto:taranaki-linu...@googlegroups.com] On Behalf Of James Gray
Sent: Sunday, 15 July 2012 9:53 a.m.
To: taranaki-linu...@googlegroups.com

Subject: Re: Help, Seems to be a faulty Telecom Global-Gateway
Infrastructure at 202.50.238.50 that does not like my clients network

 

Nodes on the internet drop packets all the time if they're overloaded. The

type of service you're using is a best effort service, have you considered
telecom oneoffice? Alternatively, primo wireless offers point to point data,
though I'm not sure cambrian is in their coverage area

On 14/07/2012 5:53 PM, "James M Taylor" <j...@world-net.co.nz> wrote:

Thought I’d throw this out to the user group to see if I need to go
completely bald or bonkers…

 

I have a client that runs an accounting package (Maxim) from New Plymouth to
a Terminal Server in Hamilton.  They run the package from two companies in

New Plymouth (Cambrian and Amtec) 15km apart on two different broadband
connections (both with telecom Xtra).  There is likely about 15 users on the
package all day at Cambrian and maybe ½ dozen on part time at the Amtec.
Over the last few weeks, they have experienced a lot of disconnected RDP
sessions at Cambrian and occasional ones at Amtec.  I started performing
some tests to see if there were any drop outs of the internet, dropped
packets, significant errors, etc.  Satisfied that the ADSL routers at both
ends have never dropped their connections, the errors appear to be small on
Cambrian and though Larger on Amtec, it is experiencing as many disconnects
and no failures through Telecoms Gateway.

 

I have run some test using Look@LAN (now OutlookFing – can’t seem to

download Look@LAN anymore – let me know if anyone needs a copy) which allows
me to connect to, scan and do a graphical ping on other PCs on the network
and across Internet.  Amtec and Cambrian are connected to each other via VPN
across the internet.  I used 5 PCs in the test (P4 (192.168.1.4) and Surfcam
(192.168.1.127) at Cambrian, DFE-4 (192.168.0.4) and DFE-7W (192.168.0.157)
at Amtec and CES-7750 (14.x.x.x) at my office).  This allows me to test
throughput on the same LAN, through the internet and through the internet
via VPN (More overhead).

 

Excerpt from Report that I’m doing for the client (only a few of the tests
are included below).

While performing the Trace Route tests further down, one of Telecoms

Global-Gateway Infrastructure (Switch IP 202.50.238.50) started faulting
intermittently.  Even though the connection between Cambrian and Amtec is
via the internet, a VPN tunnel connection has already been established which
makes it appear to be only 2 hops between the two but it will also likely
have 8 or more hops hidden by the tunnel.  The fact that it is a constant
connection could easily mean the 202.50.238.50 was not in the mix when the
connection was first established.  202.50.238.50 has the significant delay
throughout all the tests but started failing altogether or for lengthy
periods while testing from Cambrian (P4 and Surfcam).  This could be the
source of the problem for Cambrian.  The VPN tunnel 10.8.0.x is also
suffering delays and is likely using the 202.50.238.50 Gateway.

 

What can make a Telecom Gateway treat one client different than others?

Could it be something on the local network that makes a gateway 4 hops away
act the way it does in the tests below?

 

 

IP Address Lookup - Whois by IP Address :
202.50.238.50

 

 

                                         [Querying whois.apnic.net]
[whois.apnic.net]
% [whois.apnic.net node-3]

% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

 
 
inetnum:        202.50.236.0 - 202.50.239.255
 
netname:        INFRA-GGIS-NZ
 
descr:          Global-Gateway Infrastructure
 
country:        NZ
 
admin-c:        IA42-AP
 
tech-c:         IA42-AP
 
notify:         n...@netgate.net.nz
mnt-by:         NZTELECOM
changed:        db...@netgate.net.nz 20060418
status:         ASSIGNED NON-PORTABLE
source:         APNIC
 
 
person:         IP Administrator
 
address:        Telecom Internet Registry
 

address:        Level 9, Mayoral Drive BLDG

 
address:        Private Bag 92028
 
address:        Auckland
 
country:        NZ
 

phone:          +64-9-355-4052 <tel:%2B64-9-355-4052>

e-mail:         t...@telecom.co.nz
nic-hdl:        IA42-AP
mnt-by:         NZTELECOM
changed:        db...@netgate.net.nz 20070911
source:         APNIC

 

 

 

After performing the above test and noticing there seems to be a faulty
Telecom Global-Gateway Infrastructure at 202.50.238.50,

I re-tested the Trace route to CES-7750 from both Amtec’s DFE-4 and
Cambrian’s Surfcam simultaneously and 202.50.238.50 appears to only be
failing when Cambrian uses it???

 

To see if this is specific to Cambrian only, I remoted into yet another

client who uses Xtra and tested from one of their PCs to my PC.

 

Amtec’s DFE-4 to CES-7750 (My PC) Graphical Ping:

 

 

SURFCAM to CES-7750 Graphical Ping (8 Hops)

 

 

HospitalPC at Maida Vale to CES-7750 Graphical Ping (8 Hops): Sorry,

Look@LAN comes in English and Italian, it sometimes looses its language
setting and needs a registry setting or re-installing to set it back…

 

 

Amtec’s DFE-4 to CES-7750 (My PC) Traceroute: the 4th hop202.50.238.50 is

good, the 6th has a good average but has a max that is 63ms

 

 

Surfcam to CES-7750 Traceroute: the 4th hop202.50.238.50 fails, the 5th thru
8th have good averages but some high maximums

 

 

HospitalPC at Maida Vale to CES-7750 Traceroute (8 Hops):

 

 

Amtec’s DFE-4 to CES-7750 (My PC) Graphical Traceroute:

 

 

Surfcam to CES-7750 Graphical Traceroute:

 

 

HospitalPC at Maida Vale to CES-7750 Graphical Traceroute (8 Hops):

 

 

 

Amtec’s ADSL has been up for 61 & ½ days…

Amtec ADSL:

 

 

It has pumped a lot of data thru but with some errors.  They are low
proportionally but more than Cambrian’s line…

Traffic Statistics

PPPoA RoutedVPI / VCI: 0 / 100              Rx:         622,831,793/ 111

Tx:          522,439,216/ 342,243

Ethernet Connection                                Rx :        532,203,801/
80138

Tx :         629,589,041/ 0

Wireless Connection                                Rx :
2,644/ 0

Tx :                    7148/ 0

 

 

Cambrian ADSL Info & Statistics

Cambrian’s ADSL has been up for 169 days…

 

 

 

 

 

 

 

 

 

 

 

Because of the errors below, I have since disabled the DNS server in both

ADSL routers and fixed them to:

 

 

 

…

 

 

Amtec:

 

 

Cambrian:

 

 

 

 

--
You received this message because you are subscribed to the Google Groups
"Taranaki Linux Users Group" group.
To post to this group, send email to
taranaki-linu...@googlegroups.com.
To unsubscribe from this group, send email to
taranaki-linux-user...@googlegroups.com

<mailto:taranaki-linux-users-group%2Bunsu...@googlegroups.com> .

For more options, visit this group at
http://groups.google.com/group/taranaki-linux-users-group?hl=en.

--
You received this message because you are subscribed to the Google Groups
"Taranaki Linux Users Group" group.
To post to this group, send email to
taranaki-linu...@googlegroups.com.
To unsubscribe from this group, send email to
taranaki-linux-user...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/taranaki-linux-users-group?hl=en.

 

No virus found in this message.

Checked by AVG - www.avg.com
Version: 2012.0.2195 / Virus Database: 2437/5131 - Release Date: 07/14/12

--

[Vince Martin-Smith]

James,
what brand router are they using ? and how long have they been in
service ?

[James M Taylor]

Vince Wrote:

----- Original Message -----
Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 10:46:13 +1200
From: Vince Martin-Smith <vin...@tisec.co.nz>

 

something to keep in mind with diagnostics like this ... ping traffic is
first to get dropped especially around core nodes like nzgate and ape...
so dropped pings aren't necessarily indicative of a fault (as James Gray
mentioned).

Yes, I’m not worried about dropped pings, just the inconsistency between the two sites as they do a traceroute to my PC taking identical hops…

 

pings *should* pass through to other consumer addresses ok though as
that is client traffic so they try to deliver it - this will show up as
in a traceroute or mtr as failed hops if nodes are under heavy load.

This is a consistent difference in the trace at all times of the day.  I have tried this in the middle of the day, in the evening, on the weekend, at 2am, etc

 

What I would do it run an adaptive flood ping end to end... this loads
up every hop in the path with data and if there are any
mis-configurations in the core network this will show up.

(Try it from each end too as the return route is not necesarily the
same)

 

Occasionally dslams and the like get mis-configured and rather than
start throttling TCP data they just discard packets (not good especially
for terminal server - it doesn't like that). Under overload conditions,
again as James indicates, any datagram traffic (icmp/udp) can be shed as
there is no flow control protocol around that kind of data. TCP on the
other hand manages slow delivery reasonably well.

I've never looked for a flood-ping tool under Windoze but under Linux

you use ping -Afs1024 <destination node> That graphical ping included previously does the same but I have used linux servers on both ends as you suggested…

Every ping sent out draws a . and everyone that comes back erases one...
so to start with you get a row of .....s which should in theory all
disappear but the first once the buffers are loaded up through the
network. If you see frequent .s appearing then it's dropping more

traffic than it should. The drops (no losses) in the floods below aren’t significant and don’t appear to be the problem

Another thing... depending on what type of router you are using.. try
rebooting those at each end before re-running tests. (and check that the
errors you saw in the diagnostic display are not increasing as you watch
- once in a while you will often get one or two - but they should be few

and far between).  Cambrian has a fewer drops/sent than Amtec but it is suffering more than Amtec…

I have seen versions of firmware (even from the big guys) on routers
which have been running for some time - get all confused ... something
to do with internal garbage collect maybe. but they start intermittently
reporting errors and dropping packets. This can happen more frequently
the longer they have been running without restart. Restart and away it
goes for another few weeks.

A classic symptom of this is DNS starts intermittently misreporting
addresses as being non existent or times out frequently.

 

I did change the DNS in the ADSL router to Google (primary) & Xtra (Secondary) last night but still getting “dns query failed” errors.  Each – Mark -- is on the hour.

 

anyhow - my 2.3c worth.

Cheers
  Vince

 

p.s. If it does become too much of a problem then some form of
guaranteed service (aka CIR - committed information rate) is the answer
otherwise you'll always suffer from intermittent loading on public
networks (especially from the big telcos who always "over-sell" their
network capacity).

 

The main concern is that this network and terminal service access to a Hamilton server has been working fine for years for both Amtec and Cambrian up until a few weeks ago.  After testing for drop outs a few weekas ago and reporting to Maxim that we weren’t experiencing any, I got this on Friday…

 

From Maxim Support

Hi Robert and James, 

 

I have had our server hosting people look at the problem as reported by Robert. This is their finding:

 

"I have completed investigation the issue of disconnections for the one customer site.  At the times provided and across all user accounts I have reviewed the server error logs and there is no indication of mass disconnections, or any type of server or application error.  Given that the problem affects a single customer, with multiple users, at the same location, the next area to check is the customer Internet connection and looking for micro-outages.  This type of outage may show up as a break to connectionless applications such as Internet Explorer or local applications.

 

My opinion based on the notes provided, is that this is a site issue which only affects Internet applications. Internet explorer just connects instantly after a disconnection, Maxim will require re-authentication after a disconnection. The issue is the disconnection.  Given that this does not affect other Maxim users who use the same Internet connection and same servers, the problem has to be at their site or Internet based."

 

If you would like to speak to one of the engineers at our server hosting company then please let me know and I will give you a contact. 

--

Regards

 

Robert Skellern

 

Maxim Software

PO Box 1186, Rotorua, New Zealand

Ph Office: 64 7 350 1174, Fax: 64 7 350 1185, Mobile 027 4747 556

maximsoftware.co.nz, maximonline.co.nz 

 

Maxim is used via Terminal Services by many other companies who don’t seem to be experiencing these problems (and we didn’t for years), which prompts them to point their finger at our network.  I will restart the routers on both ends but I thought the Traceroute differences might point to a problem outside our network and I just couldn’t/can’t understand why or how the traces should be any different or what on our network could cause this???  It is like Telecoms Gateway has blacklisted Cambrian’s IP.

 

Flood pings…

AMTEC to CES-7750 (26102 packets transmitted, 26050 received):

[root@amtec-0 root]# ping -Afs1024 14.x.x.x

PING 14.x.x.x (14.x.x.x) 1024(1052) bytes of data.

....................................................

--- 14.x.x.x ping statistics ---

26102 packets transmitted, 26050 received, 0% packet loss, time 1652186ms

rtt min/avg/max/mdev = 58.228/63.274/1055.634/19.920 ms, pipe 7, ipg/ewma 63.299/61.460 ms

[root@amtec-0 root]#

 

CAMBRIAN to CES-7750 (25984 packets transmitted, 25949 received):

root@backup1:~# ping -Afs1024 14.x.x.x

PING 14.x.x.x (14.x.x.x) 1024(1052) bytes of data.

...................................

--- 14.x.x.x ping statistics ---

25984 packets transmitted, 25949 received, 0% packet loss, time 1627609ms

rtt min/avg/max/mdev = 56.352/62.366/245.262/8.884 ms, pipe 6, ipg/ewma 62.641/59.878 ms

 

AMTEC to CAMBRIAN (VPN) (10134 packets transmitted, 10132 received):

[root@amtec-0 root]# ping -Afs1024 192.168.1.4

PING 192.168.1.4 (192.168.1.4) 1024(1052) bytes of data.

..

--- 192.168.1.4 ping statistics ---

10134 packets transmitted, 10132 received, 0% packet loss, time 365737ms

rtt min/avg/max/mdev = 30.828/35.895/83.248/5.733 ms, pipe 4, ipg/ewma 36.093/34.411 ms

 

CAMBRIAN to AMTEC (VPN) (7092 packets transmitted, 7088 received):

root@backup1:~# ping -Afs1024 192.168.0.4

PING 192.168.0.4 (192.168.0.4) 1024(1052) bytes of data.

....

--- 192.168.0.4 ping statistics ---

7092 packets transmitted, 7088 received, 0% packet loss, time 257368ms

rtt min/avg/max/mdev = 31.106/35.973/84.284/2.865 ms, pipe 4, ipg/ewma 36.295/35.699 ms

 

Amtec to CES-7750

 

Cambrian to CES-7750

 

Amtec to CES-7750

 

Cambrian to CES-7750

 

Amtec to CES-7750

 

Cambrian to CES-7750

 

Amtec to CES-7750

[root@amtec-0 root]# traceroute 14.x.x.x

traceroute to 14.x.x.x (14.x.x.x), 30 hops max, 38 byte packets

 1  192.168.0.1 (192.168.0.1)  0.737 ms  0.517 ms  0.479 ms

 2  192.168.10.1 (192.168.10.1)  1.185 ms  1.092 ms  1.068 ms

 3  125-239-240-1.jetstream.xtra.co.nz (125.239.240.1)  11.744 ms  10.236 ms  11.051 ms

 4  * mdr-fid-dom.akcr10.global-gateway.net.nz (202.50.238.50)  16.481 ms  1143.329 ms

 5  ae4-20.akcr10.global-gateway.net.nz (202.50.238.49)  14.863 ms  14.847 ms  21.294 ms

 6  link-telecom-dom.akcr10.global-gateway.net.nz (122.56.118.102)  15.744 ms  15.466 ms  15.721 ms

 7  202.169.192.8 (202.169.192.8)  16.687 ms  16.115 ms  16.883 ms

 8  202.169.192.212 (202.169.192.212)  18.119 ms  15.794 ms  15.947 ms

 9  * * *

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

 

Cambrian to CES-7750

root@backup1:~# traceroute 14.x.x.x

traceroute to 14.x.x.x (14.x.x.x), 30 hops max, 52 byte packets

 1  gw (192.168.1.1)  0.903 ms  0.797 ms  0.478 ms

 2  192.168.11.1 (192.168.11.1)  1.782 ms  1.543 ms  1.766 ms

 3  125-239-240-1.jetstream.xtra.co.nz (125.239.240.1)  26.486 ms  12.905 ms  14.060 ms

 4  mdr-fid-dom.akcr10.global-gateway.net.nz (202.50.238.50)  1143.018 ms  1201.348 ms  1205.462 ms

 5  ae4-20.akcr10.global-gateway.net.nz (202.50.238.49)  47.709 ms  20.451 ms  19.655 ms

 6  link-telecom-dom.akcr10.global-gateway.net.nz (122.56.118.102)  20.396 ms  19.457 ms  19.624 ms

 7  202.169.192.8 (202.169.192.8)  20.914 ms  19.838 ms  21.880 ms

 8  202.169.192.212 (202.169.192.212)  18.499 ms  19.576 ms  21.695 ms

 9  * * *

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

 

 

 

----- Original Message -----
Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 10:46:13 +1200
From: Vince Martin-Smith <vin...@tisec.co.nz>

> Perhaps an upgrade to a business class connection like VDSL would be
> of benefit to them.
>
> 
>
> Regards,
>
> 
>
> Matthew Harrison
>
> Managing Director
>
> PrimoWireless
>
> www.primowireless.co.nz
>

--

Vince Martin-Smith
Director
TISEC Limited
1548 Carrington Rd
RD1
New Plymouth
ph: +64 6 824 8113
mo: +64 21 0232 6846
skype: vincemartinsmith

--

[Damien]

VoIP type services tend to be UDP so they handle dodgy connections a lot better than TCP.

[Vince Martin-Smith]

Hm... well those flood ping tests look pretty clean. They normally show
up DSLAM or WAN hardware errors and a whole raft of other issues.

There may be other stuff we can look at... I'll have a think.


We should probably take this off-group rather than flooding the mailing
list ?

> AMTEC to CES-7750(26102 packets transmitted, 26050 received):

>
> [root@amtec-0 root]# ping -Afs1024 14.x.x.x
>

> PING14.x.x.x (14.x.x.x) 1024(1052) bytes of data.

>
> ....................................................
>
> --- 14.x.x.x ping statistics ---
>
> 26102 packets transmitted, 26050 received, 0% packet loss, time
> 1652186ms
>
> rtt min/avg/max/mdev = 58.228/63.274/1055.634/19.920 ms, pipe 7,
> ipg/ewma 63.299/61.460 ms
>
> [root@amtec-0 root]#
>
>
>

> CAMBRIAN to CES-7750(25984 packets transmitted, 25949 received):

>
> root@backup1:~# ping -Afs1024 14.x.x.x
>

> PING14.x.x.x (14.x.x.x) 1024(1052) bytes of data.

>
> ...................................
>
> --- 14.x.x.x ping statistics ---
>
> 25984 packets transmitted, 25949 received, 0% packet loss, time
> 1627609ms
>
> rtt min/avg/max/mdev = 56.352/62.366/245.262/8.884 ms, pipe 6,
> ipg/ewma 62.641/59.878 ms
>
>
>

> AMTEC to CAMBRIAN (VPN)(10134 packets transmitted, 10132 received):

>
> [root@amtec-0 root]# ping -Afs1024 192.168.1.4
>

> PING192.168.1.4 (192.168.1.4) 1024(1052) bytes of data.

>
> ..
>
> --- 192.168.1.4 ping statistics ---
>
> 10134 packets transmitted, 10132 received, 0% packet loss, time
> 365737ms
>
> rtt min/avg/max/mdev = 30.828/35.895/83.248/5.733 ms, pipe 4, ipg/ewma
> 36.093/34.411 ms
>
>
>

> CAMBRIAN to AMTEC (VPN)(7092 packets transmitted, 7088 received):

>
> root@backup1:~# ping -Afs1024 192.168.0.4
>

> PING192.168.0.4 (192.168.0.4) 1024(1052) bytes of data.

>
> ....
>
> --- 192.168.0.4 ping statistics ---
>
> 7092 packets transmitted, 7088 received, 0% packet loss, time 257368ms
>
> rtt min/avg/max/mdev = 31.106/35.973/84.284/2.865 ms, pipe 4, ipg/ewma
> 36.295/35.699 ms
>
>
>
> Amtec to CES-7750
>
>
>
>
>

> Cambrian to CES-7750
>
>
>
>
>
> Amtec to CES-7750
>
>
>
>
>
> Cambrian to CES-7750
>
>
>
>
>
> Amtec to CES-7750
>
>
>
>
>
> Cambrian to CES-7750

[James M Taylor]

Simplified diagram

Amtec (Bellblock)

Linux                     Gigabit                   Linksys                      D-Link                                               To Hamilton

Server                     Switch                    WRT54G                   DSL-G804V              Internet          Terminal Server

 

                                                192.168.0.1                 192.168.10.1

 

 

 

 

 

 

PC(s)                                    VPN Tunnel

                                                 10.8.0.x

 

 

Cambrian (Vogeltown)

 

After restarting Both the D-Link & Linlsys Routers at both ends, I still have the bad trace from Cambrian only…

 

 

Best Regards

James Taylor

Computer & Electronic Service 
(  +64 6 753-2616 or 021 043-5212
2 Fax +64 6 753-2616
63A Ballance Street, Vogeltown, NEW PLYMOUTH 4310, NZ
* Email j...@cesnz.co.nz
7 Web www.cesnz.co.nz

The above message was sent to you as a customer, friend or associate.  Any pricing discussed excludes Freight and GST unless otherwise stated.  To be removed from this mailing, please click reply  and put "REMOVE" as the subject

P Please consider the environment before printing this e-mail.

 

----- Original Message -----

Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 16:08:40 +1200
From: Vince Martin-Smith <vin...@tisec.co.nz>

James,

  what brand router are they using ? and how long have they been in

service ?

 

 On Sun, 2012-07-15 at 14:15 +1200, James M Taylor wrote:
> This has been working fine for years, just started the regular
> disconnections within the last few weeks.  It could be coincidental
> that Amtec suffered a few disconnections while Cambrian was/is getting
> constant disconnections and may not be related.  Since it is the more
> serious problem on Cambrian and the only significant thing I could
> find was the losses/delays via the Telecom Gateway (202.50.238.50)
> that seems to only appear when access something over the internet from

> Cambrian, then the question is “How and why does 202.50.238.50 seem to
> stop responding only from Cambrian when accessing the internet?”

>
> 
>
> 
>
> Best Regards
>
>
> James Taylor
>
> Computer & Electronic Service
> (  +64 6 753-2616 or 021 043-5212
> 2 Fax +64 6 753-2616
> 63A Ballance Street, Vogeltown, NEW PLYMOUTH 4310, NZ
> * Email j...@cesnz.co.nz
> 7 Web www.cesnz.co.nz
>
> The above message was sent to you as a customer, friend or associate.
> Any pricing discussed excludes Freight and GST unless otherwise
> stated.  To be removed from this mailing, please click reply  and put
> "REMOVE" as the subject
>
> P Please consider the environment before printing this e-mail.
>
> 
>
> 
>

> ----- Original Message -----
> Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway
> Infrastructure at 202.50.238.50 that does not like my clients network
>

> Date: Sun, 15 Jul 2012 10:01:30 +1200
> From: "Matthew Harrison" <mat...@primowireless.co.nz>
>

> Perhaps an upgrade to a business class connection like VDSL would be
> of
> benefit to them.
>
>  
>
> Regards,
>
>  
>
> Matthew Harrison
>
> Managing Director
>
> PrimoWireless
>

> www.primowireless.co.nz <http://www.primowireless.co.nz/>

> phone:          +64-9-355-4052 <tel:%2B64-9-355-4052>

> <mailto:taranaki-linux-users-group%2Bunsu...@googlegroups.com> .

[James M Taylor]

Cheers Vince, what is your home email address (vin...@tisec.co.nz)?  I’m j...@world-net.co.nz.

----- Original Message -----
Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 17:35:00 +1200
From: Vince Martin-Smith <vin...@tisec.co.nz>

Hm... well those flood ping tests look pretty clean. They normally show

up DSLAM or WAN hardware errors and a whole raft of other issues.

There may be other stuff we can look at... I'll have a think.

 

We should probably take this off-group rather than flooding the mailing

list  ?

On Sun, 2012-07-15 at 16:31 +1200, James M Taylor wrote:

> Vince Wrote:
>
> ----- Original Message -----
> Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway
> Infrastructure at 202.50.238.50 that does not like my clients network
>

> Date: Sun, 15 Jul 2012 10:46:13 +1200
> From: Vince Martin-Smith <vin...@tisec.co.nz>
>
> 
>

> ----- Original Message -----
> Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway
> Infrastructure at 202.50.238.50 that does not like my clients network
>

> Date: Sun, 15 Jul 2012 10:46:13 +1200
> From: Vince Martin-Smith <vin...@tisec.co.nz>
>

[James M Taylor]

Thanks Damien.

----- Original Message -----
Subject: Re: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 17:31:37 +1200
From: Damien <spide...@gmail.com>

VoIP type services tend to be UDP so they handle dodgy connections a lot
better than TCP.

On Jul 15, 2012 2:06 PM, "James M Taylor" <j...@world-net.co.nz> wrote:

> ** ** ** **
>
> Thanks James,****
>
> ** **

>
> Primo can’t supply the point to point between Amtec & Cambrian but that
> does not appear to be the problem.  They are running their phone system
> thru the VPN and it is operating well, it is just their subscription to the

> ****Hamilton**** outfit that seems to be affected.  I’m sure that their

> regular internet browsing, etc are also having delays but aren’t dropping

> out before retrying.  The query is “Why does 202.50.238.50 seem to stop
> responding only from Cambrian when access the internet?”****
>
> ** **
>
>  ****
>
> *Best Regards*
>
> *
> **James Taylor*****
>
> *Computer & Electronic Service *
> (* * +64 6 753-2616 or 021 043-5212
> 2* Fax* +64 6 753-2616
> 63A ****Ballance Street****, Vogeltown, NEW ****PLYMOUTH**** 4310, NZ
> ** Email **j...@cesnz.co.nz*
> 7* **Web** **www.cesnz.co.nz*****
>
> *The above message was sent to you as a customer, friend or associate.  **Any
> pricing discussed excludes Freight and GST unless otherwise stated.  **To

> be removed from this mailing, please click reply  and put "REMOVE" as the

> subject***
>
> *P **Please consider the environment before printing this e-mail.*
>
> ** **

>
> ----- Original Message -----
> Subject: Re: Help, Seems to be a faulty Telecom Global-Gateway
> Infrastructure at 202.50.238.50 that does not like my clients network****
>
> Date: Sun, 15 Jul 2012 07:22:35 +0930

> From: James Gray <jame...@gmail.com> ****

>
> Nodes on the internet drop packets all the time if they're overloaded. The
> type of service you're using is a best effort service, have you considered
> telecom oneoffice? Alternatively, primo wireless offers point to point
> data, though I'm not sure cambrian is in their coverage area

> On 14/07/2012 5:53 PM, "James M Taylor" <j...@world-net.co.nz> wrote: ****
>
> > ** ** ** **
> >

> > Thought I’d throw this out to the user group to see if I need to go

> > completely bald or bonkers…****
> >
> > ** **

> >
> > I have a client that runs an accounting package (Maxim) from New Plymouth

> > to a Terminal Server in ****Hamilton****.  They run the package from two

> > companies in New Plymouth (Cambrian and Amtec) 15km apart on two
> different
> > broadband connections (both with telecom Xtra).  There is likely about 15
> > users on the package all day at Cambrian and maybe ½ dozen on part time
> at
> > the Amtec.  Over the last few weeks, they have experienced a lot of
> > disconnected RDP sessions at Cambrian and occasional ones at Amtec.  I
> > started performing some tests to see if there were any drop outs of the
> > internet, dropped packets, significant errors, etc.  Satisfied that the
> > ADSL routers at both ends have never dropped their connections, the
> errors
> > appear to be small on Cambrian and though Larger on Amtec, it is
> > experiencing as many disconnects and no failures through Telecoms
> Gateway.

> > ****
> >
> > ** **

> >
> > I have run some test using Look@LAN (now OutlookFing – can’t seem to
> > download Look@LAN anymore – let me know if anyone needs a copy) which
> > allows me to connect to, scan and do a graphical ping on other PCs on the
> > network and across Internet.  Amtec and Cambrian are connected to each
> > other via VPN across the internet.  I used 5 PCs in the test (P4
> > (192.168.1.4) and Surfcam (192.168.1.127) at Cambrian, DFE-4
> (192.168.0.4)
> > and DFE-7W (192.168.0.157)  at Amtec and CES-7750 (14.x.x.x) at my
> office).
> >  This allows me to test throughput on the same LAN, through the internet

> > and through the internet via VPN (More overhead).****
> >
> > ** **
> >
> > *Excerpt from Report that I’m doing for the client* (only a few of the
> > tests are included below).****
> >

> > While performing the ****Trace Route**** tests further down, one of

> Telecoms
> > Global-Gateway Infrastructure (Switch IP 202.50.238.50) started faulting
> > intermittently.  Even though the connection between Cambrian and Amtec is
> > via the internet, a VPN tunnel connection has already been established
> > which makes it appear to be only 2 hops between the two but it will also
> > likely have 8 or more hops hidden by the tunnel.  The fact that it is a
> > constant connection could easily mean the 202.50.238.50 was not in the
> > mix when the connection was first established.  202.50.238.50 has the
> > significant delay throughout all the tests but started failing altogether
> > or for lengthy periods while testing from Cambrian (P4 and Surfcam).
> This
> > could be the source of the problem for Cambrian.  The VPN tunnel 10.8.0.x
> > is also suffering delays and is likely using the 202.50.238.50 Gateway.

> **
> > **
> >
> > ** **

> >
> > What can make a Telecom Gateway treat one client different than others?
> >  Could it be something on the local network that makes a gateway 4 hops

> > away act the way it does in the tests below?****
> >
> > ** **
> > *IP Address Lookup - Whois by IP Address :
> > 202.50.238.50*
> >
> > ** **
> >
> >                                          [Querying whois.apnic.net]****
> >
> > [whois.apnic.net]****
> >
> > % [whois.apnic.net node-3]****
> >

> > % Whois data copyright terms

> > After performing the above test and noticing there *seems to be a faulty
> > Telecom Global-Gateway Infrastructure at 202.50.238.50*, ****

> >
> > I re-tested the Trace route to CES-7750 from both Amtec’s DFE-4 and
> > Cambrian’s Surfcam simultaneously and 202.50.238.50 appears to only be

> > failing when Cambrian uses it???****
> >
> > ** **

> >
> > To see if this is specific to Cambrian only, I remoted into yet another

> > client who uses Xtra and tested from one of their PCs to my PC.****
> >
> > ** **
> >
> > Amtec’s DFE-4 to CES-7750 (My PC) Graphical Ping:****
> >
> > ****
> >
> > ** **
> >
> > SURFCAM to CES-7750 Graphical Ping (8 Hops)****
> >
> > ****
> >
> > ** **

> >
> > HospitalPC at Maida Vale to CES-7750 Graphical Ping (8 Hops): Sorry,
> > Look@LAN comes in English and Italian, it sometimes looses its language

> > setting and needs a registry setting or re-installing to set it back…****
> >
> > ****
> >
> > ** **
> >
> > Amtec’s DFE-4 to CES-7750 (My PC) Traceroute: *the 4th
> hop202.50.238.50is good, the 6

> > th has a good average but has a max that is 63ms*
> >
> > ****
> >
> > ** **
> >

> > Surfcam to CES-7750 Traceroute: *the 4th hop202.50.238.50 fails, the
> 5ththru 8

> > th have good averages but some high maximums*****
> >
> > ****
> >
> > ** **
> >
> > HospitalPC at Maida Vale to CES-7750 Traceroute (8 Hops):****
> >
> > ****
> >
> > ** **
> >
> > Amtec’s DFE-4 to CES-7750 (My PC) Graphical Traceroute:****
> >
> > ****
> >
> > ** **
> >
> > Surfcam to CES-7750 Graphical Traceroute:****
> >
> > ****
> >
> > ** **
> >
> > HospitalPC at Maida Vale to CES-7750 Graphical Traceroute (8 Hops):****
> >
> > ****
> >
> > ** **
> >
> > ** **
> >
> > Amtec’s ADSL has been up for 61 & ½ days…****
> >
> > *Amtec ADSL:*
> >
> > ****
> >
> > ** **
> >

> > It has pumped a lot of data thru but with some errors.  They are low

> > proportionally but more than Cambrian’s line…****
> >
> > *Traffic Statistics*
> >

> > *PPPoA Routed*VPI / VCI: 0 / 100              Rx:         622,831,793/
> 111

> > ****
> >
> > Tx:          522,439,216/ 342,243****
> >
> > *Ethernet Connection*                                Rx :
> > 532,203,801/ 80138****
> >
> > Tx :         629,589,041/ 0****
> >
> > *Wireless Connection*                                Rx :
> >            2,644/ 0****
> >
> > Tx :                    7148/ 0****
> >
> > ** **
> >
> > ** **
> >
> > *Cambrian ADSL Info & Statistics*
> >
> > Cambrian’s ADSL has been up for 169 days…****
> >
> > ** **
> >
> > ****
> >
> > ** **
> >
> > ****
> >
> > ** **
> >
> > ****
> >
> > ** **
> >
> > ****
> >
> > ** **
> >
> > ****
> >
> > ** **
> >

> > Because of the errors below, I have since disabled the DNS server in both

> > ADSL routers and fixed them to:****
> >
> > ****
> >
> > ** **
> >
> > ****
> >
> > …****
> >
> > ****
> >
> > ** **
> >
> > *Amtec:*
> >
> > ****
> >
> > ** **
> >
> > *Cambrian:*
> >
> > ****
> >
> > ** **
> >
> > ** **
> >
> > ** **
> >

> > --
> > You received this message because you are subscribed to the Google Groups
> > "Taranaki Linux Users Group" group.
> > To post to this group, send email to
> > taranaki-linu...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > taranaki-linux-user...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/taranaki-linux-users-group?hl=en.

> > ****

>
> --
> You received this message because you are subscribed to the Google Groups
> "Taranaki Linux Users Group" group.
> To post to this group, send email to
> taranaki-linu...@googlegroups.com.
> To unsubscribe from this group, send email to
> taranaki-linux-user...@googlegroups.com.
> For more options, visit this group at

> http://groups.google.com/group/taranaki-linux-users-group?hl=en. ****
>
> ** **

>
> --
> You received this message because you are subscribed to the Google Groups
> "Taranaki Linux Users Group" group.
> To post to this group, send email to
> taranaki-linu...@googlegroups.com.
> To unsubscribe from this group, send email to
> taranaki-linux-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/taranaki-linux-users-group?hl=en.
>

[Vince Martin-Smith]

ok regarding the bad trace you mentioned at global gateway - step 4 in the trace is nothing to worry about. That was what I was alluding to earlier - traceroute simply sends pings with TTLs set for each step in the path - problem is Global Gateway drop a high percentage of pings on all their core nodes. If a ping is not for them they try to pass them through just fine... but don't rely on their nodes replying.

Note the green either side of the global internal hops - indicates a clean link - it's just the nodes in the middle ignoring you.


The WRT54G is just one such router I've seen do weird stuff when they get a bit long in the tooth or start running hot.

I strongly suggest you swap out at least one of them before spending too much more time on trying to find the problem. They tend to go in batches too. When they start to go bad (usually due to bad cap syndrome) they start really messing with ones head - they just do strange stuff.

For the cost of a TP link AP or such like (even a new one of the same model) it's worth isolating it as a probably cause.



To clarify - the network topography too... is the WRT really in-line between the router and the GB switch ? or is that just how it's drawn ?

If so I'd be looking seriously at hooking the wireless either directly to the switch OR to the router but not be piggy in the middle.



Another question are any of the workstations experiencing problems on the other end of the wifi ?  (just looking for patterns).





Something that might show up a problem is running an extended flood-ping to the TD8840 or G804V
I've seen a couple of instances where if you keep the router busy for a bit then it starts to falter... again to do with heat.

[James M Taylor]

Hi Vince, I’ve just requested a skype contact exchange with you.  Can I ring you or you ring me (753-2616) when you are not busy or watching the news or something important.

 

 

Best Regards

James Taylor

Computer & Electronic Service 
(  +64 6 753-2616 or 021 043-5212
2 Fax +64 6 753-2616
63A Ballance Street, Vogeltown, NEW PLYMOUTH 4310, NZ
* Email j...@cesnz.co.nz
7 Web www.cesnz.co.nz

The above message was sent to you as a customer, friend or associate.  Any pricing discussed excludes Freight and GST unless otherwise stated.  To be removed from this mailing, please click reply  and put "REMOVE" as the subject

P Please consider the environment before printing this e-mail.

 

----- Original Message -----
Subject: RE: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 18:02:16 +1200
From: Vince Martin-Smith <vin...@tisec.co.nz>

ok regarding the bad trace you mentioned at global gateway - step 4 in

 192.168.0.1                 192.168.10.1

>
>
>
>
>
>
>
>
>
>
>
> 
>
>
>
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
> PC(s)                                    VPN Tunnel
>
>                                                  10.8.0.x
>
>
>
> 
>
> 
>
> Cambrian (Vogeltown)

>
>
>
> 
>
> After restarting Both the D-Link & Linlsys Routers at both ends, I
> still have the bad trace from Cambrian only…
>
>
>
> 
>
> 
>

[James M Taylor]

The WRT54G was mainly chosen to be able to Flash it’s firmware with “Tomato” for more control over QOS, key exchange, etc.  This has given us optimized voice clarity on VoIP.

 

Simplified diagram

Amtec (Bellblock)

Linux                     Gigabit                   Linksys                      D-Link                                               To Hamilton

Server                     Switch                    WRT54G                   DSL-G804V              Internet          Terminal Server

 

                                            192.168.0.1                 192.168.10.1

 

               MyPBX

                                                   10.0.0.1

 

 

PC(s)           Phones                                         VPN Tunnel (to Cambrian and 2 other companies)

                                                               10.8.0.x           (Phones mainly but also networking)

 

 

 

 

 

 

Cambrian (Vogeltown)

Almost the same as above

 

 

 

 

[David Apimerika]

I have a couple of these, if you needed to test.

Sorry, I haven't been able to add to this discussion. Looks like Vince and Damien have the nounce at this stage. I'm not in much mood to think too hard at the mo.

Happy if you want to keep discussing here.

David Apimerika

Phone: 0-6-7579119

Mobile: 0274 579229

木魚

[James M Taylor]

Thanks David, I’ll let you know.  I’ll have a discussion with Vince tomorrow after work.

----- Original Message -----
Subject: Re: Help, Seems to be a faulty Telecom Global-Gateway Infrastructure at 202.50.238.50 that does not like my clients network

Date: Sun, 15 Jul 2012 21:05:25 +1200
From: David Apimerika <david.a...@gmail.com>

I have a couple of these, if you needed to test.

Sorry, I haven't been able to add to this discussion. Looks like Vince and Damien have the nounce at this stage. I'm not in much mood to think too hard at the mo.

Happy if you want to keep discussing here.

 

David Apimerika
Phone: 0-6-7579119
Mobile: 0274 579229

木éš

 

On 15/07/2012, at 7:47 PM, James M Taylor wrote:

> The WRT54G was mainly chosen to be able to Flash it’s firmware with “Tomato†for more control over QOS, key exchange, etc.  This has given us optimized voice clarity on VoIP.