Hi folks,

Anyone here with DV2 having problems ? My site just disappeared and dv2.net are down too - this happened a few days ago, something to do with an upgrade and wondered if it's happening again. I got an email from them this morning saying that the downtime the other day was for routing upgrading and my server shouldn't go down again, but less than 12 hours and it's happened again. If this is an upgrade it would be nice to be told in advance as I've customers here wanting to know what's happening and they know as much as me lol

Scott

Yes, they are upgrading routers. We went down for about 2 mins and came right back up. The one they're working on now seems to be giving them a bit more trouble than the last.

However, do a traceroute when they are done...it's not williams and verio yet, but the 'Netrail Hump' appears to be gone. w00t!

Verio etc is on the 22nd

Originally posted by hosticle
Verio etc is on the 22nd

Ya, Jeff sent out an email earlier today about that. He also mentioned this upgrade.

Hi,

Thanks for letting me know :) at least the server hasn't died then lol ;)

Do you know how you get on that mailing list by any chance ?

Thanks again,

Scott :P

Btw, if I ping it went it comes up, is it very noticable the improvment ? just wondering if it's worth mentioning to my customers as a way of cheering them up ;)

Yes, It's an enormous improvement.

I've been sitting here with a huge grin on my face running traceroutes and cursing at Cogent's crappy peering with ATDN...now I know what it feels like to be Netdude! (j/k)

Hi,

Thanks for the info - great news :)

Btw, did they give a time on the 22nd it would go down and for how long ? or if I may be so checky as to beg a copy of the email to scott@4websitestemplates.com ?

Moocho thanks,

Scott :P

Originally posted by hosticle
Verio etc is on the 22nd

I was told 24th? Maybe the second line is the 24th.

Here is the email we got from eservers:

Dear Valued eServers dot Biz Customer,

In an effort to provide our customers with the best possible hosting experience, DV2/eServers will be performing network upgrades on the following dates:

September 19, 2002

All maintenance will be performed around 10 PM EST. This will ensure that any network outages experienced during these maintenance periods will have a minimal impact on our customers.

During this upgrade we will be performing a couple of card additions and swaps on the core routers as well as migrating some users to one of the CISCO 4912's.

No-one should notice any downtime apart from certain route changes for about 5 minutes.

Should you have any questions regarding this maintenance, please direct your questions/concerns on the support desk located at http://support.eservers.biz/

Please do not reply to this email.

As always we appreciate your patience and understanding as we work to improve our services.

Regards,
Network Admin

It would be nice if we had a few days notice, but I guess this is a special curcumstance.

Thanks Haze :)

Scott :P

Alas...Netrail is back :(

Oh well...

Oh well is right. It could be worse

get a user name on our forum at tranxactglobal

The one I am on, was down for 1 hour the last time and 1 hour 15 min today.

If you aren't on the tranxactglobal forum or a customer of eServer, you may not be aware that they are putting up all our server prices by $10 per month to pay for these new lines.. just letting you know..

Is www.netrail.net still having problems??

Does anyone know what is going on with NetRail?

...does this response i received from support at one of my providers tie in to the netrail question?...

"...we have had reports of inbound traffic not being able to reach the servers due to congestion at Cogent..."

...snippet from trace: Analysis: IP packets are being lost past network "205.215.2.0" at hop 11. The route has changed so the next network at hop 12 is unknown...

I think it might be, but something is very wrong with one of our servers IPs subnet

209.124.80 block routing

lol... :)

well... cogent has done it again... out here... the cable modem company... shaw cablesystems... well... they used to peer with cogent in a lotta places... seattle, chicago and washington dc... the dsl company (primarily telus internet) buys transit from metromedia in a buncha places too (chicago, ny, seattle)... well... the cable company... their network just went to hell a few days ago... i always get ~150ms pings to chicago from dsl (which is a different story altogether... its cuz of a connection glitch or something between cogent and metromedia cuz the route itself is good) ... cable atleast used to be 60ms... (cuz of the direct peering in chicago)... well... now... its >160ms... shaw dropped all their peering except in washington dc... which means... even if i have a site hosted on cogent on the west coast... say san fran... the data goes from the west coast, to the east... back to the west...

