- NANOG - lists.nanog.org

Performance to and from Japan (who to connect to?)
by Operations 12 Nov '09

12 Nov '09

Greetings, Im sure someone here is GREAT with connecting to Japan so I ask the following: We have a POP in 600 West 7th street, Los Angeles. What provider can I cross-connect to there to get better performance to Japan? Are there Japanese providers on net in that building? Anyone want to peer with me there that can give me better routing to Japan? Thank you very much Nanog. NJ Critical Data Network http://www.critical.net

2 1

Re: Gig Throughput on IPSEC
by adel＠baklawasecrets.com 12 Nov '09

12 Nov '09

On second thoughts, thinking about this I am probably looking for some kind of Layer2 encryption devices. This will make things a lot easier for the deployment. Any experiences, thoughts on these types of devices, would be much appreciated. Adel On Wed 9:25 AM , adel(a)baklawasecrets.com sent: Hi, I have a requirement to encrypt data using IPSEC over a p-t-p gig fibre link. In the past I've normally used Juniper to terminate VPNs, as I have found them excellent devices and the route based VPN functionality very useful. However looking at their range, only the ISG will do a gig of IPSEC. I'm leaning towards keeping my exising Juniper SSG550's for firewall/routing capability at each site. Then having a separate encryption devices to handle the site-to-site vpn requiring the gig throughput. Does anyone have any suggestions on devices to use? Adel

3 2

RE: Resilience - How many BGP providers
by adel＠baklawasecrets.com 12 Nov '09

12 Nov '09

I suppose I could take the whole resilience thing further and further and further. One of the replies used a phrase which I thing captured the problem quite nicely: "diminishing returns". Basically I could spend lots and lots of money to try and eliminate all single points of failure. Clearly I don't have the money to do this and what I'm really trying to establish is at what point do the returns start to diminish with regards to obtaining multiple transit providers. The answer appears to be "it depends". So if getting a third BGP peering with divergent paths, separate last mile, separate facility and separate router will increase costs by 5x but only increase resilience by 0.001% is it really worth it? I'm trying to quantify the resilience of my Internet connectivity and quantify the effects of adding more providers. Now to run through my case: - I have one facility to locate BGP routers at. Thats not changing for the moment. - I can afford two BGP routers. - The facility I'm located at tell me they have divergent fibre paths and multiple entries into the facility. (Still need to verify this by getting them to walk the routes with me) - I am going to take transit from two upstreams. - I could ask the question as to whether I can peer with separate routers on each of the upstreams. i.e. to protect against router failures on their side. - I will make sure that neither upstream peers with the other directly. (Does this give me some AS path redundancy?) So from the above: - I have no resilience with regards to datacentre location. i.e. if a plane fell out of the sky etc., I'm done. - I can afford some BGP router resilience on my side. So I should be able to continue working if a router failure which only affects one of my routers occurs. - I have some resilience in terms of actual fibre paths to the facilites where I will be picking up the BGP feeds from. (to be verified) - I have some "AS resilience" if this is the right term. So if the AS of one of my upstreams drops off the face of the Internet, I can still get to the Internet through the AS of my other provider - Peering with separate routers may give me some resilience for router failure on the side of my upstreams? (not totally sure on this) In this situation, if I add another peering with another upstream, am I really getting much return in terms of resilience? Or should I spend this money examining the many other SPOFs in my architecture? I'm perfectly sure there is absolutely no point me peering with 6 providers, but maybe some gains in peering with 3? I'm trying to figure out at what point is adding another peering in my case a waste of money. I haven't gone into switch and power redundancy, because I "think" I understand it. I wanted to concentrate on the multiple upstreams question. Heads starting to whirl right about now. Adel On Wed 5:27 PM , "Dylan Ebner" dylan.ebner(a)crlmed.com sent: > > You question has many caveats. Just having two providers does not > necessarily get you more resiliency. If you have two providers and they are > terminating on the same router, then you still have a SPOF problem. You > also need to look at pysical paths as well. If you have two (or three) > providers and they are using a common carrier, then you have a problem as > well. For example, GLBX has a small prescence in the Minneapolis metro. If > I were to use them as a provider, they would use Qwest as a last mile. If > my other provider is Qwest (which it is), I may not have path > divergence.Facilities are important too. We have three upstreams; Qwest, MCI and ATT. > The facility only has two entrances, so that means two of these are in the > same conduit. IF you only have one entrance, all you connections are going > to run through that conduit, and that makes you susceptable to a rouge > backhoe. > You are on the right track to question your resilancy. Some upstreams can > offer good resilancy with multiple feeds. Others cannot. I would start with > your provider and see what you are getting. Maybe you already have path > divergence, sperate last miles, and multiple paths in the isp core. If you > go with multiple providers, you want to make sure you don't risk losing > something you already have. > > > > -----Original Message----- > From: adel(a)baklawasecrets.com [adel@ > baklawasecrets.com] Sent: Wednesday, November 11, 2009 11:14 AM > To: nanog(a)nanog.o > rgSubject: Resilience - How many BGP providers > > > > Hi, > > After recent discussions on the list, I've been thinking about the > affectsof multiple BGP feeds to the overall resilience of Internet > connectivityfor my organisation. So originally when I looked at the design > proposals, there was a provision in there for four connections with the > same Internet provider. Thinking about it and with the valuable input > ofmembers on this list, it was obvious that multiple connections from the > same provider defeated the aim of providing resilience. > > So having come to the decision to use two providers and BGP peer with > both, I'm wondering how much more resilience I would get by peering > with more than two providers. So will it significantly > increase myresilience by peering with three providers for example, as both of the > upstreams I choose will be multihomed to other providers. Especially > asI am only looking at peering out of the UK. > > Hope the above makes sense. > > Adel > > > > >

