November 2009 - Test - lists.nanog.org

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

about interdomain multipath routing.
by Bin Dai 10 Nov '09

10 Nov '09

Hi: These days, in the research, the interdomain multipath routing is pretty hot but i doubt its actually use in reality. Does anyone tell me any use of interdomain multipath routing like multipath BGP in the real world? Best, Daniel

6 8

Interesting Point of view - Russian police and RIPE accused of aiding RBN
by noc acrino 10 Nov '09

10 Nov '09

Greetings! Let me introduce myself - I as a part of a support team represent NOC Akrino, the team responsible of the technical use of AKRINO Networks, AS44571 (91.202.61.0/21). It's a service network for DDoS-mitigation purposes, using a combination of hardware and self-developed software which allow us to efficiently filter mostly any kind of malicious traffic providing the white traffic to the client's server. Among our clients there are some e-businesses, e-shops, e-mass media, etc. with critical losses in case of possible DDoS-attacks. I'd apply in case it's necessary, the recommendations of our foreign resellers. Anyway we have never declared ourselves as an abuse-resistant service provider - every abuse sent to service email "noc.akrino(a)gmail.com" is being investigated and responded: we can block the exact URLS or even block completely the traffic redirection to the client in case of his abusive network behavior. We're completely shocked by the declaration that the RBN moved to our AS. We have no affiliation to RBN, the personal data is hidden and can be provided by request just because of our members' personal security - in rare cases we even had those risks (just because our filtration works cyber criminals often search for other ways of influence upon us, including coercion). In fact there are some problem clients like some adult sites whose advertising programs could be popular with the spammers, but our policy demands normal network behavior and in case of the abuse - their advert partner is blocked. So, if you have any evidence of abusive network behavior of our clients you should send it directly to noc.akrino(a)gmail.com and we'll respond. If there were any unsolved cases - we'll close them. Please, excuse us if in somehow Akrino Networks were the source of problems for you - we'll do our best to prevent it in the future. And I'll sincerely ask *Jeffrey Lyon *as a representative of Blacklotus team to clarify his accusations: aren't they connected with the fact that many of your DDoS-protected clients have chosen our reseller Blockdos (blockdos.net) just because our pricing doesn't depend on the amount of attack? As far as I understand it's a question of about $20k/month. Please, tell me if I'm not right. Thank you. Kanak Akrino Abuse Team

2 5

AfNOG 2010
by Randy Bush 10 Nov '09

10 Nov '09

