Virgin routing issues

[Eric The Viking]

They've lost the plot again. For the last four days our broadbean access has been on/off, not knowing from one minute to the next whether it's working or not. Virgin have been (characteristically) less than helpful. I'm typing fast in case it goes off again...

Anyone else with Virgin broadbean, in the same soup?

 

[cambournepete]

Mines been fine AFAIK.

 

[studders]

Been a bit up and down lately. Got disconnected twice watching a Drama on iPlayer.

 

[Eric The Viking]

Forgot to say: I'm in Bristol.

(edit) ... and it's working fine, at this precise moment.

 

[TrimTheKing]

Do you know it's a routing issue? How?

 

[studders]

I think I'm served via Croydon so, not a lot of use to ya knowing my service.

 

[RobertMP]

2 or 3 times a year we will get the same thing for a few days then it is fine again. call them and the pre recorded message usually says there is work going on in the area.

I pay for 10meg broadband but most of the time get up to 40meg so on balance I'm not complaining.

 

[Eric The Viking]

Do you know it's a routing issue? How?

Thing #1: internal network is fine
Thing #2: cable modem behaving 'normally'
Thing #3: some servers (such as my mailserver, which is physically nearby) are reachable, when things like the BBC site aren't.
Thing #4: it comes and goes, and slows down and speeds up (using web pages as a guide).
Thing #5: when it does work, long-distance (e.g. NZ) is significantly slower than normal, but reachable, implying an odd route.

So taking that all together, something is rebuilding its routing tables rather painfully and often (during the problem period).

So yes, I'm guessing, and no, I haven't gone as far as tracert etc., but if I was a betting man it would be that someone's changed something in a rack somewhere, and it's taking a while to rebuild the tables.

Right now, mind, it's as fast as anything. So it may be fixed.

Famous last wor...

 

[matt]

http://status-cable.virginmedia.com/vmstatus/summary.do

 

[jlawrence]

Routing tables take next to no time to rebuild - in an organisation that size the routers shouldn't be building their own routing tables, the routes should be pushed to them from a master/slave arrangement.
That's not to say it's not a routing issue. More likely an interconnect issue - there have been a few recently in Internet Exchanges. But again we're guessing - there's likely a million and one things that can cause weird stuff on t'internet.

 

[TrimTheKing]

Thing #1: internal network is fine

Okay

Thing #2: cable modem behaving 'normally'

Not sure what 'normally is, but okay.

Thing #3: some servers (such as my mailserver, which is physically nearby) are reachable, when things like the BBC site aren't.

When you say 'physically nearby' how do you mean?

Thing #4: it comes and goes, and slows down and speeds up (using web pages as a guide).

Could be a link issue, could also be a contention issue. Have (can) you check the stats on the modem to see if you have a high CRC error rate on your WAN interface?

Thing #5: when it does work, long-distance (e.g. NZ) is significantly slower than normal, but reachable, implying an odd route.

Hmmm, routing can be an odd beast but your only routing concern will be getting from your house into Virgins network, after that it's their internal routing then out onto their country peer, so that would affect many more people than just you.

You mention tracert, it would be worth getting a tracert of a known problematic site now, while it's working, then get the same again when it goes castors up. This will tell you where any routing issues might be coming in.

So taking that all together, something is rebuilding its routing tables rather painfully and often (during the problem period).

So yes, I'm guessing, and no, I haven't gone as far as tracert etc., but if I was a betting man it would be that someone's changed something in a rack somewhere, and it's taking a while to rebuild the tables.

Hmmm, routing tables take seconds to reconverge, even less than seconds in most instances so an 'odd route' isn't really viable for any period of time unless they have a more serious issue. And if it was a serious routing issue it would be permanent rather than intermittant.

The most likely if the routing tables are regularly reconverging is a flapping route/link somewhere causing a routing relationship to flap, probably in 'the cloud' somewhere.

Sorry if this sounds like granny egg sucking lecture, it's not.

 

[Paul.J]

ETV wrote

For the last four days our broadbean access has been on/off, not knowing from one minute to the next whether it's working or not.

Been having the same problem here in sunny Brum
I gave em a call and they said there are no faults,and to switch the modem off blah blah blah..........
Then they told me to connect direct to the modem not via the router and it was/is still the same :roll:
Just got the router working as well
So i just hope it is something they are doing.

 

[TrimTheKing]

Hmmm, Brum and Bristol, sounds like they have some kind of internal issue then.

You need to get some traceroutes of sites that fail when they are working and when down, you can then escalate to their 2nd or 3rd line and press home your point.

 

[chingerspy]

Our Virgin internet was up/down a lot end of last week. Engineer came out and said everything was fine apparently. When I got home I found a line attenuator fixed to the back of the modem. Low signal level to blame then I guess and not nothing

 

[studders]

You need to get some traceroutes of sites that fail

A what? (and how?)

My web space provider is in US and I get some very long delays when using their admin panel. Would the above help or is it not related?

 

[chingerspy]

Click Start then run
Type cmd <ENTER>


in the command prompt type: tracert <address> i.e. bbc.co.uk <ENTER>

