Help - Search - Members - Calendar
Full Version: packet loss on network
The Planet Forums > System Administration > Network
revo
Anyone experiencing packet loss? One of our servers are having serious issues.
revo
Tracert;

12 257 ms 256 ms 258 ms dist-vlan32.dsr3-2.dllstx3.theplanet.com [70.85.
127.62]
13 261 ms 287 ms 262 ms dist-vlan22.dsr1-2.dllstx2.theplanet.com [70.85.
127.76]
14 289 ms 275 ms 258 ms car2-7-v2.dllstx2.theplanet.com [12.96.160.55]
15 * * 345 ms 1**.69-93-114.reverse.theplanet.com [69.93.114.1
**]
revo
Ping statistics for 69.93.114.***:
Packets: Sent = 100, Received = 42, Lost = 58 (58% loss),
Approximate round trip times in milli-seconds:
Minimum = 260ms, Maximum = 671ms, Average = 358ms
Homer
Would help if you provided a full traceroute from your server to you, from you to your server with your servers IP so others can test it.
revo
It's okay, my server is under DDOS. It has been 5 hours now and SM tech hasn't even done anything about it. icon_sad.gif
Homer
Called 'em? icon_cool.gif
revo
Sure did. Hours ago. icon_confused.gif
JustGags
How common is this whole DDOS thing? It hasn't happened to mine...yet.
hytekhosting
When any one of my servers is under DDoS attack, I usually submit a ticket and then call to let them know about it. It usually takes them 15-30 minutes to get the attack under control. They have some expensive Riverhead equipment that does the job well.
revo
Unfortunately in my case, it took much longer. It just got resolved half an hour ago.

While they took awhile to get it done, i'm glad they managed to sort things out in the end. icon_smile.gif
thedude
I'm getting some bad loss right now.
QUOTE
Microsoft Windows XP [Version 5.1.2600]
© Copyright 1985-2001 Microsoft Corp.

C:Documents and SettingsMatt>tracert 67.18.254.20

Tracing route to 20.67-18-254.reverse.theplanet.com [67.18.254.20]
over a maximum of 30 hops:

 1    <1 ms    <1 ms    <1 ms  192.168.2.1
 2    15 ms    16 ms    15 ms  vi-d13-1.rb.jax.centurytel.net [69.29.148.1]
 3    18 ms    16 ms    15 ms  jcvlarotr03.jcvlarotro1.centurytel.net [208.54.2
20.3]
 4    16 ms    16 ms    15 ms  jcvlarotro2.jcvlarotro1.centurytel.net [208.54.2
20.1]
 5    25 ms    26 ms    24 ms  centurytel.ip.att.net [12.125.75.189]
 6    24 ms    24 ms    24 ms  gbr2-p40.sl9mo.ip.att.net [12.123.24.214]
 7    26 ms    26 ms    25 ms  tbr2-p013602.sl9mo.ip.att.net [12.122.11.117]
 8    42 ms    41 ms    40 ms  tbr2-cl6.dlstx.ip.att.net [12.122.10.90]
 9    39 ms    39 ms    39 ms  gar1-p370.dlrtx.ip.att.net [12.123.196.97]
10     *      233 ms   230 ms  12.119.136.14
11    39 ms    40 ms    40 ms  dist-vlan32.dsr3-1.dllstx3.theplanet.com [70.85.
127.61]
12    39 ms    39 ms    39 ms  dist-vlan21.dsr1-1.dllstx2.theplanet.com [70.85.
127.67]
13    39 ms    40 ms    39 ms  dsr2-2-v2.dllstx4.theplanet.com [12.96.160.40]
14    39 ms    39 ms    39 ms  gig1-0-2.tp-car9-2.dllstx4.theplanet.com [67.18.
116.86]
15     *      233 ms   233 ms  20.67-18-254.reverse.theplanet.com [67.18.254.20
]

Trace complete.

C:Documents and SettingsMatt>ping -n 100 67.18.254.20

