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

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

Mansoor NathaniAsked:
Who is Participating?
Press2EscConnect With a Mentor Commented:
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

ZordrackConnect With a Mentor Commented:
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.
kdearingConnect With a Mentor Commented:
Looking at the 2 traces, it looks like this is the culprit: []
Get Certified for a Job in Cybersecurity

Want an exciting career in an emerging field? Earn your MS in Cybersecurity and get certified in ethical hacking or computer forensic investigation. WGU’s MSCSIA degree program was designed to meet the most recent U.S. Department of Homeland Security (DHS) and NSA guidelines.  

Mansoor NathaniAuthor Commented:
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.
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.
from_expConnect With a Mentor Commented:

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..
Mansoor NathaniAuthor Commented: 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.
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....
I used this (freeware) ping/traceroute pgm to "convince" an ISP THEY had a router issue...  Check out this little jewel.

Mansoor NathaniAuthor Commented:
Heres some info, I got after creating a support ticket with Steadfast Networks.
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.

Mansoor NathaniAuthor Commented:
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

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

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
Mansoor NathaniAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.