Birmingham down as well
Had problems with DSL in Birmingham from midnight, BT are trying to resolve but have had to divert resources to Paddington to sort the problem there. This from my ISP Entanet
http://noc.enta.net/
A fire at a BT building in central London is causing widespread landline, internet and mobile network problems, according to reports. A blaze at Burne House in North Paddington was reported this morning. According to Gradwell, a business ISP, 437 local exchanges and up to 37,500 Datastream circuits have been affected. It said …
Two factors at work here.
1. Nobody wants to risk halon, co2 or other methods of fire suppression which take out the fire by smothering it. The UK H&S act pretty much took care of that. If someone dies, you are guilty by default regardless of how much measures did you put in to prevent this. This is rather silly as the person can die in fire or from electrical shock once the water goes in same way as from Halon or Co2. In fact if there are cabinets with masks at every X meters in any direction Halon or CO2 are inherently safer than water. That however is impossible to explain to the idiots from Connect and other union w*nkers. So end of the day you put sprinklers in knowing that any equipment on that floor unaffected by fire will be destroyed by water. This happens on casual basis in all providers - BT has had it before, IIRC Level3 has had it, either Globix or Global Lossing had it as well.
2. The power distribution architecture in nearly all colocation facilities in the UK does not have per-rack cut-off. You do not really need to turn on sprinklers if you have per rack cut off for electricity and cooling so you can stop electricity as well as pumping fresh air to the rack in question and X neighbouring racks for 5-10 minutes before you push the big red button. It is not that difficult to plan, build and even retrofit a datacenter so you can take down completely sections from it. Considering that a rack of telecoms equipment can easily cost north of half a million pounds the common ineptitude in power and cooling design by UK telecoms operators is outright criminal. Though once again some of that can be blamed on H&S and the way it has been exploited by unions under Nu LieBore.
Actually, many data centre facilities use a high fog mist system to suppress fire which is entirely different from "sprinklers". It's also a hell of a lot safer than halon or co2 based suppression methods.
Methinks you've never actually worked in a data centre from the nonsense you've just spouted, I in fact have.
I thought that the interwebs were supposed to be robust enough to suffer nuclear destruction of some of it's connection nodes....
If one fire in one exchange was enough to bring down the national communication infrastructure, maybe the USSR should have invested in napalm rather than nukes...
As has been pointed out, you'll find the interwebs are running just fine thanks. If you put an axe through your router at home, you'll find much the same effect.
The idea of the nuclear defended network is so that the rest of the world (well, US) could still talk even if, say, Washington DC was suddenly replaced by a crater. Bear in mind also that the Internet is not a singular entity. A better description is a network of networks. One of the subnetworks is out - that's all.
If you think this is bad, consider what would happen if Telehouse Docklands were to disappear. Fortunately the more important a node, the more redunancy built in.
Your theory is far from practice. Replace london with a crater and then come tell me if the rest of the UK will be able to access anything. The chances are, all the peripheral nodes will go down as well just from the lack of routing paths. Yes, you will find that many times your packets take some pretty long routes in order to reach their destination and those routes usually go through some main exchange points.
If data for other parts of the country are being routed via central London, but they can't be more specific about whom or where. I'm just glad I'm no longer a customer of theirs, for so many reasons. This is despite the monthly 'Come Back to BT!' junk mail I seem to receive. Sometimes I don't know how I summon the willpower to overcome its hypnotic effect...
Wow, I know this is a major exchange but surely this is the reason this kind of thing is planned for. I wouldn't mind but we were running a DR scenario today that has been pulled due to this, irony indeed.
We've lost one satellite office and it is still chunking up our network nicely - If anyone is interested BT have informed us that they should have a solution in place by 16:15 - Although by the sounds of this article I am beginning to doubt it.
That's one fuck of a big exchange, lots of major routing through there - sort of line of sight up the Edgeware Road towards Birmingham.
One would assume that there are traffic jams as the rest of the system tries to re-route it all - think of the M25 being suddenly closed around Dartford Crossing on a bank holiday.
Not sure that redundancy would help in this case as it sounds like it's not just one or two major links that have gone.
( there are times when I almost wish I was back there - a few key presses and clicks and I'd know what was out)
This, according to SagePay website:
http://www.sagepay.com/system_monitor.asp
31 March 2010 12:02:45 - Please be advised Lloyds Cardnet and Halifax Bank of Scotland customers are currently unable to process transactions via the Sage Pay gateway.
This is due to a BT communications network failure, and not an issue on the processing platforms.
We are currently awaiting an update from the respective parties.
Expect other card services to be impacted.
This from a SagePay communication email:
Hello,
We'd like to update you on an external issue which is effecting nationwide telecomms/datacomms.
British Telecom has confirmed a fire at their Exchange in the Paddington area of London. This has impacted a huge number of UK businesses, including Sage Pay and the major banks that route transactions through the Exchange. Sage Pay has taken action on your behalf by quickly moving transaction processing to our backup data centre. However, the issue has affected connectivity to some banks who rely on the exchange and we are currently unable to process via those banks at this time.
Please note, as banks and payment providers look for alternative transaction routing solutions away from the Paddington Exchange, this could create some general capacity issues, resulting in transaction 'time-outs'.
Incident Report from SagePay:
At 9:50am this morning we had problems connecting to the authorising banks.
We investigated and subsequently moved our authorisations to our DR site which was processing at 9:59
After a brief period of processing the authorisations slowed, this was a result of many people moving to backup configurations to route round an issue that transpired to be a fire at a main telecoms/datacoms exchange in docklands.
Within minutes the bottle neck had eased and we were processing transactions for all banks except HBOS and Lloyds TSB. We switched the destination NUA’s to the backups and there was still nothing being processed by those banks
We made the appropriate calls and even though our backup X25 system worked perfectly it transpires that the bureau responsible for processing HBOS and Lloyds transactions did not have resilience outside of that exchange.
We have been working with the bureau and alternative to X25 in order to resolve the issue.
As of 15:15 we now have a workaround in place, however with the X25 network working at a much reduced capacity we are experiencing delays in processing transactions
Every time there is an outage of this sort there is at least one commentard who goes on about redundancy. Last week we had an outage at one of our sites which took down chip and pin for almost a whole day, this was down to an equipment failure at a BT exchange which, to be fair to BT they worked into the early hours to fix. However we got it in the ear from our customer because they said that (a) they should have been warned in advance so they could implement their BCP and (b) the system should be redundant to prevent this sort of thing happening.
We answered (a) that the point of your BCP is that it's a robust plan to account for emergencies and you don't often get warning of emergencies, unless they happen to be caused by an earthquake and you happen to speak toad. And (b) that BT could probably make every bit of kit and every single circuit redundant, they could have redundant power supplies and diverse routed circuits and it would all cost a fortune.
If BT or your ISP increased your bill by 100% or more to implement this redundancy would you be happy to pay?
The internet is packed full of redundancy. To use some old terminology if a hub site goes down somewhere the rest of the network will route around it, but you still have a big hole around that site. Any edge site that connects into that hub will be down until the hub site is back on line. If the end user wants redundancy then they need to connect to more than one hub site.
Well said.
Typically customers look at the cost of a redundant/diverse network and decide it's too expensive. Then they get an outage like this and re-evaluate the business risk. Go figure.
Biggest SPF on networks are the single circuits to customer and for retailers or small businesses running on xDSL, that's very difficult to provide any kind of diverse path back to the exchange. But it's cheap, until it goes wrong and you can't trade. Linked to that is the xDSL termination at the ISP side. Those circuits are expensive, so if ISP's don't have diverse connectivity to multiple terminating sites, there's another SPF but that one is more outside of the end customer's control, unless they ask their provider the right questions.
Unfortunately it often takes outages like this for customers to reconsider their network design, BCP and whether the cost of a resilient network solution is right for them. YGWYPF.
Serious Incident Briefing
Flooding in North Paddington Exchange
Issue No. 1 Issued at: 31/03/2010
Start: 31/03/2010 Declared SI: 31/03/2010
Finish: Ongoing
Reason For SI (SI Criteria): FLOODING IN NORTH PADDINGTON EXCHANGE
Following major flooding in North Paddington exchange, a large number of customers in parts of North and West London may be experiencing a loss of broadband and/or telephony service. Customers in other parts of the country may also be affected.
We are currently working on restoring services to customers, however as this is a complex incident we cannot accurately predict when all services will be restored.
We will issue further updates as the situation changes.
Dialling Codes Affected: 01132 01142 01159 01162 01179
01189 01202 01204 01205 01206
01207 01208 01209 012121 012123
012124 012132 012135 012136 012138
012142 012145 012150 012152 012153
012155 012160 012161 012171 012174
012177 01223 01224 01225 01226
01227 01228 01229 01233 01234
01235 01236 01241 01242 01243
01244 01245 01246 01248 01252
01253 01254 01255 01256 01257
01264 01268 01270 01271 01273
01274 01275 01276 01277 01278
01279 01280 01283 01284 01285
01286 01290 01291 01292 01293
01294 01295 01296 01297 01298
01302 01303 01304 01305 01306
01308 01309 013122 013133 013134
013144 013155 013156 013166 01322
01323 01324 01327 01329 01332
01335 01341 01342 01343 01344
01352 01353 01354 01355 01359
01361 01366 01367 01369 01371
01372 01375 01376 01379 01380
01382 01384 01386 01387 01388
01389 01392 01394 01395 01403
01404 01407 01409 014124 014135
014142 014155 014156 014157 014158
014177 014188 014193 014194 014195
01420 01422 01423 01424 01425
01428 01430 01434 01435 01438
01440 01442 01443 01444 01446
01449 01452 01453 01454 01455
01457 01458 01460 01462 01463
01472 01473 01474 01480 01483
01484 01487 01488 01489 01491
01492 01493 01494 01495 01502
01503 01506 01508 015120 015123
015129 015135 015142 015152 015162
015163 015164 015170 015172 01522
01524 01526 01527 01529 01530
01535 01536 01539 01543 01548
01553 01554 01555 01561 01563
01569 01572 01573 01576 01579
01580 01582 01590 01592 01600
01603 01604 01608 01609 016122
016123 016133 016140 016144 016147
016148 016149 016162 016163 016174
016178 016179 016183 016192 016194
01621 01622 01623 01625 01626
01628 01633 01634 01635 01638
01639 01642 01646 01652 01655
01656 01661 01665 01666 01667
01670 01672 01673 01675 01676
01678 01689 01690 01691 01697
01698 01702 01704 01706 01707
01708 01724 01725 01726 01727
01728 01729 01730 01732 01733
01736 01737 01738 01743 01744
01745 01747 01749 01750 01752
01753 01754 01760 01763 01764
01766 01767 01768 01772 01773
01775 01778 01780 01782 01784
01785 01786 01787 01788 01789
01792 01793 01794 01795 01797
01798 01799 01803 01822 01823
01824 01825 01827 01842 01843
01844 01851 01865 01869 01872
01873 01883 01884 01892 01895
01896 01900 01902 01903 01904
01905 01908 01909 019123 019125
019126 019127 019128 019129 019137
019138 019141 019143 019145 019148
019149 019151 01920 01922 01923
01924 01925 01926 01932 01933
01934 01935 01937 01942 01943
01945 01946 01947 01952 01953
01959 01962 01964 01975 01977
01978 01980 01983 01986 01992
01993 0203033 0203073 0203075 0203076
0203112 0203119 0203122 0203144 0203181
0203204 0203205 0203206 0203214 0203219
0203229 0203230 0203235 0203238 0203268
0203275 0207052 0207093 0207121 0207159
0207165 0207168 0207209 0207221 0207222
0207224 0207225 0207228 0207229 0207231
0207233 0207237 0207240 0207243 0207245
0207248 0207250 0207253 0207256 0207258
0207259 0207262 0207265 0207266 0207278
0207283 0207286 0207287 0207289 0207292
0207307 0207317 0207319 0207321 0207328
0207329 0207332 0207340 0207351 0207353
0207354 0207355 0207357 0207358 0207370
0207371 0207372 0207373 0207376 0207377
0207379 0207380 0207383 0207384 0207385
0207387 0207388 0207389 0207394 0207399
0207402 0207403 0207407 0207408 0207409
0207412 0207419 0207427 0207431 0207432
0207433 0207434 0207435 0207436 0207437
0207439 0207443 0207447 0207449 0207460
0207467 0207474 0207476 0207478 0207479
0207481 0207483 0207486 0207487 0207488
0207491 0207493 0207494 0207495 0207498
0207499 0207511 0207512 0207513 0207515
0207516 0207519 0207520 0207534 0207535
0207536 0207537 0207538 0207563 0207565
0207569 0207580 0207581 0207582 0207584
0207586 0207589 0207590 0207591 0207600
0207602 0207603 0207604 0207606 0207613
0207616 0207619 0207624 0207625 0207626
0207629 0207630 0207637 0207638 0207647
0207655 0207681 0207689 0207691 0207692
0207702 0207706 0207713 0207715 0207719
0207722 0207723 0207724 0207725 0207726
0207730 0207733 0207734 0207736 0207738
0207739 0207794 0207796 0207799 0207812
0207813 0207821 0207823 0207824 0207828
0207833 0207834 0207835 0207836 0207837
0207839 0207851 0207858 0207881 0207907
0207916 0207924 0207925 0207928 0207929
0207930 0207935 0207937 0207938 0207976
0207987 0207993 0208177 0208203 0208232
0208269 0208290 0208301 0208309 0208330
0208342 0208346 0208366 0208368 0208371
0208394 0208398 0208399 0208400 0208408
0208420 0208421 0208423 0208427 0208445
0208449 0208458 0208466 0208467 0208502
0208503 0208506 0208520 0208530 0208538
0208543 0208547 0208549 0208561 0208563
0208567 0208569 0208573 0208574 0208577
0208579 0208596 0208604 0208605 0208606
0208621 0208653 0208655 0208657 0208663
0208668 0208671 0208675 0208677 0208678
0208686 0208687 0208688 0208691 0208692
0208693 0208694 0208697 0208699 0208704
0208723 0208726 0208731 0208732 0208735
0208741 0208742 0208747 0208748 0208749
0208754 0208759 0208769 0208770 0208785
0208789 0208803 0208805 0208809 0208834
0208838 0208840 0208842 0208843 0208846
0208853 0208861 0208864 0208871 0208874
0208877 0208878 0208892 0208896 0208897
0208905 0208908 0208916 0208940 0208942
0208946 0208948 0208950 0208953 0208960
0208962 0208963 0208964 0208968 0208969
0208974 0208987 0208993 0208994 0208995
0208996 0208998 0238020 0238023 0238024
0238040 0238042 0238043 0238046 0238047
0238066 0238076 0238077 0238083 0238084
0238087 0238089 0238090 0239229 0239232
0239246 0239255 0239257 0239259 0239261
0239263 0239264 0239275 0239278 0239281
0247622 0247627 0247632 0247633 0247640
0247654 0247660 0282563 0282564 0282565
0282826 0282827 0283025 0283026 0283834
0287032 0287034 0287035 0287126 0287127
0287128 0287130 0287136 0287137 0288775
0289029 0289030 0289031 0289036 0289043
0289060 0289061 0289062 0289068 0289069
0289085 0289086 0289094 0289096 0289180
0289181 0289182 0289185 0289260 0289262
0289263 0289264 0289266 0289267 0289332
0289335 0289336 0289442 0289445 0289446
0289447 0289448 0292022 0292023 0292047
0292059 0292073 LLCL0 LLCM0 LLEA0
LLEM0 LLES0 LLLC0 LLLN0 LLLS0
LLLV0 LLLW0 LLMR0 LLMY0 LLND0
LLNE0 LLNI0 LLSD0 LLSL0 LLSM0
LLSS0 LLST0 LLSW0 LLTH0 LLWE0
LLWN0 LLWR0 LLWS0 LLWW0 To Fo
There's quite a few Lincolnshire codes in there too. Explains why my rural Interweb has been down for the last 24 hours.
Nice of Pipex to have an 'All is well' message on their status page dated 2008. Glad I stopped short of resetting my router and taking the debugging shotgun to the settings.
"data for other parts of the country are being routed via central London, but they can't be more specific about whom or where"
Dude, isn't that kind of the whole point of TCP/IP? I suspect BT have more important things to do than look at exactly where each packet is going - so long as it reaches its destination, however slow that may be, the internet's architecture has done its job.
We moved as we were sick of Sagepay's non-existant redundancy.
Thankfully, with it being pay-day today and just before a bank holiday, this has been one of our busiest days of the years. It would have fallen very flat if we'd still been with Sagepay.
£10,000s of lost income avoided thanks to forward thinking.
Funny - we had about 6 of our sites out today (out of 300 or so), but we heard about the MSO via the Register, not via our account mangler, or the service announcments.
And by 3pm, our BT contact centre had stopped accepting new calls because they were too busy. Given its location in the North of Scotland, I guess they had a fair number of staff away because of the snow. Its a good job the snow didn't fall in the South East, as all the home-workers wouldn't have been able too.. :)
I was about to post suggesting that you'd got the headline wrong, as it more usual to get flooding after the fire due to the efforts of Fireman Sam and his mates. Or the sprinklers.
Then I thought maybe BT got their logic confused and decided that if you could cure a fire with a flood, maybe you could dry out a flood with a fire? I'm glad that they've assured us this wasn't the case.
Ms Hilton, cos she's much better at dealing with unexpected heat & floods.
So you have to call their help line at vast expense, or try and navigate to their website (the link from the rss feed is broken)
It's nice to know they have a resiliant network, that can cope with any eventuality, thank goodness our buisness is in a tiny village so the exchange doesn't have the datastream link, but my home is out and won't be back on tell tomorrow at the earliest (according to the message).
I know it's a real problem with a real BT installation, but if this line was not added by the Reg for comic effect, it's proof that the gods have a sense of humour
A blaze at Burne House in North Paddington was reported this morning.
Next, a report from BT that they have suffered a second whammy because their national emergency backup centre at Loudwater was flooded early this morning.
... and my telephony just came back at around 8:30
Not sure about broadband but I am assuming that would work as well.
As Dr. Funk said, still fire engines there, must've been a big flood. I'm still curious as to how an electrical failure caused a flood which then caused a fire...
An electrical failure causing a fire causing a flood (through sprinklers) is understandable, but not the other way round. Unless they have water pumps running 24/7 which is just madness...
Land lines and broadband is back now in Marylebone. O2 down unless you could get sight of the BT Tower. T-Mobile went off for about 12 hours in all, too, a bit irritating to discover my 3G service was plumbed into the same place as the landline, without any routes around.
That said, now it's back the broandband connection is screamy loads faster...