Pinging 67.18.254.20 with 32 bytes of data:

Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=234ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=239ms TTL=51
Reply from 67.18.254.20: bytes=32 time=244ms TTL=51
Reply from 67.18.254.20: bytes=32 time=232ms TTL=51
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=245ms TTL=51
Reply from 67.18.254.20: bytes=32 time=236ms TTL=51
Reply from 67.18.254.20: bytes=32 time=243ms TTL=51
Reply from 67.18.254.20: bytes=32 time=231ms TTL=51
Request timed out.
Request timed out.
Reply from 67.18.254.20: bytes=32 time=272ms TTL=51
Reply from 67.18.254.20: bytes=32 time=241ms TTL=51
Request timed out.
Request timed out.
Reply from 67.18.254.20: bytes=32 time=238ms TTL=51
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=232ms TTL=51
Reply from 67.18.254.20: bytes=32 time=236ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=236ms TTL=51
Reply from 67.18.254.20: bytes=32 time=245ms TTL=51
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=237ms TTL=51
Reply from 67.18.254.20: bytes=32 time=234ms TTL=51
Reply from 67.18.254.20: bytes=32 time=238ms TTL=51
Reply from 67.18.254.20: bytes=32 time=232ms TTL=51
Reply from 67.18.254.20: bytes=32 time=232ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=234ms TTL=51
Reply from 67.18.254.20: bytes=32 time=234ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=237ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=230ms TTL=51
Request timed out.
Request timed out.
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=232ms TTL=51
Reply from 67.18.254.20: bytes=32 time=235ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=232ms TTL=51
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 67.18.254.20: bytes=32 time=235ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=243ms TTL=51
Reply from 67.18.254.20: bytes=32 time=241ms TTL=51
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=232ms TTL=51
Reply from 67.18.254.20: bytes=32 time=235ms TTL=51
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=241ms TTL=51
Reply from 67.18.254.20: bytes=32 time=238ms TTL=51
Reply from 67.18.254.20: bytes=32 time=244ms TTL=51
Reply from 67.18.254.20: bytes=32 time=231ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=235ms TTL=51
Reply from 67.18.254.20: bytes=32 time=231ms TTL=51
Request timed out.
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=233ms TTL=51
Reply from 67.18.254.20: bytes=32 time=231ms TTL=51
Request timed out.
Ping statistics for 67.18.254.20:


Getting about 20% packet loss

Nevermind it just straightened out.
aLLpLaY
QUOTE (JustGags)
How common is this whole DDOS thing? It hasn't happened to mine...yet.


Happened to one of mine while I was out.

Within 10 minutes of the attack, SM stopped it without me having to call or tell them anything about it icon_smile.gif
ShaneAu
Same thing going on here actually...

Pinging 70.84.245.2 with 32 bytes of data:

Request timed out.
Request timed out.
Reply from 70.84.245.2: bytes=32 time=259ms TTL=50
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 70.84.245.2: bytes=32 time=251ms TTL=50
Request timed out.
Request timed out.
Reply from 70.84.245.2: bytes=32 time=250ms TTL=50
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 70.84.245.2:
Packets: Sent = 26, Received = 3, Lost = 23 (88% loss),
Approximate round trip times in milli-seconds:
Minimum = 250ms, Maximum = 259ms, Average = 253ms


Tracing route to speedy.akadns.info [70.84.245.2]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 203-206-250-xxx.dyn.iinet.net.au [203.206.250.xx
x]
2 13 ms 12 ms 13 ms 203.55.231.88
3 12 ms 12 ms 12 ms 203.55.231.188
4 15 ms 13 ms 14 ms GE-4-1-0.ar1.syd1.gblx.net [203.192.167.141]
5 128 ms 125 ms 127 ms pos6-1.cr2.nrt1.asianetcom.net [202.147.55.98]
6 127 ms 126 ms 141 ms ip-202-147-1-37.asianetcom.net [202.147.1.37]
7 127 ms 128 ms 128 ms as6461.nspixp2.wide.ad.jp [202.249.2.102]
8 128 ms 128 ms 129 ms so-2-1-0.cr2.nrt3.jp.mfnx.net [208.184.210.74]
9 212 ms 258 ms 238 ms so-3-2-1.cr1.sjc3.us.above.net [64.125.30.10]
10 215 ms 209 ms 210 ms so-6-3-0.mpr3.sjc2.us.above.net [64.125.27.105]

