• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 428
  • Last Modified:

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. http://cent.mnathani.com  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) :

http://mnathani.com/graph 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 cent.mnathani.com
Tracing route to cent.mnathani.com []
over a maximum of 30 hops:
1 10 ms 12 ms 9 ms
2 8 ms 8 ms 8 ms dis10-toronto12_Vlan102.net.bell.ca []
3 8 ms 8 ms 8 ms core4-toronto12_GE12-1.net.bell.ca []
4 19 ms 19 ms 19 ms core2-chicago23_pos3-0-0.net.bell.ca []
5 19 ms 19 ms 19 ms bx4-chicago23_POS5-0.net.bell.ca []
6 19 ms 18 ms 18 ms dcr1-so-3-1-0.chicago.savvis.net []
7 18 ms 19 ms 19 ms ber1-ge-8-3.chicago.savvis.net []
8 19 ms 19 ms 19 ms ber1-vlan-241.chicagoequinix.savvis.net []
9 19 ms 19 ms 19 ms ber2-vlan-240.chicagoequinix.savvis.net []
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 cent.mnathani.com
Tracing route to cent.mnathani.com []
over a maximum of 30 hops:
1 9 ms 9 ms 9 ms
2 9 ms 8 ms 8 ms dis10-toronto12_Vlan102.net.bell.ca []
3 8 ms 7 ms 8 ms core4-toronto12_GE12-1.net.bell.ca []
4 18 ms 18 ms 18 ms core2-chicago23_pos3-0-0.net.bell.ca []
5 18 ms 25 ms 18 ms bx4-chicago23_POS5-0.net.bell.ca []
6 19 ms 28 ms 18 ms dcr1-so-3-1-0.chicago.savvis.net []
7 19 ms 18 ms 18 ms ber1-ge-8-3.chicago.savvis.net []
8 19 ms 18 ms 19 ms ber1-vlan-241.chicagoequinix.savvis.net []
9 18 ms 19 ms 18 ms ber2-vlan-240.chicagoequinix.savvis.net []
10 18 ms 19 ms 39 ms
11 19 ms 19 ms 24 ms ip61.216-86-149.static.steadfast.net []
12 19 ms 19 ms 19 ms chi10.fhdomains.com []
13 19 ms 19 ms 19 ms cent.mnathani.com []
Trace complete.

Open in new window

Mansoor Nathani
Mansoor Nathani
  • 5
  • 5
  • 2
  • +2
4 Solutions
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.
Looking at the 2 traces, it looks like this is the culprit:
ip61.216-86-149.static.steadfast.net []
Mansoor NathaniAuthor Commented:
Is it not possible that  >>   is not pointing to the next hop which would be ip61.216-86-149.static.steadfast.net []  

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.
Identify and Prevent Potential Cyber-threats

Become the white hat who helps safeguard our interconnected world. Transform your career future by earning your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

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 steadfast.net and tell them there's an issue between and
I wouldnt hold my breath though.

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 ip61.216-86-149.static.steadfast.net is doing some firewalling staff.
because remember, if there is routing issue you would receive route/destination unreachable instead of time outs..
I would provide this outage info a/o contact Steadfast Networks @ noc@steadfast.net or call (+1-312-602-2689). If mnathani.com is hosted, I would also provide the same info to the hosting co.

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

Mansoor NathaniAuthor Commented:
cent.mnathani.com is hosted at futurehosting.biz  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.

- http://www.filetransit.com/view.php?id=31106
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 http://mnathani.com/graph

According to your tracert to cent.mnathani.com [], 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 cent.mnathani.com [], 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 cent.mnathani.com 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 server32.mnathani.com (, 30 hops max, 40 byte packets
1 chi10.fhdomains.com ( [AS32748] 0.069 ms 0.057 ms 0.022 ms
2 chi-bb1-link.telia.net ( [AS1299] 0.711 ms 0.799 ms 0.759 ms
3 * * *
4 core2-chicago23_POS8-0.net.bell.ca ( [AS577] 0.705 ms 0.657 ms 3001.290 ms
5 core4-toronto12_pos1-0-0.net.bell.ca ( [AS577] 10.930 ms 11.012 ms 10.964 ms
6 dis10-toronto12_GE1-2.net.bell.ca ( [AS577] 11.127 ms 11.189 ms 11.162 ms
7 bas2-toronto12_GE1-0-102.net.bell.ca ( [AS577] 14.017 ms 15.625 ms 16.170 ms
8 bas2-toronto12-1168022687.dsl.bell.ca ( [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.

Join & Write a Comment

Featured Post

Get Cisco Certified in IT Security

There’s a high demand for IT security experts and network administrators who can safeguard the data that individuals, corporations, and governments rely on every day. Pursue your B.S. in Network Operations and Security and gain the credentials you need for this high-growth field.

  • 5
  • 5
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now