How much control does an ISP have on packets once they have left the ISP's network?

Posted on 2008-06-25
Last Modified: 2013-12-14
I am not really familiar with BGP routing or anything, but I am wondering if an ISP has any say in the path a packet takes on the internet once it has left their edge router? I know they can pick which direction to send it off to through one of their peers or transit providers, but once it is on that other network do they have any control in routing decisions?

The reason I ask is because I am having a strange issue with getting to a particular host on the internet.  and am unable to get to it for periods of around 30 min  a couple of times each day. I have narrowed this down to users on my ISP, it seems to be affecting only.

Trace when its not working as well as when it is (attached) : shows specific times of the 'outages'

Using a looking glass service to check if the site is up when I can't get to it shows the site online.

Not working:
C:\Documents and Settings\Mansoor>tracert
Tracing route to []
over a maximum of 30 hops:
1 10 ms 12 ms 9 ms
2 8 ms 8 ms 8 ms []
3 8 ms 8 ms 8 ms []
4 19 ms 19 ms 19 ms []
5 19 ms 19 ms 19 ms []
6 19 ms 18 ms 18 ms []
7 18 ms 19 ms 19 ms []
8 19 ms 19 ms 19 ms []
9 19 ms 19 ms 19 ms []
10 19 ms 19 ms 18 ms
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
C:\Documents and Settings\Mansoor>tracert
Tracing route to []
over a maximum of 30 hops:
1 9 ms 9 ms 9 ms
2 9 ms 8 ms 8 ms []
3 8 ms 7 ms 8 ms []
4 18 ms 18 ms 18 ms []
5 18 ms 25 ms 18 ms []
6 19 ms 28 ms 18 ms []
7 19 ms 18 ms 18 ms []
8 19 ms 18 ms 19 ms []
9 18 ms 19 ms 18 ms []
10 18 ms 19 ms 39 ms
11 19 ms 19 ms 24 ms []
12 19 ms 19 ms 19 ms []
13 19 ms 19 ms 19 ms []
Trace complete.

Open in new window

Question by:Mansoor Nathani
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 5
  • 2
  • +2

Assisted Solution

Zordrack earned 100 total points
ID: 21871740
The ISP has NO controll over a packet once it has left it's network.
That is the very nature of a packet switched network.

The only thing the ISP can do is choose the next hop in the route and, if that hop supports it, tag it with QoS.

Aside from that all bets are off and the only part the ISP plays is to pick up the packet from you and pass it on to the next hop towards it's destination.
LVL 13

Assisted Solution

kdearing earned 100 total points
ID: 21871874
Looking at the 2 traces, it looks like this is the culprit: []

Author Comment

by:Mansoor Nathani
ID: 21871975
Is it not possible that  >>   is not pointing to the next hop which would be []  

and so is therefore the culprit??

Also, does my ISP have any responsibility in getting this corrected? Seeing how this issue only affects users on my ISP.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Expert Comment

ID: 21872034
Yes it is possible, however usually it is the node the drops out that is the guilty party.

And sorry but no, your ISP's responsibility drops off as soon as the hand over your packet to a peer.
If anything try contacting and tell them there's an issue between and
I wouldnt hold my breath though.
LVL 21

Assisted Solution

from_exp earned 100 total points
ID: 21872481

As it was already been mentioned your ISP can't control traffic side from it's own network. however it's up to him to decide to which of his upstream to send traffic.
and sometimes ISPs prefer to by very cheap best effort connection, and you can experience packet drops and delays during busy hours.

As for the particular host, it is also possible, that is doing some firewalling staff.
because remember, if there is routing issue you would receive route/destination unreachable instead of time outs..

Accepted Solution

Press2Esc earned 200 total points
ID: 21873250
I would provide this outage info a/o contact Steadfast Networks @ or call (+1-312-602-2689). If is hosted, I would also provide the same info to the hosting co.

Check your log files @ server for down time (e.g., loss of internet access, unusual traffic, etc).  If is NOT hosted by a hosting service, what type of connection (e.g., cable, dsl, frame, t1, etc) do you have for