i m seeing that a lot more lately... peering partners want to get out of their peering with cogent but can't legally violate their agreements? so they just make it unfavorable for cogent?

i dunno... needless to say, the cogent network itself is still great... damn those monkeys behind the routers, if they could only get their peering done right... they fixed their routing tho... routing seems sane now...

Originally posted by lightnin
Yes, It's an enormous improvement.

I've been sitting here with a huge grin on my face running traceroutes and cursing at Cogent's crappy peering with ATDN...now I know what it feels like to be Netdude! (j/k)

netrail was bought out by cogent cuz of their peering agreements

heh

Originally posted by Montage Inc
Does anyone know what is going on with NetRail?

...here's the results of a trace for:
Report for 209.124.76.0 [dragon networks]

Analysis: No nodes are responding. Is your Internet connection up?

------------------------------------------------------------------------
| Hop | Err | IP Address | Node Name | Location | ms | Graph | Network |
------------------------------------------------------------------------

...and one for:
Report for 209.124.81.0 [also dragon networks]

Analysis: No nodes are responding. Is your Internet connection up?

------------------------------------------------------------------------
| Hop | Err | IP Address | Node Name | Location | ms | Graph | Network |
------------------------------------------------------------------------
...this has been going on for me for the past six hours...

Same here

...my sympathies to you... the server i have there is for testing | learning purpsoses only... not one real customer, three test domains... i was just about to add twelve customer domains, and was locked out...

...from this experience, i've concluded that there will never be a real customer on that server...

209.124.80 block routing was back up for 2 min. and not back down. I wonder what's going on?

Anyone else having problems?

Originally posted by netdude
lol... :)

well... cogent has done it again... out here... the cable modem company... shaw cablesystems... well... they used to peer with cogent in a lotta places... seattle, chicago and washington dc... the dsl company (primarily telus internet) buys transit from metromedia in a buncha places too (chicago, ny, seattle)... well... the cable company... their network just went to hell a few days ago... i always get ~150ms pings to chicago from dsl (which is a different story altogether... its cuz of a connection glitch or something between cogent and metromedia cuz the route itself is good) ... cable atleast used to be 60ms... (cuz of the direct peering in chicago)... well... now... its >160ms... shaw dropped all their peering except in washington dc... which means... even if i have a site hosted on cogent on the west coast... say san fran... the data goes from the west coast, to the east... back to the west...

i m seeing that a lot more lately... peering partners want to get out of their peering with cogent but can't legally violate their agreements? so they just make it unfavorable for cogent?

i dunno... needless to say, the cogent network itself is still great... damn those monkeys behind the routers, if they could only get their peering done right... they fixed their routing tho... routing seems sane now...



Sorry to disappoint you once again:

traceroute to shawcable.com (24.64.63.20), 30 hops max, 38 byte packets
1 f13.ba01.b003070-1.sfo01.atlas.cogentco.com (66.250.4.165) 0.450 ms 0.407 ms 0.384 ms
2 g0-2.core01.sfo01.atlas.cogentco.com (66.28.5.177) 0.830 ms 0.666 ms 0.642 ms
3 p14-0.core01.ord01.atlas.cogentco.com (66.28.4.41) 46.447 ms 46.393 ms 46.517 ms
4 206.220.243.184 (206.220.243.184) 76.714 ms 76.729 ms 76.644 ms
5 rc2ch-pos2-0.il.shawcable.net (66.163.65.2) 77.038 ms 77.001 ms 76.804 ms
6 rc1so-pos13-0.cg.shawcable.net (66.163.76.85) 111.869 ms 117.980 ms 111.880 ms
7 * * *
8 * * *
9 *

That's Chicago, right?

someone submited this ticket on the tranxact ticket system for a server at Dragon networks (server host) with the block listed above - this is not on the DV2 network. This is acrosst he street in Glboal compass - if you have had 6 hours of trouble - you should open a ticket with them online .

I was wondering where all this dragon network stuff was coming into a DV2 thread at. Had me confused so I just stayed quite.

As far as DV2 the data center accross the street from Dragon things are good, servers online and downtime was nothing more than a momentary blip.