3 2

Gig Throughput on IPSEC
by adel＠baklawasecrets.com 12 Nov '09

12 Nov '09

Hi, I have a requirement to encrypt data using IPSEC over a p-t-p gig fibre link. In the past I've normally used Juniper to terminate VPNs, as I have found them excellent devices and the route based VPN functionality very useful. However looking at their range, only the ISG will do a gig of IPSEC. I'm leaning towards keeping my exising Juniper SSG550's for firewall/routing capability at each site. Then having a separate encryption devices to handle the site-to-site vpn requiring the gig throughput. Does anyone have any suggestions on devices to use? Adel

4 3

[NANOG-announce] NANOG 48 Call for Presentations now available
by David Meyer 11 Nov '09

11 Nov '09

Folks, The NANOG 48 Call for Presentations is now available at http://www.nanog.org/meetings/nanog48/index.php. Please take a look at the important dates, and submit your proposals at http://pc.nanog.org. Look forward to seeing you all in Austin. Thanks, Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Re: Gig Throughput on IPSEC - alternatively Layer2 encryption devices
by adel＠baklawasecrets.com 11 Nov '09

11 Nov '09

Hi, Thanks for the pointers to the Juniper devices. I think I'm really thinking about layer2 encryption, rather than do the encryption using IPSEC. I feel that as its a p-t-p fibre link, this makes most sense in terms of throughput and least impact on the network. Operating at layer3 the IPSEC solution introduces more complexity than I would like across this link. As I understand it, with layer2 encryption devices VLANs between the sites, would "just work". I'm interested to hear of peoples experiences with layer 2 encryption devices out there, as I don't have that much experience with them. I think my subject line mentioning IPSEC is a bit confusing as I'm really after information on Layer2 encryption hardware. Adel On Wed 6:45 PM , Brad Fleming bdfleming(a)kanren.net sent: > > On Nov 11, 2009, at 3:25 AM, adel@ > baklawasecrets.com wrote: > > > > > > Hi, > > > > I have a requirement to encrypt data using IPSEC > over a p-t-p gig > fibre > > link. In the past I've normally used Juniper to > terminate VPNs, as I> have found them excellent devices and the route > based VPN > functionality > > very useful. However looking at their range, > only the ISG will do a > gig > > of IPSEC. I'm leaning towards keeping my > exising Juniper SSG550's for> firewall/routing capability at each site. Then > having a separate> encryption devices to handle the site-to-site > vpn requiring the gig> throughput. Does anyone have any suggestions on > devices to use?> > > > > > > Adel > > > > > > Not knowing all your other needs, I won't swear to it... but would the > Juniper SRX650 work for your situation? It can pass 1.5Gbps of > encrypted traffic according to their datasheet. I've never actually > tried to move that much data through the box so I can't testify to it. > > Also, the Juniper SRX3400 is advertised as handling 6Gbps of encrypted > traffic. > > Of course, these are JunosES devices as opposed to ScreenOS, but the > transition isn't as painful as you might expect. We actually use the J- > series devices with JunosES as site routers/firewalls with a great > deal of success. > > >

1 0

Transit from Cogent - thoughts?
by adel＠baklawasecrets.com 11 Nov '09

11 Nov '09

Contemplating using Cogent Communications for transit as pricing looks favourable. Just trying to get a feel for what sort of a reputation they have in the network operators community. I'm sure people have horror stories for every provider, but just trying to get a general idea of what sort of regard they are held in the community. Thanks Adel

4 3

Re: Failover how much complexity will it add?
by adel＠baklawasecrets.com 11 Nov '09

11 Nov '09