Author Comment

by:Mansoor Nathani
ID: 21881112 is hosted at  It has not been down as I have confirmed with the provider, as well as checked my logs. The outages seem specific to my ISP. I have also contacted Steadfast, and they say that they have atleast 10 other users also using my ISP having the same problem. They blame my ISP, but when I Contacted my ISP they say that the issue is occurring outside their network and they can't really do anything.
LVL 21

Expert Comment

ID: 21881185
I suppose the best you can do is collect as much trace statistics as possible, then push your own ISP. they should try to escalate the problem to their upstream....
possibly you can find the truth there....

Expert Comment

ID: 21890712
I used this (freeware) ping/traceroute pgm to "convince" an ISP THEY had a router issue...  Check out this little jewel.


Author Comment

by:Mansoor Nathani
ID: 21898018
Heres some info, I got after creating a support ticket with Steadfast Networks.

Expert Comment

ID: 21898226
As I recommended I am glad you were able to contact Steadfast Networks AND they were responsive.   Unfortunately you will need to harrass the ISP until they fix the issue OR provide you a alternate solution/explaination.  Be sure and provide them your support tkt from Steadfast Networrks.

Did you dload the pgm I recomended? It gives you % downtime and you can adjust the test period/frequency for the tests..  Maybe you need to show your ISP an actual percentage of loss on their router(s) b4 they get off their duff.


Author Comment

by:Mansoor Nathani
ID: 21899073
I have not had a chance to try the software

I currently use the software called 'The Dude' which is sufficient as it shows me graphs of when there is connectivity and when it is down.

I had posted some of them at


Expert Comment

ID: 21903289
According to your tracert to [], your issue is NOT your ISP (Bell Canada), it is, which belongs to Savvis, who is also Steadfast


Open in new window


Expert Comment

ID: 21903833
sorry for the jibberish earlier, got sidetracked and somehow the reply got sent...

According to your tracert to [], your issue is NOT your ISP (Bell Canada), it is the router @  A DNS Lookup of that router shows the IP originates from Future Hosting, LLC.  See details below:

ip whois information for
NoZone, Inc. STEADFAST-2 (NET-208-100-0-0-1) -
Future Hosting, LLC CUSTBLK-208-100-59-0-24 (NET-208-100-59-0-1) -

# ARIN WHOIS database, last updated 2008-06-29 19:10

Author Comment

by:Mansoor Nathani
ID: 21913404
I have another update on this issue. Looking at a trace route I did from the server at in chicago back to my ip, it showed Telia within the Trace route.

So, I contacted the Telia NOC and they said this is a known issue in Chicago with Bell's Hardware and affecting their Peering and that it has been going on for almost a month now.

They also mentioned that Bell is aware of it.

Unfortunately they were not able to provide the incident number to me as I am not a customer of theirs.

Here is the trace result:

traceroute to (, 30 hops max, 40 byte packets
1 ( [AS32748] 0.069 ms 0.057 ms 0.022 ms
2 ( [AS1299] 0.711 ms 0.799 ms 0.759 ms
3 * * *
4 ( [AS577] 0.705 ms 0.657 ms 3001.290 ms
5 ( [AS577] 10.930 ms 11.012 ms 10.964 ms
6 ( [AS577] 11.127 ms 11.189 ms 11.162 ms
7 ( [AS577] 14.017 ms 15.625 ms 16.170 ms
8 ( [AS577] 20.527 ms 24.562 ms 25.858 ms

Featured Post

Turn Insights Into Action

You’ve already invested in ITSM tools, chat applications, automation utilities, and more. Fortify these solutions with intelligent communications so you can drive business processes forward.

With xMatters, you'll never miss a beat.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Tired of waiting for your show or movie to load?  Are buffering issues a constant problem with your internet connection?  Check this article out to see if these simple adjustments are the solution for you.
Data center, now-a-days, is referred as the home of all the advanced technologies. In-fact, most of the businesses are now establishing their entire organizational structure around the IT capabilities.
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor ( If you're interested in additional methods for monitoring bandwidt…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
Suggested Courses

691 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question