I'm with serverhost/dragon ...
on that 209.124.* and I have the same fuc*king problem...
for the last ... ~ 11 Hs.

I want to read the 100% uptime SLA now :)

Regards.

From Techs:

Here is what happened. It is a truly honest mistake made by DV2.



A while back Dragon loaned DV2 some IP space, the block 209.124.80.x/20 I believe is the total block.

Anyway, they were removed from the configs about a month ago and all customers were moved off of that block.

Last night around 12 DV2 installed a backup RSP (processor card for their router). It had some old configs on it, so it began to announce the block of IP space that you were on and having difficulty with. So basically, two networks were announcing the same block of space to the same provider….that can’t happen, If it does, what happened this morning, is what happens.



So, I had a time trying to get in touch with someone over there as the night time guys aren’t the network guys…this morning they removed the old configs and all cleared up.



Sorry for the inconvenience. It was a freak occurrence, since we had loaned them space a while back and it was on that old configuration.





It is not likely that this will happen again. Most providers have route filters that keep stuff like this from happening. Only difference here is that Cogent was accepting the route from DV2 because they had been using it due to our loaning it to them.



Sorry for the problems.

Yeah... I received the same mail ...

But then ... where's the 100% uptime SLA now ? :eek:
I think they will do some discount on our charges .... doesnt it? :D

Originally posted by Montage Inc
Is www.netrail.net still having problems??

No, it's same as usual. A bit better actually. Are you having problems with Netrail?

yes it is... but its definately not the case outa vancouver... :P i'll get u some traceroutes outa here... heh

[edit]

just noticed something... cg = calgary... very close to vancouver... well... closer than chicago is... the route should have gone up the west coast, not up central... i think the reason the routes from here to cogent are going thru DC is cuz peering agreements don't really let transfer be all that asymetrical... usually there are limits by how much the ratio for incoming vs outgoing transfer on a peering feed can be... and cogent of course is kinda one-sided... with all the webhosts/etc using them... 111ms is really pathetic... in a case like that... from sfo to calgary... i wouldn't expect anything more than 40ms... maybe 50 on the very high side...

Originally posted by Gernot


Sorry to disappoint you once again:

traceroute to shawcable.com (24.64.63.20), 30 hops max, 38 byte packets
1 f13.ba01.b003070-1.sfo01.atlas.cogentco.com (66.250.4.165) 0.450 ms 0.407 ms 0.384 ms
2 g0-2.core01.sfo01.atlas.cogentco.com (66.28.5.177) 0.830 ms 0.666 ms 0.642 ms
3 p14-0.core01.ord01.atlas.cogentco.com (66.28.4.41) 46.447 ms 46.393 ms 46.517 ms
4 206.220.243.184 (206.220.243.184) 76.714 ms 76.729 ms 76.644 ms
5 rc2ch-pos2-0.il.shawcable.net (66.163.65.2) 77.038 ms 77.001 ms 76.804 ms
6 rc1so-pos13-0.cg.shawcable.net (66.163.76.85) 111.869 ms 117.980 ms 111.880 ms
7 * * *
8 * * *
9 *

That's Chicago, right?

where's the 100% uptime SLA nowI have 2 servers with Dragon and I doubt the SLA is valid in this case as I don't really think you can class it under a network outage. This was totally out of their control, thus I think you can forget about getting a discount.

Yes, one of my servers was affected, but it only has one site on it at the moment, so I don't really care about the downtime. I did phone them to ask what was going on. Three rings and a tech picked up and politly answered my question. The thought that tech support is actually available as promised makes up for this little 'accident'.

Lets get back on topic, this is NOT a Dragon Networks thread, if you want to talk about Dragon, open another thread.

Imran

hrm.. well actually... DV2 caused my server to be down cause this ip block "accident" ...
now, we are on topic :)

Originally posted by netdude
yes it is... but its definately not the case outa vancouver... :P i'll get u some traceroutes outa here... heh

[edit]

