Common Internet (WAN) environment issues solved through Reckon Community Support
Options
gazza73
Accredited Partner Posts: 803 
Accredited Partner
Accredited Partner
For HOSTED or Reckon ONE potential or existing users, your WAN
performance has a significant impact on your Accounting
experience. But desktop users who link to Cloud based online services such as banking or send orders/invoice/report by email, they too can be affected by their WAN (Wide Area Network) setup.
Our research and contributions to this forum, have identified WAN conflicts as another of the leading causes of the 90% of problems that are not RECKON related.
(source: statistics from ABS research tabled 16/6/15)
Capacity, interference, bottlenecks and the other end of the WAN!
Running programs that are located on a Cloud (a hosted service, or "software as a service" located in some Data Centre) requires a connection between your location and the internet in the first place. Everybody has their own choice of an internet service provider (ISP) which comes in the form of a CONTRACT with some HARDWARE (a modem, router or equivalent). The concept is the same whether it be the historical days of a dial-up service, a wireless link (external wireless that is), satellite in remote/rural locations, or the more typical CABLE, ADSL or now NBN as it roles out in Australia. Irrespective of the medium used, the connection relies on ethernet protocols which allow you to transmit DATA to and from some TARGET location. Consider the example of a laptop running wirelessly (INTERNALLY) to a ROUTER in the office, which is on some ADSL connection (modem) linked to your local telephone exchange. That is the start of the journey.
What we've described so far, is akin to taking a car trip, but first, you need a vehicle, and you need to get it started and out of the garage, and into your local street. Nobody's travelled far yet, but the engine is running.
The internet is just a huge series of connection points, each with their own unique identifier. For years this has been an IPv4 address in the form: aaa.bbb.ccc.ddd. As a user, you have some computer which will have a LAN IP address like 192.168.xxx.xxx or 10.xxx.xxx.xxx. These are reserved private IP addresses for LAN usage. But let's push on with the travel analogy.
Reaching your target location, will require you to traverse a number of intersections, and those intersections can slow you down if there is a traffic jam. The more intersections, the longer the journey will take, and the more risk of delay there will be. Don't we all wish fast highways were free of other traffic and crossroads, to reach our journey's destination (and back again) nice and fast.
Target locations rely on their connections too.
Gaining access to the private information, service, database, file, website or whatever purpose you are travelling the internet for, is also dependent upon the capacity, speed and quality of connection that the TARGET SITE uses for THEIR ISP contract/connection. Time for a pertinent example. Logging into Reckon HOSTED, located at the Amazon Data Centre in Sydney, is done by a user BROWSING to the following login page: https://hosted.reckon.com/RAHV2/ReckonAccountsLogon.aspx
hosted.reckon.com is a SERVER in Sydney located on IP: 52.65.91.115 - that is the initial TARGET location users need to reach, in order to LOG IN.
Here's an example of the JOURNEY (the 12 hops needed), for a humble Telstra Bigpond connection from the suburbs of Melbourne, that will occur up to the local ISP, then to Amazon's ISP, and finally to the target location. For security, the final hop is not directly pingable (a term that relates to seeking a response from an known device on the internet). The journey begins from the local ROUTER/FIREWALL on IP: 192.168.202.1. That is the internet private, physical address of the firewall server nicknamed: gw.lan (which means gateway of the LAN). The local journey outside the office then goes via the local telephone exchange in this example (hops 2 and 3), and into the main BIGPOND nerve centre in Melbourne at hop:5. From there, it bridges over to Sydney at hop:6 and out their back door to a dedicated link for AMAZON at hop: 8. So far it's a bit like driving a car up the Hume freeway isn't it? Provided there's no traffic jams, then the overall time to reach each successive point, further and further way, is showing the time in 1/1000th of a second (ms: milliseconds). Nearly there now. AMAZON has some of its own equipment in its major DATA CENTRE at hops 9, 10 and 11, and our destination can be assumed reached at hop 12.
Remember, the journey back to the office again, will require coming back along a similar path - not always the same, just as there are many lanes on the road or shortcuts attempted in road travel, so to does the internet follow efficient routes too. But the overall round trip could be something like 24 overall hops there and back.
gaz@absvenom:~$ traceroute hosted.reckon.com
traceroute to hosted.reckon.com (52.65.91.115), 30 hops max, 60 byte packets
1 gw.lan (192.168.202.1) 0.175 ms 0.189 ms 0.216 ms
2 172.18.211.23 (172.18.211.23) 25.816 ms 25.829 ms 26.185 ms
3 172.18.95.5 (172.18.95.5) 26.405 ms 27.045 ms 172.18.95.1 (172.18.95.1) 27.277 ms
4 bundle-ether4.win-edge902.melbourne.telstra.net (203.50.76.8) 28.690 ms 29.935 ms
31.316 ms
5 bundle-ether12.win-core10.melbourne.telstra.net (203.50.11.111) 33.283 ms 36.843 ms
35.190 ms
6 bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122) 50.810 ms 50.333 ms
51.332 ms
7 bundle-ether1.ken-edge901.sydney.telstra.net (203.50.11.95) 51.375 ms 35.094 ms
36.063 ms
8 ama1663225.lnk.telstra.net (165.228.50.190) 33.766 ms 35.388 ms 36.311 ms
9 52.95.36.64 (52.95.36.64) 39.763 ms 40.208 ms 52.95.36.112 (52.95.36.112) 41.696 ms
10 52.95.36.89 (52.95.36.89) 43.132 ms 52.95.36.57 (52.95.36.57) 43.643 ms 52.95.36.105
(52.95.36.105) 44.644 ms
11 54.240.192.107 (54.240.192.107) 47.619 ms 51.749 ms 50.064 ms
12 * * * (target reached, but silent echo)
Hops and risks
As seen in the above example, there are hops from you to your ISP, then over to THEIR ISP and down to them, and all the way back again. The overall performance is a combination of having:
Your LAN performance is also dependent on WAN performance
All the network devices in your office, and those remotely connected to servers via your office, all rely on LAN (Local Area Network) capacity, but when waiting on data coming from the WAN, then that can delay the final experience see on your LAN. An earlier article explains how devices and programs/systems running on your LAN are impacted by LAN performance.
See: https://community.reckon.com/reckon/topics/common-network-lan-environment-issues-solved-through-reckon-community-support
From that article it is important to reiterate a point. The two combined (LAN plus WAN) need to work together, in terms of CAPACITY and RULES. RULES are protocol restrictions, firewall settings, operating system permissions, and tailored settings determining the PORT (a dedicated pathway if you like) that such traffic will traverse, and is EXPECTED to traverse. RULES can change with the unscheduled arrival or deployment of system updates or addition of other software, features to your overall system - being the servers as well as your workstation.
Impact on Applications
Back to the RECKON HOSTED application example. Entering data and waiting for the screen to respond, will be impacted by the time it takes for DATA to traverse up along those HOPS and back again with the results. But at the same time, other users within your office, using the same initial WAN links, sharing the same capacity and operating concurrently, will also impact the response time of one another.
From the mentioned LAN article: There are any number of SYSTEM activities, like virus checking, anti-spam checking, malware detection, device polling (like printers being checked for online status). Behind the scenes, operating systems are forever checking the status of TIME, their network connection status, fetching remote DATA... the list is endless. And that is when the ENVIRONMENT is finely tuned and setup well.
Patience is TIMEOUT (the system's not just yours!)
When a program attempts to link up to some other service, over the WAN, and determines it has been trying to do so for long enough, it reaches a TIMEOUT setting whereby it effectively runs out of patience. It then leaves the User confronted with some error message or worse, just a screen that seems to have failed to progress to the next step.
What can cause the WAN connection to impact ACCOUNTING
Congestion at any one of the HOPS traversed, is one area to consider. Take those busy times when 10's of 1000's of users all try to reach information on the internet at the same time.
Examples include the day when sales of highly popular tickets for an event go on sale, or results of schooling are online for access, or more relevant, your BAS is due TODAY. If all that activity is stressing out the capacity of a device, service or connection point that you have traverse or reach as one of your HOPS in your journey, then you will join that data traffic jam along with all the others.
There can be unscheduled outages of equipment that is part of the route (journey). At the time of writing this article the Weather Bureau was off the air for all their domestic data.
(ie: http://www.smh.com.au/environment/weather/australia-left-in-the-dark-as-bureau-of-meteorologys-weather-data-fails-20160107-gm1lcl.html).
But the above 12 HOP example, and consider the impact if any one of those 12 hops was not running today. It would be akin to there being a road closure along the HUME Highway - we'd all have to stop and wait.
TIP for checking your WAN status
It is always a good idea to take a different look at the situation. When unable to reach a target destination, don't immediately worry about thinking the problem is at your end and start pulling hardware and software apart. Best to have a record of something you know is independent, reliable and usually not too busy, and use that as a reference point. For many years with a fleet of Subaru's in the business it was interesting to see the status of their offering.
With due respect, www.subaru.com usually doesn't suffer high's and lows of activity. You can pick your own idea on this. But pick a website, it's IP and use that as a litmus tests of whether you can see that page, ping that IP or traceroute to that target location. Do this when the system is behaving normally, and note the results (cut/paste into an email to yourself for later referral).
When failing to reach a favoured target service on the WAN, rerun that test again, to see how far you can traceroute towards that target. If you can't get past your own internal ROUTER, then the problem is likely at your end, in the office. If you can traceroute beyond your ISP, then the problem is most likely on the WAN somewhere beyond your office location, or at the tail end target you are trying to reach. The chances of your TEST site being off the air at the same time as your failing target as well, that is most unlikely. (Be sure your TEST is to a location geographically different from the main sites/services you need to use).
Have someone else ping/traceroute or attempt reaching the website or login service that you are having trouble with., If they can, and you can't, and the above test worked well, then the chances are, that there is a failure somewhere long the series of HOPS that are peculiar to the failing target. Again, having a permanent record of what that route/path looks like when working, is a great diagnostic for determining what action to take for a solution.
So think about the driving analogy above. The cause of a problem might not be you, your computer, your software or your operational techniques. There is the other end of the piece of string (WAN and LAN) and all the other travelers on board the WAN being travelled (and your LAN).
IT and ENVIRONMENT support to fellow AP's and their clients
Alchester is an independent IT consulting firm, with focus on Business Systems analysis, project management and internal cost accounting management from a business and IT perspective.
Solutions based on integrating complimentary proven technologies introduced from bona fide software developers to improve business efficiencies, is well complimented by ABS' 40 years background experience in the Accounting industry with an astute awareness of the needs of fellow AP's who focus on Accounting and Bookkeeping for their clients.
Enjoy!
Gary Pope
m: 0408994799
e: gaz@alchester.com.au
An Accredited Partner- Consultant (VIC. Aust)
http://www.alchester.com.au/reckon-ac...
"Working with Accountants/Bookkeepers PPs/APs, as an
independent IT Professional and retired FCPA Accountant"
PS: refer to related support tips at:
Common (LAN) environment tips:
https://community.reckon.com/reckon/topics/common-network-lan-environment-issues-solved-through-reck...
SYSTEM ENVIRONMENT solutions provided by Reckon Community Helphttps://community.reckon.com/reckon/topics/system-environment-solutions-provided-by-reckon-community...
and 6 ways on improving usage of the Community FORUM
https://community.reckon.com/reckon/topics/6-ways-to-gain-best-reckon-community-support-around-the-c...
performance has a significant impact on your Accounting
experience. But desktop users who link to Cloud based online services such as banking or send orders/invoice/report by email, they too can be affected by their WAN (Wide Area Network) setup.
Our research and contributions to this forum, have identified WAN conflicts as another of the leading causes of the 90% of problems that are not RECKON related.
(source: statistics from ABS research tabled 16/6/15)
Capacity, interference, bottlenecks and the other end of the WAN!
Running programs that are located on a Cloud (a hosted service, or "software as a service" located in some Data Centre) requires a connection between your location and the internet in the first place. Everybody has their own choice of an internet service provider (ISP) which comes in the form of a CONTRACT with some HARDWARE (a modem, router or equivalent). The concept is the same whether it be the historical days of a dial-up service, a wireless link (external wireless that is), satellite in remote/rural locations, or the more typical CABLE, ADSL or now NBN as it roles out in Australia. Irrespective of the medium used, the connection relies on ethernet protocols which allow you to transmit DATA to and from some TARGET location. Consider the example of a laptop running wirelessly (INTERNALLY) to a ROUTER in the office, which is on some ADSL connection (modem) linked to your local telephone exchange. That is the start of the journey.
What we've described so far, is akin to taking a car trip, but first, you need a vehicle, and you need to get it started and out of the garage, and into your local street. Nobody's travelled far yet, but the engine is running.
The internet is just a huge series of connection points, each with their own unique identifier. For years this has been an IPv4 address in the form: aaa.bbb.ccc.ddd. As a user, you have some computer which will have a LAN IP address like 192.168.xxx.xxx or 10.xxx.xxx.xxx. These are reserved private IP addresses for LAN usage. But let's push on with the travel analogy.
Reaching your target location, will require you to traverse a number of intersections, and those intersections can slow you down if there is a traffic jam. The more intersections, the longer the journey will take, and the more risk of delay there will be. Don't we all wish fast highways were free of other traffic and crossroads, to reach our journey's destination (and back again) nice and fast.
Target locations rely on their connections too.
Gaining access to the private information, service, database, file, website or whatever purpose you are travelling the internet for, is also dependent upon the capacity, speed and quality of connection that the TARGET SITE uses for THEIR ISP contract/connection. Time for a pertinent example. Logging into Reckon HOSTED, located at the Amazon Data Centre in Sydney, is done by a user BROWSING to the following login page: https://hosted.reckon.com/RAHV2/ReckonAccountsLogon.aspx
hosted.reckon.com is a SERVER in Sydney located on IP: 52.65.91.115 - that is the initial TARGET location users need to reach, in order to LOG IN.
Here's an example of the JOURNEY (the 12 hops needed), for a humble Telstra Bigpond connection from the suburbs of Melbourne, that will occur up to the local ISP, then to Amazon's ISP, and finally to the target location. For security, the final hop is not directly pingable (a term that relates to seeking a response from an known device on the internet). The journey begins from the local ROUTER/FIREWALL on IP: 192.168.202.1. That is the internet private, physical address of the firewall server nicknamed: gw.lan (which means gateway of the LAN). The local journey outside the office then goes via the local telephone exchange in this example (hops 2 and 3), and into the main BIGPOND nerve centre in Melbourne at hop:5. From there, it bridges over to Sydney at hop:6 and out their back door to a dedicated link for AMAZON at hop: 8. So far it's a bit like driving a car up the Hume freeway isn't it? Provided there's no traffic jams, then the overall time to reach each successive point, further and further way, is showing the time in 1/1000th of a second (ms: milliseconds). Nearly there now. AMAZON has some of its own equipment in its major DATA CENTRE at hops 9, 10 and 11, and our destination can be assumed reached at hop 12.
Remember, the journey back to the office again, will require coming back along a similar path - not always the same, just as there are many lanes on the road or shortcuts attempted in road travel, so to does the internet follow efficient routes too. But the overall round trip could be something like 24 overall hops there and back.
gaz@absvenom:~$ traceroute hosted.reckon.com
traceroute to hosted.reckon.com (52.65.91.115), 30 hops max, 60 byte packets
1 gw.lan (192.168.202.1) 0.175 ms 0.189 ms 0.216 ms
2 172.18.211.23 (172.18.211.23) 25.816 ms 25.829 ms 26.185 ms
3 172.18.95.5 (172.18.95.5) 26.405 ms 27.045 ms 172.18.95.1 (172.18.95.1) 27.277 ms
4 bundle-ether4.win-edge902.melbourne.telstra.net (203.50.76.8) 28.690 ms 29.935 ms
31.316 ms
5 bundle-ether12.win-core10.melbourne.telstra.net (203.50.11.111) 33.283 ms 36.843 ms
35.190 ms
6 bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122) 50.810 ms 50.333 ms
51.332 ms
7 bundle-ether1.ken-edge901.sydney.telstra.net (203.50.11.95) 51.375 ms 35.094 ms
36.063 ms
8 ama1663225.lnk.telstra.net (165.228.50.190) 33.766 ms 35.388 ms 36.311 ms
9 52.95.36.64 (52.95.36.64) 39.763 ms 40.208 ms 52.95.36.112 (52.95.36.112) 41.696 ms
10 52.95.36.89 (52.95.36.89) 43.132 ms 52.95.36.57 (52.95.36.57) 43.643 ms 52.95.36.105
(52.95.36.105) 44.644 ms
11 54.240.192.107 (54.240.192.107) 47.619 ms 51.749 ms 50.064 ms
12 * * * (target reached, but silent echo)
Hops and risks
As seen in the above example, there are hops from you to your ISP, then over to THEIR ISP and down to them, and all the way back again. The overall performance is a combination of having:
- the least number of hops
- the best speed between each hop
Your LAN performance is also dependent on WAN performance
All the network devices in your office, and those remotely connected to servers via your office, all rely on LAN (Local Area Network) capacity, but when waiting on data coming from the WAN, then that can delay the final experience see on your LAN. An earlier article explains how devices and programs/systems running on your LAN are impacted by LAN performance.
See: https://community.reckon.com/reckon/topics/common-network-lan-environment-issues-solved-through-reckon-community-support
From that article it is important to reiterate a point. The two combined (LAN plus WAN) need to work together, in terms of CAPACITY and RULES. RULES are protocol restrictions, firewall settings, operating system permissions, and tailored settings determining the PORT (a dedicated pathway if you like) that such traffic will traverse, and is EXPECTED to traverse. RULES can change with the unscheduled arrival or deployment of system updates or addition of other software, features to your overall system - being the servers as well as your workstation.
Impact on Applications
Back to the RECKON HOSTED application example. Entering data and waiting for the screen to respond, will be impacted by the time it takes for DATA to traverse up along those HOPS and back again with the results. But at the same time, other users within your office, using the same initial WAN links, sharing the same capacity and operating concurrently, will also impact the response time of one another.
From the mentioned LAN article: There are any number of SYSTEM activities, like virus checking, anti-spam checking, malware detection, device polling (like printers being checked for online status). Behind the scenes, operating systems are forever checking the status of TIME, their network connection status, fetching remote DATA... the list is endless. And that is when the ENVIRONMENT is finely tuned and setup well.
Patience is TIMEOUT (the system's not just yours!)
When a program attempts to link up to some other service, over the WAN, and determines it has been trying to do so for long enough, it reaches a TIMEOUT setting whereby it effectively runs out of patience. It then leaves the User confronted with some error message or worse, just a screen that seems to have failed to progress to the next step.
What can cause the WAN connection to impact ACCOUNTING
Congestion at any one of the HOPS traversed, is one area to consider. Take those busy times when 10's of 1000's of users all try to reach information on the internet at the same time.
Examples include the day when sales of highly popular tickets for an event go on sale, or results of schooling are online for access, or more relevant, your BAS is due TODAY. If all that activity is stressing out the capacity of a device, service or connection point that you have traverse or reach as one of your HOPS in your journey, then you will join that data traffic jam along with all the others.
There can be unscheduled outages of equipment that is part of the route (journey). At the time of writing this article the Weather Bureau was off the air for all their domestic data.
(ie: http://www.smh.com.au/environment/weather/australia-left-in-the-dark-as-bureau-of-meteorologys-weather-data-fails-20160107-gm1lcl.html).
But the above 12 HOP example, and consider the impact if any one of those 12 hops was not running today. It would be akin to there being a road closure along the HUME Highway - we'd all have to stop and wait.
TIP for checking your WAN status
It is always a good idea to take a different look at the situation. When unable to reach a target destination, don't immediately worry about thinking the problem is at your end and start pulling hardware and software apart. Best to have a record of something you know is independent, reliable and usually not too busy, and use that as a reference point. For many years with a fleet of Subaru's in the business it was interesting to see the status of their offering.
With due respect, www.subaru.com usually doesn't suffer high's and lows of activity. You can pick your own idea on this. But pick a website, it's IP and use that as a litmus tests of whether you can see that page, ping that IP or traceroute to that target location. Do this when the system is behaving normally, and note the results (cut/paste into an email to yourself for later referral).
When failing to reach a favoured target service on the WAN, rerun that test again, to see how far you can traceroute towards that target. If you can't get past your own internal ROUTER, then the problem is likely at your end, in the office. If you can traceroute beyond your ISP, then the problem is most likely on the WAN somewhere beyond your office location, or at the tail end target you are trying to reach. The chances of your TEST site being off the air at the same time as your failing target as well, that is most unlikely. (Be sure your TEST is to a location geographically different from the main sites/services you need to use).
Have someone else ping/traceroute or attempt reaching the website or login service that you are having trouble with., If they can, and you can't, and the above test worked well, then the chances are, that there is a failure somewhere long the series of HOPS that are peculiar to the failing target. Again, having a permanent record of what that route/path looks like when working, is a great diagnostic for determining what action to take for a solution.
So think about the driving analogy above. The cause of a problem might not be you, your computer, your software or your operational techniques. There is the other end of the piece of string (WAN and LAN) and all the other travelers on board the WAN being travelled (and your LAN).
IT and ENVIRONMENT support to fellow AP's and their clients
Alchester is an independent IT consulting firm, with focus on Business Systems analysis, project management and internal cost accounting management from a business and IT perspective.
Solutions based on integrating complimentary proven technologies introduced from bona fide software developers to improve business efficiencies, is well complimented by ABS' 40 years background experience in the Accounting industry with an astute awareness of the needs of fellow AP's who focus on Accounting and Bookkeeping for their clients.
Enjoy!
Gary Pope
m: 0408994799
e: gaz@alchester.com.au
An Accredited Partner- Consultant (VIC. Aust)
http://www.alchester.com.au/reckon-ac...
"Working with Accountants/Bookkeepers PPs/APs, as an
independent IT Professional and retired FCPA Accountant"
PS: refer to related support tips at:
Common (LAN) environment tips:
https://community.reckon.com/reckon/topics/common-network-lan-environment-issues-solved-through-reck...
SYSTEM ENVIRONMENT solutions provided by Reckon Community Helphttps://community.reckon.com/reckon/topics/system-environment-solutions-provided-by-reckon-community...
and 6 ways on improving usage of the Community FORUM
https://community.reckon.com/reckon/topics/6-ways-to-gain-best-reckon-community-support-around-the-c...
0
Categories
- All Categories
- 6.9K Accounts Hosted
- 11 📢 Reckon Accounts Hosted - Announcements
- 6K Reckon Accounts (Desktop)
- 3 📢 Reckon Accounts Desktop - Announcements
- 1.2K Reckon Payroll 🚀
- 21 📢 Reckon Payroll - Announcements
- 21 Reckon Payroll Help Videos 🎥
- 21 Reckon Mate App
- 3.1K Reckon One
- 7 📢 Reckon One - Announcements
- 11 Reckon Invoices App
- 14 Reckon Insights
- 114 Reckon API
- 830 Payroll Premier
- 326 Point of Sale
- 2K Personal Plus and Home & Business
- 74 About Reckon Community