11 211 ms 313 ms 238 ms so-0-0-0.mpr4.sjc2.us.above.net [64.125.30.2]
12 270 ms 272 ms 270 ms so-3-2-0.cr1.dfw2.us.above.net [64.125.29.54]
13 239 ms 286 ms 273 ms 216.200.88.141.theplanet.com [216.200.88.141]
14 241 ms 240 ms 240 ms dist-vlan32.dsr3-2.dllstx3.theplanet.com [70.85.
127.62]
15 244 ms 265 ms 262 ms dist-vlan22.dsr1-2.dllstx2.theplanet.com [70.85.
127.76]
16 244 ms 244 ms 262 ms dsr2-1-v1.dllstx4.theplanet.com [12.96.160.7]
17 * * * Request timed out.
18 * * 251 ms 2.70-84-245.reverse.theplanet.com [70.84.245.2]
nForcer
Looks like its primarily on the core or border routers. Willing to bet they (admin's) are making routing changes and due to the extreme amount of traffic they are pushing, ...well...it just takes some time to get it converged again.

Nothing out of the normal then. icon_smile.gif
ShaneAu
It seems fine now...

Good, because I gotta get to work! icon_mad.gif
node
QUOTE (hytekhosting)
When any one of my servers is under DDoS attack, I usually submit a ticket and then call to let them know about it.  It usually takes them 15-30 minutes to get the attack under control.  They have some expensive Riverhead equipment that does the job well.


I'm sorry man, but I really don't think SM or TP is going to filter any kind of attack that is a decent size.

They might be able to filter it if its like, 50 megabits or less

Guaranteed if its 200mbit or more, they are just going to nullroute you, and if you ask me thats not really putting any "equipment" to use

i dont doubt they have the ability to filter, they just dont do things like that for you, other than nullroute.

even if you add on their firewalls or whatever, those firewalls in orbit that you can add onto your account the cisco 5** etc all that stuff...

those firewalls still can't touch 200+ mbit. you'll end up nullrouted no matter what way you look at it.

so if everything i said still doesn't apply to you, and you are basically saying that they have filtered 200+ mbit for you, then wow, i am impressed, and i would like to know more, and how, and why?

It's just, from my experience, the only time i havent been nullrouted is if it was a crappy attack like 30mbit
hytekhosting
QUOTE (node)
QUOTE (hytekhosting)
When any one of my servers is under DDoS attack, I usually submit a ticket and then call to let them know about it.  It usually takes them 15-30 minutes to get the attack under control.  They have some expensive Riverhead equipment that does the job well.


I'm sorry man, but I really don't think SM or TP is going to filter any kind of attack that is a decent size.

They might be able to filter it if its like, 50 megabits or less

Guaranteed if its 200mbit or more, they are just going to nullroute you, and if you ask me thats not really putting any "equipment" to use

i dont doubt they have the ability to filter, they just dont do things like that for you, other than nullroute.

even if you add on their firewalls or whatever, those firewalls in orbit that you can add onto your account the cisco 5** etc all that stuff...

those firewalls still can't touch 200+ mbit. you'll end up nullrouted no matter what way you look at it.

so if everything i said still doesn't apply to you, and you are basically saying that they have filtered 200+ mbit for you, then wow, i am impressed, and i would like to know more, and how, and why?

It's just, from my experience, the only time i havent been nullrouted is if it was a crappy attack like 30mbit


Are you an network engineer at The Planet? I don't think so. No where did I "basically" say "that they have filtered 200+ mbit" attacks for me. They have filtered attacks over 50mbps for us in the past with no problem.
wcharnock
QUOTE (node)
QUOTE (hytekhosting)
When any one of my servers is under DDoS attack, I usually submit a ticket and then call to let them know about it.  It usually takes them 15-30 minutes to get the attack under control.  They have some expensive Riverhead equipment that does the job well.


I'm sorry man, but I really don't think SM or TP is going to filter any kind of attack that is a decent size.

They might be able to filter it if its like, 50 megabits or less

Guaranteed if its 200mbit or more, they are just going to nullroute you, and if you ask me thats not really putting any "equipment" to use

i dont doubt they have the ability to filter, they just dont do things like that for you, other than nullroute.

even if you add on their firewalls or whatever, those firewalls in orbit that you can add onto your account the cisco 5** etc all that stuff...

those firewalls still can't touch 200+ mbit. you'll end up nullrouted no matter what way you look at it.

so if everything i said still doesn't apply to you, and you are basically saying that they have filtered 200+ mbit for you, then wow, i am impressed, and i would like to know more, and how, and why?

It's just, from my experience, the only time i havent been nullrouted is if it was a crappy attack like 30mbit


FYI - we've been filtering a 1+Gbps attack (that is still over 550kpps) for over a week now through the new DDOS mitigation system.

Null routing is the last resort when dealing with an attack. Sometimes it is necessary to shield our other users from the attack, but we make every effort to mitigate the attack without a null route.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.