Hi Joe, I agree with most of what you say below regarding linux sysadmin, BSD etc. I'm quite happy and actually would prefer building a linux solution on our own hardware. However, politically I think this is going to be difficult. I just feel that they will be more comfortable with embedded network boxes as a pose to a linux solution. I guess what I'm saying is this is partially a political thing. Adel On Mon 3:20 PM , Joe Greco <jgreco(a)ns.sol.net> wrote: > > > > Thanks, > > > > I've taken your advice and decided to reconsider my requirement for a > full > > routing table. I believe I'm being greedy and a partial table will be > > sufficient. With regards to Linux/BSD, its not the CLI of quagga that > will > > be an issue, rather the sysadmin and lack of supporting infrastructure > for > > Linux boxes within the organisation. So things like package management, > > > You don't need to run Apache on your router. > > > syslog servers, > > If you didn't have syslog servers for the Cisco, you don't need one for > the Quagga. > > > monitoring, > > If you didn't monitor the Cisco, you don't need to monitor the Quagga. > > > understanding of security issues etc. > > What security issues? > > The thing is, people get all tied up over this idea that it is some major > ongoing burden to support a Linux based device. > > I have a shocker for you. The CPE your residential broadband relies on > may > well run Linux, and you didn't even know it. The wifi router you use may > run > Linux. There are thousands of embedded uses for Linux. I highly doubt > that > the average TiVo user has a degree in Linux. Many different things you > use > in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly > without any > need of someone to handhold them on security issues. > > Of course, security issues do come up. But they do with Cisco as well. > > A proper Linux router doesn't have ports open, aside from bgp and ssh, > and > those can be firewalled appropriately. This makes it very difficult to > have > any meaningful "security problems" relating to the platform... > > You can expect the occasional issue. Just like anything else. But trying > to > compare it to security issues on a general Linux platform is only > meaningful > if you're trying to argue against the solution. > > (I'm a BSD guy myself, but I don't see any reason for undue Linux > paranoia) > > > I don't want to leave them with a linux/bsd solution that they won't be > > > able to maintain/manage effectively when I am gone. > > If they're unable to maintain something as straightforward as BSD or > Linux > when you're gone, this raises alarm bells as to whether or not BGP is > really suited for them. BGP is *much* more arcane, relatively speaking. > You can go to your local bookstore and pick up a ton of Linux or BSD > sysadm > books, but you'll be lucky to find a book on BGP. > > > Thanks for your comments. Look forward to hearing which solutions come > > back into the mix having dropped the full routing table requirement. > > There's a whole plethora of BGP-capable gear that becomes possible once > you make that call. Cisco and Juniper both make good gear. A variety > of other mfrs do as well. Something as old as an Ascend GRF 400 (fast > ethernet, line speed, 150K routes, ~1998?) is perfectly capable of > dealing > with the load, though I mention this primarily to make the point that > there > is a lot of equipment within the last decade that can support this. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > [1] > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > > > > Links: > ------ > [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net > >

4 3

Re: BGP Peer Selection Considerations
by adel＠baklawasecrets.com 10 Nov '09

10 Nov '09

I've decided to get transit from provider B independently of A, so I don't create a conflict of interest as mentioned below. However I think that I will have to use provider A's dark fibre network to connect to both peerings. Provider A tells me that they will use different routes and different entry points to get to their peering and separate routes, entries to get to B's peering. As they own the datacentre and can probably provide the bests costs for getting into the datacentres where the second transit provider is, I think I will have to use I should mention there are no transit providers on net at the datacentre facility which has been acquired by the business. I suspect it will be cheaper to get the cross connects to where the transit provider is from provider A, (did I mention provider A owns the datacentre?). I know I'll be sacrificing some resilience by using A's network to get to both Internet services, however I think I will just have to outline the risks to the business and go with it. Moving datacentres isn't an option and as long as I understand exactly what resilience I sacrifice by getting A to provide all the cross connects, I can explain that to the business. Adel On Mon 7:10 PM , William Herrin <herrin-nanog(a)dirtside.com> wrote: > On Mon, Nov 9, 2009 at 12:40 PM, wrote: > > I have an existing relationship with provider A, colo, cross connects > > etc. Provider A has offered to get the PI space, ASN number, > > purchase the transit for us with provider B and manage cross > > connects to provider B (they say they have a diverse "fibre > > backhaul network"). This is quite attractive from a support > > and billing perspective. Also suspect that provider A will be > > able to get more attractive pricing from Provider B than I > > would be able to. > > > > Am I missing things that I need to consider? > > What happens when provider A is bought by provider C and you want to > dump provider C but keep provider B? You'll have created a conflict of > interest for provider B in any negotiation you have with them. > > Be aware that provider A's diverse network for provider A's service is > the same diverse network they'll use to connect you to provider B. As > a result, many or most of the outages which impact provider A will > also impact your connectivity to provider B, defeating the central > purpose of having a provider B. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us > 3005 Crane Dr. ...................... Web: >

1 0

BGP Traffic Engineering question
by Drew Weaver 10 Nov '09

10 Nov '09

Howdy, If you have several transit providers connected to your network and much of your traffic is generally directed by the "BGP tiebreaker" (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the "tie breaker winner" slightly less often? I don't want to "completely flip" the preference so that it just saturates a different link, I am just trying to see if there is any good way to influence the "natural" selection method. We have 6 transit providers, and Level3 always wins because it is 4/8, normally this isn't a problem because we have traffic engineering systems (route science/avaya) which move traffic away from that link, but if we need to reboot the RS, or something catastrophic happens we would like it to spread out a little more evenly. Anyone have any thoughts on this? -Drew

4 4