Re: Birmingham UK colocation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Gristina wrote: I have two racks in London UK. The colocation is currently in London. The contract is up soon and most of the feet on the ground in the UK of the company is in the greater Birmingham area. So I'm interested in colocating about two racks of servers to Birmingham. I would need a cage if the space were shared. We've colo space in Telford (not far from Birmingham) if you are interested and a small amount of space in Wolves but its shared only there. What is peering like in the Birmingham area? Will getting multiple provider feeds in Birmingham be possible? It was easy in London. Er, this is the sticks really. Closest peering point is NWIX/MaNAP or MCIX (or if you know the right people the 'Phantom Exchange') in Manchester. Our network connects to both Manchester and London so we could easily get you to these using MPLS... Let me know if you want more info J - -- COO Entanet International T: 0870 770 9580 http://www.enta.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFvzOpR+KszLBLUT8RAvFgAKCAdRRHLvhWnoxx9lD+6Q3FZT06swCeJ036 yf+ozHgBBIL0M9xmhOETTb4= =VqW0 -END PGP SIGNATURE-
RE: Birmingham UK colocation
No peering in Brum, quickest will be to bounce of London. COLT has a data centre in Birmingham and we can do what ever bandwidth you need to where ever. Regards, Neil.
Re: Birmingham UK colocation
On Mon, 2007-01-29 at 12:56 -0800, Andrew Gristina wrote: I have two racks in London UK. The colocation is currently in London. The contract is up soon and most of the feet on the ground in the UK of the company is in the greater Birmingham area. So I'm interested in colocating about two racks of servers to Birmingham. I would need a cage if the space were shared. BT have a POP there (certainly our BT leased line into East Yorkshire bursts out there), so you stand a chance of getting BT someone else for two transits, if you can find DC space. There's no (public) peering, so you would have to rely on something hacky like L2TP to get over to London for peering... yuck. Birmingham has a great Selfridges store, but is a bit of an IP frozen wasteland. If your London DC space is with Telecity, talk to them; they have buildings in Manchester (although I don't know whether they are full). Manchester has some public peering, and a reasonable concentration of carriers, so there's some chance of private peering. London has problems - the data centres with space may not be represented by the transit providers you like working with, or the exchanges you want to join. The well connected DCs are getting full, certainly in terms of power and cooling capacity. Good luck, I hope if you do move it goes smoothly. If you (or anyone else) wants to share recent experiences of UK hosting/colo projects, then I'll be in Toronto next week. -a
-48VDC analog modems?
Hey guys, anyone have pointers for -48VDC powered analog modem units? Paradyne and the like are no more. A -48VDC ATU-R might also be interesting, although not preferred. Best regards, Christian
messy
and hard to read... http://www.ntia.doc.gov/osmhome/allochrt.pdf adhoc allocation taken to it's limits?
How to Host a NANOG Meeting
We have a BOF slot in Toronto to discuss the general topic meeting hosting, from the perspective of learning from past mistakes and making the organisation of future events easier, and with the additional goal of demystifying the process to those who might like to host a meeting, but don't know what's involved. If you have ever thought vaguely about hosting a NANOG meeting in your city but either assumed it would be too expensive or simply didn't know where to take your vague thoughts next, you might like to drop by and join the conversation. Feel very free to drop me a note off-list if you want to find out more. We'll be in Sheraton Hall B/C from 4pm - 5:30pm on Tuesday 6 Feb. This means we clash with the Second Coming of the Peering BOF, so apologies in advance to wbn and co. for the several hundred people that will no doubt abandon his session in order to attend this one. :-)
RE: Google wants to be your Internet
On 1/30/2007 at 12:19 AM, [EMAIL PROTECTED] wrote: IPv6 makes NAT obsolete because IPv6 firewalls can provide all the useful features of IPv4 NAT without any of the downsides. IPv6 firewalls? Where? Good ones? Why good ones. NAT is a basic IPv4 firewall. All IPv6 needs to obsolete NAT is a firewall that offers all the features of NAT without requiring the address translation. Then, instead of setting up a port translation for a particular incoming protocol, you simply open up that port without modifying the packets as they flow through. Suddenly, SIP works and incoming VoIP phonecalls work just like on the phone network. Oh, if it were so easy. Even without NAT our firewalls still need to meddle in the application layer. You'll still need smarts in the firewall to use the bad ol' FTP. And of course although SIP itself usually uses a fixed port, the calls it sets up generally do not. You don't have to modify packets, but you still need to read them, understand the protocol, and add state entries to your firewall. The absence of NAT doesn't really save you much work. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
RE: Google wants to be your Internet
Hi, PIX/ASA Supports IPv6 Apparently, see below. Don't know anyone who has tested it yet though ;-) http://www.cisco.com/en/US/products/ps6120/products_configuration_guide_ chapter09186a0080636f44.html Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Abley Sent: 30 January 2007 01:34 To: Brandon Galbraith Cc: nanog@merit.edu Subject: Re: Google wants to be your Internet On 29-Jan-2007, at 20:12, Brandon Galbraith wrote: On 1/29/07, Henning Brauer [EMAIL PROTECTED] wrote: * Joseph S D Yao [EMAIL PROTECTED] [2007-01-30 01:59]: IPv6 firewalls? Where? Good ones? OpenBSD's pf has support for v6 for years now. Do a fair amount of appliance firewalls support it? To be fair, I think the question was about good firewalls, not appliances. Joe
NANOG39 PGP Key Signing
We will be running the keysigning sessions in Toronto during the general session breaks (the breaks start sometime between 1000 and 1030 each day) in Hall F. You may add your key to the keyring at: http://www.biglumber.com/x/web?keyring=9342 Additional details are available at: http://www.nanog.org/pgp.html If you have any questions, please contact me off-list. Thanks! --msa
Re: messy
Lucy Lynch [EMAIL PROTECTED] writes: and hard to read... http://www.ntia.doc.gov/osmhome/allochrt.pdf adhoc allocation taken to it's limits? different frequencies of RF have different performance characteristics. unlike ip addresses, a 1 mhz allocation at 180 mhz and a 1 mhz allocation at 6.5 ghz are not fungible. ---rob
Anyone from SBC Yahoo Available for Quick Question?
I'm assisting in troulbeshooting an issue with a large client and I have a quick question regarding the SBC Yahoo broadband service. Thanks. -- - tewks
NANOG 39: Toronto Visitor Information (and yes, Super Bowl tips).
I've updated the NANOG 39 page at cluepon.net with some information about Toronto, and a large sports bar near the hotel for Super Bowl fans. I also ask that anyone who is from or knows Toronto to please take a moment and add something useful for our esteemed NANOG'ers. http://nanog.cluepon.net/index.php/NANOG39 -- Stephen Fulton| Network Connection Network Administrator | http://www.connection.ca | +1.416.967.6767 ext. 233
IPv6 Firewalls
Steven M. Bellovin wrote: Checkpoint claims to have supported IPv6 since 2002: http://www.checkpoint.com/press/2002/ipv6_081402.html --Steve Bellovin, http://www.cs.columbia.edu/~smb Juniper (ScreenOS 5.4) does it (http://tinyurl.com/yo9soq), Pix 7.0 does it, Checkpoint's [EMAIL PROTECTED] appliance doesn't do IPv6. I don't even know if it qualifies to be called Checkpoint anyway. A lot of vendor information on this, etc. can be summarized over at http://www.moonv6.org/ (or at least the hype of it) -- J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1383A743 sil . infiltrated @ net http://www.infiltrated.net The happiness of society is the end of government. John Adams smime.p7s Description: S/MIME Cryptographic Signature
Re: messy
ack ___ Lucy E. Lynch | llynch @civil-tongue.net | llynch on jabber.org On Tue, 30 Jan 2007, Robert E. Seastrom wrote: Lucy Lynch [EMAIL PROTECTED] writes: and hard to read... http://www.ntia.doc.gov/osmhome/allochrt.pdf adhoc allocation taken to it's limits? different frequencies of RF have different performance characteristics. unlike ip addresses, a 1 mhz allocation at 180 mhz and a 1 mhz allocation at 6.5 ghz are not fungible. ---rob
Re: IPv6 Firewalls
On Tue, Jan 30, 2007 at 09:43:52PM -0500, J. Oquendo wrote: ... A lot of vendor information on this, etc. can be summarized over at http://www.moonv6.org/ (or at least the hype of it) ... This is why I asked: at some point last year, those guys said NO firewalls were IPv6-ready yet. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: IPv6 Firewalls
Joseph S D Yao wrote: On Tue, Jan 30, 2007 at 09:43:52PM -0500, J. Oquendo wrote: ... A lot of vendor information on this, etc. can be summarized over at http://www.moonv6.org/ (or at least the hype of it) ... This is why I asked: at some point last year, those guys said NO firewalls were IPv6-ready yet. From their last tests (http://www.moonv6.org/project/july2006/Moonv6_2006_Whitepaper.pdf) it seemed they accomplished a lot of their tasks. They didn't include the list of vendors that tested though: // PAGE 7 Firewall deep-inspection functionality of application traffic in a mixed IPv4/IPv6 environment was validated and compared with the same test scenarios in an IPv4 oenvironment. A realistic protocol mix was configured to simulate the forwarding and blocking capabilities in an actual network. A critical concern that must be addressed in an IPv4/IPv6 transition environment is equivalent quality of the user experience. If a security device performs adequately wIPv4, it should also sustain comparable performance levels when processing mixed IPv4/IPv6 and pure IPv6 traffic. Responding to that concern, the 2006 Moonv6 Transition Test Suite included performance tests that compared security devices IPv6 and mixed IPv4/IPv6 performance. These tests used real-world application mix traffic to measure the metrics. The tests successfully validated that security devices casustain adequate performance and QoE levels in transition IPv4/IPv6 environments. // END PAGE -- J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1383A743 sil . infiltrated @ net http://www.infiltrated.net The happiness of society is the end of government. John Adams smime.p7s Description: S/MIME Cryptographic Signature
Best way to supply colo customer with specific provider
Hello all, Being relatively new to the colocation business, we run into a fair number of issues that we've never run into before. Got a new one today, and although I can think of kludgey ways to accomplish what he wants, I'd rather get some other ideas first... We just had our first customer that's requesting bandwidth exclusively through a particular provider of ours (Cogent) at less expensive pricing. The money people here are up for it, but obviously, they want to make sure that he's confined to that Cogent connection. So now of course we're attempting to figure out the best way to do this, and I figured that rather than reinventing the wheel, I'd check to see how others accomplish things like this. The way I can imagine doing it is by using route-maps to steer all of this customer's traffic out the Cogent pipe, and modifying our BGP announcements by AS prepending on whatever block or blocks we set aside to be Cogent-exclusive. Again though, this seems to me to lack a certain amount of, for lack of a better word, grace. Any other suggestions? Thanks, Rick Kunkel
RE: Best way to supply colo customer with specific provider
We had that same problem and ended up doing it exactly as below, with limited BGP announcements and policy routing all over. The customer also demanded high-bandwidth at low cost, without regard to how good the actual bandwidth was. It was, as you say, graceless. Luckily we convinced them to purchase standard multi-carrier transit. I hope you can do the same :) Cheers, Randal Kohutek Hello all, Being relatively new to the colocation business, we run into a fair number of issues that we've never run into before. Got a new one today, and although I can think of kludgey ways to accomplish what he wants, I'd rather get some other ideas first... We just had our first customer that's requesting bandwidth exclusively through a particular provider of ours (Cogent) at less expensive pricing. The money people here are up for it, but obviously, they want to make sure that he's confined to that Cogent connection. So now of course we're attempting to figure out the best way to do this, and I figured that rather than reinventing the wheel, I'd check to see how others accomplish things like this. The way I can imagine doing it is by using route-maps to steer all of this customer's traffic out the Cogent pipe, and modifying our BGP announcements by AS prepending on whatever block or blocks we set aside to be Cogent-exclusive. Again though, this seems to me to lack a certain amount of, for lack of a better word, grace. Any other suggestions? Thanks, Rick Kunkel
Re: Best way to supply colo customer with specific provider
If you actually want to do this, you've got four choices: - Policy route, as mentioned below. - Get the customer their own connection to Cogent. - Have a border router that only talks to Cogent and doesn't receive full routes from your core, and connect the customer directly to that. - Do something involving route servers and switches outside your border routers, a-la-Equinix Direct. The policy routing idea will work, for some definition of work. I forget whether Cisco now has a fast (non-processor-switched) path for policy routed traffic; they didn't yet when somebody convinced me to try this many years ago. If nothing else, it will make a mess of configuration and troubleshooting. Getting the customer their own Cogent connection is likely the least trouble, but may not save you as much on the bandwidth cost as aggregating the customer's traffic into the rest of your traffic would. Connecting the customer to a Cogent-only border router works fine if you already have such a border router. If not, it may require significant reengineering. The route server suggestion is thrown out mainly as a conceptual exercise. It would require a lot of design work. All that said, if you're paying your engineers and operations people developed world salaries, and paying major well-connected city bandwidth rates, none of these suggestions should make your accountants or your customer's accountants happy. You'll be saving a bit on bandwidth costs while putting in large amounts of engineering time that at best will do nothing useful for your other customers. Any way you do this, you'll probably find that it costs you considerably more than it would to give the customer your standard product. -Steve On Tue, 30 Jan 2007, Rick Kunkel wrote: Hello all, Being relatively new to the colocation business, we run into a fair number of issues that we've never run into before. Got a new one today, and although I can think of kludgey ways to accomplish what he wants, I'd rather get some other ideas first... We just had our first customer that's requesting bandwidth exclusively through a particular provider of ours (Cogent) at less expensive pricing. The money people here are up for it, but obviously, they want to make sure that he's confined to that Cogent connection. So now of course we're attempting to figure out the best way to do this, and I figured that rather than reinventing the wheel, I'd check to see how others accomplish things like this. The way I can imagine doing it is by using route-maps to steer all of this customer's traffic out the Cogent pipe, and modifying our BGP announcements by AS prepending on whatever block or blocks we set aside to be Cogent-exclusive. Again though, this seems to me to lack a certain amount of, for lack of a better word, grace. Any other suggestions? Thanks, Rick Kunkel