It should go off and perform the trace then. The amount of hops is how many points you go through from your PC to the destination (hops).

If its taking lots of hops then the connection is slow due.

At some point you may not get a response or it will time out, this could be a duff router somewhere. Or if near the destination some protection could be in place dropping your request.

 

[studders]

Click Start then run
Type cmd <ENTER>

Thanks for that but I'm on a Mac. Must be some similar way of doing it, just need to work it out. :?

 

[TrimTheKing]

You need to get some traceroutes of sites that fail

A what? (and how?)

My web space provider is in US and I get some very long delays when using their admin panel. Would the above help or is it not related?

I don't want to sound patronising so, how much do you know about IP connectivity?

I will assume not a lot for the purposes of this.

Firstly a basic intro to IP routing.

In very basic terms, all computers that want to talk to anything across the internet use a protocol called TCP/IP and each one will have a unique address (known as an IP address). Now there are public IP addresses (which are routable across the internet) and private IP addresses (generally used on your internal home network, and most likely to be an address in the following range 192.168.*.*) which are not routable across the internet.

Everything (and I mean everything) that wants to send info across the internet has to have a public IP address ( or proxy through one at least), and that includes all home pc's and all websites.

Okay, a tracert (or trace route) is a way to test what routing path your traffic is taking to get from your pc to wherever you are trying to contact.

To do a trace route you need to do the following (I use WinXP so it may be slightly different on Vista or 7, and on Mac's)

-Start
-Run
-In the box you type cmd and press enter. This will bring up a black DOS window
-Now pick a website and type the following - tracert www.yourwebsitehere.com (see example below)

C:\Documents and Settings\Mark>tracert www.google.co.uk

Tracing route to www-tmmdi.l.google.com [216.239.59.147]
over a maximum of 30 hops:

1 111 ms 99 ms 99 ms bebox.config [192.168.1.254]
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 22 ms 23 ms 22 ms 87-194-0-206.bethere.co.uk [87.194.0.206]
7 42 ms 23 ms 23 ms 64.233.175.27
8 44 ms 33 ms 38 ms 209.85.240.158
9 39 ms 37 ms 35 ms 66.249.95.169
10 47 ms 39 ms 50 ms 216.239.49.114
11 39 ms 36 ms 38 ms gv-in-f147.1e100.net [216.239.59.147]

Your output will look something like the above but don't worry too much if it's not the same numbers (in red), different ISP's will give back different responses depending on their routing path. What you need to worry about is if you do this one day when the site is working fine and get one set of results, then do it again when it's going slowly and see what you get. If you get a different set of red numbers that before then your traffic is taking a different route.

This doesn't automatically mean that there's a problem as traffic can legitimately take a different route depending on if there are devices down on the internet, but may well point towards there being a problem.

However, if any of the numbers with ms next to them (have highlighted one in cyan) are particularly high (high hundreds) then this could (but again sadly not guarantee) suggest that there is a device which is slowing things down somewhere along your routing path.

Hope that wasn't too boring

PS I'm not entirely sure why lines 2-5 are timeouts but there may well be firewalls/routers in the path that are set to not respond to ICMP packets so i'm not altogether worried by this.

 

[jlawrence]

The number of hops involved is somewhat irrelevant in the grand scheme of things, what you're looking for is anomalies with the times returned.
Here's an example of what I see from my systems to a godaddy address:
1 10.168.4.254 (10.168.4.254) 2.479 ms 3.533 ms 4.519 ms
2 cr1.sswsm.uk.easynet.net (87.87.253.40) 41.036 ms 41.265 ms 42.986 ms
3 ip-87-87-135-65.easynet.co.uk (87.87.135.65) 30.020 ms 30.395 ms 31.464 ms
4 te0-6-0-7.er10.thlon.ov.easynet.net (89.200.134.221) 39.447 ms 41.537 ms 41.990 ms
5 64.209.108.249 (64.209.108.249) 43.333 ms 43.748 ms 44.482 ms
6 64.210.13.110 (64.210.13.110) 185.459 ms 169.601 ms 178.697 ms
7 ip-208-109-112-198.ip.secureserver.net (208.109.112.198) 181.364 ms 182.751 ms 184.772 ms
8 ip-208-109-112-150.ip.secureserver.net (208.109.112.150) 181.725 ms 183.266 ms 183.881 ms

This shows a problem between hop 5 and 6. Whilst this is a hop across the Atlantic 140ms is a tad excessive so you then need to look further into it in order to see where the problem lies. Both ip addresses are part of global crossing's network (shown by a whois lookup) - so to me it looks like they've a problem with something between telehouse and where ever they're landing in the US.

Traceroute queries can timeout before they get to their destinations for many reasons, a common one is that the requests are dropped at a gateway firewall - damn annoying but a lot of admin's do this nowadays.

Studders: on a mac the command is likely to be just 'traceroute'.

 

[chingerspy]

Mac, ok sorry matey. Not got one in front of me but there is a trace tool in:

HDD>Utilities>Network Utility

This is on OSX at least... sorry don't play with them much and don't have one right now for reference. I think you can go into console too and run the tracert command (Linux boys might be able to correct this)