just noticed something... cg = calgary... very close to vancouver... well... closer than chicago is... the route should have gone up the west coast, not up central... i think the reason the routes from here to cogent are going thru DC is cuz peering agreements don't really let transfer be all that asymetrical... usually there are limits by how much the ratio for incoming vs outgoing transfer on a peering feed can be... and cogent of course is kinda one-sided... with all the webhosts/etc using them... 111ms is really pathetic... in a case like that... from sfo to calgary... i wouldn't expect anything more than 40ms... maybe 50 on the very high side...



Hehe, I knew you would come up with that.

Now, here's also an interesting example thru C&W / Exodus:

traceroute to shawcable.com (24.64.63.20), 30 hops max, 38 byte packets
1 iocom-pnet-FA0-0.iocomcorp.net (206.224.79.77) 1.305 ms 0.654 ms 0.608 ms
2 aus-gw-S2-0-DS3.iocomcorp.net (206.224.79.37) 1.593 ms 1.587 ms 1.625 ms
3 209-99-107-65.texas.net (209.99.107.65) 2.171 ms 2.389 ms 1.865 ms
4 lc1.gw1.aus1.texas.net (216.166.60.1) 1.976 ms 1.957 ms 2.034 ms
5 bb1.gw2.aus1.texas.net (216.166.60.18) 1.838 ms 1.827 ms 1.726 ms
6 64.92.154.33 (64.92.154.33) 2.999 ms 2.795 ms 2.687 ms
7 216.34.160.250 (216.34.160.250) 3.045 ms 162.117 ms 3.093 ms
8 agr1-so-3-1-0.Dallas.cw.net (208.172.139.5) 8.345 ms 8.422 ms 8.310 ms
9 dcr2-so-6-0-0.Dallas.cw.net (208.172.139.177) 8.604 ms 8.506 ms 8.290 ms
10 dcr1-loopback.NewYork.cw.net (206.24.194.99) 46.828 ms 46.778 ms 46.273 ms
11 ahr1-pos-0-0.Weehawkennj2.cw.net (206.24.207.34) 46.438 ms 46.693 ms 46.447 ms
12 * * *
13 * * *
14 core1-montrealak-pos4-0.in.bellnexxia.net (64.230.240.77) 54.254 ms 54.357 ms 54.569 ms
15 core4-toronto12-pos0-3.in.bellnexxia.net (64.230.240.18) 112.533 ms 204.262 ms 205.542 ms
16 core1-toronto12-pos0-1.in.bellnexxia.net (64.230.242.198) 64.917 ms 65.134 ms 64.284 ms
17 * * *
18 * * *
19 64.230.231.138 (64.230.231.138) 99.292 ms 86.121 ms 86.487 ms
20 * * *
21 *

My favorite traceroute yet. While I'll only credit eServers with the last few hops check out the route taken from a cablemodem in Florida:

Tracing route to 216.180.224.10
over a maximum of 30 hops:

1 43 ms 15 ms 11 ms 10.51.240.1
2 * * * Request timed out.
3 * * * Request timed out.
4 10 ms 12 ms 15 ms 68.56.0.130
5 13 ms 17 ms 14 ms 12.119.95.53
6 14 ms 69 ms 15 ms gbr3-p100.ormfl.ip.att.net [12.123.218.34]
7 57 ms 25 ms 25 ms gbr4-p60.ormfl.ip.att.net [12.122.5.138]
8 27 ms 29 ms 45 ms gbr3-p10.attga.ip.att.net [12.122.2.129]
9 33 ms 28 ms 28 ms gbr4-p60.attga.ip.att.net [12.122.1.142]
10 65 ms 46 ms 48 ms gbr3-p20.dlstx.ip.att.net [12.122.2.89]
11 85 ms 77 ms 78 ms gbr3-p30.la2ca.ip.att.net [12.122.3.70]
12 85 ms 89 ms 86 ms gbr4-p90.sffca.ip.att.net [12.122.2.170]
13 86 ms 88 ms 86 ms ggr1-p370.sffca.ip.att.net [12.123.13.69]
14 95 ms 93 ms 96 ms nr1-p350.paix.ip.att.net [12.123.221.2]
15 436 ms 342 ms 292 ms 205.215.1.169
16 163 ms 202 ms 175 ms p5-0.tr1.SanFrancisco1.CA.us.netrail.net [205.21
5.12.1]
17 175 ms 176 ms 174 ms g3-0.pr1.atl01.netrail.net [66.28.28.202]
18 270 ms 264 ms 325 ms 205.215.2.6
19 474 ms 485 ms 431 ms 209.51.130.226
20 403 ms 399 ms 489 ms 216.180.224.10

