Colocation facilities in britian
Does anyone have ballpark costs on what colo space costs in England. We are getting a quote for 7500 gbp per month For 19 square meters of space. In us we pay 3500 a month for 10x10 cage at a quest facility Also I'd anyone can recommend some british colo companies would appreciate it Sent from Wireless BlackBerry
Re: Sprint Cellular: The Final Insult
Sprint certainly (luckily, not to me yet...) has a serious billing problem under certain mysterious conditions that nobody seems to ever be able to explain hence their ability to never fix.. I've been lucky but I have read of horror stories.. this not being the first. :( nealr wrote: We used to have five phones with Sprint. Two months ago we dropped them after six months of trying to get them to bill us for our plan. The bills had been consistently 50% - 100% over what we expected. Each time they were apologetic and a refund was issued. The final straw was an hour long call with a very helpful Sprint person who told me their internal systems were such a mess it was 'almost impossible' for them to provision a customer correctly if the customer had added phones as we had done. Her attempts to fix the problem only made the next month's bill worse. I spoke with someone at Sprint, told them we weren't going to put up with it any more, canceled our service, and told them they needed to have someone contact us to sort out how much of the $1,400 bill we actually owed. No one ever contacted me. A written complaint of a similar nature sent to their headquarters has also gone unanswered. Today I received a collection notice - not only the additional $1,400 due but they apparently failed to cancel our service on the basis of that call and let two more months of billing @ $300/month accumulate before placing the debt for collections. Our expected monthly rate was $175/mo and this 40% overcharge was fairly consistent with our experience with Sprint when we were a paid up customer. I can at this time wholeheartedly recommend against ever using Sprint's cellular service. We liked the service itself and bent over backwards trying to get the billing problems resolved, but they seem to be relentlessly incapable of managing their own internal systems in such a fashion as to provide good customer service. I have not yet read their 10Q/10K filings but when I see stuff like this on my own account and many other Sprint customers confirm that they've had similar experiences I have to wonder how well the company is doing financially. I see this collection notice and I imagine I am going to go ahead and pay the bill eventually, but this matter is going to be bitter pain for Sprint before I'm done. Sprint investor relations is the only visible receiver of this email but I know that a great many of you are like me - owners of businesses that might purchase cellular service, or technical staff in a position to influence such purchases. Perhaps a few of you are even more like me in that your given to writing the occasional freelance article in the telecommunications arena. I figure this email alone is worth maybe $200,000 in negative advertising for Sprint. That is a nice start, but I feel the urge to keep going. I'm going to pay the $2,000 I owe Sprint, but the only source of funds for this bill will be articles I write about this matter and sell to the various trade journals. My own story is frightful, but it'll be an easier sell if I've interviewed a few other victims. If you're smarting from Sprint's incompetent handling of billing please feel free to drop me a line and tell me all about it. Neal Rauhauser
Netgear wgt624 v3 (OT?)
Hi, Perhaps not the best place to ask but I thought I would ask here before possibly hitting Netgear (since you have to register) or BUGTRAQ. My Netgear wgt624 v3 allows for port triggering. When I do that, it doesn't seem to work. Port FORWARDING works fine. Port triggering appears completely broken in both their stable firmware and in their beta. Anyone else experience this with their Netgear?
Re: Fwd: 41/8 announcement
How was that achieved if their users still are within 41/8 locally? Route filter and PBR. hjan
Re: zotob - blocking tcp/445
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it. For example: grc.com/su-techzone1.htm scott - Original Message Follows - From: Gadi Evron [EMAIL PROTECTED] To: nanog list nanog@merit.edu Subject: zotob - blocking tcp/445 Date: Mon, 15 Aug 2005 21:51:43 +0200 I heard from several different big ISP's that to stop the spread of the worm they now block tcp/445. I suppose it works. Gadi.
DSL Network Design Question
I am going to be cutting over about 75,000 DSL lines from one core network to another. Does anyone have recommendations on subnet and DHCP scope size? If I make them /23s I have to do about 145 subents. If I make them /22s I only have to do about 73. Being mainly an always on eyeball network I don't see any problems with making big subnets (/22). flameproof undies == on suggestions, recommendations, advice? scott
Re: Graphing Peering
On Wed, 2005-01-19 at 22:41, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. off in what sense? We use mac-accounting, snmp nad mrtg to graph per peer utilization. The following script is helpful http://www.thiscow.com/dl/bgp-peers-1.5.pl I reworked it to spit out the AS number instead of the ip address. The issue you then have is that multiple sessions with one As number all show as the same target. Which MRTG does not like. You can fix that as well of course in the script. And it does not autoscan, which means that if people change their mac-address, you lose the data, until you rerun the script. Another problem you might run into is counter wrapping. When polling every 5 minutes, some counters may wrap. (there is no 64 bit counter for the mac-address accounting). So you have to run it in short timeframes, causing more cpu utilization. But all in all, mac-accounting and Netflow source-as give you a very good overview of your network flows. Frank
BTInternet Contact Please?
Hello, Are there any BTInternet Mail/Routing Engineers around on the list? If so, please contact me off-list regarding some networking issues. Thanks!
Re: eBGP, iBGP, injecting networks- Thanks!
greetings all, wanted to send a mail and say thanks to all who responded on and off list. there were a lot of great suggestions given. for now, we achieved prefix announcement redundancy (i shouldn't have called it router redundancy in the first post) in AS 1 by duplicating our network statements in bgp and also our 'pull up', static routes to Null0 254 in our routing table in another router in AS1. It runs iBGP in ASN1 to our border router that talks to Above.net we still need to achieve prefix announcement redundancy in ASN 2 tho. it looks like we are going to do this by putting network statements and null0 254 routes into a router in ASN1. We only have one router in ASN2, whereas we have 5 routers in ASN1. this will lead to an inconsistent AS origin for the routes from ASN2 but that seems like the best, temp. workaround for now until we merge AS's. thanks again. l8r- jg Quoting Fowlie, Colin [EMAIL PROTECTED]: I think the main concern you have here is the advertisement of the networks from two different ASN's to two different upstream providers. You'll have to set it up with your upstream ISP's to allow you to advertise all of the networks, but typically it's not a problem. You won't have an issue with routing loops as BGP speaker will drop a prefix that has its own ASN in the path-list. If you prepend properly to the AS path things will behave the way you want them to. This will provide your inbound redundancy. HTH Colin Fowlie -Original Message- From: Curtis Maurand [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 11:49 AM To: Ing. Hans L. Reyes Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: eBGP, iBGP, injecting networks He might try: http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a0080093f2c.shtml This one shows how to setup HSRP on the inside for the automatic failover that he's looking for. Curtis On Fri, 20 Feb 2004, Ing. Hans L. Reyes wrote: Hi Your problem may be is similar when one ISP buy to another ISP, sometimes is easy to modify the IGP like in this case (OSPF) because it is something inside of your company and you have the control over all the devices but you still have the problem outside of the company; client, others ISP, etc Check the feature of BGP Local-AS for routers Cisco if yours routers aren't Cisco, check for someone similar with your vendor. May be you need to do something else. This is the url where explain how it works. http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a00800949cd.shtml I hope it help you -Hans On Fri, 20 Feb 2004 [EMAIL PROTECTED] wrote: greetings list, hoping someone can hook me up on the right way to do this. --- we have two ASN's we control. we have two border/edge routers (1 in each ASN) that talks to a different backbone provider. the two border routers peer with eachother over eBGP and also are in the same OSPF process. (we are working to merge them into the same BGP ASN) my question is this: how do we achieve router redundancy between these two routers? currently if we lose a transit link, the traffic will flow fine out the other pipe. but we don't have BGP network statements in router 2 that exist in router 1 and we don't have BGP network statements in router 1 that exist in router 2. so the routes injected into BGP from router 1 will get withdrawn right if router 1 dies? is it a problem to announce the same networks from two different eBGP peers to two different upstreams? -- if you are still reading, thanks! to clearify some more- current setup: current setup: ASN 1 (we're not Genu!ty- just using for an example) :) ASN 1 injects all of its own space and announces this space to Above.net and ASN 2 ASN 2 injects all of its own space and announces this space to Savvis and ASN 1. so stuff out on the net looks like: 1 6461 etc etc and 1 2 6347 --- 2 6347 etc etc and 2 1 6461 etc etc --- so, you see we are prepending on of our AS's on the way out. the problem is tho, we only have 1 router in each respective Autonmous System injecting address space. if we lose that router, we lose announcing that ASN's space. is it totally going to cause probs to have routes originating from two different AS's? routing loops would be a real drag. what about having an iBGP router in AS 1 inject the same space as the border router in AS 1? this other router also peers with AS 2 thanks a lot! jg -- -- Curtis Maurand mailto:[EMAIL PROTECTED] http://www.maurand.com
Re: Fw: GLBX ICMP rate limiting (was RE: Tier-1 without their ownbackbone?)
On Thu, 28 Aug 2003, Christopher L. Morrow wrote: Rate-limiting ICMP is 'ok' if you, as the provider, think its worthwhile and you, as the provider, want to deal with the headache phone calls... Would it be fair to say that UUNET haven't been asked by Homeland Security to do the rate limiting that GLBX claim they have been asked to do? Has anyone else been asked to rate limit by the U.S. Department of Homeland Security? Rich
Re: WANTED: ISPs with DDoS defense solutions
On Wed, 30 Jul 2003, Christopher L. Morrow wrote: Sure, trace my attacks to the linux box at UW, I didn't spoof the flood and you can prove I did the attacking how? You can't because I and 7 other hackers all are fighting eachother over ownership of the poor UW student schlep's computer... You're quite right. This only means we'll be able to: 1) Stop the attack more quickly. 2) Alert the admins of the box that it's owned so that they can fix it and begin tracing how it happened. I'm all for raising the bar on attackers and having end networks implement proper source filtering, but even with that 1000 nt machines pinging 2 packet per second is still enough to destroy a T1 customer, and likely with 1500 byte packets a T3 customer as well. You can't stop this without addressing the host security problem... Agreed, we all (network providers, router vendors, software vendors and end users) need to be working together to solve this problem. There is no magic bullet. Rich
High Processor Rates on Routers.
Ladies Gentleman. Was wondering if it is common for processor rates on higher end Crisco boxes to race from 1 or 2 % show on the 5 second processor rate interval, to anywhere from 70 to 90 %, instanteously, then drop back down to 1 or 2 % after 10 seconds. The above mentioned scenario would happen every 30 seconds. The higher end boxes are very lightly loaded, with total traffic throughput of maybe 100 Meg, in some cases. Think that if these boxes are loaded more, to the point where the aggragated throughtput approaches a Gig, this will cause the processors to run at high levels constantly, driving the CPU rates indicators on the box for 1 5 minute intervals up to the values mentioned above. ( 70 to 90 % ). Higher end devices would be something like 7200, 7500, 12xxx series routers. This scenerio would be in a large ( very large network, atleast a tier 2 OR tier 1 provider )... possible rebutals to the fact that processors could race like mentioned above on lightly loaded devices of a higher end nature would be that BGP scanner is causing the problem, Telnet to the devices, show config when on the devices... So what happens to the processor rates when the devices are more heavily loaded ( 1 G aggragated throughput opposed to 100 Meg throughtput )? Will the devices work worrectly AND would a large internet be stable ? Is it also common for BGP Routing tables to be changing version every 1/2 second ? Same high end routers, lightly loaded, large Autonomous System. Thank-you for your time on this query.
High Processor Rates.
Yes, the sh proc cpu command is how you see the 5 second, 1 mintues 5 minute CPU rates... But nothing shows here... Any other thoughts ?
Re: no ip forged-source-address
On Wed, 30 Oct 2002, Daniel Senie wrote: BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation. Doesn't seem to be working. Which interface would you filter on? Customer ingress ports on the ISP side, which I suspect are the majority of ports in ISP networks. Hopefully engineers on the backbone will be clueful enough to turn it off. If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user. The routing table of the router should be used to build up a list of prefixes that you should see through the interface. In this way, you could apply it to BGP customers too without having to create filters by hand. Regards, Rich
Re: no ip forged-source-address
On Wed, 30 Oct 2002, Jesper Skriver wrote: Cannot be done, I certainly doesn't want RPF check to be default enabled on all interfaces on my routers, think for a second about asymmetric routing WITHIN the ISP network. Turn it off for backbone interfaces. Regards, Rich
Best provider to use ?
Out of the Tier 1s who is the best to use ? Thanks.
RE: Qwest Support
WOW. After going through the string of emails on this subject, it really amazes me that someone would bash someone else in regards to getting correct support. This appeared to be a legitimate need for support, Regardless of the nature of the problem, as Mr. Urban suggests, quite correctly, this gentleman Mr. Dills could not get support when he required it, was shuffled around. In fact, someone suggested that he would have had greater sympathy for this gentleman if he was really down. if it had of been a legitimate routing problem, it would have been more interesting . Now, we all can understand with the state of the industry, that support response times support in general might just be a bit stretched these days. But no sympathy, or would have had greater sympathy, come on. Infact, reading further emails, it appears that this gentleman, Mr. Dills DID have a routing issue. once he lit into his provider, via NANOG, they did not like the exposure quickly gave him some assistance. Now, NANOG is really not the place to b, but if it works... Greater sympathy ?? More interesting if it was a routing problem... When it appears it was... Wonder if they treat their customers like that at Sockeye Networks. A customer is a customer, plain simple. Dont tell him you will call him back in 30 minutes then shuffle him off. For a day. Regards. -Original Message- From: Gregory Urban [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 11:14 AM To: Daniel Golding; [EMAIL PROTECTED] Subject: RE: Qwest Support You totally missed the point. Had this been a real emergency, he would be unable to get resolution since Qwest was unable to dredge up a clue within their customer support machine. Greg U