AfNOG-11 and AfriNIC-12: Meetings 23 May-4 June, 2010 The African Network Operators' Group (AfNOG) and the African Network Information Centre (AfriNIC) are pleased to announce that the 11th AfNOG Meeting and the AfriNIC-12 Meeting would be held in Kigali, Rwanda during May & June 2010. About the Entire Event AfNOG and AfriNIC are jointly organizing a two-week event that includes the AfNOG Workshop on Network Technology (offering advanced training in a week-long hands-on workshop), several full-day Advanced Tutorials, a one-day AfNOG Meeting, and a two-day AfriNIC Meeting. In addition, several side meetings and workshops will be hosted in collaboration with other organizations. Timetable Unix Boot Camp 23 May 2010 (Sunday) AfNOG Workshop 24 - 28 May 2010 (Monday - Friday) AfriNIC IPv6 Workshop 29 - 30 May 2010 (Saturday - Sunday) AfREN Meeting / AAF 29 - 30 May 2010 (Saturday - Sunday) <http://www.afnog.org/afnog2010/tutorial/> AfNOG Tutorials 30 - 31 May 2010(Sunday - Monday) AfriNIC LIR Workshop 31 May 2010 (Monday) <http://www.afnog.org/afnog2010/conference/> AfNOG-11 Meeting 1 June 2010 (Tuesday) <http://www.afrinic.net/meeting/> AfriNIC-12 Meeting 2- 3 June 2010 (Wednesday - Thursday) Africa INET Day 4 June 2010 (Friday) Venue & Hotel Venue & hotel for the event will be announced shortly. About AfNOG AfNOG (See <http://www.afnog.org/> <http://www.afnog.org/>) is a forum for cooperation and the exchange of technical information between operators of Internet-connected networks in Africa. AfNOG has organized an event like this one every year since 2000. About AfriNIC AfriNIC (See <http://www.afrinic.net/> <http://www.afrinic.net/>) is a Regional Internet Registry (RIR), responsible for Internet Number resources Management in the Africa region. AfriNIC organizes two Public Policy meetings every year (see < <http://www.afrinic.net/meeting/> http://www.afrinic.net/meeting/>). AfNOG Workshop on Network Technology The AfNOG Workshop on Network Technology aims to offer advanced training to people who are in the process of developing and enhancing an Internet-connected network with regional and international connectivity. The target audience includes senior and mid-level technical staff of commercial Internet service providers (ISPs), academic networks, government networks, or NGO networks. This workshop builds on the experience of previous AfNOG workshops held annually from 2000 to 2009 in ten different African countries, and also the Internet Society's INET workshops, held annually from 1993 to 2000 at eight locations around the world. The workshop's instructors are an international team with many years of experience operating large networks and teaching about network operations. The workshop is divided into four parallel tracks: * SA-E - Unix System Administration (in English), focused on using a Unix-like operating system as a platform for delivery of Internet services. * SS-E - Scalable Internet Services (in English), focused on the design and operation of email, web, and other Internet services, in ways that can scale to handle large numbers of end users. * SI-E - Scalable Network Infrastructure (in English), focused on the design and operation of networks using routers and switches, in ways that can scale to handle large numbers of interconnected sites. * SI-F - Infrastructure Reseaux IP (en francais), similar to track SI-E, but given in French. Workshop application information is available here: http://www.afnog.org/afnog2010/workshop/online_application_en.html http://www.afnog.org/afnog2010/workshop/online_application_fr.html AfREN Meeting The Africa Research and Education Networking community will be holding a two-day meeting on 29 - 30 May 2010. The meeting will discuss issues of interest to the NREN community such as coordination on activites in the region, advocacy, bandwidth consortia, regional RENs etc. Additional information about AfREN 2010 will be provided shortly. AfNOG Tutorials AfNOG will offer 1 to 2 full-day(s) tutorials on advanced topics. Tutorials take place in a classroom-style environment, and may include a hands-on practical component. Tutorials are non-commercial in nature, and most are technically oriented. They are intended to offer advanced training on technology already deployed or soon to be deployed on networking and related services provisioning for ISP operations. Additional information about AfNOG 2010 Tutorials will be availabe here: < <http://afnog.org/afnog2010/tutorial/> http://www.afnog.org/afnog2010/tutorial/> 11th AfNOG Meeting The 11th AfNOG meeting will be held in Kigali, Rwanda on 01 June 2010. AfNOG conferences provide a forum for the coordination and dissemination of technical information related to backbone/enterprise networking technologies and operational practices. The meetings are informal, with an emphasis on relevance to current and future African backbone engineering practices. The AfNOG 2009 conference in Cairo, Egypt drew over 150 participants, mainly consisting of network engineering staff from national service providers, and members of the research and education community. Additional information and the Conference schedule will be available here: < <http://www.afnog.org/afnog2010/conference/> http://www.afnog.org/afnog2010/conference/> AfriNIC-12 Meeting The AfriNIC-12 meeting will be held in Kigali, Rwanda for two days from 02-03 June, 2010. AfriNIC Meetings are open to everyone and provide an excellent opportunity to take part in Internet policy discussions. These policies, which describe how Internet Number Resources should be managed and distributed, are developed by the community. The meeting will include tutorials, presentations, update on the various working groups and the AfriNIC Public Policy Meeting. The two day meeting will be preceeded by a two-day IPv6 training. The meeting will focus on the IPv6 protocol and its deployment, especially in Africa and the issue of the exhaustion of the IPv4 pool of address space. There will be an opportunity to discuss the challenges which our region will be facing with IPv4 address space exhaustion. Further information will be available at < <http://www.afrinic.net/meeting/> http://www.afrinic.net/meeting/>. ISOC - INET Africa Conference The Internet Society will be organizing an INET Africa Conference on 4th June 2010 in conjunction with the AfriNIC 12 and AfNOG 11 meetings in Kigali, Rwanda. The conference will discuss the situation of Internet Interconnection in Africa, the challenges as well as the solutions, including Internet Exchange Points. The meeting agenda will be available shortly. Visa Requirements Citizens of certain countries require a visa to enter Rwanda. Please check with the Rwandan -30-

1 0

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

10 Nov '09

If nothing else by the time this deployment is finished I will surely have become extremely cynical. Now reading through peoples answers, I think the general consensus is that I would be giving too much control to provider A in the scenario I suggested below. So as someone mentioned they have the ability to foul up my connections all by themselves. >From all of this I gather that the most resilience would be provided by: 1) Go to two tier 1 carriers myself - say Global Crossing and Level 3. Arrange to get two 100meg BGP feeds, burstable. Pick them up at different datacentres as well I suppose to provide datacentre redundancy? Negotiate pricing, any tips on negotiating appreciated. 2) Arrange cross connects to these providers i.e. get to the datacentres the Tier1 providers are in. They are not on net at the colo we are in. With regards to arranging the cross connects am I able to ask the cross connect providers for fibre maps? Is this a done thing or will they brush me off with "you don't need this our network is diverse?" 3) Arrange for PI space and ASN myself, so become an LIR through RIPE. Do I really lose a lot by asking Level3 or GBLX to get the PI and ASN for me? I think the failure mode cited by someone was if the PI and ASN provider goes out of business. I would prefer not to go through becoming an LIR and maintaining the membership, as they are not an ISP and so it is more attractive to do that through one of the Tier 1 providers. I'm not sure what my options are in terms of getting to the datacentres to pick up the Tier1 providers. The "provider A" below has said they run a diverse fibre backhaul network etc etc. and I should go with them for connectivity to other datacentres. Now it would be easier to go with them just because they are running colo for us and they run the datacentre we are in. However I assume that I should not be scared of arranging a second cross connect with someone else altogether. In all of the above, I'm most worried about administrative overhead. Managing two cross connect providers, managing ongoing relationship with two Tier1 providers and so on. However resilience comes at a cost I suppose is the answer. Comments appreciated. Adel On Mon 7:10 PM , "William Herrin" herrin-nanog(a)dirtside.com sent: > On Mon, Nov 9, 2009 at 12:40 PM, <adel@ > baklawasecrets.com> 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@di > rtside.com bill(a)herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>Falls Church, VA 22042-3004 > > >

2 1

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

10 Nov '09

Hi, Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: BGP Peer with Provider A who is multihomed to other providers. BGP Peer with Provider B who is not peered with provider A 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?

6 7