For those without patience the packet appears to go from Florida to Atlanta, Georgia to Dallas, Texas to Los Angeles, CA to San Francisco, CA to the Netrail peer before shooting back to Atlanta, Georgia for DV2.

And as if that's not bad enough the ATT/Cogent peering adds a nice bit of latency!

almost all of our traffic is outbound so - here is the real indicator of that. Not bad at all in my book.

please post tracerts from the server out as this is the best measure of performance.

Tracing route to 68.56.0.130 over a maximum of 30 hops

1 19 ms 18 ms 18 ms [209.51.137.

2 19 ms 19 ms 19 ms atl-core-router-b.dv2.net [209.51.137.77]
3 19 ms 17 ms 18 ms f13.ba01.b000173-0.atl01.atlas.cogentco.com [
28.28.253]
4 19 ms 19 ms 19 ms g9-2.core01.atl01.atlas.cogentco.com [66.28.5
5]
5 19 ms 18 ms 20 ms g6-1.core03.atl01.atlas.cogentco.com [66.28.4
2]
6 18 ms 20 ms 20 ms ge4-0.er1.atl4.us.mfnx.net [64.124.51.161]
7 18 ms 19 ms 19 ms so-3-0-0.cr2.atl2.us.mfnx.net [208.184.232.17
8 19 ms 19 ms 19 ms pos1-0.per1.atl2.us.mfnx.net [208.185.0.226]
9 19 ms 19 ms 19 ms above-gw.attga.ip.att.net [192.205.32.181]
10 94 ms 95 ms 94 ms gbr3-p50.attga.ip.att.net [12.123.20.250]
11 103 ms 104 ms 103 ms gbr4-p50.ormfl.ip.att.net [12.122.2.130]
12 107 ms 106 ms 108 ms gar1-p360.fldfl.ip.att.net [12.123.218.65]
13 108 ms 109 ms 110 ms gar1-p370.tmpfl.ip.att.net [12.123.218.37]
14 123 ms 110 ms 112 ms 68.56.0.130

Trace complete.

C:\WINDOWS>

bah, windows :D

Originally posted by sailor

Tracing route to 68.56.0.130 over a maximum of 30 hops

1 19 ms 18 ms 18 ms [209.51.137.

2 19 ms 19 ms 19 ms atl-core-router-b.dv2.net [209.51.137.77]
3 19 ms 17 ms 18 ms f13.ba01.b000173-0.atl01.atlas.cogentco.com [
28.28.253]
4 19 ms 19 ms 19 ms g9-2.core01.atl01.atlas.cogentco.com [66.28.5
5]
5 19 ms 18 ms 20 ms g6-1.core03.atl01.atlas.cogentco.com [66.28.4
2]
6 18 ms 20 ms 20 ms ge4-0.er1.atl4.us.mfnx.net [64.124.51.161]
7 18 ms 19 ms 19 ms so-3-0-0.cr2.atl2.us.mfnx.net [208.184.232.17
8 19 ms 19 ms 19 ms pos1-0.per1.atl2.us.mfnx.net [208.185.0.226]
9 19 ms 19 ms 19 ms above-gw.attga.ip.att.net [192.205.32.181]
10 94 ms 95 ms 94 ms gbr3-p50.attga.ip.att.net [12.123.20.250]
11 103 ms 104 ms 103 ms gbr4-p50.ormfl.ip.att.net [12.122.2.130]
12 107 ms 106 ms 108 ms gar1-p360.fldfl.ip.att.net [12.123.218.65]
13 108 ms 109 ms 110 ms gar1-p370.tmpfl.ip.att.net [12.123.218.37]
14 123 ms 110 ms 112 ms 68.56.0.130


While I'm accustomed to seeing asymmetric routes for improved performance why is the outgoing decent and the incoming horrid!? The incoming packets appear to be misdirected at the Georgia att router; Is Cogent not broadcasting it's incoming routes properly?