anyone else having major connection issues on Be?

  • Thread starter Thread starter uv
  • Start date Start date

uv

uv

uv

Soldato
Joined
16 May 2006
Posts
8,435
Location
Manchester
Howdy :)

Was playing some BFBC2, then noticed my ping was averaging at ~800 :/

Here's my tracert to Bethere:

Code: 
C:\Users\Ian>tracert -w 2000 bethere.co.uk

Tracing route to bethere.co.uk [94.236.39.6]
over a maximum of 30 hops:

  1    <1 ms    <1 ms     1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5    11 ms    11 ms    11 ms  linx.edge3.lon.rackspace.net [195.66.224.116]
  6    12 ms    20 ms    12 ms  vl911.core5a.lon3.rackspace.net [92.52.76.203]
  7    35 ms    13 ms    13 ms  aggr301a-core5a.lon3.rackspace.net [92.52.76.75]

  8    26 ms    15 ms    19 ms  94.236.39.6

Trace complete.

C:\Users\Ian>

It's getting really quite annoying now.. is anyone else having these issues?
 
Given your occupation I didn't expect that from you, bigredshark.

I am on BE, in the Manchester area, and having no problems at all.

Code: 
C:\Users\ncjok>tracert bethere.co.uk

Tracing route to bethere.co.uk [94.236.39.2]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  dg834 [192.168.0.1]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5    20 ms    19 ms    20 ms  linx.edge3.lon.rackspace.net [195.66.224.116]
  6    21 ms    21 ms    20 ms  vl911.core5a.lon3.rackspace.net [92.52.76.203]
  7    21 ms    22 ms    21 ms  aggr301a-core5a.lon3.rackspace.net [92.52.76.75]

  8    22 ms    21 ms    21 ms  94.236.39.2

Trace complete.

Not like pinging bethere.co.uk tells one much about the connection to an unspecified game server.
 
ncjok said:
Not like pinging bethere.co.uk tells one much about the connection to an unspecified game server.
Click to expand...

I get the same issue tracing to any destination.

It could be our local exchange on the fluff :/
 
What issue? Read Azuse05's comment.

Show us a trace to the actual game server you connect to.

edit: Scratch my last request. Connection issues in BC2 can arise due to factors other than the simple routing between your client machine and the game server. As that wasn't exactly the question you raised in the OP I'll wait to see if you want to pursue it.
 
Last edited:
ncjok said:
What issue? Read Azuse05's comment.

Show us a trace to the actual game server you connect to.
Click to expand...

This issue:

Code: 
C:\Users\Ian>tracert 81.19.214.84

Tracing route to server.killercreation.co.uk [81.19.214.84]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5    38 ms    25 ms    29 ms  linx.killercreation.co.uk [195.66.225.123]
  6    16 ms    15 ms    14 ms  rt-2-cent.killercreation.co.uk [217.146.94.2]
  7    54 ms    13 ms    13 ms  server.killercreation.co.uk [81.19.214.84]

Trace complete.

*edit*

never had problems tracert'ing before, so if it's a Be low priority thing, it's very recent.
 
As per other peoples posts, routers de-prioritising ICMP traffic is very normal. As long as you're not seeing PL to the end hop then the PL to the router(s) is not an issue - anyone saying differently is quite frankly wrong!
 
Fine this end too

Code: 
C:\Users\Dave>ping bethere.co.uk

Pinging bethere.co.uk [94.236.39.6] with 32 bytes of data:
Reply from 94.236.39.6: bytes=32 time=8ms TTL=58
Reply from 94.236.39.6: bytes=32 time=7ms TTL=58
Reply from 94.236.39.6: bytes=32 time=7ms TTL=58
Reply from 94.236.39.6: bytes=32 time=7ms TTL=58

Ping statistics for 94.236.39.6:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 8ms, Average = 7ms

C:\Users\Dave>tracert bethere.co.uk

Tracing route to bethere.co.uk [94.236.39.6]
over a maximum of 30 hops:

  1    45 ms    99 ms    99 ms  BeBox.config [192.168.1.254]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     7 ms     8 ms    10 ms  linx.edge3.lon.rackspace.net  [195.66.224.116]
  5     9 ms     9 ms     8 ms  vl911.core5a.lon3.rackspace.net  [92.52.76.203]
  6    10 ms     9 ms     9 ms  aggr301a-core5a.lon3.rackspace.net  [92.52.76.75]

  7    12 ms     7 ms     8 ms  94.236.39.6

Trace complete.

C:\Users\Dave>
 
Azuse05 said:
That's be deliberately assigning them the lowest priority i.e. normal.
Click to expand...

No, lack of replies like that is far from normal. I design these networks so I should know. It's indicative of either the supervisor/RE on the box being too busy for sense (which is a fault condition) or a link being saturated to the point where traffic is being dropped (which should be a fault condition). Under normal operation every hop should respond to ICMP because anything else, among other things, breaks path MTU discovery.

It's not a terminal fault but it's bad design or bad implementation and isn't 'normal'.

EDIT: I suspect in this case, as it's be, who have a history of being incapable of capacity planning, that it's saturated links.
 
axer said:
As per other peoples posts, routers de-prioritising ICMP traffic is very normal. As long as you're not seeing PL to the end hop then the PL to the router(s) is not an issue - anyone saying differently is quite frankly wrong!
Click to expand...

You're actually missing something here, ICMP is usually assigned a fairly high DSCP value as it's nominally control plane/management traffic and dropping it's a bad idea. What is usually de-prioritised is the routers CPU responding to ICMP, however that should not be an issue in any ISP network because the control plane CPU and forwarding logic and discrete components on any router of that size and hence the CPU should be running below 20% all the time, hence there's no reason for it not to respond.
 
Or, last option, be have deliberately filtered responses from the router to customer ranges (not impossible) in which case this is normal and their idiots because they just broke a long list of features that some applications depend on (path MTU etc etc)
 
bigredshark said:
You're actually missing something here, ICMP is usually assigned a fairly high DSCP value as it's nominally control plane/management traffic and dropping it's a bad idea. What is usually de-prioritised is the routers CPU responding to ICMP, however that should not be an issue in any ISP network because the control plane CPU and forwarding logic and discrete components on any router of that size and hence the CPU should be running below 20% all the time, hence there's no reason for it not to respond.
Click to expand...

Just because you don't think that ISP's should filter ICMP traffic doesn't mean they don't know and that's quite clearly what's happening here...
 
axer said:
Just because you don't think that ISP's should filter ICMP traffic doesn't mean they don't know and that's quite clearly what's happening here...
Click to expand...

No, there's no proof at all that's what's happening here, and if they do so they're breaking best practice and several useful network functions (not to mention making fault finding more difficult) and for no good reason at all.

Cisco say it's a pointless idea, Juniper say it's a pointless idea, that's 80%+ of the carrier router market saying don't do it.
 
Be and common-sense don't really mix. We've been waiting for sra since forever too, but the line fast, no one ever complains about high usage, pings are low and the staff (generally) quite helpful, so most people choose to overlook the small faults.
 
The reason for that is actually fair easy to explain, their staff don't have any access to anything more than slightly technical, the network is maintained under contract by alcatel-lucent so anything which requires their input will be much harder to get done.
 
You must log in or register to reply here.
Back
Top Bottom