From sh.vahabzadeh at gmail.com Sun Apr 1 01:58:34 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 1 Apr 2012 11:28:34 +0430 Subject: Outdoor Wireless Access Point In-Reply-To: <74945.1333237748@turing-police.cc.vt.edu> References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> <74945.1333237748@turing-police.cc.vt.edu> Message-ID: Hi Valdis, Thanks for your time and your answer, Of course I know how to search in google or internet. But the problem is as you told to have a good network and launch the best solution. And not do wrong things once more. Thanks On Sun, Apr 1, 2012 at 4:19 AM, wrote: > On Sat, 31 Mar 2012 15:48:37 -0700, Network IP Dog said: > > I'm utterly amazed how many people give away free consultant work. > > A lot of us are quite busy with $DAYJOB and not in a position to take on a > consulting engagement - and there's no good micropayment infrastructure to > deal > with 20-minute consulting gigs anyway. So we give away 5 minute chunks of > our > time for the benefit of the networking community. It's a large chunk of > what > makes 'best common practices' evolve. (Hint - that consultant you hired? > How > much of *their* knowledge did they aquire from other people's free advice?) > > And those of us who *do* go looking for consulting gigs often need to > market > ourselves as somebody clued. You read NANOG for a while, you get a good > idea > of who is clued and who isn't. And thus you decide who gets the gig. > > > Google is your friend... ;^) > > http://www.xckd.com/979/ > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From sh.vahabzadeh at gmail.com Sun Apr 1 01:59:53 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 1 Apr 2012 11:29:53 +0430 Subject: Outdoor Wireless Access Point In-Reply-To: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> Message-ID: Dear IP Dog, Thanks for your time too, but I think you are so free and you are only showing off yourself busy ;) Because your answer reflect that to us, Here is a mailing list and open community ;) So if you do not have a good answer for question please go away ;) Thanks On Sun, Apr 1, 2012 at 3:18 AM, Network IP Dog wrote: > Hi...How do I do it! > > I'm utterly amazed how many people give away free consultant work. > > We need to keep people working... not giving it away. > > Ethics... Security... etc... > > Does the university give away free diploma's? I don't think so. > > Must be another copy & paste e&^%$#?r too! > > Google is your friend... ;^) > > Cheers! > > > Ephesians 4:32 & Cheers!!! > > A password is like a... toothbrush ;^) > Choose a good one, change it regularly and don't share it. > > -----Original Message----- > From: Shahab Vahabzadeh [mailto:sh.vahabzadeh at gmail.com] > Sent: Saturday, March 31, 2012 2:39 AM > To: nanog at nanog.org > Subject: Outdoor Wireless Access Point > > Hi there, > I asked for a wireless solution for a university, in which they want indoor > wireless solution for more than 5 building (at least two floor) and outdoor > wireless solution for near 160m*280m garden. > As I look for maps we need at least 3 or 4 outdoor radio, I think in these > networks the best solution is to have only one SSID in whole network to > give > mobility for the network, is this called ad-hoc? or it has an other name? > I do not know if I could ask question clearly or not, suppose we have 4 > radio but only one SSID is broadcasting and when you are near the radio is > near to you you will get service from that one, as this solution must be > implement for indoor ones too. > And if there is any good company which can both indoor and outdoor solution > and they have shipping to Iran too or reseller in Iran please give me the > url. > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From Valdis.Kletnieks at vt.edu Sun Apr 1 02:58:31 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 01 Apr 2012 03:58:31 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: Your message of "Sun, 01 Apr 2012 11:28:34 +0430." References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> <74945.1333237748@turing-police.cc.vt.edu> Message-ID: <111456.1333267111@turing-police.cc.vt.edu> On Sun, 01 Apr 2012 11:28:34 +0430, Shahab Vahabzadeh said: > Thanks for your time and your answer, Of course I know how to search in google or internet. > But the problem is as you told to have a good network and launch the best solution. Unfortunately, I can't make any real recommendation for your net - although we have some 1300 access points scattered across 100 buildings (a combination of Cisco and Aruba gear) with a peak of 10,700 or so simultaneous users, we have not ireally addressed the issue of outdoor wireless. For much of campus, it's not a big problem, as buildings are packed fairly close together, and many of the good benches, trees, retaining walls, and other places to sit are close enough to a building that signal leakage from inside allows users to connect anyhow. But there's a 22 acre field (about twice the size of the garden you are trying to support) in the middle of campus... literally in the middle, as in "the campus is built around that field". ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From leigh.porter at ukbroadband.com Sun Apr 1 05:37:21 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 1 Apr 2012 10:37:21 +0000 Subject: Outdoor Wireless Access Point In-Reply-To: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> References: , <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> Message-ID: <1D88FE52-F131-4FAE-9628-79E32D390727@ukbroadband.com> On 31 Mar 2012, at 23:51, "Network IP Dog" > wrote: Hi...How do I do it! I'm utterly amazed how many people give away free consultant work. We need to keep people working... not giving it away. Ethics... Security... etc... Does the university give away free diploma's? I don't think so. Must be another copy & paste e&^%$#?r too! Google is your friend... ;^) Cheers! Ephesians 4:32 & Cheers!!! For I was hungry and you gave me nothing to eat, I was thirsty and you gave me nothing to drink, 43 I was a stranger and you did not invite me in, I needed clothes and you did not clothe me, I was sick and in prison and you did not look after me.? 44 I needed some help building a wireless network and you wanted consultancy fees. I think the day we stop helping each other on this list and start demanding consultancy fees will be the day the Internet really did die.. So whilst nobody would document an end to end design for nothing, I think the odd snipped of good advice should always be free. Of course, y'all should google it first because how else are they going to send you relevant advertisements! -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From leigh.porter at ukbroadband.com Sun Apr 1 05:45:51 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 1 Apr 2012 10:45:51 +0000 Subject: April fools joke? Message-ID: <71E3CD78-A057-4519-A561-04D998611AA2@ukbroadband.com> http://www.bbc.co.uk/news/uk-politics-17576745 It's sad when you just can't tell with things like this.. -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From jared at puck.nether.net Sun Apr 1 06:16:15 2012 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 1 Apr 2012 07:16:15 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: <111456.1333267111@turing-police.cc.vt.edu> References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> <74945.1333237748@turing-police.cc.vt.edu> <111456.1333267111@turing-police.cc.vt.edu> Message-ID: <17765155-1FEF-488D-929F-14A1D3C1C562@puck.nether.net> If you use unifi there is an outdoor version. You can mount it outside a building or on a pole. Jared Mauch On Apr 1, 2012, at 3:58 AM, Valdis.Kletnieks at vt.edu wrote: > But there's a 22 acre field (about twice the size of the garden you are trying > to support) in the middle of campus... literally in the middle, as in "the campus > is built around that field". ;) From rubensk at gmail.com Sun Apr 1 06:56:51 2012 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 1 Apr 2012 08:56:51 -0300 Subject: Attack on the DNS ? In-Reply-To: <1E6E6FF1-098B-4CAF-81AF-74C2D49A6A9C@gmail.com> References: <4F774C51.3000805@gmail.com> <20120331.222817.74728386.sthaug@nethelp.no> <1E6E6FF1-098B-4CAF-81AF-74C2D49A6A9C@gmail.com> Message-ID: On Sat, Mar 31, 2012 at 10:09 PM, Greg Ihnen wrote: > I manage a tiny network in the Amazon, a satellite internet connection and decent sized wireless network. > Is DNS traffic being directed to bogus servers? Are the real servers being overloaded? Am I seeing the results of some kind of DDOS mitigation technique? If you are using broadband connection from the brazilian incumbent operator (Oi), you might indeed being redirected to bogus servers. They are very fond of "monetizing" techniques with their user base, using either DNS or all the traffic for that matter (Phorm). Rubens From lists at mtin.net Sun Apr 1 09:30:05 2012 From: lists at mtin.net (Justin Wilson) Date: Sun, 01 Apr 2012 10:30:05 -0400 Subject: April fools joke? In-Reply-To: <71E3CD78-A057-4519-A561-04D998611AA2@ukbroadband.com> Message-ID: I hate April 1 on the Web. You are right you never can tell. I would be appalled if someone as respectable as the BBC stoops to downright dumb pranks. However, it is England. They have some of the most strict laws in the "Free" world. I hate the Interweb on April 1. lol -----Original Message----- From: Leigh Porter Date: Sun, 1 Apr 2012 10:45:51 +0000 To: "nanog at nanog.org" Subject: April fools joke? > >http://www.bbc.co.uk/news/uk-politics-17576745 > >It's sad when you just can't tell with things like this.. > >-- >Leigh > > >______________________________________________________________________ >This email has been scanned by the Symantec Email Security.cloud service. >For more information please visit http://www.symanteccloud.com >______________________________________________________________________ > From tknchris at gmail.com Sun Apr 1 09:33:22 2012 From: tknchris at gmail.com (chris) Date: Sun, 1 Apr 2012 10:33:22 -0400 Subject: April fools joke? In-Reply-To: References: <71E3CD78-A057-4519-A561-04D998611AA2@ukbroadband.com> Message-ID: April 1st or not its the gist of that story is probably already true whether you know it or not. On Sun, Apr 1, 2012 at 10:30 AM, Justin Wilson wrote: > I hate April 1 on the Web. You are right you never can tell. I > would be > appalled if someone as respectable as the BBC stoops to downright dumb > pranks. > > However, it is England. They have some of the most strict laws in > the > "Free" world. > > I hate the Interweb on April 1. lol > > -----Original Message----- > From: Leigh Porter > Date: Sun, 1 Apr 2012 10:45:51 +0000 > To: "nanog at nanog.org" > Subject: April fools joke? > > > > >http://www.bbc.co.uk/news/uk-politics-17576745 > > > >It's sad when you just can't tell with things like this.. > > > >-- > >Leigh > > > > > >______________________________________________________________________ > >This email has been scanned by the Symantec Email Security.cloud service. > >For more information please visit http://www.symanteccloud.com > >______________________________________________________________________ > > > > > > From alec.muffett at gmail.com Sun Apr 1 09:54:10 2012 From: alec.muffett at gmail.com (Alec Muffett) Date: Sun, 1 Apr 2012 15:54:10 +0100 Subject: CCDP (Was: April fools joke?) In-Reply-To: References: Message-ID: <329ED0F4-4516-4FD5-8046-5D5D7E3C0304@gmail.com> On 1 Apr 2012, at 15:30, Justin Wilson wrote: > I hate April 1 on the Web. You are right you never can tell. I would be > appalled if someone as respectable as the BBC stoops to downright dumb > pranks. It is true. It's called the Communications Capabilities Development Programme (CCDP) and is comprehensively discussed at the OpenRightsGroup* wiki: http://wiki.openrightsgroup.org/wiki/Communications_Capabilities_Development_Programme ...and somewhat less comprehensively at: http://en.wikipedia.org/wiki/Communications_Capabilities_Development_Programme See also ZDNet from February, in case you think it's still an April 1st joke: http://www.zdnet.co.uk/news/security-threats/2012/02/20/isps-kept-in-dark-about-uks-plans-to-intercept-twitter-40095083/ - alec -- * disclosure: I help out with ORG in an unpaid capacity From chcheng at ieee.org Sun Apr 1 10:23:31 2012 From: chcheng at ieee.org (Che-Hoo CHENG) Date: Sun, 1 Apr 2012 23:23:31 +0800 Subject: Was b.root-servers.net under attack on Mar 31? Message-ID: http://dnsmon.ripe.net/dns-servmon/server/plot?server=b.root-servers.net;type=drops;tstart=1333166400;tstop=1333252799;af=ipv4 There were quite a few unanswered queries from around 06:15 to around 09:15 UTC on Mar 31. Che-Hoo From sil at infiltrated.net Sun Apr 1 10:04:42 2012 From: sil at infiltrated.net (J. Oquendo) Date: Sun, 1 Apr 2012 10:04:42 -0500 Subject: STEP Security (RFC4012012) Message-ID: <20120401150442.GB14436@infiltrated.net> Interweb Re-Engineering Task Force J. Oquendo Request for Comments 4012012 E-Fensive Security Strategies Category: Informational Expires: 2020 STEP by STEP Security Status of this Memo This Internet-Draft is submitted in full nonconformance with provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 01, 2020. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Oquendo Expires Apr 01, 2020 [Page 1] Internet-Draft Security Step by STEP RFC 4012012 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This framework describes a practical methodology for ensuring security in otherwise insecure environments. The goal is to provide a rapid response mechanism to defend against the advanced persistent threats in the wild. Table of Contents 1. Introduction..................................................2 2. Conventions used in this document.............................4 3. Threats Explained.............................................4 3.1. Possible Actors..........................................4 4. STEP Explained................................................5 5. STEP in Action................................................6 6. Security Considerations.......................................7 7. IANA Considerations...........................................7 8. Conclusions...................................................8 8.1. Informative References...................................8 9. Acknowledgments...............................................8 Appendix A. Copyright............................................9 1. Introduction In the network and computing industry, malicious actions, applications and actors have become more pervasive. Response times to anomalous events are burdening today's infrastructures and often strain resources. As networks under attack are often saturated with malicious traffic and advanced persistent threat actors engage in downloading terabytes of data, resources to combat these threats have diminished. Additionally, the threats are no longer just anonymized actors engaging in juvenile behavior, there are many instances of State Actors, disgruntled employees, contractors, third party vendors and criminal organizations. Each with separate agendas, each consistently targeting devices on the Internet. Oquendo Informational [Page 2] Internet-Draft Security Step by STEP RFC 4012012 The intent behind this document is to define a methodology for rapid response to these threats. In this document, security will be achieved using a new methodology and protocol henceforth named Scissor To Ethernet Protocol (STEP). Initially designed as a last approach for security, STEP ensures that no attacker can disaffect any of the Confidentiality, Integrity, Availability of data as a whole. Many variables are involved in security, but the STEP methodology focuses on the following: o FUD (Fear Uncertainty and Doubt) o SCAM (Security Compliance and Management) o APT (Another Possible Threat) This methodology proposes STEP that SHOULD be performed at the onset of a cyber attack before more terabytes of data are exfiltrated from a network. 1. Industry Standard IP connection +-----------+ +-----------+ +-----------+ | | IP | | INGRESS | | | Rogue |-------> | Internet | ------> | Target | | A | | | | B | | | | | EGRESS | | +-----------+ +-----------+ <------ +-----------+ Figure 1 Example session between a rogue attacker and target Figure 1 illustrates the connection via the Internet from a rogue attacker, towards a target. Irrespective of the attack used, IP will ALWAYS be used as the attack vector. Oquendo Informational [Page 3] Internet-Draft Security Step by STEP RFC 4012012 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Threats Explained A security threat is a theoretical happening that may not occur but should be considered as part of a proper security architecture and design. For example, the threat always exists that your systems will become the target of a denial of service attack. A threat may or may not have a method to mitigate the possibility of attack. Vendors across the security spectrum offer FUD based solutions often promoting SCAM based systems to mitigate against APT. While some of the available solutions may minimize the potential for catastrophic transfers of terabytes of data, these solutions SHOULD NOT be used as an all-inclusive solution for security. Engineers MUST NOT rely on FUD, or SCAMs against the APT. 3.1. Possible Actors Both malicious attacks and unintended (non-malicious) attacks can occur from anywhere in the world including local attacks inside of the infrastructure. In the barest threat explanation above, the threat that someone can commit a typographical error, causing a disruption in service, is as severe as a Distributed Denial of Service attack from the public Internet. Actors can never be easily identified unless one is watching the Academy Awards on television. Oquendo Informational [Page 4] Internet-Draft Security Step by STEP RFC 4012012 4. STEP Explained o S - Scissors Scissors as defined by wikipedia are" hand-operated cutting instruments. They consist of a pair of metal blades pivoted so that the sharpened edges slide against each other when the handles (bows) opposite to the pivot are closed. Scissors are used for cutting various thin materials, such as paper, cardboard, metal foil, thin plastic, cloth, rope, and wire. Scissors can also be used to cut hair and food. Scissors and shears are functionally equivalent, but larger implements tend to be called shears. Scissors is a critical component for STEP security and MUST be readily available 99.99999% with redundant scissors within arm?..s reach. | | X X / \ O O (Opened) (Closed) o T - To To: [preposition] (Used for expressing direction or motion or direction toward something) in the direction of; toward: from north to south. o E - Ethernet Ethernet via Wikiepedia is described as a family of computer networking technologies for local area networks (LANs) commercially introduced in 1980. Standardized in IEEE 802.3, Ethernet has largely replaced competing wired LAN technologies. For clarity in our protocol, Ethernet is defined as the cabling between a device and a network component such as a router or a switch. o P - Protocol A communications protocol is a system of digital message formats and rules for exchanging those messages in or between computing systems and in telecommunications. A protocol may have a formal description. Oquendo Informational [Page 5] Internet-Draft Security Step by STEP RFC 4012012 Protocols may include signaling, authentication and error detection and correction capabilities. A protocol definition defines the syntax, semantics, and synchronization of communication; the specified behavior is typically independent of how it is to be implemented. A protocol can therefore be implemented as hardware or software or both. In STEP, Protocol is a rule an engineer MUST follow in order to complete STEP. S MUST be in a closed state. Actor -----> | Target (secured from the threat) X O O (Closed) 5. STEP in Action The following illustrates a remote APT attack against a webserver located in the demilitarized zone of an infrastucture. In the example, an APT attacker is launching a SQLI, XSS and CSRF against a target over the Internet. The attacks are common and according to statistics, are the same attacks used to leverage access against major Fortune 500 companies in the past decade. +-------+ +-----+ +-----+ +--------+ | | SQLi | | + + INGRESS | | | APT | -------> | ISP | ---> + ISP + ------> | Target | | | XSS/CSRF | A | + B + | www | | | | | + + | | +-------+ +-----+ +-----+ +--------+ o Figure 5.1 Attacker launching attacks +-------+ +-----+ +-----+ +--------+ | | TCP | | + + Reverse | | | APT | <------ | ISP | <--- + ISP + <------ | Target | | | | A | + B + Shell | www | | | | | + + | | +-------+ +-----+ +-----+ +--------+ o Figure 5.2 Attacker executing a reverse shell Oquendo Informational [Page 6] Internet-Draft Security Step by STEP RFC 4012012 In the illustration, an attacker is almost certainly attempting to obtain a reverse shell. This enables an attacker to access a device as if one were physically present at the device itself. Using STEP we can mitigate and deny this attack from various points: +-------+ +-----+ +-----+ +--------+ | | SQLi | | + + | | | | APT | -------> | ISP | ---> + ISP + -->| | Target | | | XSS/CSRF | A | + B + x | www | | | | | + + o o | | +-------+ +-----+ +-----+ +--------+ o Figure 5.2 Ingress STEP +-------+ +-----+ +-----+ +--------+ | | Attack | | | + + | | | APT | ------> | ISP | ->| + ISP + | Target | | | | A | x + B + | www | | | | | o o + + | | +-------+ +-----+ +-----+ +--------+ o Figure 5.4 Provider based STEP Both instances of STEP successfully demonstrate the power of the STEP protocol. In no case, can an attacker successfully launch any attack against a target as the security posture has now been hardened. 6. Security Considerations Cutting any Ethernet cable could potentially lead to shock and degradation of IP services on your network. Please ensure there are additional Ethernet cables for redundancy. Otherwise there is nothing to consider. 7. IANA Considerations There are no alternative considerations. STEP is the ultimate in security. Oquendo Informational [Page 7] Internet-Draft Security Step by STEP RFC 4012012 8. Conclusions Step defends against APT while minimizing your exposure to SCAMs and FUD. 8.1. Informative References [1] http://www.amazon.com/b?ie=UTF8&node=689392011 [2] http://ha.ckers.org/xss.html [3] http://en.wikipedia.org/wiki/Advanced_persistent_threat [4] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt 9. Acknowledgments Sofia Vergara Kenji, Saki and Coco Oquendo Informational [Page 8] Internet-Draft Security Step by STEP RFC 4012012 Appendix A. Copyright Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Author's Addresses Jesus Oquendo E-Fensive Security Strategies Oquendo Informational [Page 9] From bpasdar at batblue.com Sun Apr 1 10:38:05 2012 From: bpasdar at batblue.com (Babak Pasdar) Date: Sun, 01 Apr 2012 11:38:05 -0400 Subject: Outdoor Wireless Access Point Message-ID: <20120401153805.eb072199@concur.batblue.com> Shahab, We did a large scale outdoor rollout for the X-Games (both summer and winter) where we used our outdoor APs to light up the side of Buttermilk mountain in Aspen for the winter X Games as well as the LA Coliseum, Staples Center, Nokia Theater and Part of downtown LA for the summer X Games. Here is a link to a story we did on this project: Bat Blue Delivers Wifi Services for ESPN X-Games You can see one of our outdoor APs in the background as Avril Levigne hands Shaun White his medal. We would be happy to work with you on your project if you think we can help. Best Regards, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Networks (p) 212.461.3322 x3005 | (f) 212.584.9999 | www.BatBlue.com Bat Blue: AS 25885 | BGP Policy | Peering Policy Watch: Cloud Security Video | Cloud Network Video Read: Official Provider for ESPN X Games -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1666 bytes Desc: not available URL: From maxsec at gmail.com Sun Apr 1 11:02:20 2012 From: maxsec at gmail.com (Martin Hepworth) Date: Sun, 1 Apr 2012 17:02:20 +0100 Subject: April fools joke? In-Reply-To: References: <71E3CD78-A057-4519-A561-04D998611AA2@ukbroadband.com> Message-ID: On Sunday, 1 April 2012, chris wrote: > April 1st or not its the gist of that story is probably already true > whether you know it or not. > > On Sun, Apr 1, 2012 at 10:30 AM, Justin Wilson > > wrote: > > > I hate April 1 on the Web. You are right you never can tell. I > > would be > > appalled if someone as respectable as the BBC stoops to downright dumb > > pranks. > > > > However, it is England. They have some of the most strict laws in > > the > > "Free" world. > > > > I hate the Interweb on April 1. lol > > > > -----Original Message----- > > From: Leigh Porter > > > Date: Sun, 1 Apr 2012 10:45:51 +0000 > > To: "nanog at nanog.org " > > > Subject: April fools joke? > > > > > > > >http://www.bbc.co.uk/news/uk-politics-17576745 > > > > > >It's sad when you just can't tell with things like this.. > > > > > >-- > > >Leigh > > > Re visit of the stuff that was thrown out about 3 years when raised by Labour govmt and berated by the present govemt when they were in opposition Home Office and others want it but most businesses don't and the civil liberties guys are quite against it - requirement on any online or comms provider to keep logs for ages! Martin -- -- Martin Hepworth Oxford, UK From shortdudey123 at gmail.com Sun Apr 1 11:42:25 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 1 Apr 2012 11:42:25 -0500 Subject: STEP Security (RFC4012012) In-Reply-To: <20120401150442.GB14436@infiltrated.net> References: <20120401150442.GB14436@infiltrated.net> Message-ID: April 1 2012 RFC's Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) http://www.rfc-editor.org/rfc/rfc6593.txt The Null Packet http://www.rfc-editor.org/rfc/rfc6592.txt -Grant On Sun, Apr 1, 2012 at 10:04 AM, J. Oquendo wrote: > Interweb Re-Engineering Task Force J. Oquendo > Request for Comments 4012012 E-Fensive Security Strategies > Category: Informational > Expires: 2020 > > > STEP by STEP Security > > > Status of this Memo > > This Internet-Draft is submitted in full nonconformance with > provisions of BCP 78 and BCP 79. This document may not be modified, > and derivative works of it may not be created, except to publish it > as an RFC and to translate it into languages other than English. > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > This Internet-Draft will expire on April 01, 2020. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with > respect to this document. Code Components extracted from this > document must include Simplified BSD License text as described in > > > > > Oquendo Expires Apr 01, 2020 [Page 1] > > > Internet-Draft Security Step by STEP RFC 4012012 > > > Section 4.e of the Trust Legal Provisions and are provided without > warranty as described in the Simplified BSD License. > > Abstract > > This framework describes a practical methodology for ensuring > security in otherwise insecure environments. The goal is to provide > a rapid response mechanism to defend against the advanced persistent > threats in the wild. > > Table of Contents > > > 1. Introduction..................................................2 > 2. Conventions used in this document.............................4 > 3. Threats Explained.............................................4 > 3.1. Possible Actors..........................................4 > 4. STEP Explained................................................5 > 5. STEP in Action................................................6 > 6. Security Considerations.......................................7 > 7. IANA Considerations...........................................7 > 8. Conclusions...................................................8 > 8.1. Informative References...................................8 > 9. Acknowledgments...............................................8 > Appendix A. Copyright............................................9 > > > 1. Introduction > In the network and computing industry, malicious actions, > applications and actors have become more pervasive. Response times > to anomalous events are burdening today's infrastructures and often > strain resources. As networks under attack are often saturated with > malicious traffic and advanced persistent threat actors engage in > downloading terabytes of data, resources to combat these threats > have diminished. > > Additionally, the threats are no longer just anonymized actors > engaging in juvenile behavior, there are many instances of State > Actors, disgruntled employees, contractors, third party vendors and > criminal organizations. Each with separate agendas, each > consistently targeting devices on the Internet. > > > > > Oquendo Informational [Page 2] > Internet-Draft Security Step by STEP RFC > 4012012 > > > The intent behind this document is to define a methodology for rapid > response to these threats. In this document, security will be > achieved using a new methodology and protocol henceforth named > Scissor To Ethernet Protocol (STEP). > > > > Initially designed as a last approach for security, STEP ensures > that no attacker can disaffect any of the Confidentiality, > Integrity, Availability of data as a whole. > > > > Many variables are involved in security, but the STEP methodology > focuses on the following: > > > o FUD (Fear Uncertainty and Doubt) > o SCAM (Security Compliance and Management) > o APT (Another Possible Threat) > > > > This methodology proposes STEP that SHOULD be performed at the onset > of a cyber attack before more terabytes of data are exfiltrated from > a network. > > 1. Industry Standard IP connection > > > +-----------+ +-----------+ +-----------+ > | | IP | | INGRESS | | > | Rogue |-------> | Internet | ------> | Target | > | A | | | | B | > | | | | EGRESS | | > +-----------+ +-----------+ <------ +-----------+ > > Figure 1 Example session between a rogue attacker and target > Figure 1 illustrates the connection via the Internet from a rogue > attacker, towards a target. Irrespective of the attack used, IP > will ALWAYS be used as the attack vector. > > > Oquendo Informational > [Page 3] > > > Internet-Draft Security Step by STEP RFC 4012012 > > > > > 2. Conventions used in this document > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC-2119 [RFC2119]. > > In this document, these words will appear with that interpretation > only when in ALL CAPS. Lower case uses of these words are not to be > interpreted as carrying RFC-2119 significance. > > > 3. Threats Explained > > A security threat is a theoretical happening that may not occur but > should be considered as part of a proper security architecture and > design. For example, the threat always exists that your systems > will become the target of a denial of service attack. A threat may > or may not have a method to mitigate the possibility of attack. > > Vendors across the security spectrum offer FUD based solutions often > promoting SCAM based systems to mitigate against APT. While some of > the available solutions may minimize the potential for catastrophic > transfers of terabytes of data, these solutions SHOULD NOT be used > as an all-inclusive solution for security. Engineers MUST NOT rely > on FUD, or SCAMs against the APT. > > 3.1. Possible Actors > > Both malicious attacks and unintended (non-malicious) attacks can > occur from anywhere in the world including local attacks inside of > the infrastructure. In the barest threat explanation above, the > threat that someone can commit a typographical error, causing a > disruption in service, is as severe as a Distributed Denial of > Service attack from the public Internet. Actors can never be easily > identified unless one is watching the Academy Awards on television. > > > > > Oquendo Informational [Page 4] > > > Internet-Draft Security Step by STEP RFC 4012012 > > > 4. STEP Explained > > o S - Scissors > > Scissors as defined by wikipedia are" hand-operated cutting > instruments. They consist of a pair of metal blades pivoted so that > the sharpened edges slide against each other when the handles (bows) > opposite to the pivot are closed. Scissors are used for cutting > various thin materials, such as paper, cardboard, metal foil, thin > plastic, cloth, rope, and wire. Scissors can also be used to cut > hair and food. Scissors and shears are functionally equivalent, but > larger implements tend to be called shears. Scissors is a critical > component for STEP security and MUST be readily available 99.99999% > with redundant scissors within arm?..s reach. > > > | | > X X > / \ O O > > (Opened) (Closed) > > > o T - To > > To: [preposition] (Used for expressing direction or motion or > direction toward something) in the direction of; toward: from north > to south. > > o E - Ethernet > > Ethernet via Wikiepedia is described as a family of computer > networking technologies for local area networks (LANs) commercially > introduced in 1980. Standardized in IEEE 802.3, Ethernet has > largely replaced competing wired LAN technologies. For clarity in > our protocol, Ethernet is defined as the cabling between a device > and a network component such as a router or a switch. > > > > o P - Protocol > > A communications protocol is a system of digital message formats and > rules for exchanging those messages in or between computing systems > and in telecommunications. A protocol may have a formal > description. > > > Oquendo Informational [Page 5] > > > Internet-Draft Security Step by STEP RFC > 4012012 > > > Protocols may include signaling, authentication and error detection > and correction capabilities. > > A protocol definition defines the syntax, semantics, and > synchronization of communication; the specified behavior is > typically independent of how it is to be implemented. A protocol > can therefore be implemented as hardware or software or both. > > In STEP, Protocol is a rule an engineer MUST follow in order to > complete STEP. S MUST be in a closed state. > > > > Actor -----> | Target (secured from the threat) > X > O O > > (Closed) > > > 5. STEP in Action > The following illustrates a remote APT attack against a webserver > located in the demilitarized zone of an infrastucture. In the > example, an APT attacker is launching a SQLI, XSS and CSRF against a > target over the Internet. > > The attacks are common and according to statistics, are the same > attacks used to leverage access against major Fortune 500 companies > in the past decade. > > +-------+ +-----+ +-----+ +--------+ > | | SQLi | | + + INGRESS | | > | APT | -------> | ISP | ---> + ISP + ------> | Target | > | | XSS/CSRF | A | + B + | www | > | | | | + + | | > +-------+ +-----+ +-----+ +--------+ > > o Figure 5.1 Attacker launching attacks > +-------+ +-----+ +-----+ +--------+ > | | TCP | | + + Reverse | | > | APT | <------ | ISP | <--- + ISP + <------ | Target | > | | | A | + B + Shell | www | > | | | | + + | | > +-------+ +-----+ +-----+ +--------+ > > o Figure 5.2 Attacker executing a reverse shell > > > Oquendo Informational > [Page 6] > > > Internet-Draft Security Step by STEP RFC > 4012012 > > > > In the illustration, an attacker is almost certainly attempting to > obtain a reverse shell. This enables an attacker to access a device > as if one were physically present at the device itself. > Using STEP we can mitigate and deny this attack from various points: > > > +-------+ +-----+ +-----+ +--------+ > | | SQLi | | + + | | | > | APT | -------> | ISP | ---> + ISP + -->| | Target | > | | XSS/CSRF | A | + B + x | www | > | | | | + + o o | | > +-------+ +-----+ +-----+ +--------+ > > o Figure 5.2 Ingress STEP > > +-------+ +-----+ +-----+ +--------+ > | | Attack | | | + + | | > | APT | ------> | ISP | ->| + ISP + | Target | > | | | A | x + B + | www | > | | | | o o + + | | > +-------+ +-----+ +-----+ +--------+ > > o Figure 5.4 Provider based STEP > > > Both instances of STEP successfully demonstrate the power of the > STEP protocol. In no case, can an attacker successfully launch any > attack against a target as the security posture has now been > hardened. > > 6. Security Considerations > > Cutting any Ethernet cable could potentially lead to shock and > degradation of IP services on your network. Please ensure there are > additional Ethernet cables for redundancy. Otherwise there is > nothing to consider. > > > 7. IANA Considerations > > There are no alternative considerations. STEP is the ultimate in > security. > > > Oquendo Informational > [Page 7] > > > Internet-Draft Security Step by STEP RFC 4012012 > > > 8. Conclusions > > Step defends against APT while minimizing your exposure to SCAMs and > FUD. > > 8.1. Informative References > > [1] http://www.amazon.com/b?ie=UTF8&node=689392011 > [2] http://ha.ckers.org/xss.html > [3] http://en.wikipedia.org/wiki/Advanced_persistent_threat > [4] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt > > > 9. Acknowledgments > Sofia Vergara > Kenji, Saki and Coco > > > > > Oquendo Informational [Page > 8] > > > Internet-Draft Security Step by STEP RFC 4012012 > > > Appendix A. Copyright > > > > Copyright (c) 2012 IETF Trust and the persons identified as authors > of the code. All rights reserved. > > Redistribution and use in source and binary forms, with or without > modification, are permitted provided that the following conditions > are met: > > o Redistributions of source code must retain the above copyright > notice, this list of conditions and the following disclaimer. > > o Redistributions in binary form must reproduce the above copyright > notice, this list of conditions and the following disclaimer in > the documentation and/or other materials provided with the > distribution. > o Neither the name of Internet Society, IETF or IETF Trust, nor the > names of specific contributors, may be used to endorse or promote > products derived from this software without specific prior > written permission. > > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS > FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, > BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER > CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN > ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > POSSIBILITY OF SUCH DAMAGE. > > > Author's Addresses > > Jesus Oquendo > E-Fensive Security Strategies > > > Oquendo Informational [Page 9] > > > > From gbonser at seven.com Sun Apr 1 16:24:27 2012 From: gbonser at seven.com (George Bonser) Date: Sun, 1 Apr 2012 21:24:27 +0000 Subject: April fools joke? In-Reply-To: <71E3CD78-A057-4519-A561-04D998611AA2@ukbroadband.com> References: <71E3CD78-A057-4519-A561-04D998611AA2@ukbroadband.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D85482@RWC-MBX1.corp.seven.com> > From: Leigh Porter > Sent: Sunday, April 01, 2012 3:46 AM > To: nanog at nanog.org > Subject: April fools joke? > > > http://www.bbc.co.uk/news/uk-politics-17576745 > > It's sad when you just can't tell with things like this.. > > -- > Leigh I was hoping for something good, like maybe an extension of RFC 1149 implementing ECN (aka SQUAWK) in avian carriers. I'm disappointed. From mohta at necom830.hpcl.titech.ac.jp Sun Apr 1 16:44:20 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 02 Apr 2012 06:44:20 +0900 Subject: Outdoor Wireless Access Point In-Reply-To: References: Message-ID: <4F78CC34.7020603@necom830.hpcl.titech.ac.jp> Shahab Vahabzadeh wrote: > As I look for maps we need at least 3 or 4 outdoor radio, I think in these > networks the best solution is to have only one SSID in whole network to > give mobility for the network, is this called ad-hoc? or it has an other > name? It is usually called nomad, because it is not really mobility. With 802.11, you can connect to an AP and, if the AP fails, you may be connected to another AP, but the transition takes considerable amount of time not tolerable for voice communication, which is why it is not called mobility. If you want mobility, have different SSIDs for APs in the same frequency band (or, let terminals have multiple sets of radio interfaces) and let terminals connect to multiple APs simultaneously. Then, run mobile IP to *RAPIDLY* control the primary AP depending on signal quality of beacons from APs. Though you only have to modify software on terminals, AFAIK, there is no such commercial products. > And if there is any good company which can both indoor > and outdoor solution With your environment, you only need indoor equipments with external antennas located outdoors. Masataka Ohta From shadowedstrangerlists at gmail.com Sun Apr 1 17:17:58 2012 From: shadowedstrangerlists at gmail.com (Jacob Broussard) Date: Sun, 1 Apr 2012 15:17:58 -0700 Subject: Outdoor Wireless Access Point In-Reply-To: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> Message-ID: I won't touch why we share info, others have already beat that horse dead, but I will say that This list is fairly hostile to people wanting to use them as 'free consultants'. Just look back through the archives for people that post with a message similar to: 'I want to start an isp can someone give me a step by step guide'. They aren't usually received nearly as well as someone who asks 'does anyone have any solutions to this specific problem I'm facing?' On Mar 31, 2012 3:49 PM, "Network IP Dog" wrote: > Hi...How do I do it! > > I'm utterly amazed how many people give away free consultant work. > > We need to keep people working... not giving it away. > > Ethics... Security... etc... > > Does the university give away free diploma's? I don't think so. > > Must be another copy & paste e&^%$#?r too! > > Google is your friend... ;^) > > Cheers! > > > Ephesians 4:32 & Cheers!!! > > A password is like a... toothbrush ;^) > Choose a good one, change it regularly and don't share it. > > -----Original Message----- > From: Shahab Vahabzadeh [mailto:sh.vahabzadeh at gmail.com] > Sent: Saturday, March 31, 2012 2:39 AM > To: nanog at nanog.org > Subject: Outdoor Wireless Access Point > > Hi there, > I asked for a wireless solution for a university, in which they want indoor > wireless solution for more than 5 building (at least two floor) and outdoor > wireless solution for near 160m*280m garden. > As I look for maps we need at least 3 or 4 outdoor radio, I think in these > networks the best solution is to have only one SSID in whole network to > give > mobility for the network, is this called ad-hoc? or it has an other name? > I do not know if I could ask question clearly or not, suppose we have 4 > radio but only one SSID is broadcasting and when you are near the radio is > near to you you will get service from that one, as this solution must be > implement for indoor ones too. > And if there is any good company which can both indoor and outdoor solution > and they have shipping to Iran too or reseller in Iran please give me the > url. > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > > > From shadowedstrangerlists at gmail.com Sun Apr 1 17:20:01 2012 From: shadowedstrangerlists at gmail.com (Jacob Broussard) Date: Sun, 1 Apr 2012 15:20:01 -0700 Subject: Outdoor Wireless Access Point In-Reply-To: <20120401041149.E2C43800037@ip-64-139-1-69.sjc.megapath.net> References: <20120401041149.E2C43800037@ip-64-139-1-69.sjc.megapath.net> Message-ID: Don't forget Stanford's coursera! Another up and coming one that looks like it is very quality is Udacity. On Mar 31, 2012 9:12 PM, "Hal Murray" wrote: > > > Hi...How do I do it! > > I'm utterly amazed how many people give away free consultant work. > > We need to keep people working... not giving it away. > > Ethics... Security... etc... > > Does the university give away free diploma's? I don't think so. > > I don't expect a free diploma, but many universities are offering free > internet videos of various classes. > > If you want a sample, here are a few good starting points: > http://ocw.mit.edu/ > http://oyc.yale.edu/ > http://webcast.berkeley.edu/ > > > -- > These are my opinions, not necessarily my employer's. I hate spam. > > > > > From jmaslak at antelope.net Sun Apr 1 18:09:12 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Sun, 1 Apr 2012 17:09:12 -0600 Subject: Outdoor Wireless Access Point In-Reply-To: <4F78CC34.7020603@necom830.hpcl.titech.ac.jp> References: <4F78CC34.7020603@necom830.hpcl.titech.ac.jp> Message-ID: <574FC49A-619D-4CC3-B7C8-5193EAE1C412@antelope.net> On Apr 1, 2012, at 3:44 PM, Masataka Ohta wrote: > With 802.11, you can connect to an AP and, if the AP > fails, you may be connected to another AP, but the > transition takes considerable amount of time not > tolerable for voice communication, which is why it > is not called mobility. True under basic 802.11, at least with WPA2 + EAP, for some clients. Not all clients wait until they lose connectivity to start looking for another AP - it depends on how the client was built. However, even without needing to lose connectivity to learn what other APs are nearby, there still is a substantial associatiation delay with EAP. That's why 802.11r + 802.11k exist. I'm sure the big name vendors support this and also support their proprietary alternatives that may or may not be better. > If you want mobility, have different SSIDs for APs in > the same frequency band (or, let terminals have multiple > sets of radio interfaces) and let terminals connect > to multiple APs simultaneously. That's one way of doing it, provided you have a way to manage all the end devices when you add new APs. It has the disadvantage of not being a COTS solution AFAIK. Another way to do it is Meru's "one frequency, one MAC" approach. As for locating other access points, even without 802.11k, most solutions I have seen go into power save mode for long enough to do a quick scan every once in a while, taking into account the size of the phone's jitter buffer. That causes the AP to hold packets until the scan finishes. So one channel is not required for fast roaming. I've seen solutions cope without 802.11r + 802.11k by using a WEP-only SSID on each AP (typically the same SSID for all APs) and throwing that into a VOIP-only VLAN. But with smartphones capable of running VoIP clients, I'd be less inclined to do it that way even if I thought WEP was secure-enough for voice calls. The other solution that I've seen some things support is to use WDS on the VoIP device. I'm also not a fan of that personally, but others may be. WDS would require one frequency throughout the network however. > Though you only have to modify software on terminals, > AFAIK, there is no such commercial products. There are plenty of commercial products that support VoIP handoff without issues. Some are proprietary, some are open standards. Many support multi-channel networks. It starts to get expensive to do this though, as most (all?) of the cheap vendors don't do what is required on the AP side. That said, I'd love to hear I'm wrong on this - I'm looking for new APs for home. So, if I was buying an enterprise 802.11 solution and needed to support seamless VoIP roaming, I'd look at either a one-vendor solution (I'm sure Cisco phones + Cisco APs + Cisco Controller + Cisco PBX would do this just fine, for instance; you can substitute a few other big vendors for Cisco, no doubt, although not likely cheap ones; you'll be spending 10x or more per AP in many cases than if you could have used the cheap ones) or someone that complies with 802.11r + 802.11k (both for handses and APs). Obviously your network better support DSCP and/or VLAN priority marking and WMM as well. Supporting VoIP handoff is much more complex (and, at least from what I've seen, expensive) than supporting web browsing handoff. It's also what seperates different pricing tiers of wireless equipment. From kmedcalf at dessus.com Sun Apr 1 18:18:50 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 01 Apr 2012 17:18:50 -0600 Subject: April fools joke? In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D85482@RWC-MBX1.corp.seven.com> Message-ID: > > http://www.bbc.co.uk/news/uk-politics-17576745 > > It's sad when you just can't tell with things like this.. > I was hoping for something good, like maybe an extension of RFC 1149 > implementing ECN (aka SQUAWK) in avian carriers. I'm disappointed. ECN doesn't help if the Hunting Season bit is set. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From mohta at necom830.hpcl.titech.ac.jp Sun Apr 1 19:35:48 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 02 Apr 2012 09:35:48 +0900 Subject: Outdoor Wireless Access Point In-Reply-To: <574FC49A-619D-4CC3-B7C8-5193EAE1C412@antelope.net> References: <4F78CC34.7020603@necom830.hpcl.titech.ac.jp> <574FC49A-619D-4CC3-B7C8-5193EAE1C412@antelope.net> Message-ID: <4F78F464.20301@necom830.hpcl.titech.ac.jp> Joel Maslak wrote: >> With 802.11, you can connect to an AP and, if the AP >> fails, you may be connected to another AP, but the >> transition takes considerable amount of time not >> tolerable for voice communication, which is why it >> is not called mobility. > > True under basic 802.11, at least with WPA2 + EAP, for some > clients. Not all clients wait until they lose connectivity > to start looking for another AP - it depends on how the client > was built. The problem of looking for another APs is that, to scan existence of other APs with reasonable reliability, clients must listen to other channels for considerable amount of time (three times maximum beacon interval, maybe), during which the clients can't receive packets from the current APs. That's why most, if not all, clients search new APs only after they loss connection with the current APs. > However, even without needing to lose connectivity > to learn what other APs are nearby, there still is a > substantial associatiation delay with EAP. That's not a problem, in this case, when all the servers will be located in a university campus. > That's why 802.11r + 802.11k exist. I'm afraid it is a L2 implementation of broken idea of PANA. >> If you want mobility, have different SSIDs for APs in >> the same frequency band (or, let terminals have multiple >> sets of radio interfaces) and let terminals connect >> to multiple APs simultaneously. > > That's one way of doing it, provided you have a way to manage > all the end devices when you add new APs. It has the > disadvantage of not being a COTS solution AFAIK. It is because the currently recognized commercial demand is to have smooth migration between 2/3G and WLAN, for which two RFs one for 2/3G and another for WLAN is enough. > Another way to do it is Meru's "one frequency, one MAC" approach. "one frequency, one MAC"? I think it does not eliminate overhead of channel scanning, or, does it? > As for locating other access points, even without 802.11k, most > solutions I have seen go into power save mode for long enough > to do a quick scan every once in a while, taking into account > the size of the phone's jitter buffer. That causes the AP > to hold packets until the scan finishes. So one channel is > not required for fast roaming. Then, very short beacon intervals must be assumed. > But with smartphones capable of running VoIP clients, I'd be > less inclined to do it that way even if I thought WEP was > secure-enough for voice calls. Smart phones makes the situation worse. With applications with high speed communication, 50ms loss of communication can be significant. At 12Mbps, twenty 1500B packets are lost in 50ms. > Supporting VoIP handoff is much more complex (and, at least > from what I've seen, expensive) than supporting web browsing > handoff. Both of them are difficult in their own way that the complete solution (within WLAN SS, between 2/3G and WLAN, between WLAN of different service providers etc.) can be found only at L3 layer, IMHO. Masataka Ohta From jason at i6ix.com Sun Apr 1 19:37:07 2012 From: jason at i6ix.com (Jason Bertoch) Date: Sun, 01 Apr 2012 20:37:07 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330215549.68551.qmail@joyce.lan> References: <20120330215549.68551.qmail@joyce.lan> Message-ID: <4F78F4B3.4030304@i6ix.com> On 3/30/2012 5:55 PM, John Levine wrote: >>> I thought it should have died when pr0n and >>> w4rez took it over (in the late 90's).. > Many of the tech groups remain quite healthy. I still moderate > comp.compilers which gets about 100 posts/month. > > Actually, it's fine with us that the ignorant masses think that usenet > is dead, since it tends to keep out the riffraff. > > R's, > John > +1 From bonomi at mail.r-bonomi.com Sun Apr 1 23:56:46 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 1 Apr 2012 23:56:46 -0500 (CDT) Subject: April fools joke? In-Reply-To: Message-ID: <201204020456.q324ukHf003730@mail.r-bonomi.com> "Keith Medcalf" wrote: {prior attributions lost} > > > http://www.bbc.co.uk/news/uk-politics-17576745 > > > > It's sad when you just can't tell with things like this.. > > > I was hoping for something good, like maybe an extension of RFC 1149 > > implementing ECN (aka SQUAWK) in avian carriers. I'm disappointed. > > ECN doesn't help if the Hunting Season bit is set. That's a situation where you *want* Bugs in the project. "Wabbit Season!" From bortzmeyer at nic.fr Mon Apr 2 02:01:05 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 2 Apr 2012 09:01:05 +0200 Subject: Was b.root-servers.net under attack on Mar 31? In-Reply-To: References: Message-ID: <20120402070105.GA29466@nic.fr> On Sun, Apr 01, 2012 at 11:23:31PM +0800, Che-Hoo CHENG wrote a message of 9 lines which said: > http://dnsmon.ripe.net/dns-servmon/server/plot?server=b.root-servers.net;type=drops;tstart=1333166400;tstop=1333252799;af=ipv4 > > There were quite a few unanswered queries from around 06:15 to around 09:15 UTC on Mar 31. B is often the weakest link of the 13. I have no idea whether it was attacked or not but perturbations are common. Most of the time, noone watches dnsmon so they go unnoticed but, on March 31st, every small glitch was spotted... From saku at ytti.fi Mon Apr 2 03:44:45 2012 From: saku at ytti.fi (Saku Ytti) Date: Mon, 2 Apr 2012 11:44:45 +0300 Subject: Handling of L2 broadcast, L3 unicast frames Message-ID: <20120402084445.GA2667@pob.ytti.fi> If you try % sudo ip route add 194.100.7.227/32 dev eth0 % sudo arp -i eth0 -s 194.100.7.227 ff:ff:ff:ff:ff:ff % ping 194.100.7.227 Chances are that you get ping replies (Cisco VXR, Cisco ISR, Juniper SRX, Juniper M10i, Juniper M7i, Linksys e4200) But you also might not be getting replies (Catalyst 7600, 3560, EX4200) RFC[0] says in rather unambiguous way, that this should not be working. I don't think catalyst/EX guys were lot smarter and honoured the RFC. Rather I think it's hardware limitation they work like this. At least 7600 (as per ELAM capture) acts like switch and tries to normally broadcast the frame in the VLAN, but as it is L3 interface, there is only one port in the VLAN, so net effect is, frame is dropped. Now I'm facing loop, which is caused by ill-configured network, by any networker definition of ill-configured. However, if our router would behave like RFC says, then the ill-configured network would not cause loops. This puts me in bit of a pickle, I can't call cisco and juniper and tell them to fix all their routers and give me fixed release tomorrow, since this behaviour seems very standard/de-facto behaviour. Customer refuses to do any of the fixes in the ill-configured network, as problem only started after swapping catalyst to ISR, so customer understandably does not grasp the fault is not in our end (it's not, fault is caused by mismatching L2/L3 topologies with directed-broadcast in customer router) Anyone else ever had problems due to router vendors not implementing rfc1812 5.3.4? [0] http://tools.ietf.org/html/rfc1812#section-5.3.4 -- ++ytti From mansaxel at besserwisser.org Mon Apr 2 06:17:12 2012 From: mansaxel at besserwisser.org (=?iso-8859-1?Q?M=E5ns?= Nilsson) Date: Mon, 2 Apr 2012 13:17:12 +0200 Subject: Outdoor Wireless Access Point In-Reply-To: <111456.1333267111@turing-police.cc.vt.edu> References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> <74945.1333237748@turing-police.cc.vt.edu> <111456.1333267111@turing-police.cc.vt.edu> Message-ID: <20120402111708.GC6655@besserwisser.org> On Sun, Apr 01, 2012 at 03:58:31AM -0400, Valdis.Kletnieks at vt.edu wrote: > But there's a 22 acre field (about twice the size of the garden you are trying > to support) in the middle of campus... literally in the middle, as in "the campus > is built around that field". ;) (No doubt Valdis knows this, but..) It is kind of funny to realtime-translate this from Latin to English where applicable, and get "But there's a 22 acre field in the middle of the field" and "the field is built around that field" ;-) ++; -- /M?ns, blaming his Latin class. From askoorb+nanog at gmail.com Mon Apr 2 06:30:02 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Mon, 2 Apr 2012 12:30:02 +0100 Subject: CCDP (Was: April fools joke?) In-Reply-To: <329ED0F4-4516-4FD5-8046-5D5D7E3C0304@gmail.com> References: <329ED0F4-4516-4FD5-8046-5D5D7E3C0304@gmail.com> Message-ID: On Sun, Apr 1, 2012 at 3:54 PM, Alec Muffett wrote: > > > On 1 Apr 2012, at 15:30, Justin Wilson wrote: > > ? ? ? I hate April 1 on the Web. You are right you never can tell. ?I > > would be > > appalled if someone as respectable as the BBC stoops to downright dumb > > pranks. > > It is true. > > It's called the Communications Capabilities Development Programme (CCDP) More details (from a fairly level-headed viewpoint) have been published at http://www.theregister.co.uk/2012/04/02/ccdp_government_snooping_plans/. It looks like for more details we'll have to wait for the Queen's Speech on the 9th of May (and the following white / command papers and other guff) when it looks like she'll announce it with all the other legislation her government will try to pass over the next year. Alex From oscar.vives at gmail.com Mon Apr 2 06:40:25 2012 From: oscar.vives at gmail.com (Tei) Date: Mon, 2 Apr 2012 13:40:25 +0200 Subject: April fools joke? In-Reply-To: <201204020456.q324ukHf003730@mail.r-bonomi.com> References: <201204020456.q324ukHf003730@mail.r-bonomi.com> Message-ID: On 2 April 2012 06:56, Robert Bonomi wrote: > > "Keith Medcalf" wrote: > {prior attributions lost} >> > > http://www.bbc.co.uk/news/uk-politics-17576745 >> >> > > It's sad when you just can't tell with things like this.. >> >> > I was hoping for something good, like maybe an extension of RFC 1149 >> > implementing ECN (aka SQUAWK) in avian carriers. I'm disappointed. >> >> ECN doesn't help if the Hunting Season bit is set. > > That's a situation where you *want* Bugs in the project. > > ?"Wabbit Season!" > Joke is on then. I make all my terrorist talking in Counter-Strike. Since the game packets are not logued, nothing is logued. And we use a special language so a possible spy would not understand us. 1. "OMFG! It's a deagle train! Camp for your life!" 2. "W00T kill #7 Total deagle-train!" 3. "Why don't you use that M4 you have?" 2. "Because I'm deagle-training n00b!" Logging emails: - 100% false positives: log data from everyone not evil - 100% missed messages: don't log data from evil people The very definition of useless. Probably another "feel good", "look how we combat the evuuul" politics. -- -- ?in del ?ensaje. From oscar.vives at gmail.com Mon Apr 2 06:51:44 2012 From: oscar.vives at gmail.com (Tei) Date: Mon, 2 Apr 2012 13:51:44 +0200 Subject: April fools joke? In-Reply-To: References: <201204020456.q324ukHf003730@mail.r-bonomi.com> Message-ID: On 2 April 2012 13:40, Tei wrote: > On 2 April 2012 06:56, Robert Bonomi wrote: >> >> "Keith Medcalf" wrote: >> {prior attributions lost} >>> > > http://www.bbc.co.uk/news/uk-politics-17576745 >>> >>> > > It's sad when you just can't tell with things like this.. >>> >>> > I was hoping for something good, like maybe an extension of RFC 1149 >>> > implementing ECN (aka SQUAWK) in avian carriers. I'm disappointed. >>> >>> ECN doesn't help if the Hunting Season bit is set. >> >> That's a situation where you *want* Bugs in the project. >> >> ?"Wabbit Season!" >> > > Joke is on then. > > I make all my terrorist talking in Counter-Strike. ?Since the game > packets are not logued, nothing is logued. ? And we use a special > language so a possible spy would not understand us. > > 1. "OMFG! It's a deagle train! Camp for your life!" Oops. sorry, seems will use deep packet inspection for games. I suppose the trigger for wen the terrorist say "we have setup the bomb" will trigger a few hundreds of times per minute. :-/ -- -- ?in del ?ensaje. From jra at baylink.com Mon Apr 2 08:23:50 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 2 Apr 2012 09:23:50 -0400 (EDT) Subject: April fools joke? In-Reply-To: Message-ID: <1385459.9303.1333373030249.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tei" > Oops. sorry, seems will use deep packet inspection for games. > > I suppose the trigger for wen the terrorist say "we have setup the > bomb" will trigger a few hundreds of times per minute. :-/ "Somebody set up us the bomb." (Though in general use, "set us up" is more commonly heard.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Apr 2 08:25:35 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 2 Apr 2012 09:25:35 -0400 (EDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <4F78F4B3.4030304@i6ix.com> Message-ID: <30268057.9305.1333373135836.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jason Bertoch" > On 3/30/2012 5:55 PM, John Levine wrote: > > Actually, it's fine with us that the ignorant masses think that > > usenet is dead, since it tends to keep out the riffraff. > +1 +5; September is finally over. Now, where can I get a non-commercial rec.arts/tech-groups feed? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Apr 2 08:32:05 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 2 Apr 2012 09:32:05 -0400 (EDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: Message-ID: <27997262.9307.1333373525471.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John R. Levine" > Spam sucks, but I've been posting to usenet with my real unmunged email > address since 1981 and my inbox remains entirely usable. The idea that > the way to avoid spam is to hide from spammers is so 1990s. I've been posting to Usenet with my real *cell phone number* in my sig, not to mention a dozen mailing lists. You know how many unsolicited phone calls I've gotten in 29 years? Maybe as many as a dozen. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From dylan at corp.power1.com Mon Apr 2 08:38:49 2012 From: dylan at corp.power1.com (Dylan Bouterse) Date: Mon, 2 Apr 2012 13:38:49 +0000 Subject: airFiber In-Reply-To: References: <3631ff80$65b2bbb3$4de71797$@com> Message-ID: <218AB54691EB49439829EFD136F473CF27752437@exchange2k10.corp.power1.com> What published specs have you seen on the airFiber latency? I asked one of the UBNT guys and they said it's microsecond. On any network I've managed, anything sub 1ms is acceptable. Dylan -----Original Message----- From: John van Oppen [mailto:jvanoppen at spectrumnet.us] Sent: Saturday, March 31, 2012 2:22 PM To: 'Andrew McConachie'; Marshall Eubanks Cc: NANOG list Subject: RE: airFiber We actually have a lot of the old gigabeam radios in service, they are faster than the published specs of the airfiber links (1G full duplex vs 750 mbit/sec fd) and lower latency due to their very simplistic design. To be honest, from a network engineering standpoint, the gigabeams were conveninet as path issues would show up as ethernet errors that can be used to trigger reroutes or other events. That being said, we did not have a large variety of switches as the microwave side of our house is made up entirely of just a couple of cisco models. The gigabeams also have a pure OOB management setup. John From joshbaird at gmail.com Mon Apr 2 08:44:06 2012 From: joshbaird at gmail.com (Josh Baird) Date: Mon, 2 Apr 2012 09:44:06 -0400 Subject: airFiber In-Reply-To: <218AB54691EB49439829EFD136F473CF27752437@exchange2k10.corp.power1.com> References: <3631ff80$65b2bbb3$4de71797$@com> <218AB54691EB49439829EFD136F473CF27752437@exchange2k10.corp.power1.com> Message-ID: I was told to expect 0.1ms by UBNT. Haven't seen this published, though. Josh On Mon, Apr 2, 2012 at 9:38 AM, Dylan Bouterse wrote: > What published specs have you seen on the airFiber latency? I asked one of the UBNT guys and they said it's microsecond. On any network I've managed, anything sub 1ms is acceptable. > > Dylan > > -----Original Message----- > From: John van Oppen [mailto:jvanoppen at spectrumnet.us] > Sent: Saturday, March 31, 2012 2:22 PM > To: 'Andrew McConachie'; Marshall Eubanks > Cc: NANOG list > Subject: RE: airFiber > > We actually have a lot of the old gigabeam radios in service, they are faster than the published specs of the airfiber links (1G full duplex vs 750 mbit/sec fd) and lower latency due to their very simplistic design. ? ? To be honest, from a network engineering standpoint, the gigabeams were conveninet as path issues would show up as ethernet errors that can be used to trigger reroutes or other events. ? ?That being said, we did not have a large variety of switches as the microwave side of our house is made up entirely of just a couple of cisco models. ? ?The gigabeams also have a pure OOB management setup. > > > John > > From dave at temk.in Mon Apr 2 10:46:50 2012 From: dave at temk.in (Dave Temkin) Date: Mon, 02 Apr 2012 11:46:50 -0400 Subject: [NANOG-announce] NANOG 55 - Vancouver: Call For Presentations In-Reply-To: <4F42CC97.3000200@temk.in> References: <4F42CC97.3000200@temk.in> Message-ID: <4F79C9EA.6090106@temk.in> All, A reminder as per below - abstracts are due today, and we would like to ask for slides by April 9th. Best Regards, -Dave Temkin On 2/20/12 5:43 PM, Dave Temkin wrote: > NANOG Community, > > After an awesome meeting in San Diego, we're already starting to get ready for NANOG 55 in Vancouver. > If you have a topic you'd like to speak about, we'd love to consider it. Please watch > http://www.nanog.org/meetings/nanog55/callforpresentations.html for more information. > > Please keep these important dates in mind: > > > Presentation Abstracts and Draft Slides Due: 02-Apr-2012 > Final Slides Due: 09-Apr-2012 > Draft Program Published: 27-Apr-2012 > Final Agenda Published: 15-May-2012 > > Please submit your materials to http://pc.nanog.org > > Looking forward to seeing everyone in San Diego. > > -Dave Temkin > > (Chair, NANOG Program Committee) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From jerome at ceriz.fr Mon Apr 2 10:55:04 2012 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Mon, 02 Apr 2012 17:55:04 +0200 Subject: Reachability issue 193.56.43.0/24AS25186 from AS701 Message-ID: <4F79CBD8.1020202@ceriz.fr> Hi, Just changed the upstream for this network and a few customers can't reach our services anymore. According to RIPE stats, reachability, is not optimal on the north american zone, but is perfect everywhere else (see https://stat.ripe.net/193.56.43.124) One of the complaining customer is on AS1660 and the route breaks within AS701. Could anyone confirm the reachability for this prefix from the US ? Anyone at Verizon to check and fix if necessary ? Thanks ! -- J?r?me Nicolle +33 6 19 31 27 14 From todd at borked.ca Mon Apr 2 11:08:06 2012 From: todd at borked.ca (Todd Snyder) Date: Mon, 2 Apr 2012 12:08:06 -0400 Subject: Distributed DNS/etc checking Message-ID: Good day all, There have been a few instances where we've wanted to check our external DNS servers from various external networks, so we've utilized the existing looking glass tools provided by many of you. However, it's a very manual process, given that all LG's I've found say no automating/scripting. If we want to check from a couple dozen sites around the world, it's a lot of clicking and typing and collecting. If we wanted to create an tool that our NOC could use to verify our services, we would need something we could script. Ideally, we'd be able to run this constantly to do health checks on our services, but one step at a time. I've been googling, but so far I'm unable to find any larger scale projects/toolsets that we could use to simplify this process. Is anyone aware of something that would allow for me to submit a "job" to some sort of distributed service (I care about DNS, but others may care about traceroutes, pings, bgp information, etc), that will then run run the "job" and give me back an answer? Similarly, but perhaps differently, those of you who may run large anycast DNS services, how do you gather "external" stats about routing, response time, availability, and so on? It seems like this sort of thing would be a fairly common requirement (lets see how my network looks to those outside of it) but everything I can find is very manual at this point. This looks like a somewhat promising option, however I don't think I could get buy-in to run a node in our network, so it's not on the table for now: https://ring.nlnog.net/ This same functionality would likely be very helpful internal to large networks as well. I would love to know if I'm missing something obvious, or pieces of something obvious we could work with. Failing something already existing, I'd value any information people care to share about how they do this now, either on or off list. I can summarize any findings if the community is interested. Cheers, Todd. From jgreco at ns.sol.net Mon Apr 2 11:26:40 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 2 Apr 2012 11:26:40 -0500 (CDT) Subject: Distributed DNS/etc checking In-Reply-To: Message-ID: <201204021626.q32GQen2052055@aurora.sol.net> > Good day all, > > There have been a few instances where we've wanted to check our external > DNS servers from various external networks, so we've utilized the existing > looking glass tools provided by many of you. However, it's a very manual > process, given that all LG's I've found say no automating/scripting. If we > want to check from a couple dozen sites around the world, it's a lot of > clicking and typing and collecting. If we wanted to create an tool that > our NOC could use to verify our services, we would need something we could > script. Ideally, we'd be able to run this constantly to do health checks > on our services, but one step at a time. > > I've been googling, but so far I'm unable to find any larger scale > projects/toolsets that we could use to simplify this process. Is anyone > aware of something that would allow for me to submit a "job" to some sort > of distributed service (I care about DNS, but others may care about > traceroutes, pings, bgp information, etc), that will then run run the "job" > and give me back an answer? > > Similarly, but perhaps differently, those of you who may run large anycast > DNS services, how do you gather "external" stats about routing, response > time, availability, and so on? It seems like this sort of thing would be a > fairly common requirement (lets see how my network looks to those outside > of it) but everything I can find is very manual at this point. > > This looks like a somewhat promising option, however I don't think I could > get buy-in to run a node in our network, so it's not on the table for now: > https://ring.nlnog.net/ > > This same functionality would likely be very helpful internal to large > networks as well. > > I would love to know if I'm missing something obvious, or pieces of > something obvious we could work with. Failing something already existing, > I'd value any information people care to share about how they do this now, > either on or off list. I can summarize any findings if the community is > interested. The usual technique is to buy a few cheap virtual private servers at points of interest around the net and then do whatever you please. The problem is that your network will have a different monitoring system than our network, so if you want something that integrates cleanly with your Nagios based system, it'll be different than what integrates cleanly with our WhatsUp system. So it's usually easier to just go with some cheap virtual private servers. If you're clever, you might see if you can exchange services with a few other small networks. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "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. From jra at baylink.com Mon Apr 2 11:27:51 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 2 Apr 2012 12:27:51 -0400 (EDT) Subject: [outages] XO Outages In-Reply-To: Message-ID: <15197067.9511.1333384071857.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Darren Cusano" > Anyone experiencing any XO Outages? In the Philadelphia area our lines > are straight to busy. We have some direct PRIs from XO in Tampa FL, and I have no reports from the office of circuit problems at this time. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Apr 2 11:28:28 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 2 Apr 2012 12:28:28 -0400 (EDT) Subject: [outages] XO Outages In-Reply-To: <15197067.9511.1333384071857.JavaMail.root@benjamin.baylink.com> Message-ID: <23913751.9513.1333384108165.JavaMail.root@benjamin.baylink.com> Sorry folks. These are the trials of having a mailer with no list-reply key, and not enough coffee. -- j ----- Original Message ----- > From: "Jay Ashworth" > To: "NANOG" > Sent: Monday, April 2, 2012 12:27:51 PM > Subject: Re: [outages] XO Outages > ----- Original Message ----- > > From: "Darren Cusano" > > > Anyone experiencing any XO Outages? In the Philadelphia area our > > lines > > are straight to busy. > > We have some direct PRIs from XO in Tampa FL, and I have no reports > from the > office of circuit problems at this time. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From hank at efes.iucc.ac.il Mon Apr 2 12:14:28 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 2 Apr 2012 20:14:28 +0300 (IDT) Subject: Distributed DNS/etc checking In-Reply-To: References: Message-ID: On Mon, 2 Apr 2012, Todd Snyder wrote: Try: http://live.icmynet.com/icmynet-dns/ http://www.zonecut.net/dns/index.cgi Regards, Hank > Good day all, > > There have been a few instances where we've wanted to check our external > DNS servers from various external networks, so we've utilized the existing > looking glass tools provided by many of you. However, it's a very manual > process, given that all LG's I've found say no automating/scripting. If we > want to check from a couple dozen sites around the world, it's a lot of > clicking and typing and collecting. If we wanted to create an tool that > our NOC could use to verify our services, we would need something we could > script. Ideally, we'd be able to run this constantly to do health checks > on our services, but one step at a time. > > I've been googling, but so far I'm unable to find any larger scale > projects/toolsets that we could use to simplify this process. Is anyone > aware of something that would allow for me to submit a "job" to some sort > of distributed service (I care about DNS, but others may care about > traceroutes, pings, bgp information, etc), that will then run run the "job" > and give me back an answer? > > Similarly, but perhaps differently, those of you who may run large anycast > DNS services, how do you gather "external" stats about routing, response > time, availability, and so on? It seems like this sort of thing would be a > fairly common requirement (lets see how my network looks to those outside > of it) but everything I can find is very manual at this point. > > This looks like a somewhat promising option, however I don't think I could > get buy-in to run a node in our network, so it's not on the table for now: > https://ring.nlnog.net/ > > This same functionality would likely be very helpful internal to large > networks as well. > > I would love to know if I'm missing something obvious, or pieces of > something obvious we could work with. Failing something already existing, > I'd value any information people care to share about how they do this now, > either on or off list. I can summarize any findings if the community is > interested. > > Cheers, > > Todd. > From heather.schiller at verizon.com Mon Apr 2 13:03:36 2012 From: heather.schiller at verizon.com (Schiller, Heather A) Date: Mon, 2 Apr 2012 14:03:36 -0400 Subject: Reachability issue 193.56.43.0/24AS25186 from AS701 In-Reply-To: <4F79CBD8.1020202@ceriz.fr> References: <4F79CBD8.1020202@ceriz.fr> Message-ID: Sent response offlist. --heather -----Original Message----- From: J?r?me Nicolle [mailto:jerome at ceriz.fr] Sent: Monday, April 02, 2012 11:55 AM To: nanog at nanog.org Subject: Reachability issue 193.56.43.0/24AS25186 from AS701 Hi, Just changed the upstream for this network and a few customers can't reach our services anymore. According to RIPE stats, reachability, is not optimal on the north american zone, but is perfect everywhere else (see https://stat.ripe.net/193.56.43.124) One of the complaining customer is on AS1660 and the route breaks within AS701. Could anyone confirm the reachability for this prefix from the US ? Anyone at Verizon to check and fix if necessary ? Thanks ! -- J?r?me Nicolle +33 6 19 31 27 14 From owen at delong.com Mon Apr 2 13:59:58 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Apr 2012 11:59:58 -0700 Subject: French Regulator to ask all your information about your Peering In-Reply-To: References: Message-ID: Personally, I don't see this as a bad thing. Open disclosure of peering relationships strikes me as a "sunlight is the best disinfectant" kind of situation. Will they be making this information public or accepting it under seal? If they're making it public, then, I think overall it's a good thing. If not, then it's just another burdensome regulation without much public good. Owen On Mar 30, 2012, at 11:21 AM, Raphael MAUNIER wrote: > Hello All, > > This is now the end. The French regulator ( Arcep ) is now asking all the > people with an ASN in France ( with a L33 license ) to get all their > information on their peering. > > The Arcep claim it's for the "net neutrality" and still don't understand > it works because it's self regulated. > > So, some of US network with a L33 License will also have to respond ( > obligation because you have the L33-1) > > The documents can be downloaded here > http://www.arcep.fr/index.php?id=8571&L=&tx_gsactualite_pi1[uid]=1508&tx_gs > actualite_pi1[backID]=1&cHash=ed82d44a55 : ( french for now, english > courtesy version will come soon ) > > The document is asking for informations like : BW, Prices, contract or > not, level of use, date of the contract S > > You have to give them information twice a year > > > > We ( @Neo Telecoms ) and other folks in France will probably setup > something with other carriers ( I already had some discussion with some of > you ) to talk to them on a single voice. > > -- > Rapha?l Maunier > NEO TELECOMS > CTO / Directeur Ing?nierie > AS8218 > > > > > From jerome at ceriz.fr Mon Apr 2 16:22:05 2012 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Mon, 02 Apr 2012 23:22:05 +0200 Subject: Reachability issue 193.56.43.0/24AS25186 from AS701 In-Reply-To: References: <4F79CBD8.1020202@ceriz.fr> Message-ID: <4F7A187D.3050400@ceriz.fr> Le 02/04/2012 20:03, Schiller, Heather A a ?crit : > > Sent response offlist. Thanks a lot for your answers, got a few hints to nail it ;) -- J?r?me Nicolle +33 6 19 31 27 14 From jeroen at mompl.net Mon Apr 2 20:00:19 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 02 Apr 2012 18:00:19 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <20120330204119.GC23534@nntp.AegisInfoSys.com> <4F763AD7.30805@rancid.berkeley.edu> <4F76566F.5020906@mompl.net> Message-ID: <4F7A4BA3.4000809@mompl.net> C. A. Fillekes wrote: > I do not think that the closing of a service that's undergone multiple > acquisitions by actual competitors is at all surprising. Did the > closing of Alta Vista a couple years ago after its acquisition by > Yahoo! spell the death of internet search? No. Well, it's a bit hard to kill off internet searching. Because looking for stuff is pretty much everyone's main "raisin d'etre". It's not like you can replace searching with something else. You can replace email with another form of communication, but searching is searching... Since quite a number of years altavista.com searches are just submitted to search.yahoo.com and some time ago I noticed on yahoo's site the words "powered by bing". Does that mean yahoo's search engine has been abolished also and is being ran by microsoft (technology)? In that case the two main search engines of the 90s are dead. Nobody missed them though... Regards, Jeroen -- Earthquake Magnitude: 6.3 Date: Monday, April 2, 2012 17:36:43 UTC Location: Oaxaca, Mexico Latitude: 16.4769; Longitude: -98.2867 Depth: 12.30 km From ml at kenweb.org Mon Apr 2 20:01:53 2012 From: ml at kenweb.org (ML) Date: Mon, 02 Apr 2012 21:01:53 -0400 Subject: [outages] XO Outages In-Reply-To: <15197067.9511.1333384071857.JavaMail.root@benjamin.baylink.com> References: <15197067.9511.1333384071857.JavaMail.root@benjamin.baylink.com> Message-ID: <4F7A4C01.6030708@kenweb.org> On 4/2/2012 12:27 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Darren Cusano" >> Anyone experiencing any XO Outages? In the Philadelphia area our lines >> are straight to busy. > We have some direct PRIs from XO in Tampa FL, and I have no reports from the > office of circuit problems at this time. > > Cheers, > -- jra I have some customer services on XO channelized DS3 and some unmuxed DS1s..no problems. From j at arpa.com Tue Apr 3 03:27:56 2012 From: j at arpa.com (jamie rishaw) Date: Tue, 3 Apr 2012 03:27:56 -0500 Subject: Charter regional(nationwide?) flapping/multi outages Message-ID: [ This email takes place and context between 0817 GMT and 0910 GMT ] Charter is/was/has been/may still be hit by regional to national outages, starting ~ 0817 GMT Not only is my home ofc (100mb, quad doc3/rg6, hangs off chi) down (dying well within the network and not at cpe-adjacent gear), Charter NOC and Eng's cant even get to their ticketing and status/testing systems. They're dead in the water. (Voice service aside) ... : Three thoughts come to mind. 1) Tech says Charter (according to internal talk) has no v6 deploy plans until 2013. Someone stop me from pulling out my hair on this -- Does 3q '13 align with others' plans for v6 deployment ? 2) Eating your own dogfood is awesome, but where is a backup plan? My traces out during the ~30 mins on the horn had me routing thru Chi, Cle, and MO, dying at border/cores every time. Tethering my laptop to my android, I saw similarly-stopping routes inbound. (BGPlay disagrees, but thats another issue). Does it not behoove call centers and NOCs to have local access to replicated ticket and status dbs, failing over to alt carriers during severe outages (or any outage that takes down primary support)? 3) The first line tech suggested "it's DNS" (yet I run two of my own nameservers @ home, and roll neustar for global) -- Are we (senior types) just trying to get nocs off the phone with whatever answer, even if it involves lies that (we're naive to think) there /aren't/ those without clue that will challenge this, from premise to organization, sometimes *(cough)*. bringing these issues to a national stage? Thoughts, comments, insults, jokes, bring it. Anonymization assured should you want to go OTR and have me repost. From me at anuragbhatia.com Tue Apr 3 04:02:10 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 3 Apr 2012 14:32:10 +0530 Subject: Charter regional(nationwide?) flapping/multi outages In-Reply-To: References: Message-ID: Yes We are also getting issues from last 2 he's. Any ideas what caused this. (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Apr 3, 2012 1:58 PM, "jamie rishaw" wrote: > [ This email takes place and context between 0817 GMT and 0910 GMT ] > > Charter is/was/has been/may still be hit by regional to national outages, > starting ~ 0817 GMT > > Not only is my home ofc (100mb, quad doc3/rg6, hangs off chi) down (dying > well within the network and not at cpe-adjacent gear), Charter NOC and > Eng's cant even get to their ticketing and status/testing systems. They're > dead in the water. (Voice service aside) > > ... : > > Three thoughts come to mind. > > 1) Tech says Charter (according to internal talk) has no v6 deploy plans > until 2013. Someone stop me from pulling out my hair on this -- Does 3q > '13 align with others' plans for v6 deployment ? > > 2) Eating your own dogfood is awesome, but where is a backup plan? My > traces out during the ~30 mins on the horn had me routing thru Chi, Cle, > and MO, dying at border/cores every time. Tethering my laptop to my > android, I saw similarly-stopping routes inbound. (BGPlay disagrees, but > thats another issue). > Does it not behoove call centers and NOCs to have local access to > replicated ticket and status dbs, failing over to alt carriers during > severe outages (or any outage that takes down primary support)? > > 3) The first line tech suggested "it's DNS" (yet I run two of my own > nameservers @ home, and roll neustar for global) -- Are we (senior types) > just trying to get nocs off the phone with whatever answer, even if it > involves lies that (we're naive to think) there /aren't/ those without clue > that will challenge this, from premise to organization, > sometimes *(cough)*. bringing these issues to a national stage? > > > Thoughts, comments, insults, jokes, bring it. Anonymization assured should > you want to go OTR and have me repost. > From mukom.tamon at gmail.com Tue Apr 3 11:17:58 2012 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Tue, 3 Apr 2012 20:17:58 +0400 Subject: Step-by-step procedure for doing IPv6 subnetting Message-ID: Hello all I often get lots of people who want to know the procedure for doing IPv6 subnetting like we are used to in IPv4. Before using tools and utilities to make things easy, I always like to know the general principles. I've put up a post about a general and quick procedure on how to subnet in IPv6 which I believe gives anyone an good theoretical framework for how to do it. Please do check it out and let me feedback. [a] General procedure for IPv6 Subnetting http://techxcellence.net/2012/04/03/ipv6-subnetting-general-procedure/ [b] Quick procedure ('in your head') http://techxcellence.net/2011/05/09/v6-subnetting-made-easy/ Regards -- Mukom Akong [Tamon] ______________ ?We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.? [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence From georgeb at gmail.com Tue Apr 3 13:00:57 2012 From: georgeb at gmail.com (George B.) Date: Tue, 3 Apr 2012 11:00:57 -0700 Subject: Charter regional(nationwide?) flapping/multi outages In-Reply-To: References: Message-ID: On Tue, Apr 3, 2012 at 1:27 AM, jamie rishaw wrote: > Three thoughts come to mind. > > 1) Tech says Charter (according to internal talk) has no v6 deploy plans > until 2013. ?Someone stop me from pulling out my hair on this -- Does 3q > '13 align with others' plans for v6 deployment ? I have one upstream with no plans to deploy v6 until 2013. I have production operations in one of their facilities in Europe and a customer there screaming for v6 support and due to legal issues can't serve that customer from the US. This is one reason (among a few others) we have decided to migrate away from this provider. Our US operations have other v6 capable carriers and we have deployed v6 for most of our production operations in the US. From sethm at rollernet.us Tue Apr 3 13:16:40 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 03 Apr 2012 11:16:40 -0700 Subject: Charter regional(nationwide?) flapping/multi outages In-Reply-To: References: Message-ID: <4F7B3E88.1090306@rollernet.us> On 4/3/12 1:27 AM, jamie rishaw wrote: > > 1) Tech says Charter (according to internal talk) has no v6 deploy plans > until 2013. Someone stop me from pulling out my hair on this -- Does 3q > '13 align with others' plans for v6 deployment ? > All of mine already provide me with native IPv6. Whenever Charter has approached me over the last year I tell them upfront that they need to match the existing capabilities of my other providers and let them go through their process. ~Seth From Bryan.Welch at arrisi.com Tue Apr 3 16:54:34 2012 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Tue, 3 Apr 2012 21:54:34 +0000 Subject: Telia issues? Message-ID: Anyone having issues with routes through Telia? We are having reachability issues getting to some Charter netblocks in the South Eastern US which route through Telia. TIA, Bryan From me at anuragbhatia.com Tue Apr 3 19:24:18 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 4 Apr 2012 05:54:18 +0530 Subject: Telia issues? In-Reply-To: References: Message-ID: Hello Bryan We had this issue yesterday via Charter. For now it seems fixed and all is working OK. Still waiting for detained report from Charter regarding downtime. On Wed, Apr 4, 2012 at 3:24 AM, Welch, Bryan wrote: > Anyone having issues with routes through Telia? We are having > reachability issues getting to some Charter netblocks in the South Eastern > US which route through Telia. > > TIA, > > Bryan > > > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From houdini+nanog at clanspum.net Tue Apr 3 23:12:49 2012 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Tue, 3 Apr 2012 23:12:49 -0500 Subject: Distributed DNS/etc checking In-Reply-To: References: Message-ID: <20120404041248.GH25710@clanspum.net> Todd Snyder(todd at borked.ca)@Mon, Apr 02, 2012 at 12:08:06PM -0400: > Good day all, > > There have been a few instances where we've wanted to check our external > DNS servers from various external networks, so we've utilized the existing > looking glass tools provided by many of you. However, it's a very manual > process, given that all LG's I've found say no automating/scripting. If we > want to check from a couple dozen sites around the world, it's a lot of > clicking and typing and collecting. If we wanted to create an tool that > our NOC could use to verify our services, we would need something we could > script. Ideally, we'd be able to run this constantly to do health checks > on our services, but one step at a time. To suggest a service that I have no relation to (other than being a happy customer), have you looked at Pingdom [http://www.pingdom.com/] ? I'm not using the DNS check type, but I have a dozen or so HTTP checks there. Their system is super simple, no frills, and is priced like it :) It looks like you can list a domain to test, a server to check and what result you expect. They run checks from a bunch of different places (40 servers, seemingly half in the US, right now). Pricing at the low scale is $6/check/year, which is pretty compelling even against running some VPSes if you aren't checking too many sites. -- Bill Weiss From Matthew.Wright at pearson-harper.com Wed Apr 4 04:16:23 2012 From: Matthew.Wright at pearson-harper.com (Matthew Wright) Date: Wed, 4 Apr 2012 09:16:23 +0000 Subject: Distributed DNS/etc checking In-Reply-To: <20120404041248.GH25710@clanspum.net> References: <20120404041248.GH25710@clanspum.net> Message-ID: <4E8781867FE9D749BB957F1C2BDDAF582A1A32ED@phexch02> Todd Snyder(todd at borked.ca)@Mon, Apr 02, 2012 at 12:08:06PM -0400: > Good day all, > > There have been a few instances where we've wanted to check our > external DNS servers from various external networks, so we've utilized > the existing looking glass tools provided by many of you. However, > it's a very manual process, given that all LG's I've found say no > automating/scripting. If we want to check from a couple dozen sites > around the world, it's a lot of clicking and typing and collecting. > If we wanted to create an tool that our NOC could use to verify our > services, we would need something we could script. Ideally, we'd be > able to run this constantly to do health checks on our services, but one step at a time. A happy customer report for http://www.whatsmydns.net/ not scriptable as such, but very useful, and free into the bargain. I use it to check our GeoIP DNS is responding as expected. Matthew From cconn at b2b2c.ca Wed Apr 4 14:53:03 2012 From: cconn at b2b2c.ca (Chris Conn) Date: Wed, 04 Apr 2012 15:53:03 -0400 Subject: SORBS?! Message-ID: <4F7CA69F.9090206@b2b2c.ca> Hello, Is anyone from SORBS still listening? We have a few IP addresses here and there that are listed, one in particular that has been for a spam incident from over a year ago. The "last spam" date is 03/05/2011 according to their lookup tools. We don't have access to their Net Manager even if our ARIN POC corresponds to the account on their system we opened a while ago. We use their ISP feedback form and never get any responses back. Is SORBS still relevant and functional? Sincerely, Chris Conn B2B2C.ca From mjkelly at gmail.com Wed Apr 4 15:06:07 2012 From: mjkelly at gmail.com (Matt Kelly) Date: Wed, 04 Apr 2012 16:06:07 -0400 Subject: SORBS?! In-Reply-To: <4F7CA69F.9090206@b2b2c.ca> Message-ID: Good luck. Last time we heard back from them they were trying to extort us for $18,000 to have a huge block of Ips removed. They were listed from the day we received them from arin. After that we gave up on SORBS. On 4/4/12 3:53 PM, "Chris Conn" wrote: >Hello, > >Is anyone from SORBS still listening? We have a few IP addresses here >and there that are listed, one in particular that has been for a spam >incident from over a year ago. The "last spam" date is 03/05/2011 >according to their lookup tools. > >We don't have access to their Net Manager even if our ARIN POC >corresponds to the account on their system we opened a while ago. We >use their ISP feedback form and never get any responses back. > >Is SORBS still relevant and functional? > >Sincerely, > >Chris Conn >B2B2C.ca > From paul at paulgraydon.co.uk Wed Apr 4 15:08:08 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 04 Apr 2012 10:08:08 -1000 Subject: SORBS?! In-Reply-To: <4F7CA69F.9090206@b2b2c.ca> References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: <4F7CAA28.7050000@paulgraydon.co.uk> They're still functional, still used by companies but I wouldn't make any observation on them running 'well'. A friend's office IP range got blocked and unblocked recently by them so they do seem to remove entries. Beyond that on NANOG you're pretty much into "light blue touch paper and retire to a safe distance" territory even mentioning them. There is a good chance you might get a reply from Sorbs here, they almost always seem to respond when things get raised on NANOG. Paul On 04/04/2012 09:53 AM, Chris Conn wrote: > Hello, > > Is anyone from SORBS still listening? We have a few IP addresses > here and there that are listed, one in particular that has been for a > spam incident from over a year ago. The "last spam" date is > 03/05/2011 according to their lookup tools. > > We don't have access to their Net Manager even if our ARIN POC > corresponds to the account on their system we opened a while ago. We > use their ISP feedback form and never get any responses back. > > Is SORBS still relevant and functional? > > Sincerely, > > Chris Conn > B2B2C.ca > From mdavids at forfun.net Wed Apr 4 15:26:11 2012 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Wed, 4 Apr 2012 22:26:11 +0200 (CEST) Subject: DNS issues with tools.ietf.org Message-ID: Hi, Something seems wrong with the DNS of 'tools.ietf.org'. Can anyone conform? -- Marco From craig at codestorm.org Wed Apr 4 15:28:50 2012 From: craig at codestorm.org (Craig Van Tassle) Date: Wed, 4 Apr 2012 16:28:50 -0400 Subject: DNS issues with tools.ietf.org In-Reply-To: References: Message-ID: <20120404162850.23b14639@codestorm.org> On Wed, 4 Apr 2012 22:26:11 +0200 (CEST) "Marco Davids (Prive)" wrote: > Hi, > > Something seems wrong with the DNS of 'tools.ietf.org'. > > Can anyone conform? > > -- > Marco > It works for me. From ryanczak at gmail.com Wed Apr 4 15:31:39 2012 From: ryanczak at gmail.com (Matt Ryanczak) Date: Wed, 04 Apr 2012 16:31:39 -0400 Subject: DNS issues with tools.ietf.org In-Reply-To: <20120404162850.23b14639@codestorm.org> References: <20120404162850.23b14639@codestorm.org> Message-ID: <4F7CAFAB.8010004@gmail.com> On 04/04/2012 04:28 PM, Craig Van Tassle wrote: > It works for me. works for me too but there do appear to be some problems: > matt at bender:~$ dig tools.ietf.org ns +short > shiraz.levkowetz.com. > cabernet.levkowetz.com. > merlot.levkowetz.com. > zinfandel.levkowetz.com. > gamay.levkowetz.com. > grenache.levkowetz.com. > matt at bender:~$ for named in `dig tools.ietf.org ns +short`;do dig @$named tools.ietf.org soa +short; done > > ; <<>> DiG 9.7.3 <<>> @zinfandel.levkowetz.com. tools.ietf.org soa +short > ; (2 servers found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > dig: couldn't get address for 'grenache.levkowetz.com.': not found > merlot.levkowetz.com. hostmaster.tools.ietf.org. 2012022501 43200 3600 3600000 600 > merlot.levkowetz.com. hostmaster.tools.ietf.org. 2012022501 43200 3600 3600000 600 > merlot.levkowetz.com. hostmaster.tools.ietf.org. 2012022501 43200 3600 3600000 600 From bortzmeyer at nic.fr Wed Apr 4 15:34:55 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 4 Apr 2012 22:34:55 +0200 Subject: DNS issues with tools.ietf.org In-Reply-To: <29701_1333571430_4F7CAF66_29701_15224_1_alpine.DEB.2.00.1204042220260.10706@xs.forfun.net> References: <29701_1333571430_4F7CAF66_29701_15224_1_alpine.DEB.2.00.1204042220260.10706@xs.forfun.net> Message-ID: <20120404203455.GA26197@sources.org> On Wed, Apr 04, 2012 at 10:26:11PM +0200, Marco Davids (Prive) wrote a message of 8 lines which said: > Something seems wrong with the DNS of 'tools.ietf.org'. Can you be more specific? It works for me except that one name server does not actually exist (but it does not prevent the domain from working). % zonecheck tools.ietf.org ERROR: Unable to find nameserver IP address(es) for grenache.levkowetz.com (NXDOMAIN, indeed) From mdavids at forfun.net Wed Apr 4 15:35:34 2012 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Wed, 4 Apr 2012 22:35:34 +0200 (CEST) Subject: DNS issues with tools.ietf.org In-Reply-To: <4F7CAFAB.8010004@gmail.com> References: <20120404162850.23b14639@codestorm.org> <4F7CAFAB.8010004@gmail.com> Message-ID: On Wed, 4 Apr 2012, Matt Ryanczak wrote: > On 04/04/2012 04:28 PM, Craig Van Tassle wrote: >> It works for me. > > works for me too but there do appear to be some problems: And what about this: dig tools.ietf.org @merlot.levkowetz.com. ; <<>> DiG 9.7.0-P1 <<>> tools.ietf.org @merlot.levkowetz.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33101 From dougb at dougbarton.us Wed Apr 4 15:38:49 2012 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 04 Apr 2012 13:38:49 -0700 Subject: DNS issues with tools.ietf.org In-Reply-To: References: Message-ID: <4F7CB159.8020104@dougbarton.us> On 04/04/2012 13:26, Marco Davids (Prive) wrote: > Hi, > > Something seems wrong with the DNS of 'tools.ietf.org'. > > Can anyone conform? Yes: Finding name servers for tools.ietf.org in parent zone Checking serials for tools.ietf.org in: cabernet.levkowetz.com Query Error: SERVFAIL on merlot.levkowetz.com shiraz.levkowetz.com Checking zone NS set against parent Query Error: SERVFAIL on merlot.levkowetz.com Error: parent has: cabernet.levkowetz.com merlot.levkowetz.com shiraz.levkowetz.com But tools.ietf.org zone has: cabernet.levkowetz.com gamay.levkowetz.com grenache.levkowetz.com merlot.levkowetz.com shiraz.levkowetz.com zinfandel.levkowetz.com Also, as others pointed out, there does not seem to be an address for grenache. -- If you're never wrong, you're not trying hard enough From jra at baylink.com Wed Apr 4 15:45:57 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 4 Apr 2012 16:45:57 -0400 (EDT) Subject: DNS issues with tools.ietf.org In-Reply-To: Message-ID: <24111986.10045.1333572357093.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Marco Davids (Prive)" > Something seems wrong with the DNS of 'tools.ietf.org'. > > Can anyone conform? It's generally a good idea when asking this sort of question -- especially here on NANOG, which is *not* Junior Varsity -- to present what you *expected* to see, what you *saw*, and why you think that implies breakage outside your facility. Let me refer you to: http://www.catb.org/~esr/faqs/smart-questions.html and http://www.chiark.greenend.org.uk/~sgtatham/bugs.html which are the two standard reference works on the meta-topic here at hand. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From bortzmeyer at nic.fr Wed Apr 4 15:49:22 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 4 Apr 2012 22:49:22 +0200 Subject: DNS issues with tools.ietf.org In-Reply-To: <29701_1333572054_4F7CB1D4_29701_15363_1_alpine.DEB.2.00.1204042234520.10770@xs.forfun.net> References: <20120404162850.23b14639@codestorm.org> <4F7CAFAB.8010004@gmail.com> <29701_1333572054_4F7CB1D4_29701_15363_1_alpine.DEB.2.00.1204042234520.10770@xs.forfun.net> Message-ID: <20120404204922.GA11072@sources.org> On Wed, Apr 04, 2012 at 10:35:34PM +0200, Marco Davids (Prive) wrote a message of 15 lines which said: > And what about this: But two name servers, gamay and shiraz still work. So the domain works, so you can email the hostmaster :-) From lstewart at superb.net Wed Apr 4 15:55:46 2012 From: lstewart at superb.net (Landon Stewart) Date: Wed, 4 Apr 2012 13:55:46 -0700 Subject: SORBS?! In-Reply-To: <4F7CA69F.9090206@b2b2c.ca> References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: On 4 April 2012 12:53, Chris Conn wrote: > Hello, > > Is anyone from SORBS still listening? We have a few IP addresses here > and there that are listed, one in particular that has been for a spam > incident from over a year ago. The "last spam" date is 03/05/2011 > according to their lookup tools. > > We don't have access to their Net Manager even if our ARIN POC corresponds > to the account on their system we opened a while ago. We use their ISP > feedback form and never get any responses back. > > Is SORBS still relevant and functional? > I've been trying to login to their 'support' interface for a while now. Emails from them for creating a new account or trying to recover a password for an existing account don't actually come to me. I actually wrote Girish from the company that purchased SORBS (Proofpoint) about it (also CC'd here) and I have had no reply whatsoever either. I think we should all just NULL ROUTE all of their IP space on our borders to get their attention. Regards, Landon From mdavids at forfun.net Wed Apr 4 16:05:02 2012 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Wed, 4 Apr 2012 23:05:02 +0200 (CEST) Subject: DNS issues with tools.ietf.org In-Reply-To: <20120404204922.GA11072@sources.org> References: <20120404162850.23b14639@codestorm.org> <4F7CAFAB.8010004@gmail.com> <29701_1333572054_4F7CB1D4_29701_15363_1_alpine.DEB.2.00.1204042234520.10770@xs.forfun.net> <20120404204922.GA11072@sources.org> Message-ID: On Wed, 4 Apr 2012, Stephane Bortzmeyer wrote: >> And what about this: > > But two name servers, gamay and shiraz still work. So the domain > works Actually it didn't resolve at all. Even an 'unbound-host -v -d' failed. But... things seem to be working fine again, at least to the extend that I can reach the website. -- Marco From marshall.eubanks at gmail.com Wed Apr 4 16:08:15 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Wed, 4 Apr 2012 17:08:15 -0400 Subject: DNS issues with tools.ietf.org In-Reply-To: <20120404204922.GA11072@sources.org> References: <20120404162850.23b14639@codestorm.org> <4F7CAFAB.8010004@gmail.com> <29701_1333572054_4F7CB1D4_29701_15363_1_alpine.DEB.2.00.1204042234520.10770@xs.forfun.net> <20120404204922.GA11072@sources.org> Message-ID: On Wed, Apr 4, 2012 at 4:49 PM, Stephane Bortzmeyer wrote: > On Wed, Apr 04, 2012 at 10:35:34PM +0200, > ?Marco Davids (Prive) wrote > ?a message of 15 lines which said: > >> And what about this: > > But two name servers, gamay and shiraz still work. So the domain > works, so you can email the hostmaster :-) > I have forwarded this thread to Henrik Levkowetz Regards Marshall From jeroen at mompl.net Wed Apr 4 16:21:11 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 04 Apr 2012 14:21:11 -0700 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: <4F7CBB47.1010801@mompl.net> Landon Stewart wrote: > I think we should all just NULL ROUTE all of their IP space on our borders > to get their attention. Yeah you're free to do that, as well as complain about it and SORBS in turn is free to put whatever the hell they feel like on their block lists and not remove it at all, ever, for whatever reason. One common theme I did notice in the countless and, dare I say, tiresome complaints about SORBS is that it hardly ever helps and may even make it worse. It's best to not complain about it and just accept it as a fact of life your IPs are listed on SORBS and move on. It's not the end of the world. Greetings, Jeroen -- Earthquake Magnitude: 3.0 Date: Wednesday, April 4, 2012 20:59:13 UTC Location: Baja California, Mexico Latitude: 32.6142; Longitude: -115.8417 Depth: 2.90 km From mikea at mikea.ath.cx Wed Apr 4 16:21:51 2012 From: mikea at mikea.ath.cx (Mike Andrews) Date: Wed, 4 Apr 2012 16:21:51 -0500 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: <20120404212151.GD25082@mikea.ath.cx> On Wed, Apr 04, 2012 at 01:55:46PM -0700, Landon Stewart wrote: > On 4 April 2012 12:53, Chris Conn wrote: > > > Hello, > > > > Is anyone from SORBS still listening? We have a few IP addresses here > > and there that are listed, one in particular that has been for a spam > > incident from over a year ago. The "last spam" date is 03/05/2011 > > according to their lookup tools. > > > > We don't have access to their Net Manager even if our ARIN POC corresponds > > to the account on their system we opened a while ago. We use their ISP > > feedback form and never get any responses back. > > > > Is SORBS still relevant and functional? > > > > I've been trying to login to their 'support' interface for a while now. > Emails from them for creating a new account or trying to recover a > password for an existing account don't actually come to me. I actually > wrote Girish from the company that purchased SORBS (Proofpoint) about it > (also CC'd here) and I have had no reply whatsoever either. > > I think we should all just NULL ROUTE all of their IP space on our borders > to get their attention. By a happy coincidence, I got mail today from Scott Greco of Proofpoint, asking if we could get together to discuss their products. I've replied to that with a summary of this thread, and am Cc:ing him on this mail, as well. Maybe we can get their attention, though past experience with SORBS does not exactly imbue me with confidence. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From ahebert at pubnix.net Wed Apr 4 16:27:10 2012 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 04 Apr 2012 17:27:10 -0400 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: <4F7CBCAE.2090802@pubnix.net> Hi, We had an issue with one of our old subnets which was used as a pool for dynamic dial-up in the past, which we now use for virtual hosting. It took a few me a few hours but I was able to get it removed from the DUHL list. ( And a few walk around the block to calm me down after dealing with their robot =D ). As for being removed from their SPAM RBL that might be another story.. Actually knowing Chris, and his outfit, that 18k request seems unwarranted :( As for SORBS, they have a ticket system at http://support.sorbs.net/ which use the same username/password as https://www.us.sorbs.net. You can follow up there with your ticket #, if their robot is being a bit too fascist. ( ecarbonel was the guy that help us in our case ) PS: The ticketing system is not that fast, so be patient. /wave Chris ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 04/04/12 16:55, Landon Stewart wrote: > On 4 April 2012 12:53, Chris Conn wrote: > >> Hello, >> >> Is anyone from SORBS still listening? We have a few IP addresses here >> and there that are listed, one in particular that has been for a spam >> incident from over a year ago. The "last spam" date is 03/05/2011 >> according to their lookup tools. >> >> We don't have access to their Net Manager even if our ARIN POC corresponds >> to the account on their system we opened a while ago. We use their ISP >> feedback form and never get any responses back. >> >> Is SORBS still relevant and functional? >> > I've been trying to login to their 'support' interface for a while now. > Emails from them for creating a new account or trying to recover a > password for an existing account don't actually come to me. I actually > wrote Girish from the company that purchased SORBS (Proofpoint) about it > (also CC'd here) and I have had no reply whatsoever either. > > I think we should all just NULL ROUTE all of their IP space on our borders > to get their attention. > > Regards, > Landon > From lstewart at superb.net Wed Apr 4 16:36:09 2012 From: lstewart at superb.net (Landon Stewart) Date: Wed, 4 Apr 2012 14:36:09 -0700 Subject: SORBS?! In-Reply-To: <4F7CBB47.1010801@mompl.net> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> Message-ID: On 4 April 2012 14:21, Jeroen van Aart wrote: > Landon Stewart wrote: > >> I think we should all just NULL ROUTE all of their IP space on our borders >> to get their attention. >> > > Yeah you're free to do that, as well as complain about it and SORBS in > turn is free to put whatever the hell they feel like on their block lists > and not remove it at all, ever, for whatever reason. > The latter part of that sentence has already been confirmed for years now. > It's best to not complain about it and just accept it as a fact of life > your IPs are listed on SORBS and move on. It's not the end of the world. > It turns into a customer service issue for most service providers. From lstewart at superb.net Wed Apr 4 16:39:04 2012 From: lstewart at superb.net (Landon Stewart) Date: Wed, 4 Apr 2012 14:39:04 -0700 Subject: SORBS?! In-Reply-To: <4F7CBCAE.2090802@pubnix.net> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBCAE.2090802@pubnix.net> Message-ID: On 4 April 2012 14:27, Alain Hebert wrote: > As for SORBS, they have a ticket system at http://support.sorbs.net/which use the same username/password as > https://www.us.sorbs.net. You can follow up there with your ticket #, if > their robot is being a bit too fascist. ( ecarbonel was the guy that help > us in our case ) > Yeah that's my main complaint right now is that we can't get into their ticket system *or* register a new account for our AS. The new account registration email never gets received for confirmation. The account we used to use doesn't work despite it being somewhere around 7 years old. > PS: The ticketing system is not that fast, so be patient. > It's better than it was a few months ago I must say. It was almost absolutely unusably slow the last time I was in there probably late last year some time. --- Landon Stewart > Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": www.superb.net From cconn at b2b2c.ca Wed Apr 4 16:39:10 2012 From: cconn at b2b2c.ca (Chris Conn) Date: Wed, 04 Apr 2012 17:39:10 -0400 Subject: SORBS?! In-Reply-To: References: Message-ID: <4F7CBF7E.7010507@b2b2c.ca> On 2012-04-04 17:33: > > Hi, > > Actually knowing Chris, and his outfit, that 18k request seems unwarranted :( > > As for SORBS, they have a ticket system at http://support.sorbs.net/ which use the same username/password as https://www.us.sorbs.net. You can follow up there with your ticket #, if their robot is being a bit too fascist. > ( ecarbonel was the guy that help us in our case ) > > PS: The ticketing system is not that fast, so be patient. > > /wave Chris > Hi Alain! The 18K thing was another operator, but we have not had much luck. I will give my attention to the ticket for now and wait until something happens. Its not a crucial issue since from what I can tell its mostly a cosmetic thing (and a bit of a managerial pain to have to explain the implications to a customer). I have no beef with SORBS, we even rsync their zone on our DNS servers so we can provide faster access to it to our customers that might use it. However recently, getting listing action seems to fall into a void. Cheers, Chris From amogh at cc.gatech.edu Wed Apr 4 17:41:19 2012 From: amogh at cc.gatech.edu (Amogh Dhamdhere) Date: Wed, 4 Apr 2012 15:41:19 -0700 Subject: CAIDA's 2012 IPv6 survey -- need network operators to fill out In-Reply-To: <20120313215614.GA39216@caida.org> References: <20120313215614.GA39216@caida.org> Message-ID: Hello folks, Thanks much to those of you who already completed our IPv6 deployment survey. We forgot to mention in the first email (though it's on the survey URL) that we are offering a free iPad to a randomly chosen survey respondent. Hopefully this is an additional incentive for more of you to fill out the survey :) The survey URL once again: http://www.surveygizmo.com/s3/749797/ipv6survey We will keep the survey open until April 20, 2012. Please let us know if you have questions/comments, or if you can chat with us for follow-up questions outside the survey. Thanks, Amogh, kc, Emile On Mar 13, 2012, at 2:56 PM, k claffy wrote: > > > [direct link to IPv6 operational deployment [plans] survey > if you don't need background: > http://www.surveygizmo.com/s3/749797/ipv6survey > ] > > hello folks, > > we're trying to do some quantitative modeling of > the IPv4->IPv6 transition, including the impact of > IPv4 markets on likely future trajectories, but > really need some empirical data to parametrize our model. > with much help from many patient reviewers of the questions, > we finally have a survey ready for operators to fill out. > > below i'll give an extremely terse description of the model > just to give you an idea of why we need this granularity. > there are another 10 dense pages describing the model pending > peer review at NSF, which i can send to anyone interested in > giving us feedback on it. but it's not necessary for > responding to the survey. also note the checkbox to > indicate you're amenable to further followup questions. > survey will be available till 12 april 2012. > (or tell us if you want to fill it out but need more time.) > > survey link, again: > http://www.surveygizmo.com/s3/749797/ipv6survey > > thanks much, > k, amogh, emile > > ------------------------------ > > Most prior work on modeling the adoption of new technologies assumed a > binary decision at the organization level -- in the context of > IPv6, this decision means switching completely to IPv6 or not at > all. We propose to account for the fact that an organization may > deploy IPv6 incrementally in its network, meaning that it will > continue to have both IPv4 and IPv6 space. A key aspect of our model > is that instead of a binary state per organization, we work at the > granularity of devices, which are entities that need to be > assigned IP addresses. We consider a device to correspond to a single > instance of an IP addressing need, which typically corresponds to an > interface. Though there can be multiple interfaces (``devices'') on > the same computer/router, and multiple addresses (``virtual > interfaces'') on a single interface, we will model each need for an > independent IP address as an independent device. We define device > classes based on the nature of addresses used to number those devices, > e.g., public IPv4, IPv6, dual-stack-NATv4, dual-stack-public-IPv4, etc. > We model the network growth requirements of each network in terms > of the number of additional devices in that network that need to > be configured in one of these device classes. > > ... (then we catalog a list of costs and incentives associated with the > decision to adopt IPv6 or satisfy one's addressing needs with IPv4-based > technologies. costs parameters include the costs of IPv4 addresses, NAT > deployment, renumbering, and translation between IPv4 and IPv6. we will > also try to model incentives such as policies and regulations.) > > We will then model two separate decision processes for a network, based > on whether it seeks to add new devices (to expand its network, provision > for new customers, deploy new services, etc.), or whether it seeks to > optimize the numbering of its existing devices from among the five > device classes defined previously. The latter operation may be necessary > if external factors and costs have changed such that the network could > substantially lower its costs by numbering its devices differently. We > want to structure the model (based on feedback from opsfolk like you) > to capture both initial costs as well as ongoing operational costs of > supporting a given configuration of devices for a specified window > following the decision. Iteration of the decision process continues > for each network until we reach a state where no network has the incentive > to change the numbering of its devices, which represents the equilibrium. > .... > From benc at brennanit.com.au Thu Apr 5 00:55:43 2012 From: benc at brennanit.com.au (Ben Cornish) Date: Thu, 5 Apr 2012 15:55:43 +1000 Subject: Looking for North American Carriage providers Message-ID: <0D7EE45B5EED4D44A97ED31496F8E9E65334E2709A@BRENSYD-MBX.brennanit.com.au> Hi All, I apologize for the Spam - We recently expanded into North America from Australia to service our Australian Clients with their international needs. We are seeking a Carrier or few carriers that can provide us with layer 2 Ethernet services that has coverage to the majority of North America. We are looking at the smaller services of 2 to 20mb area. Preferable handoff in Equinix-SV1(San Jose) or 1 Wilshire(Coresite LA) as VLAN's Seeking responses off list please. Cheers. Ben Cornish |Brennan IT| National Network Manager T: 0732349302 Direct: 0282353520 | M: 0417617204 | mailto:benc at brennanit.com.au | www.brennanit.com.au http://www.brennanit.com.au/press-release/brennan-it-named-1-managed-services-provider/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 14181 bytes Desc: not available URL: From sam.oduor at gmail.com Thu Apr 5 06:55:32 2012 From: sam.oduor at gmail.com (Sam Oduor) Date: Thu, 5 Apr 2012 14:55:32 +0300 Subject: SORBS?! In-Reply-To: <4F7CA69F.9090206@b2b2c.ca> References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: Some of the IP's I manage got blacklisted and its true they were spamming and Sorbs had a very valid reason for blacklisting them. I got this response response from sorbs after resolving the problem amicably. Sorbs responded well on time. *Your request appear to have been resolved. If you have any further questions or concerns, please respond to this message. Please note: If your IP address has been delisted (marked as 'Inactive'), it will take up to 2 hours to get from the database to all the SORBS DNS servers. Changes to the database are exported to the DNS zone files periodically, not immediately after every change. Furthermore, after the updated database contents have been exported to the DNS zone files, it will then take up to 48 hours for the outdated DNS information to be removed from DNS caches around the world - none of these are in SORBS' control. Please do not reply to this call with problems not related to this ticket or your request will be ignored. * *On Wed, Apr 4, 2012 at 10:53 PM, Chris Conn wrote: * > > *Hello, > > Is anyone from SORBS still listening? We have a few IP addresses here > and there that are listed, one in particular that has been for a spam > incident from over a year ago. The "last spam" date is 03/05/2011 > according to their lookup tools.* * > > We don't have access to their Net Manager even if our ARIN POC corresponds > to the account on their system we opened a while ago. We use their ISP > feedback form and never get any responses back.* * > > Is SORBS still relevant and functional?* * > > Sincerely,* > > Chris Conn > B2B2C.ca > > -- Samson Oduor From drew.weaver at thenap.com Thu Apr 5 10:56:27 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 5 Apr 2012 11:56:27 -0400 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: Now, if we could only teach Senderbase that if their customers receive 'questionable' smtp traffic from 1 IP address in a /24 it doesn't mean that all IP addresses in that /24 are malicious we'd really be living it up in 2012. -----Original Message----- From: Sam Oduor [mailto:sam.oduor at gmail.com] Sent: Thursday, April 05, 2012 7:56 AM To: Chris Conn Cc: nanog at nanog.org Subject: Re: SORBS?! Some of the IP's I manage got blacklisted and its true they were spamming and Sorbs had a very valid reason for blacklisting them. I got this response response from sorbs after resolving the problem amicably. Sorbs responded well on time. *Your request appear to have been resolved. If you have any further questions or concerns, please respond to this message. Please note: If your IP address has been delisted (marked as 'Inactive'), it will take up to 2 hours to get from the database to all the SORBS DNS servers. Changes to the database are exported to the DNS zone files periodically, not immediately after every change. Furthermore, after the updated database contents have been exported to the DNS zone files, it will then take up to 48 hours for the outdated DNS information to be removed from DNS caches around the world - none of these are in SORBS' control. Please do not reply to this call with problems not related to this ticket or your request will be ignored. * *On Wed, Apr 4, 2012 at 10:53 PM, Chris Conn wrote: * > > *Hello, > > Is anyone from SORBS still listening? We have a few IP addresses here > and there that are listed, one in particular that has been for a spam > incident from over a year ago. The "last spam" date is 03/05/2011 > according to their lookup tools.* * > > We don't have access to their Net Manager even if our ARIN POC > corresponds to the account on their system we opened a while ago. We > use their ISP feedback form and never get any responses back.* * > > Is SORBS still relevant and functional?* * > > Sincerely,* > > Chris Conn > B2B2C.ca > > -- Samson Oduor From esavage at digitalrage.org Thu Apr 5 11:41:13 2012 From: esavage at digitalrage.org (Elijah Savage) Date: Thu, 5 Apr 2012 12:41:13 -0400 (EDT) Subject: SIP Carrier Consolidation Message-ID: <13733103.140.1333644073293.JavaMail.root@ubuntu.digitalrage.org> Anyone here that have gone through the process of SIP trunking consolidation care to comment offline on Whom do you utilize? What has been your experience operationally? What was your experience during transition/implementation? Thank you ahead of time. From goemon at anime.net Thu Apr 5 11:48:15 2012 From: goemon at anime.net (goemon at anime.net) Date: Thu, 5 Apr 2012 09:48:15 -0700 (PDT) Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: This is often the only way to get peoples attention and get action. Providers dont care about individual /32's and will let them sit around and spew nigerian scams and pill spams without any consequences. But they will care about a /24. -Dan On Thu, 5 Apr 2012, Drew Weaver wrote: > Now, if we could only teach Senderbase that if their customers receive 'questionable' smtp traffic from 1 IP address in a /24 it doesn't mean that all IP addresses in that /24 are malicious we'd really be living it up in 2012. > > > > -----Original Message----- > From: Sam Oduor [mailto:sam.oduor at gmail.com] > Sent: Thursday, April 05, 2012 7:56 AM > To: Chris Conn > Cc: nanog at nanog.org > Subject: Re: SORBS?! > > Some of the IP's I manage got blacklisted and its true they were spamming and Sorbs had a very valid reason for blacklisting them. > > I got this response response from sorbs after resolving the problem amicably. Sorbs responded well on time. > > *Your request appear to have been resolved. If you have any further questions or concerns, please respond to this message. > > Please note: > > If your IP address has been delisted (marked as 'Inactive'), it will take up to 2 hours to get from the database to all the SORBS DNS servers. Changes to the database are exported to the DNS zone files periodically, not immediately after every change. Furthermore, after the updated database contents have been exported to the DNS zone files, it will then take up to 48 hours for the outdated DNS information to be removed from DNS caches around the world - none of these are in SORBS' control. > > Please do not reply to this call with problems not related to this ticket or your request will be ignored. > > > > * > *On Wed, Apr 4, 2012 at 10:53 PM, Chris Conn wrote: > * >> >> *Hello, >> >> Is anyone from SORBS still listening? We have a few IP addresses here >> and there that are listed, one in particular that has been for a spam >> incident from over a year ago. The "last spam" date is 03/05/2011 >> according to their lookup tools.* * >> >> We don't have access to their Net Manager even if our ARIN POC >> corresponds to the account on their system we opened a while ago. We >> use their ISP feedback form and never get any responses back.* * >> >> Is SORBS still relevant and functional?* * >> >> Sincerely,* >> >> Chris Conn >> B2B2C.ca >> >> > > > -- > Samson Oduor > > From lstewart at superb.net Thu Apr 5 12:06:03 2012 From: lstewart at superb.net (Landon Stewart) Date: Thu, 5 Apr 2012 10:06:03 -0700 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: > > On Thu, 5 Apr 2012, Drew Weaver wrote: > > Now, if we could only teach Senderbase that if their customers receive >> 'questionable' smtp traffic from 1 IP address in a /24 it doesn't mean that >> all IP addresses in that /24 are malicious we'd really be living it up in >> 2012. >> >> On 5 April 2012 09:48, wrote: > This is often the only way to get peoples attention and get action. > > Providers dont care about individual /32's and will let them sit around > and spew nigerian scams and pill spams without any consequences. > > But they will care about a /24. > > -Dan > If the purpose of blacklist is to block spam for recipients using that blacklist then a /32 works. If the purpose of a blacklist is to annoy providers then a /24 works. The most reputable and useful blacklists IMHO are Spamhaus and Spamcop - they don't block /24s. Spamhaus sometimes does if your rwhois shows that a large amount of the /24 is owned by the offending party but generally they don't. In my opinion a blacklist is useful when it notifies a provider of a listing, provides the reason for the listing and gives you a way to remove the listing. Spamhaus encourages companies to resolve all the issues while only blocking /32s by showing all the listings under your responsibility and making nice to see that list empty. Pretty simple. Incidentally SORBS usually blocks /24s and, as far as I know, provides no way for you to lookup all listings under a providers responsibility (by AS or otherwise). Incidentally, I have yet to see anything from Proofpoint, SORBS or their support system regarding the access issues we are having to their system. If anyone has another contact at Proofpoint other than Girish I'd appreciate knowing what it is. --- Landon Stewart > Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": www.superb.net From georgeb at gmail.com Thu Apr 5 12:26:11 2012 From: georgeb at gmail.com (George B.) Date: Thu, 5 Apr 2012 10:26:11 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F74485F.3040401@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4f73d08d.c4c52a0a.5a34.4638SMTPIN_ADDED@mx.google.com> <4F74485F.3040401@gmail.com> Message-ID: On Thu, Mar 29, 2012 at 4:32 AM, Matt Ryanczak wrote: > I too had AAAA with nesol years ago. It required special phone calls to > special people to update. Customer support never knew what was going on > regarding AAAA or IPvWhat?. > > I suspect all of the people there that know about these types of things have > moved on. Netsol has been leaking people since their sale to web.com last > year, from actual layoffs and fear of the same. > > ~matt How long did it take them? We have had a request in for AAAA records for a domain for over a week now, and nothing in whois yet. From rs at seastrom.com Thu Apr 5 12:44:22 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 05 Apr 2012 13:44:22 -0400 Subject: SIP Carrier Consolidation In-Reply-To: <13733103.140.1333644073293.JavaMail.root@ubuntu.digitalrage.org> (Elijah Savage's message of "Thu, 5 Apr 2012 12:41:13 -0400 (EDT)") References: <13733103.140.1333644073293.JavaMail.root@ubuntu.digitalrage.org> Message-ID: <867gxudqfd.fsf@seastrom.com> "SIP trunking consolidation" is buzzword heavy and context-light. What problem are you trying to solve and at what scale? Do you have a requirement to have the provider be a traditional TDM-based organization or is an aggregator sufficient? How price-sensitive are you? At fairly small scale (10 DIDs including some 877 numbers, feeding to Asterisk) I've had fine luck with http://voip.ms/ But your requirements may vary... -r Elijah Savage writes: > Anyone here that have gone through the process of SIP trunking consolidation care to comment offline on > > Whom do you utilize? > What has been your experience operationally? > What was your experience during transition/implementation? > > Thank you ahead of time. From nick at foobar.org Thu Apr 5 12:45:30 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 05 Apr 2012 18:45:30 +0100 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: <4F7DDA3A.4080406@foobar.org> On 05/04/2012 17:48, goemon at anime.net wrote: > But they will care about a /24. I'm curious as to why they would want to stop at /24. If you're going to take the shotgun approach, why not blacklist the entire ASN? Nick From paul4004 at gmail.com Thu Apr 5 13:01:02 2012 From: paul4004 at gmail.com (PC) Date: Thu, 5 Apr 2012 12:01:02 -0600 Subject: SORBS?! In-Reply-To: <4F7DDA3A.4080406@foobar.org> References: <4F7CA69F.9090206@b2b2c.ca> <4F7DDA3A.4080406@foobar.org> Message-ID: That's probably a better idea. I moved "into" a /24 ip block that was SWIPed to me that they reported was "dynamic cable/DSL users" (no spam history, mind you). Didn't matter, I couldn't send e-mail. When trying to get it delisted I had a TTL on the zone that was "incompatible" with their standards (for DR failover purposes) and was unwilling to maintain a TTL of how many ever hours they wanted as it didn't fit the company's requirements. I ended up just getting a new IP block from the ISP as they gave up on resolving it too. Kind of a waste, but it worked. I relocated to there instead. 1 year later they updated my ticket and delisted it. On Thu, Apr 5, 2012 at 11:45 AM, Nick Hilliard wrote: > On 05/04/2012 17:48, goemon at anime.net wrote: > > But they will care about a /24. > > I'm curious as to why they would want to stop at /24. If you're going to > take the shotgun approach, why not blacklist the entire ASN? > > Nick > > From esavage at digitalrage.org Thu Apr 5 13:09:20 2012 From: esavage at digitalrage.org (Elijah Savage) Date: Thu, 5 Apr 2012 14:09:20 -0400 (EDT) Subject: SIP Carrier Consolidation In-Reply-To: <867gxudqfd.fsf@seastrom.com> Message-ID: <8456958.164.1333649360104.JavaMail.root@ubuntu.digitalrage.org> Thank you for the reply. Yes an aggregator, large deployment. Initially this is discovery, though price is always important it is most about understanding operations and implementation at this point. ----- Original Message ----- From: "Robert E. Seastrom" To: "Elijah Savage" Cc: "NANOG list" Sent: Thursday, April 5, 2012 1:44:22 PM Subject: Re: SIP Carrier Consolidation "SIP trunking consolidation" is buzzword heavy and context-light. What problem are you trying to solve and at what scale? Do you have a requirement to have the provider be a traditional TDM-based organization or is an aggregator sufficient? How price-sensitive are you? At fairly small scale (10 DIDs including some 877 numbers, feeding to Asterisk) I've had fine luck with http://voip.ms/ But your requirements may vary... -r Elijah Savage writes: > Anyone here that have gone through the process of SIP trunking consolidation care to comment offline on > > Whom do you utilize? > What has been your experience operationally? > What was your experience during transition/implementation? > > Thank you ahead of time. From daryl at introspect.net Thu Apr 5 19:51:45 2012 From: daryl at introspect.net (Daryl G. Jurbala) Date: Thu, 5 Apr 2012 20:51:45 -0400 Subject: SIP Carrier Consolidation In-Reply-To: <8456958.164.1333649360104.JavaMail.root@ubuntu.digitalrage.org> References: <8456958.164.1333649360104.JavaMail.root@ubuntu.digitalrage.org> Message-ID: I have to respond with the sentiments of Robert: "large" is a very relative term. Also, are we talking about origination or termination here? How many minutes a day of each? What's your ACD? What are your top destinations? If it's bursty like a call center how many concurrent calls? You can't get any real answers without providing relevant information. On Apr 5, 2012, at 2:09 PM, Elijah Savage wrote: > Thank you for the reply. > > Yes an aggregator, large deployment. > > Initially this is discovery, though price is always important it is most about understanding operations and implementation at this point. From bmanning at vacation.karoshi.com Thu Apr 5 23:37:46 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 6 Apr 2012 04:37:46 +0000 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4f73d08d.c4c52a0a.5a34.4638SMTPIN_ADDED@mx.google.com> <4F74485F.3040401@gmail.com> Message-ID: <20120406043746.GA4766@vacation.karoshi.com.> On Thu, Apr 05, 2012 at 10:26:11AM -0700, George B. wrote: > On Thu, Mar 29, 2012 at 4:32 AM, Matt Ryanczak wrote: > > > I too had AAAA with nesol years ago. It required special phone calls to > > special people to update. Customer support never knew what was going on > > regarding AAAA or IPvWhat?. > > > > I suspect all of the people there that know about these types of things have > > moved on. Netsol has been leaking people since their sale to web.com last > > year, from actual layoffs and fear of the same. > > > > ~matt > > How long did it take them? We have had a request in for AAAA records > for a domain for over a week now, and nothing in whois yet. 2002, it took 3hrs. /bill From drew.weaver at thenap.com Fri Apr 6 06:31:47 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 6 Apr 2012 07:31:47 -0400 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: That's just not true, we would much rather be notified of something that a reputation list finds objectionable and take it down ourselves than have Senderbase set a poor reputation on dozens of IaaS customers. -Drew -----Original Message----- From: goemon at anime.net [mailto:goemon at anime.net] Sent: Thursday, April 05, 2012 12:48 PM To: Drew Weaver Cc: 'Sam Oduor'; Chris Conn; nanog at nanog.org Subject: RE: SORBS?! This is often the only way to get peoples attention and get action. Providers dont care about individual /32's and will let them sit around and spew nigerian scams and pill spams without any consequences. But they will care about a /24. -Dan On Thu, 5 Apr 2012, Drew Weaver wrote: > Now, if we could only teach Senderbase that if their customers receive 'questionable' smtp traffic from 1 IP address in a /24 it doesn't mean that all IP addresses in that /24 are malicious we'd really be living it up in 2012. > > > > -----Original Message----- > From: Sam Oduor [mailto:sam.oduor at gmail.com] > Sent: Thursday, April 05, 2012 7:56 AM > To: Chris Conn > Cc: nanog at nanog.org > Subject: Re: SORBS?! > > Some of the IP's I manage got blacklisted and its true they were spamming and Sorbs had a very valid reason for blacklisting them. > > I got this response response from sorbs after resolving the problem amicably. Sorbs responded well on time. > > *Your request appear to have been resolved. If you have any further questions or concerns, please respond to this message. > > Please note: > > If your IP address has been delisted (marked as 'Inactive'), it will take up to 2 hours to get from the database to all the SORBS DNS servers. Changes to the database are exported to the DNS zone files periodically, not immediately after every change. Furthermore, after the updated database contents have been exported to the DNS zone files, it will then take up to 48 hours for the outdated DNS information to be removed from DNS caches around the world - none of these are in SORBS' control. > > Please do not reply to this call with problems not related to this ticket or your request will be ignored. > > > > * > *On Wed, Apr 4, 2012 at 10:53 PM, Chris Conn wrote: > * >> >> *Hello, >> >> Is anyone from SORBS still listening? We have a few IP addresses here >> and there that are listed, one in particular that has been for a spam >> incident from over a year ago. The "last spam" date is 03/05/2011 >> according to their lookup tools.* * >> >> We don't have access to their Net Manager even if our ARIN POC >> corresponds to the account on their system we opened a while ago. We >> use their ISP feedback form and never get any responses back.* * >> >> Is SORBS still relevant and functional?* * >> >> Sincerely,* >> >> Chris Conn >> B2B2C.ca >> >> > > > -- > Samson Oduor > > From vincent.ferran-lacome at bnpparibas.com Fri Apr 6 07:28:19 2012 From: vincent.ferran-lacome at bnpparibas.com (vincent.ferran-lacome at bnpparibas.com) Date: Fri, 6 Apr 2012 14:28:19 +0200 Subject: AUTO : Vincent FERRAN-LACOME est absent(e). (retour 16/04/2012) Message-ID: Je suis absent(e) du bureau jusqu'au 16/04/2012 Je suis absent pour le moment. En cas de n?cessit?, merci de transmettre vos messages ? l'?quipe CSIRT: csirt at bnpparibas.com +33 1 40 14 26 95 (office hours UTC +1/+2) -- I am currently out of office. If necessary, please forward your messages to the CSIRT team: csirt at bnpparibas.com +33 1 40 14 26 95 (office hours UTC +1/+2) Remarque?: ceci est une r?ponse automatique ? votre message "NANOG Digest, Vol 51, Issue 11" envoy? le 6/4/12 13:31:56. C'est la seule notification que vous recevrez pendant l'absence de cette personne. This message and any attachments (the "message") is intended solely for the intended addressees and is confidential. If you receive this message in error,or are not the intended recipient(s), please delete it and any copies from your systems and immediately notify the sender. Any unauthorized view, use that does not comply with its purpose, dissemination or disclosure, either whole or partial, is prohibited. Since the internet cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS (and its subsidiaries) shall not be liable for the message if modified, changed or falsified. Do not print this message unless it is necessary,consider the environment. ---------------------------------------------------------------------------------------------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur ou s'il ne vous est pas destine, merci de le detruire ainsi que toute copie de votre systeme et d'en avertir immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de ce message qui n'est pas conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer l'integrite de ce message electronique susceptible d'alteration, BNP Paribas (et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese ou il aurait ete modifie, deforme ou falsifie. N'imprimez ce message que si necessaire, pensez a l'environnement. From Valdis.Kletnieks at vt.edu Fri Apr 6 08:48:11 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 06 Apr 2012 09:48:11 -0400 Subject: SORBS?! In-Reply-To: Your message of "Fri, 06 Apr 2012 07:31:47 -0400." References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: <30556.1333720091@turing-police.cc.vt.edu> On Fri, 06 Apr 2012 07:31:47 -0400, Drew Weaver said: > That's just not true, we would much rather be notified of something that a > reputation list finds objectionable and take it down ourselves than have > Senderbase set a poor reputation on dozens of IaaS customers. If it was industry-wide standard practice that just notifying a provider resulted in something being done, we'd not need things like Senderbase, which is after all basically a list of people who don't take action when notified... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From drew.weaver at thenap.com Fri Apr 6 08:55:35 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 6 Apr 2012 09:55:35 -0400 Subject: SORBS?! In-Reply-To: <30556.1333720091@turing-police.cc.vt.edu> References: <4F7CA69F.9090206@b2b2c.ca> <30556.1333720091@turing-police.cc.vt.edu> Message-ID: That is again, not true. Senderbase's listings don't correlate to any public information so it's pretty much impossible to pro-actively protect ourselves from having our IPs set to poor. I.e. when Senderbase assigns IPs to poor, those same IPs aren't listed on any RBLs or anything. They operate in a vacuum where there is no visibility into why they do anything. Unlike organizations like Spamhaus where you know exactly why IPs are listed. Thanks, -Drew -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Friday, April 06, 2012 9:48 AM To: Drew Weaver Cc: 'goemon at anime.net'; nanog at nanog.org Subject: Re: SORBS?! On Fri, 06 Apr 2012 07:31:47 -0400, Drew Weaver said: > That's just not true, we would much rather be notified of something > that a reputation list finds objectionable and take it down ourselves > than have Senderbase set a poor reputation on dozens of IaaS customers. If it was industry-wide standard practice that just notifying a provider resulted in something being done, we'd not need things like Senderbase, which is after all basically a list of people who don't take action when notified... From ryanczak at gmail.com Fri Apr 6 09:00:35 2012 From: ryanczak at gmail.com (Matt Ryanczak) Date: Fri, 06 Apr 2012 10:00:35 -0400 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4f73d08d.c4c52a0a.5a34.4638SMTPIN_ADDED@mx.google.com> <4F74485F.3040401@gmail.com> Message-ID: <4F7EF703.8090407@gmail.com> On 4/5/12 1:26 PM, George B. wrote: > How long did it take them? We have had a request in for AAAA records > for a domain for over a week now, and nothing in whois yet. between a couple of hours and 5 to 10 business days. The long leads times came when I no longer had direct contacts and had to go through the helpdesk. From esavage at digitalrage.org Fri Apr 6 09:42:31 2012 From: esavage at digitalrage.org (Elijah Savage) Date: Fri, 6 Apr 2012 10:42:31 -0400 (EDT) Subject: SIP Carrier Consolidation In-Reply-To: Message-ID: <28030947.174.1333723351436.JavaMail.root@ubuntu.digitalrage.org> Thanks to all who responded off list even to those that are intrested in the opportunity, I do appreciate it. ----- Original Message ----- From: "Daryl G. Jurbala" To: "Elijah Savage" Cc: "Robert E. Seastrom" , "NANOG list" Sent: Thursday, April 5, 2012 8:51:45 PM Subject: Re: SIP Carrier Consolidation I have to respond with the sentiments of Robert: "large" is a very relative term. Also, are we talking about origination or termination here? How many minutes a day of each? What's your ACD? What are your top destinations? If it's bursty like a call center how many concurrent calls? You can't get any real answers without providing relevant information. On Apr 5, 2012, at 2:09 PM, Elijah Savage wrote: > Thank you for the reply. > > Yes an aggregator, large deployment. > > Initially this is discovery, though price is always important it is most about understanding operations and implementation at this point. From bruns at 2mbit.com Fri Apr 6 09:54:49 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 06 Apr 2012 08:54:49 -0600 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> Message-ID: <4F7F03B9.80400@2mbit.com> On 4/4/12 3:36 PM, Landon Stewart wrote: >> > It's best to not complain about it and just accept it as a fact of life >> > your IPs are listed on SORBS and move on. It's not the end of the world. >> > > It turns into a customer service issue for most service providers. Eh, guess they'll just have to absorb the cost of that, like its expected that the recipients of spam have to absorb the cost of ISPs not disconnecting infected/spamming customers... And like how I have to absorb the costs of spending my time during the day answering removal requests from people who lie to me constantly and hope that I don't notice their little games. Ever wonder why it takes time for DNSbl's to process removals, sometimes very long periods? Well, someone's gotta pay for that time the removal person does it (and I have yet to see a dime of compensation for the time I spend). -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From patrick at ianai.net Fri Apr 6 10:02:32 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Apr 2012 11:02:32 -0400 Subject: SORBS?! In-Reply-To: <4F7F03B9.80400@2mbit.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: On Apr 6, 2012, at 10:54 , Brielle Bruns wrote: > On 4/4/12 3:36 PM, Landon Stewart wrote: > >>>> It's best to not complain about it and just accept it as a fact of life >>>> your IPs are listed on SORBS and move on. It's not the end of the world. >>>> >> It turns into a customer service issue for most service providers. > > Eh, guess they'll just have to absorb the cost of that, like its expected that the recipients of spam have to absorb the cost of ISPs not disconnecting infected/spamming customers... > > And like how I have to absorb the costs of spending my time during the day answering removal requests from people who lie to me constantly and hope that I don't notice their little games. > > Ever wonder why it takes time for DNSbl's to process removals, sometimes very long periods? Well, someone's gotta pay for that time the removal person does it (and I have yet to see a dime of compensation for the time I spend). No, they don't. Many DNSBLs use self-service tools. Someone has to write the tool, but the rest is automated. Total cost is power & space, which is frequently donated (I have personally donated some myself to DNSBLs I thought were well run). Besides, anyone who knowingly causes harm to a third party and claims "it is a cost of doing business" or "mostly people like it" or "our $FOO is targeted and almost always correct, you must be an outlier and that's why it costs you" sound -exactly- like spammers to me. Spammer who are up-front about it I can deal with. Don't agree with or even like them, but at least we understand each other. Hypocrisy is a different story. -- TTFN, patrick From bruns at 2mbit.com Fri Apr 6 10:37:13 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 06 Apr 2012 09:37:13 -0600 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: <4F7F0DA9.2010607@2mbit.com> On 4/6/12 9:02 AM, Patrick W. Gilmore wrote: > No, they don't. Many DNSBLs use self-service tools. Someone has to > write the tool, but the rest is automated. Total cost is power& > space, which is frequently donated (I have personally donated some > myself to DNSBLs I thought were well run). Proxy removals and automated additions are self service removals. I don't trust automated removal for stuff that we add by hand. Too many variables, too much in the way of games... If I were to let the people in spam-sources request removal and handle removal entirely on their own without one of us reviewing it by hand, there'd be no entries left in my database. > > Besides, anyone who knowingly causes harm to a third party and claims > "it is a cost of doing business" or "mostly people like it" or "our > $FOO is targeted and almost always correct, you must be an outlier > and that's why it costs you" sound -exactly- like spammers to me. I was more pointing out to people that you expect someone else, who you've got no contractual obligation with, or relationship with, to make time and effort to handle a request you made. All I hear these days from people is that I have no right to tell them who they can have as customers, or how to run their business. Well, the reverse applies as well. I take great offense to people telling me how to run my own service, that I provide free at no charge with no obligations. When a provider actually works with me to resolve an issue, I bend over backwards to help them. Unfortunately, those kinds of providers are few and far in between. > > Spammer who are up-front about it I can deal with. Don't agree with > or even like them, but at least we understand each other. Hypocrisy > is a different story. Unfortunately, the apathy of providers, backbones, and network operators in general have created an environment that the almighty buck rules everything. Yeah, I've had offers for financial support of the AHBL. Turned them down every time, even though it would give me a chance to hire actual people to run it. But, then, I'd have someone hanging over my shoulder, pulling strings and interfering with my project. My independence goes out the window, and I can't truly say I have no financial interest in the listings. So, forgive me if my independence as a non-commercial DNSbl makes me somewhat jaded towards people who expect me to prioritize their demands over what pays the bills. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From george.herbert at gmail.com Fri Apr 6 10:49:13 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 6 Apr 2012 08:49:13 -0700 Subject: SORBS?! In-Reply-To: <4F7F0DA9.2010607@2mbit.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> Message-ID: This seems like a very 1999 anti-spam attitude. I have been doing anti-spam a long long time - literally since before Canter and Siegel (who I had as customers...) and before jj at cup.portal.com. It's not 1999 anymore. Patrick is not the enemy. Your attitude is worrying. The "I am not responsible for who uses the blacklist or what that means" isn't good enough anymore. George William Herbert Sent from my iPhone On Apr 6, 2012, at 8:37, Brielle Bruns wrote: > On 4/6/12 9:02 AM, Patrick W. Gilmore wrote: >> No, they don't. Many DNSBLs use self-service tools. Someone has to >> write the tool, but the rest is automated. Total cost is power& >> space, which is frequently donated (I have personally donated some >> myself to DNSBLs I thought were well run). > > > Proxy removals and automated additions are self service removals. I don't trust automated removal for stuff that we add by hand. Too many variables, too much in the way of games... > > If I were to let the people in spam-sources request removal and handle removal entirely on their own without one of us reviewing it by hand, there'd be no entries left in my database. > >> >> Besides, anyone who knowingly causes harm to a third party and claims >> "it is a cost of doing business" or "mostly people like it" or "our >> $FOO is targeted and almost always correct, you must be an outlier >> and that's why it costs you" sound -exactly- like spammers to me. > > > I was more pointing out to people that you expect someone else, who you've got no contractual obligation with, or relationship with, to make time and effort to handle a request you made. > > All I hear these days from people is that I have no right to tell them who they can have as customers, or how to run their business. > > Well, the reverse applies as well. I take great offense to people telling me how to run my own service, that I provide free at no charge with no obligations. > > When a provider actually works with me to resolve an issue, I bend over backwards to help them. Unfortunately, those kinds of providers are few and far in between. > >> >> Spammer who are up-front about it I can deal with. Don't agree with >> or even like them, but at least we understand each other. Hypocrisy >> is a different story. > > > Unfortunately, the apathy of providers, backbones, and network operators in general have created an environment that the almighty buck rules everything. > > Yeah, I've had offers for financial support of the AHBL. Turned them down every time, even though it would give me a chance to hire actual people to run it. But, then, I'd have someone hanging over my shoulder, pulling strings and interfering with my project. My independence goes out the window, and I can't truly say I have no financial interest in the listings. > > > So, forgive me if my independence as a non-commercial DNSbl makes me somewhat jaded towards people who expect me to prioritize their demands over what pays the bills. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From mike at mtcc.com Fri Apr 6 11:02:09 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 06 Apr 2012 09:02:09 -0700 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> Message-ID: <4F7F1381.7060408@mtcc.com> On 04/06/2012 08:49 AM, George Herbert wrote: > This seems like a very 1999 anti-spam attitude. > > I have been doing anti-spam a long long time - literally since before Canter and Siegel (who I had as customers...) and before jj at cup.portal.com. > > It's not 1999 anymore. Patrick is not the enemy. Your attitude is worrying. The "I am not responsible for who uses the blacklist or what that means" isn't good enough anymore. I wonder how long a popularish blacklist operator would last if they, oh say, blacklisted all of google or microsoft before they got some very threatening letters from their legal staff. An hour? A day? A week? You may have the right to list them and change your mind in your own good time, but they also have the right to defend their reputation civilly too. With great power comes great responsibility and all that. Mike From bruns at 2mbit.com Fri Apr 6 11:06:51 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 06 Apr 2012 10:06:51 -0600 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> Message-ID: <4F7F149B.2070005@2mbit.com> On 4/6/12 9:49 AM, George Herbert wrote: > This seems like a very 1999 anti-spam attitude. > > I have been doing anti-spam a long long time - literally since before > Canter and Siegel (who I had as customers...) and > beforejj at cup.portal.com. > > It's not 1999 anymore. Patrick is not the enemy. Your attitude is > worrying. The "I am not responsible for who uses the blacklist or > what that means" isn't good enough anymore. I know he's not the enemy. Hate the idea that he would be. The only reason why I responded the way I did, was because I sit here, watching everyone talk about how SORBS is bad this, how they are bad that, how they need to change this, and how they need to change how they operate to their guidelines, not SORBS's guidelines. Its not directed at Patrick. I just got the feeling like he was saying its okay for these people to dictate how SORBS operates. Like its been said, DNSbl's have a right to run as they see fit, and handle removals as they see fit. Just like every ISP has the right to run their network as they see fit, and refuse to remove spamming customers and deal with network abuse. I've been working on variations of the AHBL since 1998 or so under different names, so if I seem 'old school' in my beliefs how the DNSbl is run, that's probably why. Reality is, people use a DNSbl how they see fit. I can't really control that without restricting access, requiring payments or registration, etc. I gave up years ago trying to tell people how not to use it, since noone actually listens. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Fri Apr 6 11:17:03 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 06 Apr 2012 10:17:03 -0600 Subject: SORBS?! In-Reply-To: <4F7F1381.7060408@mtcc.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F1381.7060408@mtcc.com> Message-ID: <4F7F16FF.80007@2mbit.com> On 4/6/12 10:02 AM, Michael Thomas wrote: > > I wonder how long a popularish blacklist operator would last if they, > oh say, blacklisted all of google or microsoft before they got some > very threatening letters from their legal staff. An hour? A day? A week? > > You may have the right to list them and change your mind in your own > good time, but they also have the right to defend their reputation civilly > too. With great power comes great responsibility and all that. Slippery slope. For large providers who depend alot on spam filters, thats one huge door to open that could get very ugly very quick in the reverse path. Imagine every ISP suing hotmail and google for blocking messages for arbitrary reasons with no apparent justification. What's good for the goose is good for the gander. There's also USC 47,230 to contend with. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From Valdis.Kletnieks at vt.edu Fri Apr 6 11:18:59 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 06 Apr 2012 12:18:59 -0400 Subject: SORBS?! In-Reply-To: Your message of "Fri, 06 Apr 2012 09:55:35 -0400." References: <4F7CA69F.9090206@b2b2c.ca> <30556.1333720091@turing-police.cc.vt.edu> Message-ID: <36861.1333729139@turing-police.cc.vt.edu> On Fri, 06 Apr 2012 09:55:35 -0400, Drew Weaver said: > That is again, not true. > > Senderbase's listings don't correlate to any public information so it's pretty > much impossible to pro-actively protect ourselves from having our IPs set to poor. You missed the point - if it was industry standard practice, reputation lists at Senderbase, Spamhaus, and SORBS would *all 3* be out of business, because the average spammer's lifespan at a provider would be less than the time it takes the average reputation list to put up an entry. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mike at mtcc.com Fri Apr 6 11:35:12 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 06 Apr 2012 09:35:12 -0700 Subject: SORBS?! In-Reply-To: <4F7F16FF.80007@2mbit.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F1381.7060408@mtcc.com> <4F7F16FF.80007@2mbit.com> Message-ID: <4F7F1B40.3030005@mtcc.com> On 04/06/2012 09:17 AM, Brielle Bruns wrote: > On 4/6/12 10:02 AM, Michael Thomas wrote: >> >> I wonder how long a popularish blacklist operator would last if they, >> oh say, blacklisted all of google or microsoft before they got some >> very threatening letters from their legal staff. An hour? A day? A week? >> >> You may have the right to list them and change your mind in your own >> good time, but they also have the right to defend their reputation civilly >> too. With great power comes great responsibility and all that. > > Slippery slope. > > For large providers who depend alot on spam filters, thats one huge door to open that could get very ugly very quick in the reverse path. Imagine every ISP suing hotmail and google for blocking messages for arbitrary reasons with no apparent justification. > > What's good for the goose is good for the gander. > > There's also USC 47,230 to contend with. > It's more of an arms race than a slippery slope, but my point is that a big enough company would absolutely respond if they felt a big enough blacklist was being capricious in a way that was affecting their making money. I sympathize with "my blacklist, my donated time, my rules", but when you're affecting their business, you better get it right and better respond reasonably when the inevitable screwups happen. The one absolute right you have is to not be in the blacklist business (paid or not) at all. Beyond that, you have responsibilities too, and it would be best for everybody to not take them lightly causing the entire thing to get escalated to the legal domain where everybody most likely loses. Mike From bill at herrin.us Fri Apr 6 11:56:08 2012 From: bill at herrin.us (William Herrin) Date: Fri, 6 Apr 2012 12:56:08 -0400 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: On Fri, Apr 6, 2012 at 7:31 AM, Drew Weaver wrote: > That's just not true, we would much rather be notified of >something that a reputation list finds objectionable and take >it down ourselves than have Senderbase set a poor >reputation on dozens of IaaS customers. I think the idea is that you're supposed to proactively monitor your systems for abuse and generally make your network inhospitable to spammers, not just reactively move the customer to a new IP address when the unpaid anti-spammers kindly let you know you've been detected. Personally I see SORBS as the canary in the coal mine. Except for the DUHL (which identifies dynamic IPs, not spamming activity) nobody serious relies on SORBS' data. So, it doesn't much hurt when they list you. But, like the canary that dies first if the air turns bad, if you're careful to watch SORBS you know when you're headed for problems which will get you listed by a real RBL. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drew.weaver at thenap.com Fri Apr 6 12:01:55 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 6 Apr 2012 13:01:55 -0400 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: So you're suggesting that hosting companies do what? How many emails or port 25/587 connections a (day, week, hour) makes someone a spammer if there are no objections being lodged at the abuse department? Are we supposed to do DPI on every email that a dedicated server sends out and then decide whether it's spam? My point is if a list has a problem with a /32 they could have the courtesy to contact the ISP/host prior to causing huge problems for a /24 I'm not sure what more can be done than having an abuse department staffed up and checking all published data before accepting a customer. And I'm mostly just complaining about senderbase, because they seem to be the one that really large companies reference. Thanks, -Drew -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Friday, April 06, 2012 12:56 PM To: Drew Weaver Cc: nanog at nanog.org Subject: Re: SORBS?! On Fri, Apr 6, 2012 at 7:31 AM, Drew Weaver wrote: > That's just not true, we would much rather be notified of something >that a reputation list finds objectionable and take it down ourselves >than have Senderbase set a poor reputation on dozens of IaaS customers. I think the idea is that you're supposed to proactively monitor your systems for abuse and generally make your network inhospitable to spammers, not just reactively move the customer to a new IP address when the unpaid anti-spammers kindly let you know you've been detected. Personally I see SORBS as the canary in the coal mine. Except for the DUHL (which identifies dynamic IPs, not spamming activity) nobody serious relies on SORBS' data. So, it doesn't much hurt when they list you. But, like the canary that dies first if the air turns bad, if you're careful to watch SORBS you know when you're headed for problems which will get you listed by a real RBL. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dmiller at tiggee.com Fri Apr 6 12:11:27 2012 From: dmiller at tiggee.com (David Miller) Date: Fri, 06 Apr 2012 13:11:27 -0400 Subject: SORBS?! In-Reply-To: <4F7F1B40.3030005@mtcc.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F1381.7060408@mtcc.com> <4F7F16FF.80007@2mbit.com> <4F7F1B40.3030005@mtcc.com> Message-ID: <4F7F23BF.3010800@tiggee.com> On 4/6/2012 12:35 PM, Michael Thomas wrote: > On 04/06/2012 09:17 AM, Brielle Bruns wrote: >> On 4/6/12 10:02 AM, Michael Thomas wrote: >>> >>> I wonder how long a popularish blacklist operator would last if they, >>> oh say, blacklisted all of google or microsoft before they got some >>> very threatening letters from their legal staff. An hour? A day? A >>> week? >>> >>> You may have the right to list them and change your mind in your own >>> good time, but they also have the right to defend their reputation >>> civilly >>> too. With great power comes great responsibility and all that. >> >> Slippery slope. >> >> For large providers who depend alot on spam filters, thats one huge >> door to open that could get very ugly very quick in the reverse path. >> Imagine every ISP suing hotmail and google for blocking messages for >> arbitrary reasons with no apparent justification. >> >> What's good for the goose is good for the gander. >> >> There's also USC 47,230 to contend with. >> > > It's more of an arms race than a slippery slope, but my point is that a > big enough company would absolutely respond if they felt a big enough > blacklist was being capricious in a way that was affecting their making > money. > > I sympathize with "my blacklist, my donated time, my rules", but when > you're affecting their business, you better get it right and better > respond > reasonably when the inevitable screwups happen. The one absolute right > you > have is to not be in the blacklist business (paid or not) at all. > Beyond that, > you have responsibilities too, and it would be best for everybody to not > take them lightly causing the entire thing to get escalated to the legal > domain where everybody most likely loses. What grounds would these large senders have to file any legal objections against an RBL? RBLs don't block emails. Operators of mail servers who use RBLs block emails (in part) based on information from RBLs. Noone has a "right" to send email to anyone else. Email is a cooperative agreement between sender and receiver. The receiver agrees to accept the email, but at any time and for any reason the receiver can stop agreeing to accept emails from a sender. It is completely legal to decide not to accept (i.e. block) emails from a sender. RBLs are not beholden to senders. RBLs are beholden to the receivers who use their RBL to preserve the quality of the RBL. RBLs are a meritocracy. If an RBL either lists too many valid senders or does not list enough bad senders, then receivers will notice and stop using the RBL on their servers. -DMM From patrick at ianai.net Fri Apr 6 10:02:32 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Apr 2012 11:02:32 -0400 Subject: SORBS?! In-Reply-To: <4F7F03B9.80400@2mbit.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: On Apr 6, 2012, at 10:54 , Brielle Bruns wrote: > On 4/4/12 3:36 PM, Landon Stewart wrote: > >>>> It's best to not complain about it and just accept it as a fact of life >>>> your IPs are listed on SORBS and move on. It's not the end of the world. >>>> >> It turns into a customer service issue for most service providers. > > Eh, guess they'll just have to absorb the cost of that, like its expected that the recipients of spam have to absorb the cost of ISPs not disconnecting infected/spamming customers... > > And like how I have to absorb the costs of spending my time during the day answering removal requests from people who lie to me constantly and hope that I don't notice their little games. > > Ever wonder why it takes time for DNSbl's to process removals, sometimes very long periods? Well, someone's gotta pay for that time the removal person does it (and I have yet to see a dime of compensation for the time I spend). No, they don't. Many DNSBLs use self-service tools. Someone has to write the tool, but the rest is automated. Total cost is power & space, which is frequently donated (I have personally donated some myself to DNSBLs I thought were well run). Besides, anyone who knowingly causes harm to a third party and claims "it is a cost of doing business" or "mostly people like it" or "our $FOO is targeted and almost always correct, you must be an outlier and that's why it costs you" sound -exactly- like spammers to me. Spammer who are up-front about it I can deal with. Don't agree with or even like them, but at least we understand each other. Hypocrisy is a different story. -- TTFN, patrick From goemon at anime.net Fri Apr 6 12:21:00 2012 From: goemon at anime.net (goemon at anime.net) Date: Fri, 6 Apr 2012 10:21:00 -0700 (PDT) Subject: The day SORBS goes away ... In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: The day SORBS goes away is the day abuse at yahoo.com starts functioning properly and yahoo starts booting spammers. The day SORBS goes away is the day BS like this stops happening: ----- The following addresses had permanent fatal errors ----- (reason: 554 rejected due to spam content) -Dan From nathan at atlasnetworks.us Fri Apr 6 12:41:48 2012 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 6 Apr 2012 17:41:48 +0000 Subject: DNS noise Message-ID: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> Anyone else seeing this sort of noise lately? 10:35:00.958556 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:00.961055 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.262461 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.350979 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.351001 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.573166 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.573204 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.730128 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.970730 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.121218 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374853 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374879 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.493257 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.493270 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.726303 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.863667 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.023693 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251935 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251964 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:03.326562 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.630514 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.638327 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) Note that the server involved does not run a DNS daemon, or listen on 53, or anything else that would attract attention. From keegan.holley at sungard.com Fri Apr 6 12:47:43 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Fri, 6 Apr 2012 13:47:43 -0400 Subject: DNS noise In-Reply-To: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> Message-ID: Have you tried contacting the owner of the IP? A DDOS attack from that particular IP would be ironic. # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=true&showARIN=false&ext=netref2 # Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 - 72.20.63.255 DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - 72.20.23.63 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # 2012/4/6 Nathan Eisenberg > Anyone else seeing this sort of noise lately? > > 10:35:00.958556 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:00.961055 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:01.262461 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:01.350979 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:01.351001 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp > port 53 unreachable, length 74 > 10:35:01.573166 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:01.573204 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp > port 53 unreachable, length 74 > 10:35:01.730128 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:01.970730 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:02.121218 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:02.374853 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:02.374879 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp > port 53 unreachable, length 74 > 10:35:02.493257 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:02.493270 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp > port 53 unreachable, length 74 > 10:35:02.726303 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:02.863667 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:03.023693 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:03.251935 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:03.251964 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp > port 53 unreachable, length 74 > 10:35:03.326562 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:03.630514 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > 10:35:03.638327 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > ripe.net. (38) > > Note that the server involved does not run a DNS daemon, or listen on 53, > or anything else that would attract attention. > > > > From michael at rancid.berkeley.edu Fri Apr 6 12:51:50 2012 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Fri, 06 Apr 2012 10:51:50 -0700 Subject: DNS noise In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> Message-ID: <4F7F2D36.50309@rancid.berkeley.edu> On 04/06/12 10:47, Keegan Holley wrote: > Have you tried contacting the owner of the IP? A DDOS attack from that > particular IP would be ironic. > > # > # The following results may also be obtained via: > # > http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=true&showARIN=false&ext=netref2 > # > > Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 > - 72.20.63.255 > DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - > 72.20.23.63 If it's an attempt at a reflective DNS-based DDoS attack, then the source IP address making the query is likely spoofed. The IP address in question is really the target, not the source of the attack. That is, of course, if this is a standard reflective DDoS attack. michael From paul4004 at gmail.com Fri Apr 6 12:52:10 2012 From: paul4004 at gmail.com (PC) Date: Fri, 6 Apr 2012 11:52:10 -0600 Subject: DNS noise In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> Message-ID: It could be a DNS amplification attack, with the source IP forged. They may be hoping you "reply" to the forged source with a response greater than the cost of them sending the query. Of course you'd have to actually be running a poorly configured DNS server on that IP for this to work... On Fri, Apr 6, 2012 at 11:47 AM, Keegan Holley wrote: > Have you tried contacting the owner of the IP? A DDOS attack from that > particular IP would be ironic. > > # > # The following results may also be obtained via: > # > > http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=true&showARIN=false&ext=netref2 > # > > Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 > - 72.20.63.255 > DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - > 72.20.23.63 > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > > > > 2012/4/6 Nathan Eisenberg > > > Anyone else seeing this sort of noise lately? > > > > 10:35:00.958556 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:00.961055 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:01.262461 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:01.350979 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:01.351001 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp > > port 53 unreachable, length 74 > > 10:35:01.573166 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:01.573204 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp > > port 53 unreachable, length 74 > > 10:35:01.730128 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:01.970730 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:02.121218 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:02.374853 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:02.374879 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp > > port 53 unreachable, length 74 > > 10:35:02.493257 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:02.493270 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp > > port 53 unreachable, length 74 > > 10:35:02.726303 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:02.863667 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:03.023693 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:03.251935 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:03.251964 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp > > port 53 unreachable, length 74 > > 10:35:03.326562 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:03.630514 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > 10:35:03.638327 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? > > ripe.net. (38) > > > > Note that the server involved does not run a DNS daemon, or listen on 53, > > or anything else that would attract attention. > > > > > > > > > From nick at foobar.org Fri Apr 6 13:04:41 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 06 Apr 2012 19:04:41 +0100 Subject: DNS noise In-Reply-To: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> Message-ID: <4F7F3039.3000604@foobar.org> On 06/04/2012 18:41, Nathan Eisenberg wrote: > Anyone else seeing this sort of noise lately? There has been a bit of that recently for ripe.net and several other well known DNSSEC enabled domains (e.g. isc.org). It turns out that DNSSEC makes a respectable traffic amplification vector: > twinkie# dig +ignore +notcp any ripe.net | grep rcvd > ;; MSG SIZE rcvd: 490 > twinkie# The dns request packet size was 26 bytes. Add packet overhead to both the request and the reply, and you end up with: request: 26 (data) + 8 (udp) + 20 (ip) + 18 (ethernet frame) + ipg (12) + 8 (preamble) = 92 reply: 490 (data) + 8 (udp) + 20 (ip) + 18 (ethernet frame) + ipg (12) + 8 (preamble) = 556 => amplification on ethernet medium == 556/92, or slightly more than 6x. Welcome back to the 1990s. Nick From mysidia at gmail.com Fri Apr 6 13:08:31 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 6 Apr 2012 13:08:31 -0500 Subject: DNS noise In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> Message-ID: On Fri, Apr 6, 2012 at 12:52 PM, PC wrote: > Of course you'd have to actually be running a poorly configured DNS server > on that IP for this to work... Right.... was that IP ever running a DNS service? Picking random IPs to spoof and hope some of the random IPs happen to be DNS servers doesn't sound like a very "efficient" attack. It seems like the attacker would want to 'probe first' before selecting innocent servers to reflect at Perhaps 2 or 3% of the possible random IPs on the internet actually run DNS servers that could possibly respond to spoofed queries? -- -JH From mysidia at gmail.com Fri Apr 6 13:13:22 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 6 Apr 2012 13:13:22 -0500 Subject: DNS noise In-Reply-To: <4F7F3039.3000604@foobar.org> References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> <4F7F3039.3000604@foobar.org> Message-ID: On Fri, Apr 6, 2012 at 1:04 PM, Nick Hilliard wrote: > On 06/04/2012 18:41, Nathan Eisenberg wrote: >> Anyone else seeing this sort of noise lately? > > There has been a bit of that recently for ripe.net and several other well > known DNSSEC enabled domains (e.g. isc.org). > > It turns out that DNSSEC makes a respectable traffic amplification vector: This is definitely a problem. Unfortunately, what really should happen is DNSSEC should be revised, to, either make sure that the client initiating the query has to either do more work than the server, or make a round trip before the DNSSEC data can be requested. One way of accomplishing that would be to indicate that DNSSEC data can be transmitted only over DNS when using TCP; since a reflection spoofer cannot complete a 3-way TCP handshake, the attacker cannot send spoofed requests for DNSSEC data over TCP. -- -JH From drc at virtualized.org Fri Apr 6 13:24:18 2012 From: drc at virtualized.org (David Conrad) Date: Fri, 6 Apr 2012 11:24:18 -0700 Subject: DNS noise In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> <4F7F3039.3000604@foobar.org> Message-ID: <4CCA6692-AD36-4660-86DA-44F6D19D4BB6@virtualized.org> On Apr 6, 2012, at 11:13 AM, Jimmy Hess wrote: >> It turns out that DNSSEC makes a respectable traffic amplification vector: > This is definitely a problem. Yep. So are SNMP reflection attacks (biggest attack I've seen was one of these) and any other datagram-oriented query/response protocol. > Unfortunately, what really should happen is DNSSEC should be revised, to, > either make sure that the client initiating the query has to either do more > work than the server, or make a round trip before the DNSSEC data can > be requested. Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38 > One way of accomplishing that would be to indicate that DNSSEC data > can be transmitted only over DNS when using TCP; I suspect the root server operators might not like this idea very much. Regards, -drc From mysidia at gmail.com Fri Apr 6 13:29:30 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 6 Apr 2012 13:29:30 -0500 Subject: SORBS?! In-Reply-To: <30556.1333720091@turing-police.cc.vt.edu> References: <4F7CA69F.9090206@b2b2c.ca> <30556.1333720091@turing-police.cc.vt.edu> Message-ID: On Fri, Apr 6, 2012 at 8:48 AM, wrote: > If it was industry-wide standard practice that just notifying a provider resulted > in something being done, we'd not need things like Senderbase, which is after > all basically a list of people who don't take action when notified... > [snip] Pot calling the kettle black. Before we talk about industry-wide practice about the providers "doing something". We should talk about industry-wide practice for "Black lists" doing something to correct entries, instead of just building up indiscriminate or irresponsibly maintained lists of networks or "scores" of networks that were targetted by a spammer at one time in the past. It's just as bad for a blacklist operator to not respond and "do something" for a network operator legitimately trying to resolve spam problems with their network and clear the listing as it is for a network abuse contact to not respond to a network operator. We should talk about industry-wide practices for how providers should be notified, what providers are actually supposed to do to "authenticate reports", because sometimes the report/notification itself is malicious or false abusive attempt to harass an innocent email user, and what exactly providers are actually expected to do with certain kinds of notification. The informal standard of "just call or send an e-mail to an abuse contact" is poorly specified. The informal standard of "the abuse contact should investigate and take immediate action" is poorly specified. Some of these things that are not specified by RFC should be specified by RFC as best practice. There should be abuse notification and response notification mechanisms other than free form e-mail. -- -JH From bill at herrin.us Fri Apr 6 13:40:32 2012 From: bill at herrin.us (William Herrin) Date: Fri, 6 Apr 2012 14:40:32 -0400 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: On Fri, Apr 6, 2012 at 1:01 PM, Drew Weaver wrote: > So you're suggesting that hosting companies do what? I believe I'm suggesting you use SORBS as your canary in the coal mine and otherwise ignore them. But if you're asking what hosting companies could do to proactively prevent spamming and make their systems inhospitable to spammers, I might start with blocking non-local outbound TCP 25 by default. Then have the customer fill out and sign a form. Spell out your bulk email policies, have the customer specify which of their IPs will originate email and have them send the form to you signed via U.S. Mail. No "proof" or other major hoops, just sign and mail the form. Unless you're *trying* to run a "bulletproof hosting" system, you'll find the customers who intentionally spam would prefer to stay under the radar. Forcing them to "out" themselves by telling you they intend to send mail from every one of their addresses is often enough to encourage their voluntary departure. And it's certainly enough to tell you *which* among your thousands of customers you should watch to make sure they're not spammers. For the non-spamming customers, you've emphasized that running a well secured email server is a challenge which takes more than clicking install.exe. You haven't told them they can't, but you've spelled out "be careful" in big, bold letters. > And I'm mostly just complaining about senderbase, because they seem to be the one that really large companies reference. Meh. If you catch them while they're still just annoying SORBS, they'll never make it in to senderbase. Canary. Coal mine. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cscora at apnic.net Fri Apr 6 13:47:53 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Apr 2012 04:47:53 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201204061847.q36Ilrhi030560@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Apr, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 404580 Prefixes after maximum aggregation: 171963 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 196184 Total ASes present in the Internet Routing Table: 40624 Prefixes per ASN: 9.96 Origin-only ASes present in the Internet Routing Table: 32993 Origin ASes announcing only one prefix: 15464 Transit ASes present in the Internet Routing Table: 5440 Transit-only ASes present in the Internet Routing Table: 139 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 32 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 670 Unregistered ASNs in the Routing Table: 296 Number of 32-bit ASNs allocated by the RIRs: 2347 Number of 32-bit ASNs visible in the Routing Table: 2191 Prefixes from 32-bit ASNs in the Routing Table: 5373 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 1411 Number of addresses announced to Internet: 2533675600 Equivalent to 151 /8s, 4 /16s and 210 /24s Percentage of available address space announced: 68.4 Percentage of allocated address space announced: 68.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.1 Total number of prefixes smaller than registry allocations: 171899 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 99031 Total APNIC prefixes after maximum aggregation: 32155 APNIC Deaggregation factor: 3.08 Prefixes being announced from the APNIC address blocks: 95427 Unique aggregates announced from the APNIC address blocks: 39280 APNIC Region origin ASes present in the Internet Routing Table: 4678 APNIC Prefixes per ASN: 20.40 APNIC Region origin ASes announcing only one prefix: 1237 APNIC Region transit ASes present in the Internet Routing Table: 730 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table: 172 Number of APNIC addresses announced to Internet: 642926944 Equivalent to 38 /8s, 82 /16s and 73 /24s Percentage of available APNIC address space announced: 81.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 149419 Total ARIN prefixes after maximum aggregation: 75874 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120748 Unique aggregates announced from the ARIN address blocks: 50004 ARIN Region origin ASes present in the Internet Routing Table: 14948 ARIN Prefixes per ASN: 8.08 ARIN Region origin ASes announcing only one prefix: 5685 ARIN Region transit ASes present in the Internet Routing Table: 1571 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 805818560 Equivalent to 48 /8s, 7 /16s and 208 /24s Percentage of available ARIN address space announced: 64.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 100976 Total RIPE prefixes after maximum aggregation: 53317 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 92174 Unique aggregates announced from the RIPE address blocks: 57205 RIPE Region origin ASes present in the Internet Routing Table: 16359 RIPE Prefixes per ASN: 5.63 RIPE Region origin ASes announcing only one prefix: 7947 RIPE Region transit ASes present in the Internet Routing Table: 2636 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1480 Number of RIPE addresses announced to Internet: 502244616 Equivalent to 29 /8s, 239 /16s and 165 /24s Percentage of available RIPE address space announced: 80.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 40366 Total LACNIC prefixes after maximum aggregation: 8212 LACNIC Deaggregation factor: 4.92 Prefixes being announced from the LACNIC address blocks: 39937 Unique aggregates announced from the LACNIC address blocks: 19771 LACNIC Region origin ASes present in the Internet Routing Table: 1569 LACNIC Prefixes per ASN: 25.45 LACNIC Region origin ASes announcing only one prefix: 431 LACNIC Region transit ASes present in the Internet Routing Table: 295 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 517 Number of LACNIC addresses announced to Internet: 98728072 Equivalent to 5 /8s, 226 /16s and 120 /24s Percentage of available LACNIC address space announced: 65.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8950 Total AfriNIC prefixes after maximum aggregation: 2118 AfriNIC Deaggregation factor: 4.23 Prefixes being announced from the AfriNIC address blocks: 7001 Unique aggregates announced from the AfriNIC address blocks: 2160 AfriNIC Region origin ASes present in the Internet Routing Table: 526 AfriNIC Prefixes per ASN: 13.31 AfriNIC Region origin ASes announcing only one prefix: 164 AfriNIC Region transit ASes present in the Internet Routing Table: 118 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 31531520 Equivalent to 1 /8s, 225 /16s and 34 /24s Percentage of available AfriNIC address space announced: 47.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2476 11110 997 Korea Telecom (KIX) 17974 1782 503 63 PT TELEKOMUNIKASI INDONESIA 7545 1658 301 85 TPG Internet Pty Ltd 4755 1575 386 157 TATA Communications formerly 9583 1237 94 541 Sify Limited 9829 1235 1041 30 BSNL National Internet Backbo 7552 1167 1062 11 Vietel Corporation 4808 1105 2050 316 CNCGROUP IP network: China169 24560 1021 385 167 Bharti Airtel Ltd., Telemedia 18101 947 131 159 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3432 3807 196 bellsouth.net, inc. 7029 3381 990 156 Windstream Communications Inc 18566 2092 383 179 Covad Communications 1785 1893 680 129 PaeTec Communications, Inc. 20115 1637 1561 617 Charter Communications 4323 1598 1044 380 Time Warner Telecom 22773 1568 2910 111 Cox Communications, Inc. 30036 1461 265 742 Mediacom Communications Corp 7018 1279 9774 828 AT&T WorldNet Services 11492 1185 216 365 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1773 544 16 Corbina telecom 2118 1394 97 14 EUnet/RELCOM Autonomous Syste 31148 679 37 9 FreeNet ISP 34984 676 188 173 BILISIM TELEKOM 12479 656 658 57 Uni2 Autonomous System 20940 651 206 500 Akamai Technologies European 6830 639 1943 410 UPC Distribution Services 8551 574 360 81 Bezeq International 3320 532 8442 398 Deutsche Telekom AG 2578 501 33 7 Demos, Moscow, Russia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1794 326 167 TVCABLE BOGOTA 28573 1773 1105 61 NET Servicos de Comunicao S.A 6503 1531 418 64 AVANTEL, S.A. 8151 1481 2998 354 UniNet S.A. de C.V. 7303 1353 827 189 Telecom Argentina Stet-France 26615 847 697 32 Tim Brasil S.A. 27947 687 74 102 Telconet S.A 11172 637 107 74 Servicios Alestra S.A de C.V 22047 584 326 15 VTR PUNTO NET S.A. 3816 570 242 100 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1305 958 13 TEDATA 24863 848 274 35 LINKdotNET AS number 6713 493 649 18 Itissalat Al-MAGHRIB 3741 266 921 224 The Internet Solution 33776 208 12 21 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 24835 178 80 8 RAYA Telecom - Egypt 15706 168 32 6 Sudatel Internet Exchange Aut 16637 165 666 83 MTN Network Solutions 29571 161 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3432 3807 196 bellsouth.net, inc. 7029 3381 990 156 Windstream Communications Inc 4766 2476 11110 997 Korea Telecom (KIX) 18566 2092 383 179 Covad Communications 1785 1893 680 129 PaeTec Communications, Inc. 10620 1794 326 167 TVCABLE BOGOTA 17974 1782 503 63 PT TELEKOMUNIKASI INDONESIA 8402 1773 544 16 Corbina telecom 28573 1773 1105 61 NET Servicos de Comunicao S.A 7545 1658 301 85 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3381 3225 Windstream Communications Inc 18566 2092 1913 Covad Communications 1785 1893 1764 PaeTec Communications, Inc. 8402 1773 1757 Corbina telecom 17974 1782 1719 PT TELEKOMUNIKASI INDONESIA 28573 1773 1712 NET Servicos de Comunicao S.A 10620 1794 1627 TVCABLE BOGOTA 7545 1658 1573 TPG Internet Pty Ltd 4766 2476 1479 Korea Telecom (KIX) 6503 1531 1467 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 54439 UNALLOCATED 8.25.174.0/24 17378 DBS International 54470 UNALLOCATED 8.30.171.0/24 3356 Level 3 Communicatio 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 23.27.0.0/20 54500 EGIHosting 23.27.16.0/20 54500 EGIHosting Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:235 /13:459 /14:832 /15:1485 /16:12182 /17:6284 /18:10499 /19:20616 /20:28820 /21:29800 /22:40437 /23:37608 /24:211529 /25:1182 /26:1430 /27:784 /28:163 /29:59 /30:17 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3040 3381 Windstream Communications Inc 6389 2149 3432 bellsouth.net, inc. 18566 2041 2092 Covad Communications 8402 1750 1773 Corbina telecom 10620 1689 1794 TVCABLE BOGOTA 30036 1401 1461 Mediacom Communications Corp 6503 1290 1531 AVANTEL, S.A. 11492 1148 1185 Cable One 8452 1114 1305 TEDATA 1785 1067 1893 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:532 2:754 4:14 6:3 8:396 12:1999 13:1 14:599 15:12 16:3 17:7 20:8 23:161 24:1768 27:1267 31:966 32:58 33:2 34:2 36:8 37:319 38:786 40:120 41:3114 42:129 44:3 46:1467 47:3 49:350 50:536 52:13 54:7 55:9 56:3 57:31 58:958 59:494 60:280 61:1203 62:973 63:1997 64:4167 65:2260 66:4500 67:2017 68:1152 69:3172 70:908 71:467 72:1833 74:2599 75:494 76:313 77:968 78:1006 79:498 80:1210 81:899 82:662 83:548 84:489 85:1195 86:404 87:908 88:351 89:1635 90:297 91:4683 92:520 93:1375 94:1476 95:1137 96:378 97:318 98:880 99:37 100:6 101:167 103:956 106:74 107:181 108:229 109:1272 110:757 111:900 112:448 113:590 114:621 115:796 116:911 117:721 118:903 119:1209 120:341 121:695 122:1667 123:1104 124:1368 125:1249 128:558 129:190 130:257 131:596 132:173 133:21 134:244 135:62 136:207 137:176 138:354 139:145 140:494 141:243 142:386 143:399 144:512 145:64 146:481 147:272 148:765 149:299 150:159 151:176 152:462 153:172 154:7 155:428 156:216 157:379 158:175 159:522 160:342 161:256 162:347 163:189 164:572 165:388 166:562 167:464 168:820 169:127 170:844 171:126 172:4 173:1735 174:576 175:429 176:459 177:640 178:1317 180:1181 181:73 182:787 183:284 184:451 185:1 186:2118 187:1029 188:1184 189:1792 190:5459 192:5990 193:5599 194:4615 195:3600 196:1291 197:129 198:3630 199:4481 200:5785 201:1902 202:8477 203:8590 204:4339 205:2484 206:2746 207:2783 208:4062 209:3581 210:2749 211:1476 212:1993 213:1907 214:886 215:109 216:5078 217:1521 218:542 219:323 220:1228 221:554 222:322 223:331 End of report From jlewis at lewis.org Fri Apr 6 13:47:55 2012 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 6 Apr 2012 14:47:55 -0400 (EDT) Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: On Fri, 6 Apr 2012, Patrick W. Gilmore wrote: >> Ever wonder why it takes time for DNSbl's to process removals, >> sometimes very long periods? Well, someone's gotta pay for that time >> the removal person does it (and I have yet to see a dime of >> compensation for the time I spend). > > No, they don't. Many DNSBLs use self-service tools. Someone has to > write the tool, but the rest is automated. Total cost is power & space, > which is frequently donated (I have personally donated some myself to > DNSBLs I thought were well run). This depends on the DNSBL, the type of listing, and that DNSBL's policies. Some DNSBLs, some listings, automated removal is possible and appropriate. Sometimes it's not, and a human is needed to make the decision as to whether a delisting request should be granted or refused. Even when there is a path for automated removals via a web form, not everyone will find or use that path. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Fri Apr 6 14:02:49 2012 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 6 Apr 2012 15:02:49 -0400 (EDT) Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> Message-ID: On Thu, 5 Apr 2012, Landon Stewart wrote: > If the purpose of blacklist is to block spam for recipients using that > blacklist then a /32 works. If the purpose of a blacklist is to annoy > providers then a /24 works. The most reputable and useful blacklists IMHO > are Spamhaus and Spamcop - they don't block /24s. Spamhaus sometimes does > if your rwhois shows that a large amount of the /24 is owned by the > offending party but generally they don't. Spamhaus may not default to doing /24 listings for a /32 spam emitter, but they certainly do list /24s or shorter subnets when they feel it's appropriate. They even do "escalations" to corporate mail servers on rare occasions when a provider appears to be complicit with spammers and ignoring their SBLs. The purpose thing is an interesting question though. Is the purpose of DNSBLs simply to help admins avoid accepting spam from spammers or to attempt to prevent spammers from operating on the internet? For most of the DNSBLs I'm familiar with, I'd say they're trying to do both. > Spamhaus encourages companies to resolve all the issues while only > blocking /32s by showing all the listings under your responsibility and > making nice to see that list empty. Pretty simple. Incidentally SORBS > usually blocks /24s and, as far as I know, provides no way for you to > lookup all listings under a providers responsibility (by AS or > otherwise). That's really either not true or an oversimplification. Spamhaus blocks shorter than /32 pretty frequently. You could maybe argue that Spamhaus works harder to avoid innocent collateral damage. Having not used SORBS for many years, I couldn't say if that's true or not. The vast majority of my recent years interactions with SORBS have been trying to get inappropriately listed IPs removed from their DUHL. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From me at anuragbhatia.com Fri Apr 6 14:11:47 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 7 Apr 2012 00:41:47 +0530 Subject: Question about peering Message-ID: Hello everyone I am curious to know how small ISPs plan peering with other interested parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say A and C both have open peering policy and assuming the exist in same exchange or nearby. Now at this point is there is any "minimum bandwidth" considerations? Say if A and C have 1Gbps + of flowing traffic - very likely peering would be good idea to save transit costs to B. But if A and C have very low levels - does it still makes sense? Does peering costs anything if ISPs are in same exchange? Does at low traffic level it makes more sense to keep on reaching other ISPs via big transit provider? Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From mysidia at gmail.com Fri Apr 6 15:24:24 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 6 Apr 2012 15:24:24 -0500 Subject: DNS noise In-Reply-To: <4CCA6692-AD36-4660-86DA-44F6D19D4BB6@virtualized.org> References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> <4F7F3039.3000604@foobar.org> <4CCA6692-AD36-4660-86DA-44F6D19D4BB6@virtualized.org> Message-ID: On Fri, Apr 6, 2012 at 1:24 PM, David Conrad wrote: [snip] > I suspect the root server operators might not like this idea very much. If it solves other problems adequately, they might eventually just have to learn to like it. [snip] > Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38 No. Implementation of BCP38 does have value, but the existence of BCP38 does not solve DNS application problems; Just looking towards BCP38 as a solution is like attempting to treat a disease with a theoretically effective treatment that you can't possibly get enough of to cure the disease due to limited supplies -- but ignoring mitigation of the symptoms, despite there being more readily available options for symptom mitigation. It's similar to the idea of promoting SPF as a means of stopping e-mail forgery, and saying RBLs just treat the symptoms -- stop using RBLs, and get everyone to implement SPF. The underlying problem is that "BCP38" is not really a "best common practice", despite the name of the series. It's really a "Best Uncommon Practice that really ought to be more common", but we can't control operators and force them to make it more common. Lots of networks don't and will not ever implement BCP38; BCP38 is not being more widely implemented, and there's no obvious action that will force it to change. -- -JH From joe at oregon.uoregon.edu Fri Apr 6 14:27:57 2012 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Fri, 6 Apr 2012 12:27:57 -0700 (PDT) Subject: DNS noise Message-ID: <12040612275707_443B@oregon.uoregon.edu> Jimmy commented: #The underlying problem is that "BCP38" is not really a "best common practice", #despite the name of the series. # #It's really a "Best Uncommon Practice that really ought to be more common", #but we can't control operators and force them to make it more common. # #Lots of networks don't and will not ever implement BCP38; BCP38 is not being #more widely implemented, and there's no obvious action that will #force it to change. Check out the MIT Spoofer Project (http://spoofer.csail.mit.edu/summary.php) BCP38 anti-spoofing filtering is more common than you might think (on the order of 80% of {netblocks, IPs, ASNs} filter as of October 2011) Regards, Joe From drc at virtualized.org Fri Apr 6 15:44:00 2012 From: drc at virtualized.org (David Conrad) Date: Fri, 6 Apr 2012 13:44:00 -0700 Subject: DNS noise In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> <4F7F3039.3000604@foobar.org> <4CCA6692-AD36-4660-86DA-44F6D19D4BB6@virtualized.org> Message-ID: Jimmy, On Apr 6, 2012, at 1:24 PM, Jimmy Hess wrote: > On Fri, Apr 6, 2012 at 1:24 PM, David Conrad wrote: >> I suspect the root server operators might not like this idea very much. > If it solves other problems adequately, they might eventually just have to learn to like it. I was, of course, using the root servers as a proxy for pretty much any DNS server operator. The root server operators aren't unique in the requirement to respond to an unbounded number of queries. >> Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38 > No. Implementation of BCP38 does have value, but the existence of > BCP38 does not solve DNS application problems; You seemed to have missed the part where it isn't just a DNS problem. Your solution would appear to be to replace every datagram-based query/response protocol such as ICMP and SNMP. I personally think it is more feasible for ISPs to implement BCP38 than it is for the entire Internet to move away from using datagram-based query/response protocols, but that's probably just me. > but ignoring mitigation of the symptoms, > despite there being more readily available options for symptom mitigation. Sorry, which more readily available options are those? I don't think forcing a 3-way exchange for stuff like PMTUD is 'readily available'. > The underlying problem is that "BCP38" is not really a "best common practice", > despite the name of the series. The name of the series is "Best Current Practice". > Lots of networks don't and will not ever implement BCP38; It is true that lots of networks don't implement BCP38. Whether or not they will ever is more debatable. I suspect that we're about one major spoofing-based infrastructure attack away from proposed legislation that would force folks to implement something like BCP38, but I may be a bit more pessimistic than most. However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days. Regards, -drc From jared at puck.nether.net Fri Apr 6 15:49:48 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 6 Apr 2012 16:49:48 -0400 Subject: DNS noise In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C287CA17C7F@EX-MB-1.corp.atlasnetworks.us> <4F7F3039.3000604@foobar.org> <4CCA6692-AD36-4660-86DA-44F6D19D4BB6@virtualized.org> Message-ID: <1F0C9578-A9F7-4CFE-98D4-42CA9A0E252E@puck.nether.net> On Apr 6, 2012, at 4:44 PM, David Conrad wrote: > However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days. Easy: 1) hardare support varies 2) implementing bcp-38 drives customer support costs up in cases where the customer is doing something weird "e.g.: using toms isdn-dial backup to source return packets". 3) customers can't be trusted to give a complete list of valid source addresses 4) asymmetric or highly kinky routing exists more than one would like to admit There are cases where it's fairly inexcusable: Fixed broadband providers (static IP address or dynamic to a customer port/pool) CGN exit points Static routed customers (They shouldn't be doing asymmetric routing) The real reason imho.. is #2 above. desire to keep unnecessary support calls from your call center. - Jared From rbf+nanog at panix.com Fri Apr 6 16:33:05 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Fri, 6 Apr 2012 16:33:05 -0500 Subject: SORBS?! In-Reply-To: <4F7DDA3A.4080406@foobar.org> References: <4F7CA69F.9090206@b2b2c.ca> <4F7DDA3A.4080406@foobar.org> Message-ID: <20120406213305.GA4832@panix.com> On Thu, Apr 05, 2012 at 06:45:30PM +0100, Nick Hilliard wrote: > On 05/04/2012 17:48, goemon at anime.net wrote: > > But they will care about a /24. > > I'm curious as to why they would want to stop at /24. If you're going to > take the shotgun approach, why not blacklist the entire ASN? It's a balancing act. Too little collateral damage and the provider hosting the spammer isn't motivated to act. Too much collateral damage, and no one uses your blacklist because using it generates too many user complaints, and then your list doesn't motivate anyone to do anything because there's no real downside to being on the list. Just the right amount of collateral damage, and your list gets widely used, and causes enough pain on the other of the /24 that they clean things up. I'm not arguing for or against any particular amount of collateral damage. Just commenting on the effects of varying amounts of collateral damage. -- Brett From bonomi at mail.r-bonomi.com Fri Apr 6 16:49:17 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 6 Apr 2012 16:49:17 -0500 (CDT) Subject: SORBS?! In-Reply-To: Message-ID: <201204062149.q36LnHqE056801@mail.r-bonomi.com> Jimmy Hess wrote: > > On Fri, Apr 6, 2012 at 8:48 AM, wrote: > > If it was industry-wide standard practice that just notifying a provider > > resulted in something being done, we'd not need things like Senderbase, > > which is after all basically a list of people who don't take action > > when notified... > > > [snip] > Pot calling the kettle black. Before we talk about industry-wide > practice about the providers "doing something". We should talk about > industry-wide practice for "Black lists" doing something to correct > entries, instead of just building up indiscriminate or irresponsibly > maintained lists of networks or "scores" of networks that were > targetted by a spammer at one time in the past. Sorry, but blocklists _came_into_existance_ ONLY because of large numbers of providers *ignoring* the problems their networks were causing the rest of the world. The very existance of 'widely used' blocklists is a damning indictment of the entire services provider industry. _Everybody_, including the major blocklist operators, would prefer that blocklists were _not_ needed -- that all providers would simply 'do the right thing', and insure that their users did =not= abuse other people's systems. Were that pipe-dream to come to pass, the major blocklists would *happily* shut down. They are all 'money sinks', operating at a loss, 'for the good of the community as a whole'. Before blocklists. 'policing your own network' was a pure expense item with no return. _Not_ policing one's own users *added* to profitability. There was no 'business incentive' to be a "good neighbor". With the advent of blocklists, providers have an 'economic self interest' justification in remaining out of the major/widely used ones. It is still an expense item, but "not doing anything" costs _more_ in 'lost revenues'. It is a sad comment on the state of affairs that _all_ the major providers have repeatedly demonstrated they simply "cannot be trusted to 'do the right thing'" *without* a loaded gun held to their heads -- but that *is* the reality of today's marketplace. Today, for any of the major spam-based blocklists, a single entry consisting of more than a single address is indiicative of a _failure_ of a provider's self-policing. It is the height of hubris for a provider to 'demand' (or even 'expect') prompt/immediate response from a blocklist, *when* the provider 'demonstrably' couldn't be bothered to act that way themselves. (What's 'sauce for the goose' _is_ sauce for the gander. :) IF the provider had been actively self-policing, the blocklist entry would not have been escalalated to larger than the single offending address. Yes, it would be "nice" if everybody responded promptly; but, in the real world, that simply doesn't happen -- on either side of the fence. I once got an ack about a spam complaint *over*five*months* after sending it. (For 'some strange reason', that provider is no longer in business. Thank goodness! > It's just as bad for a blacklist operator to not respond and "do > something" for a network operator legitimately trying to resolve spam > problems with their network and clear the listing as it is for a > network abuse contact to not respond to a network operator. This is provably not true. There is no recourse/remedy for an unresponsive network operator. The 'network abuse' ccontinues to flow, _unabated_, from that network. A blocklist, on the other hand, tends to be self-regulating. If it is not responsive to changing conitions, especially the 'cleaning' of formerly 'bad reputation' addresses/blocks, it generates an 'unacceptably high' number -- as determined by it's USERS, not the senders -- of 'false positive' evaluations, *wherepon* increasing numbers of users =stop= using that service. Resulting in an automatic _lessening_ of the impact of being listed on that blocklist. See the APEWS list for a 'textbook' demonstration of this self-regulation in action. > We should talk about industry-wide practices for how providers should > be notified, what providers are actually supposed to do to "authenticate > reports", because > sometimes the report/notification itself is > malicious or false abusive attempt to harass an innocent email user, > and what exactly providers are actually expected to do with certain kinds > of notification. > > The informal standard of "just call or send an e-mail to an abuse > contact" is poorly specified. The informal standard of "the abuse > contact should investigate and take immediate action" is poorly > specified. > > Some of these things that are not specified by RFC should be specified > by RFC as best practice. There should be abuse notification and response > notification mechanisms other than free form e-mail. It would appear that you are not familiar with RFC 5965. From cidr-report at potaroo.net Fri Apr 6 17:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Apr 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201204062200.q36M01ZP022333@wattle.apnic.net> BGP Update Report Interval: 29-Mar-12 -to- 05-Apr-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 67283 3.7% 33.7 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS10201 52074 2.9% 197.2 -- DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless 3 - AS14374 48402 2.7% 1210.0 -- AGRI-VALLEY - Agri-Valley Services Inc. 4 - AS9829 40535 2.2% 50.7 -- BSNL-NIB National Internet Backbone 5 - AS7843 34206 1.9% 1266.9 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 6 - AS12479 28304 1.6% 43.1 -- UNI2-AS France Telecom Espana SA 7 - AS7029 23655 1.3% 6.7 -- WINDSTREAM - Windstream Communications Inc 8 - AS7552 23336 1.3% 21.4 -- VIETEL-AS-AP Vietel Corporation 9 - AS32528 23234 1.3% 3319.1 -- ABBOTT Abbot Labs 10 - AS26615 21440 1.2% 24.0 -- Tim Celular S.A. 11 - AS2118 19486 1.1% 13.6 -- RELCOM-AS OOO "NPO Relcom" 12 - AS5800 17725 1.0% 57.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS24560 17518 1.0% 39.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 14 - AS5976 16773 0.9% 148.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS28683 16207 0.9% 274.7 -- BENINTELECOM 16 - AS28573 12874 0.7% 12.1 -- NET Servicos de Comunicao S.A. 17 - AS45899 9521 0.5% 29.1 -- VNPT-AS-VN VNPT Corp 18 - AS594 9181 0.5% 65.1 -- LVLT594-598 - Level 3 Communications, Inc. 19 - AS25620 8895 0.5% 57.4 -- COTAS LTDA. 20 - AS8452 8678 0.5% 8.2 -- TE-AS TE-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3563 3832 0.2% 3832.0 -- PILOT-ASN - Pilot Network Services, Inc 2 - AS17408 3365 0.2% 3365.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 3 - AS32528 23234 1.3% 3319.1 -- ABBOTT Abbot Labs 4 - AS7843 34206 1.9% 1266.9 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 5 - AS14374 48402 2.7% 1210.0 -- AGRI-VALLEY - Agri-Valley Services Inc. 6 - AS55665 998 0.1% 998.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 7 - AS22733 910 0.1% 910.0 -- 8 - AS11553 888 0.1% 888.0 -- MANNATECH-AS MANNATECH 9 - AS57767 871 0.1% 871.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network 10 - AS44798 808 0.0% 808.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 11 - AS38364 1220 0.1% 610.0 -- CNNIC-LTEL-AP LONGTEL NETWORKS & TECHNOLOGIES LTD. 12 - AS38857 1121 0.1% 560.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 13 - AS15825 2193 0.1% 548.2 -- UNSPECIFIED 14 - AS34369 1563 0.1% 521.0 -- SHATELIX SHATEL Internet Exchange 15 - AS27169 490 0.0% 490.0 -- TRIDENTAS - Trident Systems, Inc. 16 - AS52366 952 0.1% 476.0 -- Lunamen S.A. 17 - AS25600 454 0.0% 454.0 -- MATRIKON-1 - Matrikon Inc. 18 - AS37169 887 0.1% 443.5 -- SOLSI 19 - AS33377 866 0.1% 433.0 -- FHLBC - Federal Home Loan Bank of Chicago 20 - AS38455 830 0.1% 415.0 -- IPC-NETWORK-SERVICES-AS-AP IPC Network Services TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 11607 0.6% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 11607 0.6% AS32528 -- ABBOTT Abbot Labs 3 - 204.234.0.0/17 11054 0.6% AS7029 -- WINDSTREAM - Windstream Communications Inc 4 - 62.36.252.0/22 8750 0.5% AS12479 -- UNI2-AS France Telecom Espana SA 5 - 205.107.121.0/24 7545 0.4% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - 122.161.0.0/16 6862 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 62.36.249.0/24 6450 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 62.36.241.0/24 5921 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.210.0/24 5674 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 205.106.248.0/24 5466 0.3% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - 23.54.176.0/22 5267 0.3% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 12 - 194.63.9.0/24 5145 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 184.50.208.0/20 4913 0.2% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 14 - 205.211.136.0/24 4864 0.2% AS6407 -- PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 15 - 173.222.100.0/22 4828 0.2% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 16 - 184.28.206.0/23 4826 0.2% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 17 - 23.54.188.0/22 4718 0.2% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 18 - 23.54.184.0/22 4718 0.2% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 19 - 23.54.180.0/22 4717 0.2% AS7843 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 20 - 182.64.0.0/16 4495 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 6 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Apr 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201204062200.q36M006f022328@wattle.apnic.net> This report has been generated at Fri Apr 6 21:12:44 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 30-03-12 406585 236412 31-03-12 406736 236071 01-04-12 406429 236409 02-04-12 406722 236897 03-04-12 406676 237014 04-04-12 406639 237399 05-04-12 406957 237397 06-04-12 407232 237558 AS Summary 40739 Number of ASes in routing system 17045 Number of ASes announcing only one prefix 3432 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 111508768 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 06Apr12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 407551 237560 169991 41.7% All ASes AS6389 3432 199 3233 94.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3417 1822 1595 46.7% WINDSTREAM - Windstream Communications Inc AS4766 2480 1021 1459 58.8% KIXS-AS-KR Korea Telecom AS22773 1568 120 1448 92.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2092 705 1387 66.3% COVAD - Covad Communications Co. AS28573 1773 493 1280 72.2% NET Servicos de Comunicao S.A. AS2118 1394 141 1253 89.9% RELCOM-AS OOO "NPO Relcom" AS4323 1599 382 1217 76.1% TWTC - tw telecom holdings, inc. AS4755 1574 393 1181 75.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1896 807 1089 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1795 825 970 54.0% Telmex Colombia S.A. AS7552 1172 219 953 81.3% VIETEL-AS-AP Vietel Corporation AS8402 1720 800 920 53.5% CORBINA-AS OJSC "Vimpelcom" AS7303 1353 439 914 67.6% Telecom Argentina S.A. AS26615 887 32 855 96.4% Tim Celular S.A. AS8151 1483 667 816 55.0% Uninet S.A. de C.V. AS18101 948 163 785 82.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1105 347 758 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS30036 1461 771 690 47.2% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17974 1782 1099 683 38.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS9394 892 210 682 76.5% CRNET CHINA RAILWAY Internet(CRNET) AS3356 1100 462 638 58.0% LEVEL3 Level 3 Communications AS17676 687 75 612 89.1% GIGAINFRA Softbank BB Corp. AS19262 997 402 595 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1021 433 588 57.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22561 996 416 580 58.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 1012 440 572 56.5% GBLX Global Crossing Ltd. AS4804 655 95 560 85.5% MPX-AS Microplex PTY LTD AS22047 584 31 553 94.7% VTR BANDA ANCHA S.A. AS4780 808 257 551 68.2% SEEDNET Digital United Inc. Total 43683 14266 29417 67.3% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.32.0/20 AS18255 BRISBANE-AP Brisbane City Council 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jeroen at mompl.net Fri Apr 6 20:13:12 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 06 Apr 2012 18:13:12 -0700 Subject: SORBS?! In-Reply-To: <4F7F0DA9.2010607@2mbit.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> Message-ID: <4F7F94A8.1020000@mompl.net> Brielle Bruns wrote: > Unfortunately, the apathy of providers, backbones, and network operators > in general have created an environment that the almighty buck rules > everything. I totally agree with pretty much everything in this email. I also agree that blocking whole /24 or bigger when spam has been detected to come from such a block is more often than not a necessity. It's very unlikely to see 1 abuser in between an otherwise perfectly behaving network neighbourhood. Greetings, Jeroen -- Earthquake Magnitude: 5.5 Date: Friday, April 6, 2012 19:24:11 UTC Location: Kepulauan Mentawai region, Indonesia Latitude: -3.3944; Longitude: 100.4205 Depth: 1.00 km From ops.lists at gmail.com Fri Apr 6 20:30:52 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 7 Apr 2012 07:00:52 +0530 Subject: The day SORBS goes away ... In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: err, i dont know but yahoo hasnt yet acquired this random webhost whose abuse you're trying to mail On Friday, April 6, 2012, goemon at anime.net wrote: > The day SORBS goes away is the day abuse at yahoo.com starts functioning > properly and yahoo starts booting spammers. > > The day SORBS goes away is the day BS like this stops happening: > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 rejected due to spam content) > > -Dan > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Fri Apr 6 20:45:16 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 7 Apr 2012 07:15:16 +0530 Subject: Question about peering In-Reply-To: References: Message-ID: what does it cost you to peer, versus what does it cost you to not peer? if you are at the same ix the costs of peering are very low indeed On Saturday, April 7, 2012, Anurag Bhatia wrote: > Hello everyone > > > > I am curious to know how small ISPs plan peering with other interested > parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say > A and C both have open peering policy and assuming the exist in same > exchange or nearby. Now at this point is there is any "minimum bandwidth" > considerations? Say if A and C have 1Gbps + of flowing traffic - very > likely peering would be good idea to save transit costs to B. But if A and > C have very low levels - does it still makes sense? Does peering costs > anything if ISPs are in same exchange? Does at low traffic level it makes > more sense to keep on reaching other ISPs via big transit provider? > > > > Thanks. > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > -- Suresh Ramasubramanian (ops.lists at gmail.com) From mysidia at gmail.com Fri Apr 6 20:48:44 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 6 Apr 2012 20:48:44 -0500 Subject: SORBS?! In-Reply-To: <4F7F94A8.1020000@mompl.net> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F94A8.1020000@mompl.net> Message-ID: On Fri, Apr 6, 2012 at 8:13 PM, Jeroen van Aart wrote: > Brielle Bruns wrote: > to come from such a block is more often than not a necessity. It's very > unlikely to see 1 abuser in between an otherwise perfectly behaving network > neighbourhood. That's kind of vague to say it's "unlikely to see 1 abuser". What is the probability that more IPs in the same /24 are likely to harbor abusers, given that you have received abuse from one IP? And how have you discovered this? ( What is the criteria used to determine that it is unlikely, and what is your source of the information?) Are you assuming that if you've seen the abuse, that you probably weren't the first victim, that the ISP has probably already been notified by someone else, that they have likely had a reasonable amount of time to put a stop to the abuse, and that they failed to do so? There is the one good case where a single abuser has a dynamic IP address; but it's not a safe assumption that they will live in the same /24 next time the abuser dials in. So not only does listing an entire /24 list innocent users' IP addresses, it also does not necessarily effectively list the one abuser. -- -JH From tknchris at gmail.com Fri Apr 6 20:55:17 2012 From: tknchris at gmail.com (chris) Date: Fri, 6 Apr 2012 21:55:17 -0400 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F94A8.1020000@mompl.net> Message-ID: i dont think anyone would miss sorbs if it was gone, dare i say it not even a single person On Fri, Apr 6, 2012 at 9:48 PM, Jimmy Hess wrote: > On Fri, Apr 6, 2012 at 8:13 PM, Jeroen van Aart wrote: > > Brielle Bruns wrote: > > to come from such a block is more often than not a necessity. It's very > > unlikely to see 1 abuser in between an otherwise perfectly behaving > network > > neighbourhood. > > That's kind of vague to say it's "unlikely to see 1 abuser". What is > the probability that > more IPs in the same /24 are likely to harbor abusers, given that you > have > received abuse from one IP? > > And how have you discovered this? > ( What is the criteria used to determine that it is unlikely, and what > is your source of the information?) > > Are you assuming that if you've seen the abuse, that you probably > weren't the first victim, > that the ISP has probably already been notified by someone else, > that they have likely had a > reasonable amount of time to put a stop to the abuse, and that they > failed to do so? > > > There is the one good case where a single abuser has a dynamic IP address; > but it's not a safe assumption that they will live in the same /24 > next time the abuser dials in. > > So not only does listing an entire /24 list innocent users' IP > addresses, > it also does not necessarily effectively list the one abuser. > > -- > -JH > > From Valdis.Kletnieks at vt.edu Fri Apr 6 20:55:17 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 06 Apr 2012 21:55:17 -0400 Subject: The day SORBS goes away ... In-Reply-To: Your message of "Sat, 07 Apr 2012 07:00:52 +0530." References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: <60973.1333763717@turing-police.cc.vt.edu> On Sat, 07 Apr 2012 07:00:52 +0530, Suresh Ramasubramanian said: > err, i dont know but yahoo hasnt yet acquired this random webhost whose > abuse you're trying to mail > > ----- The following addresses had permanent fatal errors ----- > > > > (reason: 554 rejected due to spam content) Right - that one is doing stupid stuff like filtering out spam reports sent to abuse@ because they contain spam all by itself, without Yahoo's assistance. Yahoo is only a hegemony among spam havens, not a monopoly. There's still freelance havens out there, and they'll go away when SORBS does. I'm not so sanguine about Yahoo's chances of lasting till then though... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From goemon at anime.net Fri Apr 6 21:01:40 2012 From: goemon at anime.net (goemon at anime.net) Date: Fri, 6 Apr 2012 19:01:40 -0700 (PDT) Subject: The day SORBS goes away ... In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: the yahoo item was a point all its own, unrelated to iweb's idiocy. yahoo no longer care to receive abuse reports from anyone at all. -Dan On Sat, 7 Apr 2012, Suresh Ramasubramanian wrote: > err, i dont know but yahoo hasnt yet acquired this random webhost whose > abuse you're trying to mail > > On Friday, April 6, 2012, goemon at anime.net wrote: > >> The day SORBS goes away is the day abuse at yahoo.com starts functioning >> properly and yahoo starts booting spammers. >> >> The day SORBS goes away is the day BS like this stops happening: >> >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 554 rejected due to spam content) >> >> -Dan >> >> > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From Valdis.Kletnieks at vt.edu Fri Apr 6 22:02:18 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 06 Apr 2012 23:02:18 -0400 Subject: SORBS?! In-Reply-To: Your message of "Fri, 06 Apr 2012 20:48:44 -0500." References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F94A8.1020000@mompl.net> Message-ID: <63390.1333767738@turing-police.cc.vt.edu> On Fri, 06 Apr 2012 20:48:44 -0500, Jimmy Hess said: > That's kind of vague to say it's "unlikely to see 1 abuser". What is > the probability that > more IPs in the same /24 are likely to harbor abusers, given that you have > received abuse from one IP? It's similar to pirhanas or cockroaches - they can't be found everywhere, but if you spot one in a location, there's a near certainty that there's plent more in the area. Or if you don't like that, you can run a simple Monte Carlo simulation. Assume 256 customer slots, and that initially, there is a 3% chance that the next customer to arrive is evil. Also add a feedback - each time you terminate an evil customer in less than the average arrival time, the chance the next customer is evil is cut by 10% of the current value. Each time an evil customer is allowed to last 3 times the average arrival time, the chance of an evil customer goes up 10%. Simulate for various termination times for evil customers. Are there any steady-state solutions where the *average* number of evil users is one? Or does it decay down towards zero or upwards towards a high number? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ops.lists at gmail.com Fri Apr 6 23:30:24 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 7 Apr 2012 10:00:24 +0530 Subject: The day SORBS goes away ... In-Reply-To: <60973.1333763717@turing-police.cc.vt.edu> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <60973.1333763717@turing-police.cc.vt.edu> Message-ID: On Sat, Apr 7, 2012 at 7:25 AM, wrote: > Yahoo is only a hegemony among spam havens, not a monopoly. ?There's still > freelance havens out there, and they'll go away when SORBS does. Sorbs did have a decent set of traps - and did catch a lot of spam. The problem was atrociously poor maintenance - stale entries, entries that'd reappear due to db issues, people skills of the volunteers handling the queue .. I'd have thought there'd be some improvement with their being acquired. Got to see. -- Suresh Ramasubramanian (ops.lists at gmail.com) From blakjak at blakjak.net Sat Apr 7 01:42:23 2012 From: blakjak at blakjak.net (Mark Foster) Date: Sat, 07 Apr 2012 18:42:23 +1200 Subject: SORBS?! In-Reply-To: <4F7F23BF.3010800@tiggee.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F1381.7060408@mtcc.com> <4F7F16FF.80007@2mbit.com> <4F7F1B40.3030005@mtcc.com> <4F7F23BF.3010800@tiggee.com> Message-ID: <4F7FE1CF.5090908@blakjak.net> On 07/04/12 05:11, David Miller wrote: > > > RBLs don't block emails. Operators of mail servers who use RBLs block > emails (in part) based on information from RBLs. If only one could convince end-users of this fact. More often than not, end-user simply sees the company that they pay to provide them with email service, unable to provide it. > > Noone has a "right" to send email to anyone else. Email is a > cooperative agreement between sender and receiver. The receiver agrees > to accept the email, but at any time and for any reason the receiver can > stop agreeing to accept emails from a sender. It is completely legal to > decide not to accept (i.e. block) emails from a sender. Absolutely true. Of course, for the vast majority of end-users, they're simply expecting to be able to exchange email with anyone that has an email address. There's no connection between the end user, their local mail service providers administrators, and the decisions they make about who they'll exchange email with. Nevermind trying to make connections between mail service providers... > > RBLs are not beholden to senders. RBLs are beholden to the receivers > who use their RBL to preserve the quality of the RBL. RBLs are a > meritocracy. If an RBL either lists too many valid senders or does not > list enough bad senders, then receivers will notice and stop using the > RBL on their servers. > Or receivers will be oblivious, and simply not care. (They don't know what they're not receiving). Consider an MSP with say, 1 Million mailboxes. What proportion of those customers are going to need to be affected by a poor RBL-based decision, and what proportion of those are going to be motivated to complain, and what proportion of those are going to get the attention of the right people, and what proportion of those will count for enough that the relevant beancounters see fit to change their RBL usage? Whilst i'm sure there's some players out there bucking the trend, the reality is that the senders MSP wind up carrying a lot of the cost; they have to find an out-of-band method of engaging the receiving MSP, advising them of the predicament, and justifying some sort of exception; they also obviously have to be seen to try to get off the RBL (and we've seen how hard SORBS, notably, make this) and the receiving ISP can fall back on the 'well everyone else is fine, so the vast majority of our expected inbound email is fine, why should we care about you, and change our behavior because of it?' .... Sending MSP then has to try to explain the reality to their customer, and risk losing business because their competitor isn't (right now) having the same problems... Bottom of my rambly-line is that as a major point of issue with your post; you're posting the position of the Network or Mail Service Operator as it 'should' be, but not indeed how it actually is, in practise. (And FWIW I agree with the poster who pointed out that RBL's would be unnecessary if network operators took responsibility for the behavior of their networks (ala their customers). The small players are usually pretty damn good. It seems that the bigger you get, the less you care about issues that affect a smaller proportion of your scale. Which probably explains the attitude that several of the big players take around rejecting email due to obscure reasons... Mark. From jamie at macisa.ac Sat Apr 7 02:32:17 2012 From: jamie at macisa.ac (Jamie MacIsaac) Date: Sat, 7 Apr 2012 08:32:17 +0100 Subject: Question about peering In-Reply-To: References: Message-ID: On 6 Apr 2012, at 20:11, Anurag Bhatia wrote: > I am curious to know how small ISPs plan peering with other interested > parties. Hi, It's not the precise answer you're probably after, but I found the "Internet Peering Playbook" (http://drpeering.net/core/buyTheBook.html) to be full of examples of the sort of question you've asked. Can't remember where I found out about it (so apologies if this isn't news to you), but it did answer _many_ of the questions I had. Cheers, jmi -- http://jamie.macisa.ac mailto jamie at macisa.ac mobile +44 7715 707078 gnupg 1024D/A9E61DBE From randy at psg.com Sat Apr 7 05:38:13 2012 From: randy at psg.com (Randy Bush) Date: Sat, 07 Apr 2012 19:38:13 +0900 Subject: SORBS?! In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <4F7F0DA9.2010607@2mbit.com> <4F7F94A8.1020000@mompl.net> Message-ID: > i dont think anyone would miss sorbs if it was gone, dare i say it not > even a single person while i would not dispute what you think you think, i think you are thinking quite incorrectly randy From rsk at gsp.org Sat Apr 7 06:59:42 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 7 Apr 2012 07:59:42 -0400 Subject: The day SORBS goes away ... In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> Message-ID: <20120407115942.GA3136@gsp.org> Yahoo's "personnel" have long since demonstrated that (a) they couldn't possibly care less about the spam, phishing, and other forms of abuse that they're emanating, supporting or hosting on a systemic and chronic basis (b) they are incapable of recognizing their own users, hosts, and networks even when same are explicitly pointed out to them (c) under no circumstances will they take any prompt or effective action -- they will, however, repeatedly lie about it and/or pass on complainers' personal information to the abusers so that they can retaliate. ---rsk From hank at efes.iucc.ac.il Sat Apr 7 12:33:10 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 7 Apr 2012 20:33:10 +0300 (IDT) Subject: The day SORBS goes away ... In-Reply-To: <20120407115942.GA3136@gsp.org> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> Message-ID: On Sat, 7 Apr 2012, Rich Kulawiec wrote: I recently had a similar run-in with another ISP unrelated to Yahoo. It involved a phishing site on one of their customers. Countless emails to their abuse@ email went unanswered. Then one day I bumped into their VP who was trying to sell me something. I asked him about why they apppear so high on Ironport Senderbase with a huge spam pool as well as phishing sites that are not taken down. His answer, which might mirror Yahoo's (or not), was that at a corporate level they decided to only handle issues like this via a court order. They did not think it appropriate to interfere with their customers data in any sort of way unless a court order told them to make it stop. Clearly, this is idiotic reasoning and only when others start blocking their IP ranges and DNS servers will they ever wake up. But when the ISP is big enough, they think no one will block them and if they do it will just be small cases and nothing massive that would make them into a 2nd league ISP. This therefore becomes a cost savings area since you no longer need any abuse staff to handle your customers. You just ignore it all. -Hank > > Yahoo's "personnel" have long since demonstrated that (a) they couldn't > possibly care less about the spam, phishing, and other forms of abuse > that they're emanating, supporting or hosting on a systemic and chronic > basis (b) they are incapable of recognizing their own users, hosts, > and networks even when same are explicitly pointed out to them (c) under > no circumstances will they take any prompt or effective action -- they > will, however, repeatedly lie about it and/or pass on complainers' personal > information to the abusers so that they can retaliate. > > ---rsk > From mpalmer at hezmatt.org Sat Apr 7 16:19:03 2012 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 8 Apr 2012 07:19:03 +1000 Subject: The day SORBS goes away ... In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> Message-ID: <20120407211903.GZ2056@hezmatt.org> On Sat, Apr 07, 2012 at 08:33:10PM +0300, Hank Nussbacher wrote: > On Sat, 7 Apr 2012, Rich Kulawiec wrote: > Clearly, this is idiotic reasoning and only when others start > blocking their IP ranges and DNS servers will they ever wake up. But how idiotic is it? Do you have all Yahoo IP space and domains blocked on your mail server? How many mailboxes does that cover? What percentage of Yahoo's daily e-mail volume are you blocking, and how much of a rat's arse do you think Yahoo cares? I think you can see where I'm going with this. It's only "idiotic reasoning" if it doesn't work, and so far as I can see, it's working just great -- there are effectively service providers who are "too big to fai^Wblock", and so they get away with things that everyone else would only dream of. They do care about the "almighty buck" more than the 'net, but I'd say that almost all of us do, because almost none of us are willing to take the plunge and block Yahoo and other giant providers of spam and other abuse. (For the record, I'm in this camp, too -- I'm not willing to lose my job -- my almighty buck -- for taking the step of blocking Yahoo, so I'm not any sort of trailblazer along this path). To anyone out there who is blocking Yahoo, and is big enough for them to take notice, bravo to you! Speak up, tell the world what you're doing, and it might give the rest of us the courage and the precedent to do the same. - Matt -- A friend is someone you can call to help you move. A best friend is someone you can call to help you move a body. From rs at seastrom.com Sat Apr 7 17:16:30 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 07 Apr 2012 18:16:30 -0400 Subject: Question about peering In-Reply-To: (Suresh Ramasubramanian's message of "Sat, 7 Apr 2012 07:15:16 +0530") References: Message-ID: <86wr5r4281.fsf@seastrom.com> Actually, Suresh, I disagree. It depends on the facility/country/continent, the cost of joining the local IX fabric at a reasonable bandwidth, your cost model, and your transit costs. In short, it's not 1999 anymore, and peering is not automatically the right answer from a purely fiscal perspective (though it may be from a technical perspective; see below). At certain IXes that have a perfect storm of high priced ports and a good assortment of carriers with sufficiently high quality service and aggressive pricing, a good negotiator can fairly easily find himself in a position where the actual cost per megabit of traffic moved on peered bandwidth exceeds the cost of traffic moved on transit _by an order of magnitude_. That's without even factoring in the (low) maintenance cost of having a bunch of BGP sessions around or upgraded routers or whatever. Sometimes making the AS path as short as possible makes a lot of sense (e.g. when trying to get an anycast network to do the right thing), but assumptions that peering results in lower costs are less true every day. -r Suresh Ramasubramanian writes: > what does it cost you to peer, versus what does it cost you to not peer? > > if you are at the same ix the costs of peering are very low indeed > > On Saturday, April 7, 2012, Anurag Bhatia wrote: > >> Hello everyone >> >> >> >> I am curious to know how small ISPs plan peering with other interested >> parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say >> A and C both have open peering policy and assuming the exist in same >> exchange or nearby. Now at this point is there is any "minimum bandwidth" >> considerations? Say if A and C have 1Gbps + of flowing traffic - very >> likely peering would be good idea to save transit costs to B. But if A and >> C have very low levels - does it still makes sense? Does peering costs >> anything if ISPs are in same exchange? Does at low traffic level it makes >> more sense to keep on reaching other ISPs via big transit provider? >> >> >> >> Thanks. >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected >> network! >> >> Twitter: @anurag_bhatia >> Linkedin: http://linkedin.anuragbhatia.com >> > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From lsc at prgmr.com Sat Apr 7 17:35:15 2012 From: lsc at prgmr.com (Luke S. Crawford) Date: Sat, 7 Apr 2012 18:35:15 -0400 Subject: Question about peering In-Reply-To: <86wr5r4281.fsf@seastrom.com> References: <86wr5r4281.fsf@seastrom.com> Message-ID: <20120407223515.GD30092@luke.xen.prgmr.com> On Sat, Apr 07, 2012 at 06:16:30PM -0400, Robert E. Seastrom wrote: > Sometimes making the AS path as short as possible makes a lot of sense > (e.g. when trying to get an anycast network to do the right thing), > but assumptions that peering results in lower costs are less true > every day. I keep reading people say that. But wouldn't the same forces that push down the per-megabit cost of transit also push down the per-megabit cost of peering? From bzs at world.std.com Sat Apr 7 17:35:33 2012 From: bzs at world.std.com (Barry Shein) Date: Sat, 7 Apr 2012 18:35:33 -0400 Subject: The day SORBS goes away ... In-Reply-To: <20120407211903.GZ2056@hezmatt.org> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> Message-ID: <20352.49461.630910.651396@world.std.com> Something I'm considering is just limiting the max size of an email from Yahoo severely, enough to say "I've changed my address from yahoo to _______". We get pounded day and night with multimegabyte (per each) spam emails from them. Yahoo isn't the only one but the most frequent. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From rs at seastrom.com Sat Apr 7 18:25:24 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 07 Apr 2012 19:25:24 -0400 Subject: Question about peering In-Reply-To: <20120407223515.GD30092@luke.xen.prgmr.com> (Luke S. Crawford's message of "Sat, 7 Apr 2012 18:35:15 -0400") References: <86wr5r4281.fsf@seastrom.com> <20120407223515.GD30092@luke.xen.prgmr.com> Message-ID: <86iphb3z17.fsf@seastrom.com> "Luke S. Crawford" writes: > On Sat, Apr 07, 2012 at 06:16:30PM -0400, Robert E. Seastrom wrote: >> Sometimes making the AS path as short as possible makes a lot of sense >> (e.g. when trying to get an anycast network to do the right thing), >> but assumptions that peering results in lower costs are less true >> every day. > > I keep reading people say that. But wouldn't the same forces that push > down the per-megabit cost of transit also push down the per-megabit > cost of peering? Generally the costs of transit are pushed down by competition. As a vendor your costs for bandwidth/transport/port*bw may drop but you are unlikely to drop your prices to your customers merely because your costs have gone down unless prompted to by a competitor. In any given IX, cross-connect fibers and peering switch ports are often a monopoly. While not unheard-of for there to be two competing IX switch fabrics available in a single facility, the cross-connects to those competing exchanges are not free, and I'm not aware of any sizeabe facilities that are still "run your own XC and don't pay anyone for it" (of course, as soon as I say that I'll get private email or an IRC message pointing out the corner case). Consider the case of a peering n00b network (the target of this discussion after all) in hypothetical facility that charges $1000/month for a gigabit ethernet port on the peering fabric. You turn up a connection to this port and discover that (without buying people drinks / sushi dinners / etc at a conference) you can bring up enough peering with other networks to move 150 Mbit/sec on it. That's pretty optimistic for a small player, but still... now you're paying $6.66/mbit for that transit. If you can move 150 Mbit/sec to low-hanging-fruit transit you're probably between 1 and 2gbps total. How's that compare with what you're paying for transit with that level of commit? -r From tshaw at oitc.com Sat Apr 7 18:41:07 2012 From: tshaw at oitc.com (TR Shaw) Date: Sat, 7 Apr 2012 19:41:07 -0400 Subject: The day SORBS goes away ... In-Reply-To: <20352.49461.630910.651396@world.std.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> Message-ID: <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> On Apr 7, 2012, at 6:35 PM, Barry Shein wrote: > > Something I'm considering is just limiting the max size of an email > from Yahoo severely, enough to say "I've changed my address from yahoo > to _______". > > We get pounded day and night with multimegabyte (per each) spam emails > from them. > > Yahoo isn't the only one but the most frequent. As for Yahoo, the problem will probably go away on its own over time. The problem with companies that are in questionable/bad financial shape is that they defund many activities that do not seem important but actually are. These, such as abuse handling, will actually cause them to increase their spiral down by causing more customers away. Another item of interest is that Yahoo says they will only accept ARF (RFC-5965) reports to "abuse@" However, they reject all ARF abuse reports just like the plain text ones. So much for standards support.... As an aside, one can not/will not/may not block all their mailservers but I would suggest blocking all mail that contains their shortener, y.ahoo.it. It is highly abused and they don't respond to abuse reports on it either. Its a real shame that the original high quality search engine/company that everyone aspired to be on has fallen so far both financially and in quality. As for SORBS, most competent mail admins dropped its use a long time ago. I thought when Proofpoint took it over things would change (I actually thought they would dump the SORBS name because of bad karma) but it hasn't happened. From randy at psg.com Sat Apr 7 18:48:17 2012 From: randy at psg.com (Randy Bush) Date: Sun, 08 Apr 2012 08:48:17 +0900 Subject: Question about peering In-Reply-To: <20120407223515.GD30092@luke.xen.prgmr.com> References: <86wr5r4281.fsf@seastrom.com> <20120407223515.GD30092@luke.xen.prgmr.com> Message-ID: > wouldn't the same forces that push down the per-megabit cost of > transit also push down the per-megabit cost of peering? at some point in the race to the bottom, the cost of a port plus the opex to maintain a peer becomes a significant factor. randy From lsc at prgmr.com Sat Apr 7 19:34:10 2012 From: lsc at prgmr.com (Luke S. Crawford) Date: Sat, 7 Apr 2012 20:34:10 -0400 Subject: Question about peering In-Reply-To: <86iphb3z17.fsf@seastrom.com> References: <86wr5r4281.fsf@seastrom.com> <20120407223515.GD30092@luke.xen.prgmr.com> <86iphb3z17.fsf@seastrom.com> Message-ID: <20120408003410.GH30092@luke.xen.prgmr.com> On Sat, Apr 07, 2012 at 07:25:24PM -0400, Robert E. Seastrom wrote: > Generally the costs of transit are pushed down by competition. As a > vendor your costs for bandwidth/transport/port*bw may drop but you are > unlikely to drop your prices to your customers merely because your > costs have gone down unless prompted to by a competitor. ah, so it's not the cost of production that is the problem, it is the 'natural monopoly' state of an IX that is the problem. It seems like that problem could be overcome by making the IX a cooperative owned by the members, maybe? > Consider the case of a peering n00b network (the target of this > discussion after all) in hypothetical facility that charges > $1000/month for a gigabit ethernet port on the peering fabric. You I am in almost that exact position (A peering n00b network) - Of couse, I'm fairly certain I'm paying sucker prices, but I can get a gigE to any2 at 55 s market for less than a third the price you quote. just a data point. From Joel.Snyder at Opus1.COM Sat Apr 7 19:51:19 2012 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sat, 07 Apr 2012 17:51:19 -0700 Subject: Question about peering In-Reply-To: References: Message-ID: <4F80E107.7040904@opus1.com> >It seems like that problem could be overcome by making the >IX a cooperative owned by the members, maybe? Even if an IX is a cooperative, that doesn't say anything about their costs and the costs of interconnection. Networks and buildings and cross-connects can get cheap for lots of reasons, but the nature of the ownership isn't really a factor. Cooperatives can be as poorly run or have as high costs as any commercial facility. In fact, you could argue that without some cross-subsidy of co-lo or one of the providers 'donating' space, a small cooperative is likely to be more expensive to put together than a large colo facility that has lots of revenue streams. Or you could argue the opposite. I'm just pointing out that motivation and ownership don't necessarily dictate final costs. That being said... >I am in almost that exact position (A peering n00b network) - Of >couse, I'm fairly certain I'm paying sucker prices, but I can get a >gigE to any2 at 55 s market for less than a third the price you quote. Well, bully for you, but at this very instant I'm looking at a contract from PCCW which has a component of a cross-connect in Telecity London (Harbour Exchange) where the cross-connect has been priced out at USD 2400/month (maybe that also includes 1U of space; it's hard to tell). I do understand that this is NANOG with emphasis on the "NA" part, and so costs in other geographies may not be all that interesting, but some facilities do charge an arm and a leg (or maybe PCCW is screwing us over on the proposal). jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From rs at seastrom.com Sat Apr 7 20:20:24 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 07 Apr 2012 21:20:24 -0400 Subject: Question about peering In-Reply-To: <20120408003410.GH30092@luke.xen.prgmr.com> (Luke S. Crawford's message of "Sat, 7 Apr 2012 20:34:10 -0400") References: <86wr5r4281.fsf@seastrom.com> <20120407223515.GD30092@luke.xen.prgmr.com> <86iphb3z17.fsf@seastrom.com> <20120408003410.GH30092@luke.xen.prgmr.com> Message-ID: <86pqbjnhnr.fsf@seastrom.com> "Luke S. Crawford" writes: > On Sat, Apr 07, 2012 at 07:25:24PM -0400, Robert E. Seastrom wrote: >> Generally the costs of transit are pushed down by competition. As a >> vendor your costs for bandwidth/transport/port*bw may drop but you are >> unlikely to drop your prices to your customers merely because your >> costs have gone down unless prompted to by a competitor. > > ah, so it's not the cost of production that is the problem, it is > the 'natural monopoly' state of an IX that is the problem. > > It seems like that problem could be overcome by making the > IX a cooperative owned by the members, maybe? The whole datacenter? >> Consider the case of a peering n00b network (the target of this >> discussion after all) in hypothetical facility that charges >> $1000/month for a gigabit ethernet port on the peering fabric. You > > I am in almost that exact position (A peering n00b network) - Of > couse, I'm fairly certain I'm paying sucker prices, but I can get a > gigE to any2 at 55 s market for less than a third the price you quote. > > just a data point. You might want to analyze peering opportunities there: https://www.peeringdb.com/private/facility_view.php?id=20&peerParticipantsPrivatesPage=1 and get some netflow data out of your own network to see just how much traffic you're sending there. Fairly easy to do with only 34 participants. Excel Will Tell You What To Do (tm vgill) -r From ops.lists at gmail.com Sat Apr 7 22:42:43 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 8 Apr 2012 09:12:43 +0530 Subject: Question about peering In-Reply-To: <86wr5r4281.fsf@seastrom.com> References: <86wr5r4281.fsf@seastrom.com> Message-ID: fair enough. i was thinking smaller and more localized exchanges rather than the big ones --srs (iPad) On 08-Apr-2012, at 3:46, "Robert E. Seastrom" wrote: > > Actually, Suresh, I disagree. It depends on the > facility/country/continent, the cost of joining the local IX fabric at > a reasonable bandwidth, your cost model, and your transit costs. In > short, it's not 1999 anymore, and peering is not automatically the > right answer from a purely fiscal perspective (though it may be from a > technical perspective; see below). > > At certain IXes that have a perfect storm of high priced ports and a > good assortment of carriers with sufficiently high quality service and > aggressive pricing, a good negotiator can fairly easily find himself > in a position where the actual cost per megabit of traffic moved on > peered bandwidth exceeds the cost of traffic moved on transit _by an > order of magnitude_. That's without even factoring in the (low) > maintenance cost of having a bunch of BGP sessions around or upgraded > routers or whatever. > > Sometimes making the AS path as short as possible makes a lot of sense > (e.g. when trying to get an anycast network to do the right thing), > but assumptions that peering results in lower costs are less true > every day. > > -r > > Suresh Ramasubramanian writes: > >> what does it cost you to peer, versus what does it cost you to not peer? >> >> if you are at the same ix the costs of peering are very low indeed >> >> On Saturday, April 7, 2012, Anurag Bhatia wrote: >> >>> Hello everyone >>> >>> >>> >>> I am curious to know how small ISPs plan peering with other interested >>> parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say >>> A and C both have open peering policy and assuming the exist in same >>> exchange or nearby. Now at this point is there is any "minimum bandwidth" >>> considerations? Say if A and C have 1Gbps + of flowing traffic - very >>> likely peering would be good idea to save transit costs to B. But if A and >>> C have very low levels - does it still makes sense? Does peering costs >>> anything if ISPs are in same exchange? Does at low traffic level it makes >>> more sense to keep on reaching other ISPs via big transit provider? >>> >>> >>> >>> Thanks. >>> >>> -- >>> >>> Anurag Bhatia >>> anuragbhatia.com >>> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected >>> network! >>> >>> Twitter: @anurag_bhatia >>> Linkedin: http://linkedin.anuragbhatia.com >>> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) From mrp at mrp.net Mon Apr 9 06:27:09 2012 From: mrp at mrp.net (Mark Prior) Date: Mon, 09 Apr 2012 20:57:09 +0930 Subject: Fwd: AusNOG 2012 Call For Presentations In-Reply-To: <8168868D-8CB7-4E6A-B45D-466CD6D4B65D@mmc.com.au> References: <8168868D-8CB7-4E6A-B45D-466CD6D4B65D@mmc.com.au> Message-ID: <4F82C78D.4090108@mrp.net> In case anyone wants a trip down under in September. Mark. -------- Original Message -------- Subject: AusNOG 2012 Call For Presentations Date: Mon, 9 Apr 2012 20:25:30 +0930 From: Matthew Moyle-Croft To: Ausnog at ausnog.net (ausnog at ausnog.net) Call for presentations for AusNOG 2012 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Langham Hotel **Melbourne** 6 & 7 September, 2012 Notes =-=-=- The AusNOG organisers have decided to change the name of the conference to reflect the year instead of the number of the event. So this year's conference is going to be known as AusNOG 2012. It's hoped this will remove some confusion. AusNOG 2012 is being held in Melbourne for the first time. The organisers encourage Melbourne based network operators, especially those that have not previously attended an AusNOG, will take advantage of this opportunity to not only attend the meeting but also present! Topics =-=-=-= Internet operations can be a broad topic and the presentation selection committee will be short-listing presentations in the following focus areas: * Improving the redundancy/resiliency/sustainability of your network * Making leaps in service or network availability * Taking the network operations BCP to the next level * Using 'offline' communications tools to keep the network working * How technology is changing network architectures * Evolution in network architectures and scaling issues Other topics which are of interest to the network operator community are also welcome at AusNOG 2012. Naturally, presentations of a marketing nature are not welcome at this technical event. Notes to presenters =-=-=-=-=-=-=-=-=-= Preference will be given to presentations that result in actual operational outcomes. Session speakers should be prepared to present for 30 minutes. Keynote speakers will be expected to present for 45 minutes to 1 hour. Short presentations of strong operational content are also acceptable. Once the final slides are submitted, changes will only be permitted where the presentation requires the most up to date information or data. By submitting a presentation for consideration in the AusNOG 2012 programme, and if selected the presenter will allow AusNOG to: * Take photographs of the presentation and presenter. * Record and rebroadcast video and audio of the presentation and presenter. * Redistribute, the presentation slides, audio, video, and photographs electronically, on the AusNOG website, or otherwise but leaving all intellectual property in the hands of presenter or rightful property holder where possible[1]. Deadlines =-=-=-=-=- 01 June: Submission of presentation title, presentation description (300 words), and presenter biography (200-400 words) 15 July: Presenters notified of their acceptance status as an AusNOG 2012 presentation. August 29: Submission of final presentation slides as Portable Document Format (pdf), PowerPoint, or Keynote. Provision of a recent digital photograph (<500k) of the presenter. All submissions must be sent to organisers at ausnog.net. A separate call for lightning talks will be made closer to the AusNOG 2012 event [1]: AusNOG accepts that some speakers are unable to allow us to archive their presentation due to company or corporate policy, and if the situation arises AusNOG will delete all copies in its possession after the presentation. From chort at smtps.net Mon Apr 9 11:50:00 2012 From: chort at smtps.net (Brian Keefer) Date: Mon, 9 Apr 2012 09:50:00 -0700 Subject: The day SORBS goes away ... In-Reply-To: <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> Message-ID: <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> On Apr 7, 2012, at 4:41 PM, TR Shaw wrote: > > As for SORBS, most competent mail admins dropped its use a long time ago. I thought when Proofpoint took it over things would change (I actually thought they would dump the SORBS name because of bad karma) but it hasn't happened. Out of curiosity, has anyone other than the OP and one other gentlemen on the 4th had a serious issue? Do we know whether the issues from the 4th have been resolved? I'm wondering whether this is a chronic issue, or if folks are just extrapolating from one complaint. I looked back through the archives for the last year and the only other SORBS mentions were in July and August of last year. -- chort From rvandolson at esri.com Mon Apr 9 11:55:32 2012 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 9 Apr 2012 09:55:32 -0700 Subject: The day SORBS goes away ... In-Reply-To: <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> References: <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> Message-ID: <20120409165532.GA11458@esri.com> On Mon, Apr 09, 2012 at 09:50:00AM -0700, Brian Keefer wrote: > > > On Apr 7, 2012, at 4:41 PM, TR Shaw wrote: > > > > As for SORBS, most competent mail admins dropped its use a long > > time ago. I thought when Proofpoint took it over things would > > change (I actually thought they would dump the SORBS name because > > of bad karma) but it hasn't happened. > > Out of curiosity, has anyone other than the OP and one other > gentlemen on the 4th had a serious issue? Do we know whether the > issues from the 4th have been resolved? I'm wondering whether this is > a chronic issue, or if folks are just extrapolating from one > complaint. > > I looked back through the archives for the last year and the only > other SORBS mentions were in July and August of last year. I last worked at an ISP back in 2006, so this may not be relevant today. I do remember however relying pretty much exclusively on Spamhaus. Originally used SORBS too but found they were overly aggressive on what they'd add to their RBL. Maybe great if you're an individual user, but not so great to be blocking all of yahoo/gmail, etc as an ISP. Don't think they were as frustrating to deal with as Spamcop though :) Ray From patrick at ianai.net Mon Apr 9 11:58:21 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 9 Apr 2012 12:58:21 -0400 Subject: The day SORBS goes away ... In-Reply-To: <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> Message-ID: <6F38FDC8-E94E-4CB1-89D4-E9D592CC9A45@ianai.net> On Apr 7, 2012, at 19:41 , TR Shaw wrote: > As for Yahoo, the problem will probably go away on its own over time. The problem with companies that are in questionable/bad financial shape is that they defund many activities that do not seem important but actually are. These, such as abuse handling, will actually cause them to increase their spiral down by causing more customers away. For the 3 months ending 2011-12-31 (last quarter available), Yahoo!'s revenue was US$1.3B, with a net income of nearly US$300M - for the _quarter_. I wish I were in such "questionable/bad financial shape". Before anyone pounces, yes, I know they're not growing. The results above up slightly from Q3 2011, although down slightly (~5%) from Q4 2010. But they still make more revenue & profit than 99.mumble% of the companies represented on this list. And they have more than enough to do abuse correctly. Perhaps more importantly, I seriously doubt Yahoo! mail is going away any time soon. -- TTFN, patrick From dwhite at olp.net Mon Apr 9 12:05:15 2012 From: dwhite at olp.net (Dan White) Date: Mon, 9 Apr 2012 12:05:15 -0500 Subject: The day SORBS goes away ... In-Reply-To: <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> References: <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> Message-ID: <20120409170514.GC6643@dan.olp.net> On 04/09/12?09:50?-0700, Brian Keefer wrote: > > >On Apr 7, 2012, at 4:41 PM, TR Shaw wrote: >> >> As for SORBS, most competent mail admins dropped its use a long time >> ago. I thought when Proofpoint took it over things would change (I >> actually thought they would dump the SORBS name because of bad karma) >> but it hasn't happened. > >Out of curiosity, has anyone other than the OP and one other gentlemen on >the 4th had a serious issue? Do we know whether the issues from the 4th >have been resolved? I'm wondering whether this is a chronic issue, or if >folks are just extrapolating from one complaint. > >I looked back through the archives for the last year and the only other >SORBS mentions were in July and August of last year. I've had nothing but sore issues with SORBS and getting removed from whatever black list was getting us blocked by participating mail systems. Our ARIN allocation is: 67.217.144.0/20 and SORBS had us listed within a larger black listed range, like the containing /12. It took us weeks to be removed from that range (or to have an exception added). This was probably a couple of years ago, or early last year. -- Dan White From dmiller at tiggee.com Mon Apr 9 12:44:19 2012 From: dmiller at tiggee.com (David Miller) Date: Mon, 09 Apr 2012 13:44:19 -0400 Subject: FYI Coresite xconn price increases Message-ID: <4F831FF3.7030501@tiggee.com> Just as an FYI, anyone with space and xconns in a Coresite facility (e.g. OW) might want to double check their recent invoices. Coresite more than doubled our MRC on existing and new fiber xconns. I have heard from others that they also had the same increase across the board for all xconns at all locations. We had this more than double price increase on our latest invoices even at locations where we, by contract, locked in our xconn prices. We are fighting this with their folks now. It appears that they did a global search and replace in their billing system for xconn prices without regard to the actual contract. -DMM From nathan at atlasnetworks.us Mon Apr 9 12:48:03 2012 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 9 Apr 2012 17:48:03 +0000 Subject: The day SORBS goes away ... In-Reply-To: <20120409170514.GC6643@dan.olp.net> References: <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> <20120409170514.GC6643@dan.olp.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C287CA1CF31@EX-MB-1.corp.atlasnetworks.us> > Our ARIN allocation is: > > 67.217.144.0/20 > > and SORBS had us listed within a larger black listed range, like the > containing /12. It took us weeks to be removed from that range (or to > have > an exception added). This was probably a couple of years ago, or early > last > year. Our experience with their DUHL was very similar, and around the same time. My post to NANOG about it is here: http://mailman.nanog.org/pipermail/nanog/2011-June/037568.html Despite the only public reply being utterly unhelpful, the post resulted in human contact from SORBs and an eventual resolution of the issue. I have observed this pattern repeated several times on-list since then (and several times prior to my post), so it would seem that posting to NANOG is (or, at that time, was) part of their delisting process. Nathan Eisenberg From ikiris at gmail.com Mon Apr 9 13:41:26 2012 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 9 Apr 2012 13:41:26 -0500 Subject: The day SORBS goes away ... In-Reply-To: <8C26A4FDAE599041A13EB499117D3C287CA1CF31@EX-MB-1.corp.atlasnetworks.us> References: <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> <20120409170514.GC6643@dan.olp.net> <8C26A4FDAE599041A13EB499117D3C287CA1CF31@EX-MB-1.corp.atlasnetworks.us> Message-ID: Generally when faced with SORBS related blocking, I have found it far more effective to contact the receiving side and show them the ample Google history about SORBS and the effect it has on their ability to receive email their customers/employees have requested, and have them either change their email policies, or their executives change their email admins. I'm honestly amazed these days every time I run into someone still blocking based on SORBS, or even giving a non insignificant point score as such. -Blake From bpasdar at batblue.com Mon Apr 9 15:11:15 2012 From: bpasdar at batblue.com (Babak Pasdar) Date: Mon, 09 Apr 2012 16:11:15 -0400 Subject: Cablevision / Lightpath / Optimum Online hard limit Message-ID: <20120409201115.3015a369@concur.batblue.com> Hello, Is there anyone on the Cablevision / Lightpath / Optimum Online IP team that can work with us on a hard 60mbps limit between us and a client's network? Thanks Babak -- Babak Pasdar Bat Blue Networks (p) 212.461.3322 x3005 | (f) 212.584.9999 | www.BatBlue.com Bat Blue: AS 25885 | BGP Policy | Peering Policy Watch: Cloud Security Video | Cloud Network Video Read: Official Provider for ESPN X Games -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1666 bytes Desc: not available URL: From randy at psg.com Mon Apr 9 17:52:16 2012 From: randy at psg.com (Randy Bush) Date: Tue, 10 Apr 2012 07:52:16 +0900 Subject: The day SORBS goes away ... In-Reply-To: <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> Message-ID: drop condition = ${if isip4{$sender_host_address}} message = blocked because $sender_host_address is \ in blacklist at $dnslist_domain: $dnslist_text !dnslists = list.dnswl.org dnslists = dialups.mail-abuse.org \ : rbl-plus.mail-abuse.org \ : dnsbl.sorbs.net \ : zen.spamhaus.org logwrite = REJECT because $sender_host_address listed in $dnslist_domain works pretty well for me. looking forward to a bit of ipv6 prophylaxis randy From jlewis at lewis.org Mon Apr 9 19:22:55 2012 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 9 Apr 2012 20:22:55 -0400 (EDT) Subject: The day SORBS goes away ... In-Reply-To: References: <4F7CA69F.9090206@b2b2c.ca> <4F7CBB47.1010801@mompl.net> <4F7F03B9.80400@2mbit.com> <20120407115942.GA3136@gsp.org> <20120407211903.GZ2056@hezmatt.org> <20352.49461.630910.651396@world.std.com> <0F218528-A983-45B9-84EB-33EB7E0BB59E@oitc.com> <017D2400-B9C7-48D0-AFFB-574843A76A38@smtps.net> Message-ID: On Tue, 10 Apr 2012, Randy Bush wrote: > drop condition = ${if isip4{$sender_host_address}} > message = blocked because $sender_host_address is \ > in blacklist at $dnslist_domain: $dnslist_text > !dnslists = list.dnswl.org > dnslists = dialups.mail-abuse.org \ > : rbl-plus.mail-abuse.org \ > : dnsbl.sorbs.net \ > : zen.spamhaus.org > logwrite = REJECT because $sender_host_address listed in $dnslist_domain > > works pretty well for me. looking forward to a bit of ipv6 prophylaxis If you were to move dialups.mail-abuse.org below zen.spamhaus.org (assuming these are checked in the order they're entered in the config), I'm curious if dialups.mail-abuse.org would block anything. If it did, I'd be curious if those were FPs. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nicotine at warningg.com Mon Apr 9 22:21:41 2012 From: nicotine at warningg.com (Brandon Ewing) Date: Mon, 9 Apr 2012 22:21:41 -0500 Subject: AT&T DSL bypass first line Message-ID: <20120410032141.GA29906@radiological.warningg.com> I've been an AT&T DSL customer for 3+ years, with no issues until they started sending people into my neighborhood to "start retrofitting for UVerse". Since they've visited, my PPPoE has dropped once an hour, many times requiring me to restart my router (Cisco 877) to get my virtual interface to come back up. Speaking with the front line on the phone has given me nothing but problems (in their defense, I do have a non-standard modem) -- could someone with knowledge provide me with a way to bypass the CSRs and speak to someone with clue to work out debug logs and figure out why I am suddenly an unhappy AT&T customer? -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nathana at fsr.com Mon Apr 9 22:52:33 2012 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 9 Apr 2012 20:52:33 -0700 Subject: AT&T DSL bypass first line In-Reply-To: <20120410032141.GA29906@radiological.warningg.com> References: <20120410032141.GA29906@radiological.warningg.com> Message-ID: On Monday, April 09, 2012 8:22 PM, Brandon Ewing wrote: > I've been an AT&T DSL customer for 3+ years, with no issues until they > started sending people into my neighborhood to "start retrofitting for > UVerse". Since they've visited, my PPPoE has dropped once an hour, many > times requiring me to restart my router (Cisco 877) to get my virtual > interface to come back up. Although your problems with the service provider are definitely not good, one might also make the observation that if you're needing to reboot your router to get it to take action again, then it might not exactly be blameless itself... -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From sking at kingrst.com Mon Apr 9 23:31:17 2012 From: sking at kingrst.com (Steven King) Date: Tue, 10 Apr 2012 00:31:17 -0400 Subject: Cheap Juniper Gear for Lab Message-ID: <4F83B795.4010301@kingrst.com> Hello All, I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself. Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke? Thanks! -- Steve King Network/Linux Engineer - AdSafe Media Cisco Certified Network Professional CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From sethm at rollernet.us Tue Apr 10 00:45:39 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Apr 2012 22:45:39 -0700 Subject: AT&T DSL bypass first line In-Reply-To: <20120410032141.GA29906@radiological.warningg.com> References: <20120410032141.GA29906@radiological.warningg.com> Message-ID: <4F83C903.2060900@rollernet.us> On 4/9/12 8:21 PM, Brandon Ewing wrote: > I've been an AT&T DSL customer for 3+ years, with no issues until > they started sending people into my neighborhood to "start > retrofitting for UVerse". Since they've visited, my PPPoE has > dropped once an hour, many times requiring me to restart my router > (Cisco 877) to get my virtual interface to come back up. > > Speaking with the front line on the phone has given me nothing but > problems (in their defense, I do have a non-standard modem) -- > could someone with knowledge provide me with a way to bypass the > CSRs and speak to someone with clue to work out debug logs and > figure out why I am suddenly an unhappy AT&T customer? > The same thing happened to me. You can try asking them to simply change the line from "fastpath" to "interleaved" or lower the sync rate. I was transferred to someone who made the changes live on the phone. After they retrofitted my neighborhood for Uverse, fastpath would no longer hold sync. I ultimately had to give up ADSL via my 877W because AT&T coincidentally no longer offered anything better than 2Mbps ADSL after the Uverse changes rolled through. ~Seth From bclark at spectraaccess.com Tue Apr 10 07:23:07 2012 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 10 Apr 2012 08:23:07 -0400 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F83B795.4010301@kingrst.com> References: <4F83B795.4010301@kingrst.com> Message-ID: <4F84262B.7080000@spectraaccess.com> On 04/10/2012 12:31 AM, Steven King wrote: > Hello All, > > I am tasked with replacing an old linux router setup with Juniper gear > in the near future. Though I am a Cisco guy myself. > > Does anyone know of any older cheap Juniper gear I might find on Ebay so > that I may build a home lab without going broke? > > Thanks! > http://www.ebay.com/sch/Networking-Communications-/11176/i.html?_from=R40&_nkw=juniper From faisal at snappydsl.net Tue Apr 10 07:38:31 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 10 Apr 2012 08:38:31 -0400 Subject: AT&T DSL bypass first line In-Reply-To: <4F83C903.2060900@rollernet.us> References: <20120410032141.GA29906@radiological.warningg.com> <4F83C903.2060900@rollernet.us> Message-ID: <4F8429C7.4030101@snappydsl.net> Yes, you can ask them to change the 'profile', which can make things more stable. Or you can dump you switch your DSL out for Uverse (Internet Only)... Which is sold online (only) without any bundle. In most cases you can end up with more bandwidth at the same or lower cost. http://www.att.com/u-verse/shop/index.jsp?shopFilterId=500001#fbid=y_8VIHP6LWJ Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 4/10/2012 1:45 AM, Seth Mattinen wrote: > On 4/9/12 8:21 PM, Brandon Ewing wrote: >> I've been an AT&T DSL customer for 3+ years, with no issues until >> they started sending people into my neighborhood to "start >> retrofitting for UVerse". Since they've visited, my PPPoE has >> dropped once an hour, many times requiring me to restart my router >> (Cisco 877) to get my virtual interface to come back up. >> >> Speaking with the front line on the phone has given me nothing but >> problems (in their defense, I do have a non-standard modem) -- >> could someone with knowledge provide me with a way to bypass the >> CSRs and speak to someone with clue to work out debug logs and >> figure out why I am suddenly an unhappy AT&T customer? >> > > The same thing happened to me. You can try asking them to simply > change the line from "fastpath" to "interleaved" or lower the sync > rate. I was transferred to someone who made the changes live on the phone. > > After they retrofitted my neighborhood for Uverse, fastpath would no > longer hold sync. I ultimately had to give up ADSL via my 877W because > AT&T coincidentally no longer offered anything better than 2Mbps ADSL > after the Uverse changes rolled through. > > ~Seth > > From nanog at studio442.com.au Tue Apr 10 07:58:43 2012 From: nanog at studio442.com.au (Julien Goodwin) Date: Tue, 10 Apr 2012 22:58:43 +1000 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F83B795.4010301@kingrst.com> References: <4F83B795.4010301@kingrst.com> Message-ID: <4F842E83.6040703@studio442.com.au> On 10/04/12 14:31, Steven King wrote: > I am tasked with replacing an old linux router setup with Juniper gear > in the near future. Though I am a Cisco guy myself. > > Does anyone know of any older cheap Juniper gear I might find on Ebay so > that I may build a home lab without going broke? A slightly more useful way of answering this then just pointing to eBay is to give some candidates. Routing/switching *config*, firewalling - Branch SRX / J The lower end SRX, and J series devices are nice as they take nearly all the config (except MX-type bridging, and some EX bits), including MPLS. Switching - EX [34]200 The 4200 & 3200 are essentially the flagship, and if you can only buy one switch for a lab make it one of those Routing - M5/10/7i/10i/20 A bunch of the smaller and older M series kit is now fairly cheaply available. These are still quite nice boxes, and support SONET and ATM unlike the platforms above should you need them. MX Routing - MX 80 (new) The MX80 (or as locked 5/10/40 variants) is by far the cheapest way to test the MX-specific ethernet services, as long as you don't want BRAS functionality. Juniper do have a bunch more lines, but those are the most common (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are not long for this world). If you just want one box to get to know the OS an SRX2X0 (or possibly a 100) is by far the most flexible way, and can be had for < $500 used). From dbrisson at uvm.edu Tue Apr 10 08:03:39 2012 From: dbrisson at uvm.edu (Dan Brisson) Date: Tue, 10 Apr 2012 09:03:39 -0400 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F83B795.4010301@kingrst.com> References: <4F83B795.4010301@kingrst.com> Message-ID: <4F842FAB.2080207@uvm.edu> I think GNS3 can emulate Juniper devices. http://www.gns3.net/ -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbrisson at uvm.edu On 4/10/12 12:31 AM, Steven King wrote: > Hello All, > > I am tasked with replacing an old linux router setup with Juniper gear > in the near future. Though I am a Cisco guy myself. > > Does anyone know of any older cheap Juniper gear I might find on Ebay > so that I may build a home lab without going broke? > > Thanks! > From quantumfoam at gmail.com Tue Apr 10 08:36:27 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Tue, 10 Apr 2012 09:36:27 -0400 Subject: AT&T DSL bypass first line In-Reply-To: <4F8429C7.4030101@snappydsl.net> References: <20120410032141.GA29906@radiological.warningg.com> <4F83C903.2060900@rollernet.us> <4F8429C7.4030101@snappydsl.net> Message-ID: I can vouch for Uverse being excellent service, at least in my area (Atlanta). It's fast, it hasn't gone down once in over a year since I got it, and I went ahead and got the Uverse TV service as well which has proven to be a better deal than cable offerings in my area (satellite isn't an option due to the arrangement of my property). The 2WIRE gateway they provide is surprisingly capable. Port forwarding, the ability to scan the wifi spectrum to see what channels are occupied, and a lot more. I haven't found the need to replace it although it doesn't support 802.11n so I'm going to add an AP at some point. Jonathan On Tue, Apr 10, 2012 at 8:38 AM, Faisal Imtiaz wrote: > Yes, you can ask them to change the 'profile', which can make things more > stable. > > Or you can dump you switch your DSL out for Uverse (Internet Only)... > Which is sold online (only) without any bundle. > In most cases you can end up with more bandwidth at the same or lower cost. > > http://www.att.com/u-verse/**shop/index.jsp?shopFilterId=** > 500001#fbid=y_8VIHP6LWJ > > Faisal Imtiaz > Snappy Internet& Telecom > 7266 SW 48 Street > Miami, Fl 33155 > Tel: 305 663 5518 x 232 > Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net > > > > On 4/10/2012 1:45 AM, Seth Mattinen wrote: > >> On 4/9/12 8:21 PM, Brandon Ewing wrote: >> >>> I've been an AT&T DSL customer for 3+ years, with no issues until >>> they started sending people into my neighborhood to "start >>> retrofitting for UVerse". Since they've visited, my PPPoE has >>> dropped once an hour, many times requiring me to restart my router >>> (Cisco 877) to get my virtual interface to come back up. >>> >>> Speaking with the front line on the phone has given me nothing but >>> problems (in their defense, I do have a non-standard modem) -- >>> could someone with knowledge provide me with a way to bypass the >>> CSRs and speak to someone with clue to work out debug logs and >>> figure out why I am suddenly an unhappy AT&T customer? >>> >>> >> The same thing happened to me. You can try asking them to simply >> change the line from "fastpath" to "interleaved" or lower the sync >> rate. I was transferred to someone who made the changes live on the phone. >> >> After they retrofitted my neighborhood for Uverse, fastpath would no >> longer hold sync. I ultimately had to give up ADSL via my 877W because >> AT&T coincidentally no longer offered anything better than 2Mbps ADSL >> after the Uverse changes rolled through. >> >> ~Seth >> >> >> > > From owen at delong.com Tue Apr 10 08:33:32 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Apr 2012 06:33:32 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F842E83.6040703@studio442.com.au> References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> Message-ID: On Apr 10, 2012, at 5:58 AM, Julien Goodwin wrote: > On 10/04/12 14:31, Steven King wrote: >> I am tasked with replacing an old linux router setup with Juniper gear >> in the near future. Though I am a Cisco guy myself. >> >> Does anyone know of any older cheap Juniper gear I might find on Ebay so >> that I may build a home lab without going broke? > > A slightly more useful way of answering this then just pointing to eBay > is to give some candidates. > > Routing/switching *config*, firewalling - Branch SRX / J > > The lower end SRX, and J series devices are nice as they take nearly all > the config (except MX-type bridging, and some EX bits), including MPLS. > But not so nice in that they run Services JunOS instead of real JunOS meaning that they behave like Netscreens with a JunOS style configuration file instead of behaving like Junipers. If you're wanting to model Services JunOS, then, yes, the SRX-100 is a good candidate and dirt cheap. If you want real JunOS, avoid SRX or J series at all costs. > Juniper do have a bunch more lines, but those are the most common > (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are > not long for this world). > Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products. > If you just want one box to get to know the OS an SRX2X0 (or possibly a > 100) is by far the most flexible way, and can be had for < $500 used). With the caveat about Services JunOS above. Owen From xmin0s at gmail.com Tue Apr 10 09:24:35 2012 From: xmin0s at gmail.com (Tim Eberhard) Date: Tue, 10 Apr 2012 14:24:35 +0000 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> Message-ID: I find it humorous that you think J/SRX junos isn't real junos. So what makes it not real junos? The fact it has a flowd process? Lets technically talk about this for a moment. Realistically one of the only differences between "flow based junos" and the legacy "packet based junos" is the flowd process. Which can be easily bypassed by issuing a couple of configuration commands. So what exactly makes this platform/code so horrible and not "real" junos? If anything to me it's a better platform to deploy and learn on. It's more flexible as it comes with more advanced flow based features but they are optional. There are certain limitations as mentioned previously around the switching and class of service however these same feature limitations were also in the "real" junos low end devices. If there are other differences that I am unaware of then by all means feel free to educate me. I am well aware that branch devices don't have the capabilities of the MX/M series in regards to ATM and other such specific platforms, but you called this "not real junos". So lets keep any responses limited to that aspect. -Tim Eberhard On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong wrote: > If you want real JunOS, avoid SRX or J series at all costs. > >> Juniper do have a bunch more lines, but those are the most common >> (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are >> not long for this world). >> > > Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products. > >> If you just want one box to get to know the OS an SRX2X0 (or possibly a >> 100) is by far the most flexible way, and can be had for < $500 used). > > With the caveat about Services JunOS above. > > Owen > > From sethm at rollernet.us Tue Apr 10 09:33:14 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 10 Apr 2012 07:33:14 -0700 Subject: AT&T DSL bypass first line In-Reply-To: <4F8429C7.4030101@snappydsl.net> References: <20120410032141.GA29906@radiological.warningg.com> <4F83C903.2060900@rollernet.us> <4F8429C7.4030101@snappydsl.net> Message-ID: <4F8444AA.5060306@rollernet.us> On 4/10/12 5:38 AM, Faisal Imtiaz wrote: > Yes, you can ask them to change the 'profile', which can make things > more stable. > > Or you can dump you switch your DSL out for Uverse (Internet Only)... > Which is sold online (only) without any bundle. > In most cases you can end up with more bandwidth at the same or lower cost. > I did indeed end up switching to Uverse because it was the same price as ADSL. The Uverse CPE can hand off its public address to a connected device as well, so it doesn't preclude running your own router if you have a need to do so. ~Seth From lorddoskias at gmail.com Tue Apr 10 09:57:22 2012 From: lorddoskias at gmail.com (lorddoskias) Date: Tue, 10 Apr 2012 15:57:22 +0100 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F83B795.4010301@kingrst.com> References: <4F83B795.4010301@kingrst.com> Message-ID: <4F844A52.3090509@gmail.com> On 4/10/2012 5:31 AM, Steven King wrote: > Hello All, > > I am tasked with replacing an old linux router setup with Juniper gear > in the near future. Though I am a Cisco guy myself. > > Does anyone know of any older cheap Juniper gear I might find on Ebay > so that I may build a home lab without going broke? > > Thanks! > Have you considered this http://www.juniper.net/us/en/products-services/software/junos-platform/junosphere/lab/ Regards, N. From hvb at dsms.com Tue Apr 10 09:59:41 2012 From: hvb at dsms.com (harold barker) Date: Tue, 10 Apr 2012 07:59:41 -0700 Subject: AT&T DSL bypass first line In-Reply-To: <4F8444AA.5060306@rollernet.us> References: <20120410032141.GA29906@radiological.warningg.com> <4F83C903.2060900@rollernet.us> <4F8429C7.4030101@snappydsl.net> <4F8444AA.5060306@rollernet.us> Message-ID: Can uverse do Proxy ARP? Last time i tried, it made such a mess that i moved to Comcast. From owen at delong.com Tue Apr 10 09:58:52 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Apr 2012 07:58:52 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> Message-ID: <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> On Apr 10, 2012, at 7:24 AM, Tim Eberhard wrote: > I find it humorous that you think J/SRX junos isn't real junos. > > So what makes it not real junos? The fact it has a flowd process? Lets > technically talk about this for a moment. > The fact that you can't put it into flow mode. > Realistically one of the only differences between "flow based junos" > and the legacy "packet based junos" is the flowd process. Which can be > easily bypassed by issuing a couple of configuration commands. So what > exactly makes this platform/code so horrible and not "real" junos? Actually, not. Try again. It can be partially bypassed. There are real and serious differences in how forwarding works in flow-based JunOS and how it behaves under many circumstances. > If anything to me it's a better platform to deploy and learn on. It's > more flexible as it comes with more advanced flow based features but > they are optional. There are certain limitations as mentioned > previously around the switching and class of service however these > same feature limitations were also in the "real" junos low end > devices. They aren't entirely optional and that is the problem. You can't actually completely bypass them and they do sometimes get in the way. > If there are other differences that I am unaware of then by all means > feel free to educate me. I am well aware that branch devices don't > have the capabilities of the MX/M series in regards to ATM and other > such specific platforms, but you called this "not real junos". So lets > keep any responses limited to that aspect. I believe that the flow-based routing goes quite a bit deeper than just having a flowd. It causes a number of problems with tunnel recursion among other things. Sure, if you want a firewall, flow-based JunOS is a pretty nice set of firewall features. However, if you just want to forward packets, it can really suck to have to work around it's flow-based "features". Owen > > -Tim Eberhard > > > > On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong wrote: > >> If you want real JunOS, avoid SRX or J series at all costs. >> >>> Juniper do have a bunch more lines, but those are the most common >>> (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are >>> not long for this world). >>> >> >> Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products. >> >>> If you just want one box to get to know the OS an SRX2X0 (or possibly a >>> 100) is by far the most flexible way, and can be had for < $500 used). >> >> With the caveat about Services JunOS above. >> >> Owen >> >> From nickellman at gmail.com Tue Apr 10 10:25:19 2012 From: nickellman at gmail.com (brian nikell) Date: Tue, 10 Apr 2012 09:25:19 -0600 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F83B795.4010301@kingrst.com> References: <4F83B795.4010301@kingrst.com> Message-ID: http://www.juniper.net/us/en/products-services/software/junos-platform/junosphere/lab/ On Mon, Apr 9, 2012 at 10:31 PM, Steven King wrote: > Hello All, > > I am tasked with replacing an old linux router setup with Juniper gear in > the near future. Though I am a Cisco guy myself. > > Does anyone know of any older cheap Juniper gear I might find on Ebay so > that I may build a home lab without going broke? > > Thanks! > > -- > Steve King > > Network/Linux Engineer - AdSafe Media > Cisco Certified Network Professional > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional > > > -- -B From telmnstr at 757.org Tue Apr 10 12:20:59 2012 From: telmnstr at 757.org (telmnstr at 757.org) Date: Tue, 10 Apr 2012 13:20:59 -0400 (EDT) Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F83B795.4010301@kingrst.com> References: <4F83B795.4010301@kingrst.com> Message-ID: > Does anyone know of any older cheap Juniper gear I might find on Ebay so that > I may build a home lab without going broke? I got my J series cheap off of ebay because it wouldn't power on. Turns out getting a replacement power supply was very difficult from Juniper or the manufacturer of the power supply. I ended up rebuilding a PC supply to do the job. Now to find rack ears and a module slot cover. Juniper quoted $150+ for the rack ears. If I can find a set, I think I might look to make a bunch of them. From shacolby at bluejeans.com Tue Apr 10 12:32:47 2012 From: shacolby at bluejeans.com (Shacolby Jackson) Date: Tue, 10 Apr 2012 10:32:47 -0700 Subject: AMS-IX for local loop Message-ID: I know this is a bit off topic since Amsterdam isn't exactly in North America but... Has anyone used AMS-IX for a private interconnect from one datacenter to another to avoid a classic local loop to another party or provider? For example, I'm in Equinix but might want to connect directly to someone at Interxion. -shac From listas at esds.com.br Tue Apr 10 13:39:09 2012 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 10 Apr 2012 15:39:09 -0300 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F842FAB.2080207@uvm.edu> References: <4F83B795.4010301@kingrst.com> <4F842FAB.2080207@uvm.edu> Message-ID: There is no "olives". ;-) -- Eduardo Schoedler Em 10 de abril de 2012 10:03, Dan Brisson escreveu: > I think GNS3 can emulate Juniper devices. > > http://www.gns3.net/ > > -dan > > > Dan Brisson > Network Engineer > University of Vermont > (Ph) 802.656.8111 > dbrisson at uvm.edu > > > > On 4/10/12 12:31 AM, Steven King wrote: > >> Hello All, >> >> I am tasked with replacing an old linux router setup with Juniper gear in >> the near future. Though I am a Cisco guy myself. >> >> Does anyone know of any older cheap Juniper gear I might find on Ebay so >> that I may build a home lab without going broke? >> >> Thanks! >> >> > -- Eduardo Schoedler ESDS Consultoria de TI From aris033 at hotmail.com Tue Apr 10 13:48:55 2012 From: aris033 at hotmail.com (Aris Lambrianidis) Date: Tue, 10 Apr 2012 18:48:55 +0000 (UTC) Subject: AMS-IX for local loop References: Message-ID: Shacolby Jackson bluejeans.com> writes: > > I know this is a bit off topic since Amsterdam isn't exactly in North > America but... Has anyone used AMS-IX for a private interconnect from one > datacenter to another to avoid a classic local loop to another party or > provider? For example, I'm in Equinix but might want to connect directly to > someone at Interxion. > > -shac > > Hello Shac, Yes. Please see http://www.ams-ix.net/private-interconnect/ --Aris From owen at delong.com Tue Apr 10 13:57:31 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Apr 2012 11:57:31 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> Message-ID: <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> On Apr 10, 2012, at 7:58 AM, Owen DeLong wrote: > > On Apr 10, 2012, at 7:24 AM, Tim Eberhard wrote: > >> I find it humorous that you think J/SRX junos isn't real junos. >> >> So what makes it not real junos? The fact it has a flowd process? Lets >> technically talk about this for a moment. >> > > The fact that you can't put it into flow mode. s/flow/packet/ (oops, wasn't awake yet) > >> Realistically one of the only differences between "flow based junos" >> and the legacy "packet based junos" is the flowd process. Which can be >> easily bypassed by issuing a couple of configuration commands. So what >> exactly makes this platform/code so horrible and not "real" junos? > > Actually, not. Try again. It can be partially bypassed. There are real and > serious differences in how forwarding works in flow-based JunOS and > how it behaves under many circumstances. > >> If anything to me it's a better platform to deploy and learn on. It's >> more flexible as it comes with more advanced flow based features but >> they are optional. There are certain limitations as mentioned >> previously around the switching and class of service however these >> same feature limitations were also in the "real" junos low end >> devices. > > They aren't entirely optional and that is the problem. You can't actually > completely bypass them and they do sometimes get in the way. > >> If there are other differences that I am unaware of then by all means >> feel free to educate me. I am well aware that branch devices don't >> have the capabilities of the MX/M series in regards to ATM and other >> such specific platforms, but you called this "not real junos". So lets >> keep any responses limited to that aspect. > > I believe that the flow-based routing goes quite a bit deeper than > just having a flowd. It causes a number of problems with tunnel > recursion among other things. > > Sure, if you want a firewall, flow-based JunOS is a pretty nice set of > firewall features. However, if you just want to forward packets, it can > really suck to have to work around it's flow-based "features". > > Owen > >> >> -Tim Eberhard >> >> >> >> On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong wrote: >> >>> If you want real JunOS, avoid SRX or J series at all costs. >>> >>>> Juniper do have a bunch more lines, but those are the most common >>>> (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are >>>> not long for this world). >>>> >>> >>> Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products. >>> >>>> If you just want one box to get to know the OS an SRX2X0 (or possibly a >>>> 100) is by far the most flexible way, and can be had for < $500 used). >>> >>> With the caveat about Services JunOS above. >>> >>> Owen >>> >>> > From eric at telic.us Tue Apr 10 14:08:17 2012 From: eric at telic.us (Eric Krichbaum) Date: Tue, 10 Apr 2012 14:08:17 -0500 Subject: AMS-IX for local loop In-Reply-To: References: Message-ID: <01b801cd174d$4c7c0810$e5741830$@telic.us> I just checked. It was uploaded. The database was backed up with version 10.50.1600 (SQL Server 2008R2) and this is running 10.00.5500 (SQL Server 2008) and reporting an error. I'll have to reload the server version before I can import that db. -----Original Message----- From: Aris Lambrianidis [mailto:aris033 at hotmail.com] Sent: Tuesday, April 10, 2012 1:49 PM To: nanog at nanog.org Subject: Re: AMS-IX for local loop Shacolby Jackson bluejeans.com> writes: > > I know this is a bit off topic since Amsterdam isn't exactly in North > America but... Has anyone used AMS-IX for a private interconnect from > one datacenter to another to avoid a classic local loop to another > party or provider? For example, I'm in Equinix but might want to > connect directly to someone at Interxion. > > -shac > > Hello Shac, Yes. Please see http://www.ams-ix.net/private-interconnect/ --Aris From eric at telic.us Tue Apr 10 14:11:16 2012 From: eric at telic.us (Eric Krichbaum) Date: Tue, 10 Apr 2012 14:11:16 -0500 Subject: AMS-IX for local loop In-Reply-To: <01b801cd174d$4c7c0810$e5741830$@telic.us> References: <01b801cd174d$4c7c0810$e5741830$@telic.us> Message-ID: <01ba01cd174d$b713c820$253b5860$@telic.us> Apologies for the list noise. -----Original Message----- From: Eric Krichbaum [mailto:eric at telic.us] Sent: Tuesday, April 10, 2012 2:08 PM To: 'Aris Lambrianidis'; nanog at nanog.org Subject: RE: AMS-IX for local loop I just checked. It was uploaded. The database was backed up with version 10.50.1600 (SQL Server 2008R2) and this is running 10.00.5500 (SQL Server 2008) and reporting an error. I'll have to reload the server version before I can import that db. -----Original Message----- From: Aris Lambrianidis [mailto:aris033 at hotmail.com] Sent: Tuesday, April 10, 2012 1:49 PM To: nanog at nanog.org Subject: Re: AMS-IX for local loop Shacolby Jackson bluejeans.com> writes: > > I know this is a bit off topic since Amsterdam isn't exactly in North > America but... Has anyone used AMS-IX for a private interconnect from > one datacenter to another to avoid a classic local loop to another > party or provider? For example, I'm in Equinix but might want to > connect directly to someone at Interxion. > > -shac > > Hello Shac, Yes. Please see http://www.ams-ix.net/private-interconnect/ --Aris From mysidia at gmail.com Tue Apr 10 18:05:40 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 10 Apr 2012 18:05:40 -0500 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> Message-ID: On Tue, Apr 10, 2012 at 9:24 AM, Tim Eberhard wrote: > I find it humorous that you think J/SRX junos isn't real junos. > If it runs JunOS, then yeah, it's real JunOS. It might not have the feature you're looking for, but that's something different. The Juniper ERX edge routers are what isn't "real" JunOS. It's as if they were trying to make a clone of the IOS CLI: http://www.juniper.net/techpubs/en_US/junose10.2/information-products/topic-collections/swconfig-system-basics/id-21972.html#jd0e9955 -- -JH From randy at psg.com Tue Apr 10 18:33:59 2012 From: randy at psg.com (Randy Bush) Date: Wed, 11 Apr 2012 08:33:59 +0900 Subject: Cheap Juniper Gear for Lab In-Reply-To: <4F844A52.3090509@gmail.com> References: <4F83B795.4010301@kingrst.com> <4F844A52.3090509@gmail.com> Message-ID: > http://www.juniper.net/us/en/products-services/software/junos-platform/junosphere/lab/ use. like. randy From prox at prolixium.com Tue Apr 10 20:02:07 2012 From: prox at prolixium.com (Mark Kamichoff) Date: Tue, 10 Apr 2012 21:02:07 -0400 Subject: Cheap Juniper Gear for Lab In-Reply-To: <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> Message-ID: <20120411010207.GA2368@prolixium.com> On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote: > > The fact that you can't put it into flow mode. > s/flow/packet/ > (oops, wasn't awake yet) Actually, this is possible: prox at asgard> show configuration security forwarding-options { family { inet6 { mode packet-based; } mpls { mode packet-based; } } } The above is from an SRX210B, but the same configuration will work on any J-series or /branch/ SRX-series platform. Don't let the "mpls" keyword throw you off. This actually causes the box to run the inet /and/ mpls address families in packet mode. - Mark -- Mark Kamichoff prox at prolixium.com http://www.prolixium.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From owen at delong.com Tue Apr 10 20:23:55 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Apr 2012 18:23:55 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> Message-ID: <9D10559B-E305-4A18-938D-608048F238CC@delong.com> On Apr 10, 2012, at 4:05 PM, Jimmy Hess wrote: > On Tue, Apr 10, 2012 at 9:24 AM, Tim Eberhard wrote: >> I find it humorous that you think J/SRX junos isn't real junos. >> > If it runs JunOS, then yeah, it's real JunOS. It might not have the > feature you're looking for, but that's something different. > No, it's not. Flow mode is NOT packet mode and it doesn't really ever run packet mode in the current version. This has fundamental and significant impacts on the way packets are handled when being forwarded through the box which come with side-effects that cannot be overcome by mere configuration changes. > The Juniper ERX edge routers are what isn't "real" JunOS. > It's as if they were trying to make a clone of the IOS CLI: > Those are not JunOS at all. They don't really try to pretend to be. The SRX and J-Series Services routers, OTOH, are most definitely pretending to be JunOS while not behaving like JunOS at certain fundamental levels. Owen From xmin0s at gmail.com Tue Apr 10 20:31:04 2012 From: xmin0s at gmail.com (Tim Eberhard) Date: Tue, 10 Apr 2012 20:31:04 -0500 Subject: Cheap Juniper Gear for Lab In-Reply-To: <9D10559B-E305-4A18-938D-608048F238CC@delong.com> References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <9D10559B-E305-4A18-938D-608048F238CC@delong.com> Message-ID: Owen, While I know you are a smart engineer and obviously have been working with this gear for a long time you're really not adding anything or backing up your argument besides saying yet again the packet forwarding is different. While this maybe true..It's my understanding that enabling packet mode does turn it into a normal packet based junos. Admittedly I have limited experience with turning these branch devices into pure packet mode so instead of repeating the same thing over and over why not provide links and other documentation showing the difference? On Tue, Apr 10, 2012 at 8:23 PM, Owen DeLong wrote: > > On Apr 10, 2012, at 4:05 PM, Jimmy Hess wrote: > >> On Tue, Apr 10, 2012 at 9:24 AM, Tim Eberhard wrote: >>> I find it humorous that you think J/SRX junos isn't real junos. >>> >> If it runs JunOS, then yeah, it's real JunOS. ? It might not have the >> feature you're looking for, but that's something different. >> > No, it's not. Flow mode is NOT packet mode and it doesn't really ever run packet > mode in the current version. This has fundamental and significant impacts on the > way packets are handled when being forwarded through the box which come with > side-effects that cannot be overcome by mere configuration changes. > >> The ?Juniper ERX edge routers are what isn't ?"real" ?JunOS. >> It's as if they were trying to make a clone of the IOS CLI: >> > > Those are not JunOS at all. They don't really try to pretend to be. > > The SRX and J-Series Services routers, OTOH, are most definitely pretending to be > JunOS while not behaving like JunOS at certain fundamental levels. > > Owen > From owen at delong.com Tue Apr 10 20:30:37 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Apr 2012 18:30:37 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: <20120411010207.GA2368@prolixium.com> References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> <20120411010207.GA2368@prolixium.com> Message-ID: On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote: > On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote: >>> The fact that you can't put it into flow mode. >> s/flow/packet/ >> (oops, wasn't awake yet) > > Actually, this is possible: > > prox at asgard> show configuration security > forwarding-options { > family { > inet6 { > mode packet-based; > } > mpls { > mode packet-based; > } > } > } > > The above is from an SRX210B, but the same configuration will work on > any J-series or /branch/ SRX-series platform. > Right, sort of. To the extent that it works. It doesn't actually do everything you think it should, and, it's somewhat dependent on the version of JunOS as to how well it does or doesn't work. > Don't let the "mpls" keyword throw you off. This actually causes the > box to run the inet /and/ mpls address families in packet mode. > I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for over a year and it escalated quite high up their escalation chain before they finally admitted "Yeah, Services JunOS is different and it behaves differently and if you need to do what you're trying to do, you should buy an M or MX series." It's quite unfortunate. I'd really like for the SRX series to not be so crippled for my purposes. Owen From surfer at mauigateway.com Tue Apr 10 20:40:36 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 10 Apr 2012 18:40:36 -0700 Subject: Cheap Juniper Gear for Lab Message-ID: <20120410184036.85D883ED@m0005311.ppops.net> --- mysidia at gmail.com wrote: From: Jimmy Hess The Juniper ERX edge routers are what isn't "real" JunOS. It's as if they were trying to make a clone of the IOS CLI: http://www.juniper.net/techpubs/en_US/junose10.2/information-products/topic-collections/swconfig-system-basics/id-21972.html#jd0e9955 ------------------------------------------ That's because Juniper bought the ERX series from Unisphere. It's not a "real" JunOS. My suggestion: if you make a lot of changes stay away from the ERXs, but if you don't do much to them they will mostly purr along just fine. I was running them fairly hard, with 30K plus ATM/DSL subs per router... scott From leigh.porter at ukbroadband.com Wed Apr 11 01:35:32 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 11 Apr 2012 06:35:32 +0000 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> <20120411010207.GA2368@prolixium.com>, Message-ID: On 11 Apr 2012, at 02:34, "Owen DeLong" wrote:. > >> Don't let the "mpls" keyword throw you off. This actually causes the >> box to run the inet /and/ mpls address families in packet mode. >> > > I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for > over a year and it escalated quite high up their escalation chain before they > finally admitted "Yeah, Services JunOS is different and it behaves differently > and if you need to do what you're trying to do, you should buy an M or MX > series." > > It's quite unfortunate. I'd really like for the SRX series to not be so crippled for > my purposes. Do you have an example of this crippledness? -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From ido at oasis-tech.net Wed Apr 11 01:55:48 2012 From: ido at oasis-tech.net (Ido Szargel) Date: Wed, 11 Apr 2012 09:55:48 +0300 Subject: facebook ipv6 is down? Message-ID: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> Hi, It seems that on the last 3 hours facebook isn't available via ipv6, when tracing from HE I don't even get to FB network, only as far as Ashburn on their network, When tracing from nl-ix I get to facebook network but the trace stops traceroute6 -I www.v6.facebook.com traceroute to www.v6.facebook.com (2620:0:1cfe:face:b00c:0:3:0), 30 hops max, 40 byte packets 1 2a01:1b0:705::f (2a01:1b0:705::f) 3.858 ms 3.744 ms 3.504 ms 2 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 2.133 ms 2.061 ms 1.923 ms 3 br01.ams1.tfbnw.net (2001:7f8:1::a503:2934:1) 3.276 ms 3.159 ms 3.000 ms 4 ae28.bb02.iad1.tfbnw.net (2620:0:1cff:dead:beef::485) 90.835 ms 91.009 ms 90.953 ms 5 ae12.bb02.sjc1.tfbnw.net (2620:0:1cff:dead:beef::85) 160.883 ms 160.820 ms 160.897 ms 6 ae2.pr01.sjc1.tfbnw.net (2620:0:1cff:dead:beef::10) 152.688 ms 152.638 ms 152.890 ms 7 * * * 8 * * * 9 * * * 10 * * * Is anyone else having the same issue? Thanks, Ido -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6073 bytes Desc: not available URL: From aftab.siddiqui at gmail.com Wed Apr 11 01:59:59 2012 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 11 Apr 2012 11:59:59 +0500 Subject: facebook ipv6 is down? In-Reply-To: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> Message-ID: Yes, its down from Asian route via C&W for atleast an hour now (first problem reported). Regards, Aftab A. Siddiqui On Wed, Apr 11, 2012 at 11:55 AM, Ido Szargel wrote: > Hi, > > > > It seems that on the last 3 hours facebook isn't available via ipv6, when > tracing from HE I don't even get to FB network, only as far as Ashburn on > their network, > > When tracing from nl-ix I get to facebook network but the trace stops > > > > traceroute6 -I www.v6.facebook.com > > traceroute to www.v6.facebook.com (2620:0:1cfe:face:b00c:0:3:0), 30 hops > max, 40 byte packets > > 1 2a01:1b0:705::f (2a01:1b0:705::f) 3.858 ms 3.744 ms 3.504 ms > > 2 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 2.133 ms 2.061 ms > 1.923 ms > > 3 br01.ams1.tfbnw.net (2001:7f8:1::a503:2934:1) 3.276 ms 3.159 ms > 3.000 > ms > > 4 ae28.bb02.iad1.tfbnw.net (2620:0:1cff:dead:beef::485) 90.835 ms > 91.009 > ms 90.953 ms > > 5 ae12.bb02.sjc1.tfbnw.net (2620:0:1cff:dead:beef::85) 160.883 ms > 160.820 > ms 160.897 ms > > 6 ae2.pr01.sjc1.tfbnw.net (2620:0:1cff:dead:beef::10) 152.688 ms > 152.638 > ms 152.890 ms > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > > > Is anyone else having the same issue? > > > > Thanks, > > Ido > > From frnkblk at iname.com Wed Apr 11 02:16:22 2012 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 11 Apr 2012 02:16:22 -0500 Subject: facebook ipv6 is down? In-Reply-To: References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> Message-ID: <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> It's been down three times today, first from 2:58 pm to 5:58 pm Central, and then again from 7:59 pm to 9:58 pm, and then again from 10:59 pm till now. Interesting that the up and downs have been one to two minutes before the hour. Frank -----Original Message----- From: Aftab Siddiqui [mailto:aftab.siddiqui at gmail.com] Sent: Wednesday, April 11, 2012 2:00 AM To: Ido Szargel Cc: NANOG list (nanog at nanog.org) Subject: Re: facebook ipv6 is down? Yes, its down from Asian route via C&W for atleast an hour now (first problem reported). Regards, Aftab A. Siddiqui On Wed, Apr 11, 2012 at 11:55 AM, Ido Szargel wrote: > Hi, > > > > It seems that on the last 3 hours facebook isn't available via ipv6, when > tracing from HE I don't even get to FB network, only as far as Ashburn on > their network, > > When tracing from nl-ix I get to facebook network but the trace stops > > > > traceroute6 -I www.v6.facebook.com > > traceroute to www.v6.facebook.com (2620:0:1cfe:face:b00c:0:3:0), 30 hops > max, 40 byte packets > > 1 2a01:1b0:705::f (2a01:1b0:705::f) 3.858 ms 3.744 ms 3.504 ms > > 2 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 2.133 ms 2.061 ms > 1.923 ms > > 3 br01.ams1.tfbnw.net (2001:7f8:1::a503:2934:1) 3.276 ms 3.159 ms > 3.000 > ms > > 4 ae28.bb02.iad1.tfbnw.net (2620:0:1cff:dead:beef::485) 90.835 ms > 91.009 > ms 90.953 ms > > 5 ae12.bb02.sjc1.tfbnw.net (2620:0:1cff:dead:beef::85) 160.883 ms > 160.820 > ms 160.897 ms > > 6 ae2.pr01.sjc1.tfbnw.net (2620:0:1cff:dead:beef::10) 152.688 ms > 152.638 > ms 152.890 ms > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > > > Is anyone else having the same issue? > > > > Thanks, > > Ido > > From tore.anderson at redpill-linpro.com Wed Apr 11 02:17:13 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 11 Apr 2012 09:17:13 +0200 Subject: facebook ipv6 is down? In-Reply-To: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> Message-ID: <4F852FF9.1010500@redpill-linpro.com> * Ido Szargel > It seems that on the last 3 hours facebook isn't available via ipv6, when > tracing from HE I don't even get to FB network, only as far as Ashburn on > their network, > > When tracing from nl-ix I get to facebook network but the trace stops > Is anyone else having the same issue? Yes, but only to their IPv6-only host name. Their main host name works. $ curl -v http://www.v6.facebook.com * About to connect() to www.v6.facebook.com port 80 (#0) * Trying 2620:0:1cfe:face:b00c:0:3:0... Timeout * connect() timed out! [...] $ curl -v http://www.facebook.com * About to connect() to www.facebook.com port 80 (#0) * Trying 2620:0:1c18:0:face:b00c:0:3... connected * Connected to www.facebook.com (2620:0:1c18:0:face:b00c:0:3) port 80 (#0) [...] -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From eric at atlantech.net Wed Apr 11 06:34:56 2012 From: eric at atlantech.net (Eric Van Tol) Date: Wed, 11 Apr 2012 07:34:56 -0400 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> <20120411010207.GA2368@prolixium.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B863E78A8BC5E@exchange.aoihq.local> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, April 10, 2012 9:31 PM > To: Mark Kamichoff > Cc: jgoodwin at studio442.com.au; nanog at nanog.org > Subject: Re: Cheap Juniper Gear for Lab > > It's quite unfortunate. I'd really like for the SRX series to not be > so crippled for > my purposes. > > Owen While it may not forward packets exactly like an M-series or MX, for the OP's purpose of simply learning JUNOS in a home lab, it will work just fine. I learned quite a bit using Olives (which don't exist), with the understanding that there were a lot of limitations. To the OP, I would also suggest checking out Juniper's website, specifically the 'Education' section. There are a ton of excellent learning tools on there - Learning Bytes, Web-Based Training, Day One books, etc.: http://www.juniper.net/us/en/training/jnbooks/ https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5853 https://learningportal.juniper.net/juniper/user_courses.aspx -evt From alexb at ripe.net Wed Apr 11 08:01:15 2012 From: alexb at ripe.net (Alex Band) Date: Wed, 11 Apr 2012 15:01:15 +0200 Subject: RPKI field experiences Message-ID: <5FA3A319-E665-4107-B44E-BC2B3E2E9D01@ripe.net> We just released a new version of our RPKI relying party software, RIPE NCC RPKI Validator 2.0.4: http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources There are now more than 7,200 RPKI valid BGP route announcements entered in the global system, so there is a solid data set to gain operational experience with. We would really like you to try it out and report back on the usability and reliability. ARINs Pilot information is here in case you want to create some of your own ROAs: https://www.arin.net/resources/rpki.html As always, the RIPE NCC RPKI Validator requires no configuration and has no dependencies other than Java 1.6 and rsync available on your system. Simply unzip the package, run ./bin/rpki-validator from the base directory and browse to http://localhost:8080 Cheers, Alex From bicknell at ufp.org Wed Apr 11 09:02:58 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 Apr 2012 07:02:58 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <9D10559B-E305-4A18-938D-608048F238CC@delong.com> Message-ID: <20120411140258.GA45401@ussenterprise.ufp.org> In a message written on Tue, Apr 10, 2012 at 08:31:04PM -0500, Tim Eberhard wrote: > While I know you are a smart engineer and obviously have been working > with this gear for a long time you're really not adding anything or > backing up your argument besides saying yet again the packet > forwarding is different. While this maybe true..It's my understanding > that enabling packet mode does turn it into a normal packet based > junos. I honestly don't remember what caused the problem when I ran into it, but the first time I configured IPv6 on a SRX I used per-packet and I had all sorts of problems. After contacting Juniper support and some friends who ran them they all told me to configure flow-based for IPv6, and it started working properly. Juniper support basically said IPv6 didn't work at all unless it was in flow mode. My vague memory at least was OSPFv3 would not come up in IPv6 per-packet mode no matter what changes were made, but with flow mode it came right up. In any event, I will back up Owen on this one. Any JunOS box with a security {} section (which I think means of Netscreen lineage) does a number of weird things when you're used to the JunOS boxes without a security section. For instance they basically default to a stateful firewall, so when I used a pair for redundancy and had asymmetrical paths it took way too many lines of config (4-5 features that had to be turned off) to make it not-stateful. That's a big surprise when you come from working on M-series. Still, they are very nice boxes, particularly for the capabilities you get at the price point. It's just that darn security {} section that seems to be quite poorly thought out, even all the working parts are just laid out in a way that's not intuitive to me and don't seem to match the rest of JunOS well. Want to list a netblock, you have to put it in an "address book". Want to list two, it has to be in an "address-book group", you can't just list them between brackets, and so on. It may be the only router platform where I turn to the web gui from time to time to configure things, otherwise it's an exercise in frustration trying to get the syntax right. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From crosevear at skytap.com Wed Apr 11 12:33:41 2012 From: crosevear at skytap.com (Carl Rosevear) Date: Wed, 11 Apr 2012 10:33:41 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> <20120411010207.GA2368@prolixium.com> Message-ID: Yeah, I have to apply the term "awful" and "annoying" to the packet mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC on the phone trying to get the thing to just pass packets. Best part was, I didn't know how to do it and nor did they! I escalated, worked with many engineers. My key statement was "I just want my router to route. Make it do what it is supposed to do. No session tracking! This is not a firewall." So, now it doesn't require valid sessions to pass packets but it does still appear to *track* sessions in some tables and I am, of course, very curious when some attack vector will fill up some table. Anyway, not the best devices for an edge router that is for sure. Which is too bad... for very small DC edge applications, the J6350 was a pretty cool router in earlier versions of JunOS that didn't decide to re-engineer your network and transit for you. Anyway I digress. But this had, in the past, been a frustrating enough issue for me that I had to share. --Carl On Tue, Apr 10, 2012 at 6:30 PM, Owen DeLong wrote: > > On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote: > >> On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote: >>>> The fact that you can't put it into flow mode. >>> s/flow/packet/ >>> (oops, wasn't awake yet) >> >> Actually, this is possible: >> >> prox at asgard> show configuration security >> forwarding-options { >> ? ?family { >> ? ? ? ?inet6 { >> ? ? ? ? ? ?mode packet-based; >> ? ? ? ?} >> ? ? ? ?mpls { >> ? ? ? ? ? ?mode packet-based; >> ? ? ? ?} >> ? ?} >> } >> >> The above is from an SRX210B, but the same configuration will work on >> any J-series or /branch/ SRX-series platform. >> > > Right, sort of. To the extent that it works. It doesn't actually do everything you > think it should, and, it's somewhat dependent on the version of JunOS as to > how well it does or doesn't work. > >> Don't let the "mpls" keyword throw you off. ?This actually causes the >> box to run the inet /and/ mpls address families in packet mode. >> > > I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for > over a year and it escalated quite high up their escalation chain before they > finally admitted "Yeah, Services JunOS is different and it behaves differently > and if you need to do what you're trying to do, you should buy an M or MX > series." > > It's quite unfortunate. I'd really like for the SRX series to not be so crippled for > my purposes. > > Owen > > -- Carl Rosevear Manager of Operations Skytap, Inc. direct (206) 588-8899 From sthaug at nethelp.no Wed Apr 11 12:45:05 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 11 Apr 2012 19:45:05 +0200 (CEST) Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <20120411010207.GA2368@prolixium.com> Message-ID: <20120411.194505.41678391.sthaug@nethelp.no> > Anyway, not the best devices for an edge router that is for sure. > Which is too bad... for very small DC edge applications, the J6350 > was a pretty cool router in earlier versions of JunOS that didn't > decide to re-engineer your network and transit for you. We have 3 J2320s in the lab, all running 9.3R3.8. That's the last *real* JunOS (no session/flow tracking) for these boxes. They'll stay in the lab, and they'll never be upgraded to anything newer. Which is too bad, I had great hopes for the J series. But at least they're nice boxes to teach the JunOS CLI and things like that... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nanog at maunier.org Wed Apr 11 13:03:38 2012 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Wed, 11 Apr 2012 20:03:38 +0200 Subject: IPv6 Launch day preparation Message-ID: Hello all, we've had an interesting day today in Paris discussing about how to prepare the IPv6 implementation in various networks. With a couple of vendors and software companies (Juniper, Cisco, A10 Networks, Fortinet, BreakingPoint, StoneSoft, Infoblox, PaloAlto) we decided to make a very technical day about IPv6 transition techniques and various ways to implement it in different type of networks. We've had the morning for some mechanisms presentations and all the afternoon with a lab interconnecting all the vendors and having various scenarios to test all the mechanisms we discussed in the morning. The lab description can be found here : http://g6.asso.fr/wp-content/uploads/2012/03/ipv6-launch-lab.pdf (it's in "frenglish" but really understable for english speaking only people, personnaly I'm dual stack french/english :-) ) Actually we had : - a Juniper MX480 with a service card to act as a eyeball network providing IPv6 only connectivity to their customers and a NAT64 (Juniper) + DNS64 (Infoblox) to allow them to reach IPv4 only contents - Stonesoft running a dual stack entreprise network (FW+IPS) that can reach all IPv4/IPv6 contents - A10 networks configured as a IPv4 load balancer and IPv6 NAT64 gateway for contents servers using private IPv4 only address space : The IPv4 only servers were reachable from IPv6 only machines - PaloAlto and Fortinet as IPv4/IPv6 Firewalls - an IPv4 only web server (to be accessible from the IPv6 only eyeball network thanks to the NAT64+DNS64 setup) - an IPv6 only web server And in order to stress all the vendors hardware/software, we had breaking point which was able to generate IPv4/IPv6 applicative traffic from several kpps/mbps to loads of Mpps/Gbps It was very interesting to have this setup on which anybody in the audience was able to ask for specific test/configuration to understand all the mechanisms. Unfortunately we did not have a link to the DFZ to run more interesting tests but we will probably have another Lab day with a better setup for this (and having all the people in the audience using their laptops to simulate eyeball customers). Our goal was mainly to make people aware about what can be done to move forward with IPv6 and I think we achieved this goal. If you have any comments, feel free to reply here. -- Pierre-Yves Maunier From me at anuragbhatia.com Wed Apr 11 13:16:28 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 11 Apr 2012 23:46:28 +0530 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE Message-ID: Hello, Does anyone here has clues on IPv6 support via Charter? We recently got BGP up on the connection and they denied for IPv6 support for now. Support engineer gave expected time of something like end of year which seems very late as per our plans. Is situation same for everyone who sits in downstream of Charter? Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6 Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of overhead. Yet to test other parameters. I heard Tunnels are usually bad. Can someone tell how to test this tunnel setup to confirm if there is a performance issue or not? I am thinking of writing a quick bash script and run via cron to test latency, packet loss and bandwidth throughput for couple of days. If anyone has better idea, please let me know. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From dxs at twitter.com Wed Apr 11 13:27:04 2012 From: dxs at twitter.com (Dan Sneddon) Date: Wed, 11 Apr 2012 11:27:04 -0700 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: <25BB2F0CE4854C50B6820B7989D7686A@twitter.com> Hurricane Electric have a presentation on testing their tunnels using Traceroute6, Tracepath6, and mtr: http://ipv6.he.net/presentations/trace6.pdf iperf now supports IPv6 and works well for testing tunnels as well. I have previously gotten good results from Hurricane Electric tunnels. -- Dan Sneddon Network Engineering & Network Security twitter | AS13414 dxs at twitter.com | Follow me! @dansneddon On Wednesday, April 11, 2012 at 11:16 AM, Anurag Bhatia wrote: > Hello, > > > Does anyone here has clues on IPv6 support via Charter? We recently got BGP > up on the connection and they denied for IPv6 support for now. Support > engineer gave expected time of something like end of year which seems very > late as per our plans. > > > Is situation same for everyone who sits in downstream of Charter? > > > Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6 > Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of > overhead. Yet to test other parameters. I heard Tunnels are usually bad. > Can someone tell how to test this tunnel setup to confirm if there is a > performance issue or not? I am thinking of writing a quick bash script and > run via cron to test latency, packet loss and bandwidth throughput for > couple of days. If anyone has better idea, please let me know. > > > > Thanks. > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > > From jim.rampley at chartercom.com Wed Apr 11 13:30:04 2012 From: jim.rampley at chartercom.com (Rampley Jr, Jim F) Date: Wed, 11 Apr 2012 13:30:04 -0500 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: <5D717D6976F4D8498089CBEE22C2EBCD33E4DD4B@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM> Anurag, We (Charter) are planning on starting early field trials with our business customers with IPv6 real soon (within Q2). We have a few customers already identified, but would you be interested in participating with us? Jim Rampley | Principal Engineer | 314-543-2505 12405 Powerscourt Drive, St. Louis, MO 63131 -----Original Message----- From: Anurag Bhatia [mailto:me at anuragbhatia.com] Sent: Wednesday, April 11, 2012 1:16 PM To: NANOG Mailing List Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE Hello, Does anyone here has clues on IPv6 support via Charter? We recently got BGP up on the connection and they denied for IPv6 support for now. Support engineer gave expected time of something like end of year which seems very late as per our plans. Is situation same for everyone who sits in downstream of Charter? Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6 Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of overhead. Yet to test other parameters. I heard Tunnels are usually bad. Can someone tell how to test this tunnel setup to confirm if there is a performance issue or not? I am thinking of writing a quick bash script and run via cron to test latency, packet loss and bandwidth throughput for couple of days. If anyone has better idea, please let me know. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From jay.hanke at mankatonetworks.com Wed Apr 11 14:03:13 2012 From: jay.hanke at mankatonetworks.com (Jay Hanke) Date: Wed, 11 Apr 2012 14:03:13 -0500 Subject: Cheap Juniper Gear for Lab In-Reply-To: <20120411.194505.41678391.sthaug@nethelp.no> References: <20120411010207.GA2368@prolixium.com> <20120411.194505.41678391.sthaug@nethelp.no> Message-ID: > We have 3 J2320s in the lab, all running 9.3R3.8. That's the last > *real* JunOS (no session/flow tracking) for these boxes. > +1 on that. We have a number of 2300s in our lab for the same purpose running 8.x code. We also use Junosphere extensively, but nothing beats real hardware. j2300s are cheap. Jay From tom.ammon at utah.edu Wed Apr 11 14:19:05 2012 From: tom.ammon at utah.edu (Tom Ammon) Date: Wed, 11 Apr 2012 19:19:05 +0000 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <20120411010207.GA2368@prolixium.com> <20120411.194505.41678391.sthaug@nethelp.no> Message-ID: <34FB1D1922F27F439B677D238AF0A4AC0AF1C2D7@X-MB10.xds.umail.utah.edu> >-----Original Message----- >From: Jay Hanke [mailto:jay.hanke at mankatonetworks.com] >Sent: Wednesday, April 11, 2012 1:03 PM >To: sthaug at nethelp.no >Cc: nanog at nanog.org >.Subject: Re: Cheap Juniper Gear for Lab > >> We have 3 J2320s in the lab, all running 9.3R3.8. That's the last >> *real* JunOS (no session/flow tracking) for these boxes. >>> > >+1 on that. We have a number of 2300s in our lab for the same purpose >running 8.x code. > >We also use Junosphere extensively, but nothing beats real hardware. >j2300s are cheap. > >Jay So, I have a question, then. For the purposes of learning JUNOS, is 8.3 code sufficient? Would you be missing a lot of features that are in newer code? I would assume IPv6 features are different between 8.3 and the latest code, is that right? Tom ----------------------------------------------------------------------------- Tom Ammon Network Engineer M: (801)674-9273 tom.ammon at utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -------------------------------L-O------------------------------------------- From seth.mos at dds.nl Wed Apr 11 14:34:31 2012 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 11 Apr 2012 21:34:31 +0200 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: Hi, Op 11 apr 2012, om 20:16 heeft Anurag Bhatia het volgende geschreven: > Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6 > Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of > overhead. Yet to test other parameters. I heard Tunnels are usually bad. > Can someone tell how to test this tunnel setup to confirm if there is a > performance issue or not? I am thinking of writing a quick bash script and > run via cron to test latency, packet loss and bandwidth throughput for > couple of days. If anyone has better idea, please let me know. Also using a HE.net BGP tunnel for our IPv6, simply because having just 1 native provider with Ipv6 isn't redundant. That and it's 8mbit. The v4 connection which the tunnel connects over is 90mbit, and the tunnel needs to travel from NL to DE for the FRA BGP peering. I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, although the throughput has slowly been dropping to the 30's range over the last 6 months. But that's probably because of the latency. For something that is provided for free I'm really glad we have it. I should have peered with their UK PoP as it's much closer by latency, thus faster. Cheers, Seth From bill at herrin.us Wed Apr 11 15:00:10 2012 From: bill at herrin.us (William Herrin) Date: Wed, 11 Apr 2012 16:00:10 -0400 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: On Wed, Apr 11, 2012 at 2:16 PM, Anurag Bhatia wrote: > Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6 > Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of > overhead. Yet to test other parameters. I heard Tunnels are usually bad. > Can someone tell how to test this tunnel setup to confirm if there is a > performance issue or not? I am thinking of writing a quick bash script and > run via cron to test latency, packet loss and bandwidth throughput for > couple of days. If anyone has better idea, please let me know. HE does a fine job with their IPv6 tunnels. If they're you're only v6 connectivity or you need them to provide a backup IPv6 route for when sole native v6 provider goes down, they're a superb choice. However... Do not, do not, do not, rig your system to prefer tunneled IPvanything to native IPvanythingelse. For all of the obvious reasons. If you publish an IPv6 address for www.anuragbhatia.com, clients with IPv6 will use that IPv6 address in preference to the address published for IPv4. If your sole IPv6 access is with a tunnel, don't publish an IPv6 address for www. Publish the IPv6 address under www6.anuragbhatia.com instead. And on your mail server, have the second MX point to a name with a AAAA, and let the first MX stay on v4. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From me at anuragbhatia.com Wed Apr 11 15:03:22 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 12 Apr 2012 01:33:22 +0530 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: Hi Seth I just did a test from Eu based server sitting below EU based HE Tunnel node by downloading Ubuntu release file from US based server. This does not tells about possible high speed but surely tells what is available atleast. Server itself is sitting on M-Online with 100Mbps pipe. IPv4: traceroute to mirror.anl.gov (146.137.96.7), 30 hops max, 60 byte packets 1 gw.giga-dns.com (91.194.90.1) [AS51167] 16.876 ms 16.925 ms 16.915 ms 2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767] 1.166 ms 1.449 ms 1.445 ms 3 xe-2-1-0.rt-decix-1.m-online.net (212.18.6.162) [AS8767] 8.889 ms 8.888 ms 8.880 ms 4 20gigabitethernet4-3.core1.fra1.he.net (80.81.192.172) [AS6695] 18.586 ms 19.831 ms 19.824 ms 5 10gigabitethernet1-4.core1.par2.he.net (184.105.213.162) [AS6939] 18.794 ms 18.789 ms 10gigabitethernet2-2.core1.par2.he.net (72.52.92.26) [AS6939] 18.437 ms 6 10gigabitethernet1-1.core1.par2.he.net (184.105.213.90) [AS6939] 18.507 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) [AS6939] 96.880 ms 97.345 ms 7 esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939] 95.544 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) [AS6939] 97.616 ms esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939] 95.354 ms 8 washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 97.835 ms esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939] 95.727 ms washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 98.492 ms 9 washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 98.463 ms washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293] 110.668 ms 110.641 ms 10 starsdn1-ip-washsdn2.es.net (134.55.218.65) [AS293] 120.357 ms 120.844 ms washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293] 110.834 ms 11 starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293] 164.788 ms 164.548 ms 164.550 ms 12 starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293] 164.758 ms anlmr2-starcr1.es.net (134.55.219.53) [AS293] 128.288 ms 128.286 ms 13 guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.532 ms anlmr2-starcr1.es.net (134.55.219.53) [AS293] 128.263 ms guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.500 ms 14 * guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.687 ms 117.858 ms 15 * * * 16 * * * 17 * * * 18 * * * root at server7:/home/anurag/tmp# wget -4 http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso --2012-04-11 21:56:46-- http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso Resolving mirror.anl.gov... 146.137.96.7 Connecting to mirror.anl.gov|146.137.96.7|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1644474368 (1.5G) [application/octet-stream] Saving to: `ubuntu-12.04-beta2-dvd-i386.iso.1' 100%[============================================================================================================================>] 1,644,474,368 4.78M/s in 5m 38s 2012-04-11 22:02:25 (4.64 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso.1' saved [1644474368/1644474368] IPv6: traceroute to mirror.anl.gov (2620:0:dc0:1800:214:4fff:fe7d:1b9), 30 hops max, 80 byte packets 1 2001:470:25:78f::1 (2001:470:25:78f::1) [AS6939] 18.918 ms 21.147 ms 23.357 ms 2 gige-g2-20.core1.zrh1.he.net (2001:470:0:11d::1) [AS6939] 23.341 ms 23.324 ms 23.797 ms 3 10gigabitethernet5-1.core1.fra1.he.net (2001:470:0:21c::1) [AS6939] 29.781 ms 30.252 ms 23.671 ms 4 10gigabitethernet5-3.core1.lon1.he.net (2001:470:0:1d2::1) [AS6939] 37.897 ms 37.880 ms 43.095 ms 5 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) [AS6939] 104.552 ms 105.763 ms 105.742 ms 6 10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1) [AS6939] 113.963 ms 114.467 ms 111.478 ms 7 lawrence-berkeley-national-laboratory.gigabitethernet4-15.core1.ash1.he.net(2001:470:1:27f::2) [AS6939] 109.467 ms 109.452 ms 109.435 ms 8 washcr1-te-eqxashrt1.es.net (2001:400:0:15a::1) [AS293] 115.929 ms 113.625 ms 115.896 ms 9 washsdn1-sdn2-washcr1.es.net (2001:400:0:e0::2) [AS293] 114.606 ms 112.068 ms 112.045 ms 10 starsdn1-ip-washsdn2.es.net (2001:400:0:ab::1) [AS293] 126.783 ms 130.008 ms 126.747 ms 11 starcr1-ip-starsdn1.es.net (2001:400:0:a2::2) [AS293] 127.268 ms 124.223 ms 124.125 ms 12 anlmr2-starcr1.es.net (2001:400:0:c0::1) [AS293] 128.066 ms 130.529 ms 130.513 ms 13 2001:400:2202:8::2 (2001:400:2202:8::2) [AS293] 130.976 ms 128.915 ms 128.892 ms 14 * * * 15 * * * root at server7:/home/anurag/tmp# wget -6 http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso --2012-04-11 21:45:52-- http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso Resolving mirror.anl.gov... 2620:0:dc0:1800:214:4fff:fe7d:1b9 Connecting to mirror.anl.gov|2620:0:dc0:1800:214:4fff:fe7d:1b9|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1644474368 (1.5G) [application/octet-stream] Saving to: `ubuntu-12.04-beta2-dvd-i386.iso' 100%[============================================================================================================================>] 1,644,474,368 *3.66M/s in 6m 11s* 2012-04-11 21:52:04 (4.22 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso' saved [1644474368/1644474368] On Thu, Apr 12, 2012 at 1:04 AM, Seth Mos wrote: > Hi, > > Op 11 apr 2012, om 20:16 heeft Anurag Bhatia het volgende geschreven: > > > Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6 > > Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of > > overhead. Yet to test other parameters. I heard Tunnels are usually bad. > > Can someone tell how to test this tunnel setup to confirm if there is a > > performance issue or not? I am thinking of writing a quick bash script > and > > run via cron to test latency, packet loss and bandwidth throughput for > > couple of days. If anyone has better idea, please let me know. > > Also using a HE.net BGP tunnel for our IPv6, simply because having just 1 > native provider with Ipv6 isn't redundant. That and it's 8mbit. > > The v4 connection which the tunnel connects over is 90mbit, and the tunnel > needs to travel from NL to DE for the FRA BGP peering. > > I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works > well, although the throughput has slowly been dropping to the 30's range > over the last 6 months. But that's probably because of the latency. > > For something that is provided for free I'm really glad we have it. > > I should have peered with their UK PoP as it's much closer by latency, > thus faster. > > Cheers, > > Seth > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From leigh.porter at ukbroadband.com Wed Apr 11 15:29:33 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 11 Apr 2012 20:29:33 +0000 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> <20120411010207.GA2368@prolixium.com> , Message-ID: <8FC61074-8591-4A86-BACD-BD3249B91EE3@ukbroadband.com> On 11 Apr 2012, at 18:36, "Carl Rosevear" wrote: > Yeah, I have to apply the term "awful" and "annoying" to the packet > mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC > on the phone trying to get the thing to just pass packets. Best part > was, I didn't know how to do it and nor did they! I escalated, worked > with many engineers. My key statement was "I just want my router to > route. Make it do what it is supposed to do. No session tracking! > This is not a firewall." So, now it doesn't require valid sessions to > pass packets but it does still appear to *track* sessions in some > tables and I am, of course, very curious when some attack vector will > fill up some table. > I have had some rather odd issues with the SRX boxes but JTAC were pretty good at turning around fixes for me for my specific issues. Since then I have had quite a lot of SRX boxes across the range running various MPLS services including MPLS over GRE with fragmentation/reassembly which has been working very well. Since 11.1R3 I've had no issues at all with them. So yeah the new flow mode stuff had its issues, but as a *small* MPLS box it is very functional. Of course in MPLS mode, you turn the flow stuff off.. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From charles-lists at knownelement.com Wed Apr 11 16:14:15 2012 From: charles-lists at knownelement.com (Charles N Wyble) Date: Wed, 11 Apr 2012 16:14:15 -0500 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: <4F85F427.8040701@knownelement.com> On 04/11/2012 02:34 PM, Seth Mos wrote: > > > I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, although the throughput has slowly been dropping to the 30's range over the last 6 months. But that's probably because of the latency. > > For something that is provided for free I'm really glad we have it. Indeed. It's pretty amazing what HE has put together. > I should have peered with their UK PoP as it's much closer by latency, thus faster. Why don't you? Can you setup more then one peering? From paul4004 at gmail.com Wed Apr 11 16:19:25 2012 From: paul4004 at gmail.com (PC) Date: Wed, 11 Apr 2012 15:19:25 -0600 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: He.net tunnels are also good to have because depending on your provider, there's still many with incomplete views of the ipv6 routing table and he might have a path. This is a more prevalent issue with ipv6 than v4 at the moment. On Apr 11, 2012 2:03 PM, "Anurag Bhatia" wrote: > Hi Seth > > > I just did a test from Eu based server sitting below EU based HE Tunnel > node by downloading Ubuntu release file from US based server. This does not > tells about possible high speed but surely tells what is available atleast. > Server itself is sitting on M-Online with 100Mbps pipe. > > > > > IPv4: > > traceroute to mirror.anl.gov (146.137.96.7), 30 hops max, 60 byte packets > 1 gw.giga-dns.com (91.194.90.1) [AS51167] 16.876 ms 16.925 ms 16.915 > ms > 2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767] > 1.166 ms 1.449 ms 1.445 ms > 3 xe-2-1-0.rt-decix-1.m-online.net (212.18.6.162) [AS8767] 8.889 ms > 8.888 ms 8.880 ms > 4 20gigabitethernet4-3.core1.fra1.he.net (80.81.192.172) [AS6695] > 18.586 > ms 19.831 ms 19.824 ms > 5 10gigabitethernet1-4.core1.par2.he.net (184.105.213.162) [AS6939] > 18.794 ms 18.789 ms 10gigabitethernet2-2.core1.par2.he.net (72.52.92.26) > [AS6939] 18.437 ms > 6 10gigabitethernet1-1.core1.par2.he.net (184.105.213.90) [AS6939] > 18.507 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) > [AS6939] > 96.880 ms 97.345 ms > 7 esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939] > 95.544 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) > [AS6939] > 97.616 ms esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) > [AS6939] 95.354 ms > 8 washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 97.835 ms > esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939] > 95.727 > ms washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 98.492 ms > 9 washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293] 98.463 ms > washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293] 110.668 ms 110.641 > ms > 10 starsdn1-ip-washsdn2.es.net (134.55.218.65) [AS293] 120.357 ms > 120.844 ms washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293] 110.834 > ms > 11 starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293] 164.788 ms > 164.548 > ms 164.550 ms > 12 starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293] 164.758 ms > anlmr2-starcr1.es.net (134.55.219.53) [AS293] 128.288 ms 128.286 ms > 13 guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.532 ms > anlmr2-starcr1.es.net (134.55.219.53) [AS293] 128.263 ms > guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.500 ms > 14 * guava-esnet.anchor.anl.gov (192.5.170.77) [AS683] 117.687 ms > 117.858 ms > 15 * * * > 16 * * * > 17 * * * > 18 * * * > > > root at server7:/home/anurag/tmp# wget -4 > > http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso > --2012-04-11 21:56:46-- > > http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso > Resolving mirror.anl.gov... 146.137.96.7 > Connecting to mirror.anl.gov|146.137.96.7|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1644474368 (1.5G) [application/octet-stream] > Saving to: `ubuntu-12.04-beta2-dvd-i386.iso.1' > > > 100%[============================================================================================================================>] > 1,644,474,368 4.78M/s in 5m 38s > > 2012-04-11 22:02:25 (4.64 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso.1' saved > [1644474368/1644474368] > > > > > > > > > IPv6: > > > traceroute to mirror.anl.gov (2620:0:dc0:1800:214:4fff:fe7d:1b9), 30 hops > max, 80 byte packets > 1 2001:470:25:78f::1 (2001:470:25:78f::1) [AS6939] 18.918 ms 21.147 ms > 23.357 ms > 2 gige-g2-20.core1.zrh1.he.net (2001:470:0:11d::1) [AS6939] 23.341 ms > 23.324 ms 23.797 ms > 3 10gigabitethernet5-1.core1.fra1.he.net (2001:470:0:21c::1) [AS6939] > 29.781 ms 30.252 ms 23.671 ms > 4 10gigabitethernet5-3.core1.lon1.he.net (2001:470:0:1d2::1) [AS6939] > 37.897 ms 37.880 ms 43.095 ms > 5 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) [AS6939] > 104.552 ms 105.763 ms 105.742 ms > 6 10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1) [AS6939] > 113.963 ms 114.467 ms 111.478 ms > 7 > lawrence-berkeley-national-laboratory.gigabitethernet4-15.core1.ash1.he.net > (2001:470:1:27f::2) > [AS6939] 109.467 ms 109.452 ms 109.435 ms > 8 washcr1-te-eqxashrt1.es.net (2001:400:0:15a::1) [AS293] 115.929 ms > 113.625 ms 115.896 ms > 9 washsdn1-sdn2-washcr1.es.net (2001:400:0:e0::2) [AS293] 114.606 ms > 112.068 ms 112.045 ms > 10 starsdn1-ip-washsdn2.es.net (2001:400:0:ab::1) [AS293] 126.783 ms > 130.008 ms 126.747 ms > 11 starcr1-ip-starsdn1.es.net (2001:400:0:a2::2) [AS293] 127.268 ms > 124.223 ms 124.125 ms > 12 anlmr2-starcr1.es.net (2001:400:0:c0::1) [AS293] 128.066 ms 130.529 > ms 130.513 ms > 13 2001:400:2202:8::2 (2001:400:2202:8::2) [AS293] 130.976 ms 128.915 ms > 128.892 ms > 14 * * * > 15 * * * > > > > > > > > > root at server7:/home/anurag/tmp# wget -6 > > http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso > --2012-04-11 21:45:52-- > > http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso > Resolving mirror.anl.gov... 2620:0:dc0:1800:214:4fff:fe7d:1b9 > Connecting to mirror.anl.gov|2620:0:dc0:1800:214:4fff:fe7d:1b9|:80... > connected. > HTTP request sent, awaiting response... 200 OK > Length: 1644474368 (1.5G) [application/octet-stream] > Saving to: `ubuntu-12.04-beta2-dvd-i386.iso' > > > 100%[============================================================================================================================>] > 1,644,474,368 *3.66M/s in 6m 11s* > > 2012-04-11 21:52:04 (4.22 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso' saved > [1644474368/1644474368] > > > On Thu, Apr 12, 2012 at 1:04 AM, Seth Mos wrote: > > > Hi, > > > > Op 11 apr 2012, om 20:16 heeft Anurag Bhatia het volgende geschreven: > > > > > Also, does it makes sense to go for BGP Tunnel for now? I just setup > IPv6 > > > Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms > of > > > overhead. Yet to test other parameters. I heard Tunnels are usually > bad. > > > Can someone tell how to test this tunnel setup to confirm if there is a > > > performance issue or not? I am thinking of writing a quick bash script > > and > > > run via cron to test latency, packet loss and bandwidth throughput for > > > couple of days. If anyone has better idea, please let me know. > > > > Also using a HE.net BGP tunnel for our IPv6, simply because having just 1 > > native provider with Ipv6 isn't redundant. That and it's 8mbit. > > > > The v4 connection which the tunnel connects over is 90mbit, and the > tunnel > > needs to travel from NL to DE for the FRA BGP peering. > > > > I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works > > well, although the throughput has slowly been dropping to the 30's range > > over the last 6 months. But that's probably because of the latency. > > > > For something that is provided for free I'm really glad we have it. > > > > I should have peered with their UK PoP as it's much closer by latency, > > thus faster. > > > > Cheers, > > > > Seth > > > > > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > From jared at puck.nether.net Wed Apr 11 16:41:17 2012 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Apr 2012 17:41:17 -0400 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: Message-ID: <0D26CF48-6FE3-4E3D-ABC8-4C2C7BEE398D@puck.nether.net> On Apr 11, 2012, at 5:19 PM, PC wrote: > He.net tunnels are also good to have because depending on your provider, > there's still many with incomplete views of the ipv6 routing table and he > might have a path. This is a more prevalent issue with ipv6 than v4 at the > moment. This is a big problem for the two providers involved in this "spat" having inconsistent IPv4/IPv6 business relationships (peering, etc). There are many professional service providers that will happily dual-stack your internet port with consistent business relationships. Don't let these two parties that so far have agreed to disagree prevent you from using IPv6 to its fullest. Select another carrier. - Jared From jeff.richmond at gmail.com Wed Apr 11 17:06:17 2012 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Wed, 11 Apr 2012 15:06:17 -0700 Subject: Cheap Juniper Gear for Lab In-Reply-To: <8FC61074-8591-4A86-BACD-BD3249B91EE3@ukbroadband.com> References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> <20120411010207.GA2368@prolixium.com> , <8FC61074-8591-4A86-BACD-BD3249B91EE3@ukbroadband.com> Message-ID: <9343468A-3E1F-4313-9E35-1C0F8A20B90A@gmail.com> FWIW, when I took my JNCIE, I used all J-series running flow code (disabled) for my study pod and never had any issues. I have 9 physical routers plus a bunch of VRs on them. I agree there can be issues depending on what you are trying to do, but I am not sure why this is such a big deal if this is just a lab setup. I wouldn't test something on a J-series and expect to deploy it on M/MX/T in production or something, but that wasn't what the OP was asking to do. For a home lab I can't think of any reason not to use some J-series boxes. -Jeff On Apr 11, 2012, at 1:29 PM, Leigh Porter wrote: > > On 11 Apr 2012, at 18:36, "Carl Rosevear" wrote: > >> Yeah, I have to apply the term "awful" and "annoying" to the packet >> mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC >> on the phone trying to get the thing to just pass packets. Best part >> was, I didn't know how to do it and nor did they! I escalated, worked >> with many engineers. My key statement was "I just want my router to >> route. Make it do what it is supposed to do. No session tracking! >> This is not a firewall." So, now it doesn't require valid sessions to >> pass packets but it does still appear to *track* sessions in some >> tables and I am, of course, very curious when some attack vector will >> fill up some table. >> > > I have had some rather odd issues with the SRX boxes but JTAC were pretty good at turning around fixes for me for my specific issues. > > Since then I have had quite a lot of SRX boxes across the range running various MPLS services including MPLS over GRE with fragmentation/reassembly which has been working very well. Since 11.1R3 I've had no issues at all with them. > > So yeah the new flow mode stuff had its issues, but as a *small* MPLS box it is very functional. Of course in MPLS mode, you turn the flow stuff off.. > > > -- > Leigh Porter > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > From bill at herrin.us Wed Apr 11 17:19:07 2012 From: bill at herrin.us (William Herrin) Date: Wed, 11 Apr 2012 18:19:07 -0400 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: <0D26CF48-6FE3-4E3D-ABC8-4C2C7BEE398D@puck.nether.net> References: <0D26CF48-6FE3-4E3D-ABC8-4C2C7BEE398D@puck.nether.net> Message-ID: On Wed, Apr 11, 2012 at 5:41 PM, Jared Mauch wrote: > This is a big problem for the two providers involved in this "spat" having > inconsistent IPv4/IPv6 business relationships (peering, etc). > > There are many professional service providers that will happily dual-stack > your internet port with consistent business relationships. ?Don't let these > two parties that so far have agreed to disagree prevent you from using IPv6 > to its fullest. ?Select another carrier. Hi Jared, Is it really fair to say there are "two" parties in a peering spat when Cogent is one of them? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jared at puck.nether.net Wed Apr 11 17:35:43 2012 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Apr 2012 18:35:43 -0400 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: References: <0D26CF48-6FE3-4E3D-ABC8-4C2C7BEE398D@puck.nether.net> Message-ID: On Apr 11, 2012, at 6:19 PM, William Herrin wrote: > On Wed, Apr 11, 2012 at 5:41 PM, Jared Mauch wrote: >> This is a big problem for the two providers involved in this "spat" having >> inconsistent IPv4/IPv6 business relationships (peering, etc). >> >> There are many professional service providers that will happily dual-stack >> your internet port with consistent business relationships. Don't let these >> two parties that so far have agreed to disagree prevent you from using IPv6 >> to its fullest. Select another carrier. > > Hi Jared, > > Is it really fair to say there are "two" parties in a peering spat > when Cogent is one of them? I know that the following IPv4 as-paths appear to enumerate transit paths where the providers can do IPv6 transit as well. If HE does not take advantage of those existing IP transit connections for whichever IP version I'm not sure where I would cast blame. Perhaps those ports don't have IPv6. I have my own opinions about peering disputes which you can obtain privately. route-views>sh ip bgp 216.218.186.2 BGP routing table entry for 216.218.128.0/17, version 417045 Paths: (35 available, best #26, table Default-IP-Routing-Table) ...snip... 1239 3549 6939 6939 144.228.241.130 from 144.228.241.130 (144.228.241.130) Origin IGP, localpref 100, valid, external 2914 1299 6939 6939 129.250.0.11 from 129.250.0.11 (129.250.0.12) Origin IGP, metric 5, localpref 100, valid, external Community: 2914:420 2914:1008 2914:2000 2914:3000 65504:1299 3356 3549 6939 6939 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:3 3356:22 3356:86 3356:575 3356:666 3356:2012 3549:4143 3549:30840 701 1299 6939 6939 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin IGP, localpref 100, valid, external 1668 3549 6939 6939 66.185.128.48 from 66.185.128.48 (66.185.128.48) Origin IGP, metric 7, localpref 100, valid, external 7018 1299 6939 6939 12.0.1.63 from 12.0.1.63 (12.0.1.63) Origin IGP, localpref 100, valid, external Community: 7018:5000 3257 1299 6939 6939 89.149.178.10 from 89.149.178.10 (213.200.87.91) Origin IGP, metric 10, localpref 100, valid, external Community: 3257:8100 3257:30052 3257:50001 3257:54900 3257:54901 3561 3549 6939 6939 206.24.210.102 from 206.24.210.102 (206.24.210.102) Origin IGP, localpref 100, valid, external 6453 3549 6939 6939 66.110.0.86 from 66.110.0.86 (66.110.0.86) Origin IGP, localpref 100, valid, external From owen at delong.com Wed Apr 11 18:31:06 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Apr 2012 16:31:06 -0700 Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE In-Reply-To: <4F85F427.8040701@knownelement.com> References: <4F85F427.8040701@knownelement.com> Message-ID: <38240F28-D768-4116-8177-FA6AB379D894@delong.com> On Apr 11, 2012, at 2:14 PM, Charles N Wyble wrote: > On 04/11/2012 02:34 PM, Seth Mos wrote: >> >> >> I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, although the throughput has slowly been dropping to the 30's range over the last 6 months. But that's probably because of the latency. >> >> For something that is provided for free I'm really glad we have it. > > Indeed. It's pretty amazing what HE has put together. > >> I should have peered with their UK PoP as it's much closer by latency, thus faster. > > Why don't you? Can you setup more then one peering? > > Yes... Many of our customers set up multiple peerings. Owen From rs at seastrom.com Wed Apr 11 18:47:31 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 11 Apr 2012 19:47:31 -0400 Subject: Cheap Juniper Gear for Lab In-Reply-To: <20120411.194505.41678391.sthaug@nethelp.no> (sthaug@nethelp.no's message of "Wed, 11 Apr 2012 19:45:05 +0200 (CEST)") References: <20120411010207.GA2368@prolixium.com> <20120411.194505.41678391.sthaug@nethelp.no> Message-ID: <86obqxq19o.fsf@seastrom.com> sthaug at nethelp.no writes: >> Anyway, not the best devices for an edge router that is for sure. >> Which is too bad... for very small DC edge applications, the J6350 >> was a pretty cool router in earlier versions of JunOS that didn't >> decide to re-engineer your network and transit for you. > > We have 3 J2320s in the lab, all running 9.3R3.8. That's the last > *real* JunOS (no session/flow tracking) for these boxes. > > They'll stay in the lab, and they'll never be upgraded to anything > newer. Which is too bad, I had great hopes for the J series. Got a pair of J2350s in the previous job to run as part of a command and control network. Had the same "I just want this stuff to route!" experience that others have mentioned and griped about. We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs. That came in 10.1 or something. As a member of the ARIN Advisory Council, I felt compelled to eat the same dog food that I was selling, and we found ourselves at an impasse. We ended up putting the C&C network in VRFs on a couple of MX80s that were already there. With a few contemptuous comments on the side we sent the 2350s back to the VAR. I think my successors ended up undoing the VRFs and putting Cisco 2951s in their place. I've heard it hypothesized that this change was related to the costs of maintaining two different packet forwarding paths (remember that the J series used, in 9.3 and before, an emulation of the ASIC in the hardware based routers) and that, having decided to cancel one, they decided to cancel the "less featureful" one. This is a reasonable decision to make even if we don't like it as techies. None of the difficulties we had, however, would have gotten in the way of the OP's apparent goal of getting comfortable typing things like "show chassis environment", "request system software add", "show config | display set", and "show version and haiku". Unlike Owen I'm not going to say "useless due to security { ... }", I'm going to say "useful with caveats, and you might want to think twice about what you're trying to do before moving it out of the lab". -r From sotnickd-nanog at ddv.com Wed Apr 11 23:08:05 2012 From: sotnickd-nanog at ddv.com (Dave Sotnick) Date: Wed, 11 Apr 2012 21:08:05 -0700 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: References: Message-ID: Hello Nanog, Looks like Level3's only IPv6 route to HE is via London right now: Show Level 3 (Las Vegas, NV) Traceroute to www.he.net ?1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec ?2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec 0 msec ?3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228 msec 224 msec ?4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 msec 20 msec ?5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 msec 44 msec ?6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212 msec 224 msec ?7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216 msec 232 msec ?8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 msec 80 msec ?9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 msec 80 msec ?10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144 msec 164 msec ?11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 msec ? ?vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec ?12 2001:1900:5:3::11E 160 msec 156 msec 160 msec ?13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344 msec 208 msec 200 msec ?14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276 msec 260 msec 268 msec ?15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272 msec 272 msec 324 msec ?16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec 272 msec 276 msec ?17 ?* ?* ?* ?18 ?* ?* ?* Confirmed by L3's looking glasses ( http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true ) and my own corporate IPv6 connection from Level 3. I opened a ticket with Level 3. Anyone else seen this? -Dave From derek at derekivey.com Wed Apr 11 23:16:15 2012 From: derek at derekivey.com (Derek Ivey) Date: Thu, 12 Apr 2012 00:16:15 -0400 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: References: Message-ID: <4F86570F.9040602@derekivey.com> I'm seeing the same thing from my area (Harrisburg, PA). Strange. *Show Level 3 (Harrisburg, PA) Traceroute to www.he.net* 1 vl-17.car1.Pittsburgh3.Level3.net (2001:1900:35::21) 208 msec 200 msec 276 msec 2 vl-4044.car1.Washington1.Level3.net (2001:1900:4:1::2B9) 48 msec 208 msec 200 msec 3 vl-4083.car2.Washington1.Level3.net (2001:1900:4:1::DE) 200 msec 312 msec 104 msec 4 vl-4061.car1.NewYork2.Level3.net (2001:1900:4:1::106) 160 msec 100 msec 124 msec 5 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 156 msec 56 msec 6 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 212 msec 116 msec 248 msec 7 vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 200 msec vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 200 msec 204 msec 8 2001:1900:5:3::11E 208 msec 204 msec 208 msec 9 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 204 msec 40 msec 200 msec 10 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 408 msec 404 msec 260 msec 11 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 368 msec 380 msec 416 msec 12 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 256 msec 400 msec 224 msec C:\Users\Derek>tracert 2001:1900:35::21 (from my HE tunnel) Tracing route to vl-17.car1.Pittsburgh3.Level3.net [2001:1900:35::21] over a maximum of 30 hops: ... 3 16 ms 14 ms 21 ms gige-g4-12.core1.ash1.he.net [2001:470:0:90::1] 4 25 ms 25 ms 24 ms 10gigabitethernet1-2.core1.nyc4.he.net [2001:470:0:36::2] 5 88 ms 90 ms 98 ms 10gigabitethernet1-2.core1.lon1.he.net [2001:470:0:128::2] 6 88 ms 89 ms 89 ms ge-5-3-2.edge4.London.Level3.net [2001:1900:5:3::11d] 7 88 ms 89 ms 89 ms vl-4080.edge4.London1.Level3.net [2001:1900:5:1::105] 8 158 ms 158 ms 158 ms vl-4086.car1.NewYork1.Level3.net [2001:1900:6:1::12] 9 163 ms 163 ms 163 ms ae-2-4047.edge2.Washington12.Level3.net [2001:1900:4:1::3b9] 10 163 ms 163 ms 163 ms ae-1-4080.edge1.Washington12.Level3.net [2001:1900:4:1::3d9] 11 164 ms 164 ms 164 ms vl-4046.car1.Washington1.Level3.net [2001:1900:4:1::3b2] 12 177 ms 177 ms 187 ms vl-17.car1.Pittsburgh3.Level3.net [2001:1900:35::21] Trace complete. On 4/12/2012 12:08 AM, Dave Sotnick wrote: > Hello Nanog, > > Looks like Level3's only IPv6 route to HE is via London right now: > > Show Level 3 (Las Vegas, NV) Traceroute to www.he.net > 1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec > 2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec 0 msec > 3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228 > msec 224 msec > 4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 msec 20 msec > 5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 msec 44 msec > 6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212 > msec 224 msec > 7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216 > msec 232 msec > 8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 msec 80 msec > 9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 msec 80 msec > 10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144 > msec 164 msec > 11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 msec > vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec > 12 2001:1900:5:3::11E 160 msec 156 msec 160 msec > 13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344 > msec 208 msec 200 msec > 14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276 > msec 260 msec 268 msec > 15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272 > msec 272 msec 324 msec > 16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec > 272 msec 276 msec > 17 * * * > 18 * * * > > Confirmed by L3's looking glasses ( > http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true > ) and my own corporate IPv6 connection from Level 3. > > I opened a ticket with Level 3. Anyone else seen this? > > -Dave > From me at anuragbhatia.com Wed Apr 11 23:19:09 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 12 Apr 2012 09:49:09 +0530 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: <4F86570F.9040602@derekivey.com> References: <4F86570F.9040602@derekivey.com> Message-ID: I emailed about this to friends at HE yesterday. Heard they are working on it. I can see forwward as well as reverse paths via Europe - so very likely they lost connectivity/BGP session with Level3 in US or something like that. Let's see how it goes. On Thu, Apr 12, 2012 at 9:46 AM, Derek Ivey wrote: > I'm seeing the same thing from my area (Harrisburg, PA). Strange. > > *Show Level 3 (Harrisburg, PA) Traceroute to www.he.net* > 1 vl-17.car1.Pittsburgh3.Level3.**net(2001:1900:35::21) 208 msec 200 msec 276 msec > 2 vl-4044.car1.Washington1.**Level3.net(2001:1900:4:1::2B9) 48 msec 208 msec 200 msec > 3 vl-4083.car2.Washington1.**Level3.net(2001:1900:4:1::DE) 200 msec 312 msec 104 msec > 4 vl-4061.car1.NewYork2.Level3.**net(2001:1900:4:1::106) 160 msec 100 msec 124 msec > 5 vl-4041.car1.NewYork1.Level3.**net(2001:1900:4:1::101) 80 msec 156 msec 56 msec > 6 vl-4086.edge3.London1.Level3.**net(2001:1900:6:1::11) 212 msec 116 msec 248 msec > 7 vl-4081.edge4.London1.Level3.**net(2001:1900:5:1::106) 200 msec > vl-4081.edge3.London1.Level3.**net(2001:1900:5:1::102) 200 msec 204 msec > 8 2001:1900:5:3::11E 208 msec 204 msec 208 msec > 9 10gigabitethernet7-4.core1.**nyc4.he.net(2001:470:0:128::1) 204 msec 40 msec 200 msec > 10 10gigabitethernet5-3.core1.**lax1.he.net(2001:470:0:10E::1) 408 msec 404 msec 260 msec > 11 10gigabitethernet7-4.core1.**fmt2.he.net(2001:470:0:18D::1) 368 msec 380 msec 416 msec > 12 10gigabitethernet2-1.core1.**fmt1.he.net(2001:470:0:2D::1) 256 msec 400 msec 224 msec > > C:\Users\Derek>tracert 2001:1900:35::21 (from my HE tunnel) > > Tracing route to vl-17.car1.Pittsburgh3.Level3.**net[2001:1900:35::21] > over a maximum of 30 hops: > ... > 3 16 ms 14 ms 21 ms gige-g4-12.core1.ash1.he.net[2001:470:0:90::1] > 4 25 ms 25 ms 24 ms 10gigabitethernet1-2.core1.**nyc4.he.net[2001:470:0:36::2] > 5 88 ms 90 ms 98 ms 10gigabitethernet1-2.core1.**lon1.he.net[2001:470:0:128::2] > 6 88 ms 89 ms 89 ms ge-5-3-2.edge4.London.Level3.**net[2001:1900:5:3::11d] > 7 88 ms 89 ms 89 ms vl-4080.edge4.London1.Level3.**net[2001:1900:5:1::105] > 8 158 ms 158 ms 158 ms vl-4086.car1.NewYork1.Level3.**net[2001:1900:6:1::12] > 9 163 ms 163 ms 163 ms ae-2-4047.edge2.Washington12.**Level3.net[2001:1900:4:1::3b9] > 10 163 ms 163 ms 163 ms ae-1-4080.edge1.Washington12.**Level3.net[2001:1900:4:1::3d9] > 11 164 ms 164 ms 164 ms vl-4046.car1.Washington1.**Level3.net[2001:1900:4:1::3b2] > 12 177 ms 177 ms 187 ms vl-17.car1.Pittsburgh3.Level3.**net[2001:1900:35::21] > > Trace complete. > > > > On 4/12/2012 12:08 AM, Dave Sotnick wrote: > >> Hello Nanog, >> >> Looks like Level3's only IPv6 route to HE is via London right now: >> >> Show Level 3 (Las Vegas, NV) Traceroute to www.he.net >> 1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec >> 2 vl-11.bar2.LasVegas1.Level3.**net(2001:1900:4:1::3C6) 0 msec 0 msec 0 msec >> 3 vl-4045.car1.Denver1.Level3.**net(2001:1900:4:1::276) 84 msec 228 >> msec 224 msec >> 4 vl-4081.car2.Denver1.Level3.**net(2001:1900:4:1::32) 20 msec 20 msec 20 msec >> 5 vl-4042.edge1.Chicago2.Level3.**net(2001:1900:4:1::36) 44 msec 44 msec 44 msec >> 6 vl-4067.car1.Chicago1.Level3.**net(2001:1900:4:1::1D) 48 msec 212 >> msec 224 msec >> 7 vl-4061.car2.NewYork2.Level3.**net(2001:1900:4:1::22) 184 msec 216 >> msec 232 msec >> 8 vl-4080.car1.NewYork2.Level3.**net(2001:1900:4:1::F1) 80 msec 80 msec 80 msec >> 9 vl-4041.car1.NewYork1.Level3.**net(2001:1900:4:1::101) 80 msec 80 msec 80 msec >> 10 vl-4086.edge3.London1.Level3.**net(2001:1900:6:1::11) 176 msec 144 >> msec 164 msec >> 11 vl-4081.edge3.London1.Level3.**net(2001:1900:5:1::102) 136 msec 132 msec >> vl-4081.edge4.London1.Level3.**net(2001:1900:5:1::106) 148 msec >> 12 2001:1900:5:3::11E 160 msec 156 msec 160 msec >> 13 10gigabitethernet7-4.core1.**nyc4.he.net(2001:470:0:128::1) 344 >> msec 208 msec 200 msec >> 14 10gigabitethernet5-3.core1.**lax1.he.net(2001:470:0:10E::1) 276 >> msec 260 msec 268 msec >> 15 10gigabitethernet7-4.core1.**fmt2.he.net(2001:470:0:18D::1) 272 >> msec 272 msec 324 msec >> 16 10gigabitethernet2-1.core1.**fmt1.he.net(2001:470:0:2D::1) 288 msec >> 272 msec 276 msec >> 17 * * * >> 18 * * * >> >> Confirmed by L3's looking glasses ( >> http://lg.level3.net/**traceroute/traceroute.cgi?** >> site=lvg1&target=www.he.net&**ipv6=true >> ) and my own corporate IPv6 connection from Level 3. >> >> I opened a ticket with Level 3. Anyone else seen this? >> >> -Dave >> >> > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From geier at geier.ne.tz Thu Apr 12 02:28:53 2012 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 12 Apr 2012 10:28:53 +0300 Subject: Cheap Juniper Gear for Lab In-Reply-To: <86obqxq19o.fsf@seastrom.com> References: <20120411010207.GA2368@prolixium.com> <20120411.194505.41678391.sthaug@nethelp.no> <86obqxq19o.fsf@seastrom.com> Message-ID: <4F868435.8070203@geier.ne.tz> On 4/12/2012 2:47 AM, Robert E. Seastrom wrote: > We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs. > That came in 10.1 or something. Hi, we are running Model: j2350 JUNOS Software Release [9.3R4.4] and had: neighbor 41.188.165.50 { description AfNOG_Whitesands; peer-as 327686; } with success. (and several on this list used it ~10months ago) so, a 32-bit AS as neighbor works, not sure if you meant router's own AS to be 32-bit. Regards, Frank From nanog at studio442.com.au Thu Apr 12 03:04:26 2012 From: nanog at studio442.com.au (Julien Goodwin) Date: Thu, 12 Apr 2012 18:04:26 +1000 Subject: Cheap Juniper Gear for Lab In-Reply-To: <86obqxq19o.fsf@seastrom.com> References: <20120411010207.GA2368@prolixium.com> <20120411.194505.41678391.sthaug@nethelp.no> <86obqxq19o.fsf@seastrom.com> Message-ID: <4F868C8A.8090308@studio442.com.au> On 12/04/12 09:47, Robert E. Seastrom wrote: > We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs. > That came in 10.1 or something. As a member of the ARIN Advisory > Council, I felt compelled to eat the same dog food that I was selling, > and we found ourselves at an impasse. Er, I think you're probably meaning 8.3 and 9.1. (32-bit ASN's were introduced in 9.1, and I don't remember seeing anything in the release notes for 10.x about them) From me at anuragbhatia.com Thu Apr 12 04:00:14 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 12 Apr 2012 14:30:14 +0530 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: References: <4F86570F.9040602@derekivey.com> Message-ID: Issue seems resolved. I just retested and routing between HE and Level 3 looks normal now. On Thu, Apr 12, 2012 at 9:49 AM, Anurag Bhatia wrote: > I emailed about this to friends at HE yesterday. Heard they are working on > it. > > > I can see forwward as well as reverse paths via Europe - so very likely > they lost connectivity/BGP session with Level3 in US or something like that. > > > Let's see how it goes. > > On Thu, Apr 12, 2012 at 9:46 AM, Derek Ivey wrote: > >> I'm seeing the same thing from my area (Harrisburg, PA). Strange. >> >> *Show Level 3 (Harrisburg, PA) Traceroute to www.he.net* >> 1 vl-17.car1.Pittsburgh3.Level3.**net(2001:1900:35::21) 208 msec 200 msec 276 msec >> 2 vl-4044.car1.Washington1.**Level3.net(2001:1900:4:1::2B9) 48 msec 208 msec 200 msec >> 3 vl-4083.car2.Washington1.**Level3.net(2001:1900:4:1::DE) 200 msec 312 msec 104 msec >> 4 vl-4061.car1.NewYork2.Level3.**net(2001:1900:4:1::106) 160 msec 100 msec 124 msec >> 5 vl-4041.car1.NewYork1.Level3.**net(2001:1900:4:1::101) 80 msec 156 msec 56 msec >> 6 vl-4086.edge3.London1.Level3.**net(2001:1900:6:1::11) 212 msec 116 msec 248 msec >> 7 vl-4081.edge4.London1.Level3.**net(2001:1900:5:1::106) 200 msec >> vl-4081.edge3.London1.Level3.**net(2001:1900:5:1::102) 200 msec 204 msec >> 8 2001:1900:5:3::11E 208 msec 204 msec 208 msec >> 9 10gigabitethernet7-4.core1.**nyc4.he.net(2001:470:0:128::1) 204 msec 40 msec 200 msec >> 10 10gigabitethernet5-3.core1.**lax1.he.net(2001:470:0:10E::1) 408 msec 404 msec 260 msec >> 11 10gigabitethernet7-4.core1.**fmt2.he.net(2001:470:0:18D::1) 368 msec 380 msec 416 msec >> 12 10gigabitethernet2-1.core1.**fmt1.he.net(2001:470:0:2D::1) 256 msec 400 msec 224 msec >> >> C:\Users\Derek>tracert 2001:1900:35::21 (from my HE tunnel) >> >> Tracing route to vl-17.car1.Pittsburgh3.Level3.**net[2001:1900:35::21] >> over a maximum of 30 hops: >> ... >> 3 16 ms 14 ms 21 ms gige-g4-12.core1.ash1.he.net[2001:470:0:90::1] >> 4 25 ms 25 ms 24 ms 10gigabitethernet1-2.core1.**nyc4.he.net[2001:470:0:36::2] >> 5 88 ms 90 ms 98 ms 10gigabitethernet1-2.core1.**lon1.he.net[2001:470:0:128::2] >> 6 88 ms 89 ms 89 ms ge-5-3-2.edge4.London.Level3.**net[2001:1900:5:3::11d] >> 7 88 ms 89 ms 89 ms vl-4080.edge4.London1.Level3.**net[2001:1900:5:1::105] >> 8 158 ms 158 ms 158 ms vl-4086.car1.NewYork1.Level3.**net[2001:1900:6:1::12] >> 9 163 ms 163 ms 163 ms ae-2-4047.edge2.Washington12.**Level3.net[2001:1900:4:1::3b9] >> 10 163 ms 163 ms 163 ms ae-1-4080.edge1.Washington12.**Level3.net[2001:1900:4:1::3d9] >> 11 164 ms 164 ms 164 ms vl-4046.car1.Washington1.**Level3.net[2001:1900:4:1::3b2] >> 12 177 ms 177 ms 187 ms vl-17.car1.Pittsburgh3.Level3.**net[2001:1900:35::21] >> >> Trace complete. >> >> >> >> On 4/12/2012 12:08 AM, Dave Sotnick wrote: >> >>> Hello Nanog, >>> >>> Looks like Level3's only IPv6 route to HE is via London right now: >>> >>> Show Level 3 (Las Vegas, NV) Traceroute to www.he.net >>> 1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec >>> 2 vl-11.bar2.LasVegas1.Level3.**net(2001:1900:4:1::3C6) 0 msec 0 msec 0 msec >>> 3 vl-4045.car1.Denver1.Level3.**net(2001:1900:4:1::276) 84 msec 228 >>> msec 224 msec >>> 4 vl-4081.car2.Denver1.Level3.**net(2001:1900:4:1::32) 20 msec 20 msec 20 msec >>> 5 vl-4042.edge1.Chicago2.Level3.**net(2001:1900:4:1::36) 44 msec 44 msec 44 msec >>> 6 vl-4067.car1.Chicago1.Level3.**net(2001:1900:4:1::1D) 48 msec 212 >>> msec 224 msec >>> 7 vl-4061.car2.NewYork2.Level3.**net(2001:1900:4:1::22) 184 msec 216 >>> msec 232 msec >>> 8 vl-4080.car1.NewYork2.Level3.**net(2001:1900:4:1::F1) 80 msec 80 msec 80 msec >>> 9 vl-4041.car1.NewYork1.Level3.**net(2001:1900:4:1::101) 80 msec 80 msec 80 msec >>> 10 vl-4086.edge3.London1.Level3.**net(2001:1900:6:1::11) 176 msec 144 >>> msec 164 msec >>> 11 vl-4081.edge3.London1.Level3.**net(2001:1900:5:1::102) 136 msec 132 msec >>> vl-4081.edge4.London1.Level3.**net(2001:1900:5:1::106) 148 msec >>> 12 2001:1900:5:3::11E 160 msec 156 msec 160 msec >>> 13 10gigabitethernet7-4.core1.**nyc4.he.net(2001:470:0:128::1) 344 >>> msec 208 msec 200 msec >>> 14 10gigabitethernet5-3.core1.**lax1.he.net(2001:470:0:10E::1) 276 >>> msec 260 msec 268 msec >>> 15 10gigabitethernet7-4.core1.**fmt2.he.net(2001:470:0:18D::1) 272 >>> msec 272 msec 324 msec >>> 16 10gigabitethernet2-1.core1.**fmt1.he.net(2001:470:0:2D::1) 288 msec >>> 272 msec 276 msec >>> 17 * * * >>> 18 * * * >>> >>> Confirmed by L3's looking glasses ( >>> http://lg.level3.net/**traceroute/traceroute.cgi?** >>> site=lvg1&target=www.he.net&**ipv6=true >>> ) and my own corporate IPv6 connection from Level 3. >>> >>> I opened a ticket with Level 3. Anyone else seen this? >>> >>> -Dave >>> >>> >> > > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From juicewvu at gmail.com Thu Apr 12 07:46:59 2012 From: juicewvu at gmail.com (Josh Smith) Date: Thu, 12 Apr 2012 08:46:59 -0400 Subject: att wireless Message-ID: Can a clueful DNS person fro AT&T wireless please contact me off list if possible. Thanks, Josh Smith KD8HRX email/jabber:? juicewvu at gmail.com phone:? 304.237.9369(c) From carlosm3011 at gmail.com Thu Apr 12 10:14:41 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 12 Apr 2012 12:14:41 -0300 Subject: Cheap Juniper Gear for Lab In-Reply-To: References: <4F83B795.4010301@kingrst.com> <4F842E83.6040703@studio442.com.au> <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com> <0DE1A05A-F993-47FC-B04E-48B362D80F8F@delong.com> <20120411010207.GA2368@prolixium.com> Message-ID: <4F86F161.6020506@gmail.com> I was bitten by a similar issue when I deployed a couple of J2350s at our edge. On 4/11/12 2:33 PM, Carl Rosevear wrote: > Yeah, I have to apply the term "awful" and "annoying" to the packet > mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC > on the phone trying to get the thing to just pass packets. Best part > was, I didn't know how to do it and nor did they! I escalated, worked > with many engineers. My key statement was "I just want my router to > route. Make it do what it is supposed to do. No session tracking! > This is not a firewall." So, now it doesn't require valid sessions to > pass packets but it does still appear to *track* sessions in some > tables and I am, of course, very curious when some attack vector will > fill up some table. > > Anyway, not the best devices for an edge router that is for sure. > Which is too bad... for very small DC edge applications, the J6350 > was a pretty cool router in earlier versions of JunOS that didn't > decide to re-engineer your network and transit for you. > > Anyway I digress. But this had, in the past, been a frustrating > enough issue for me that I had to share. > > > --Carl > > > > On Tue, Apr 10, 2012 at 6:30 PM, Owen DeLong wrote: >> On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote: >> >>> On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote: >>>>> The fact that you can't put it into flow mode. >>>> s/flow/packet/ >>>> (oops, wasn't awake yet) >>> Actually, this is possible: >>> >>> prox at asgard> show configuration security >>> forwarding-options { >>> family { >>> inet6 { >>> mode packet-based; >>> } >>> mpls { >>> mode packet-based; >>> } >>> } >>> } >>> >>> The above is from an SRX210B, but the same configuration will work on >>> any J-series or /branch/ SRX-series platform. >>> >> Right, sort of. To the extent that it works. It doesn't actually do everything you >> think it should, and, it's somewhat dependent on the version of JunOS as to >> how well it does or doesn't work. >> >>> Don't let the "mpls" keyword throw you off. This actually causes the >>> box to run the inet /and/ mpls address families in packet mode. >>> >> I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for >> over a year and it escalated quite high up their escalation chain before they >> finally admitted "Yeah, Services JunOS is different and it behaves differently >> and if you need to do what you're trying to do, you should buy an M or MX >> series." >> >> It's quite unfortunate. I'd really like for the SRX series to not be so crippled for >> my purposes. >> >> Owen >> >> > > From sotnickd-nanog at ddv.com Thu Apr 12 10:35:13 2012 From: sotnickd-nanog at ddv.com (Dave Sotnick) Date: Thu, 12 Apr 2012 08:35:13 -0700 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: <4F867829.8060404@he.net> References: <4F867829.8060404@he.net> Message-ID: Yep, looks much better now. This is what Level3 had to say: "David, You should see this repaired at this time, looks like the peering between L3 and HE crashed in stateside when the ipv6 max prefix limits exceeded the router configurations. Please let us know if any further questions. Regards, Level 3 Communications" Thanks all, -Dave On Wed, Apr 11, 2012 at 11:37 PM, Mike Leber wrote: > Was fixed a short while ago, please retest. > > Mike. > > > On 4/11/12 9:08 PM, Dave Sotnick wrote: >> >> Hello Nanog, >> >> Looks like Level3's only IPv6 route to HE is via London right now: >> >> Show Level 3 (Las Vegas, NV) Traceroute to www.he.net >> ?1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec >> ?2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec 0 >> msec >> ?3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228 >> msec 224 msec >> ?4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 msec 20 >> msec >> ?5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 msec >> 44 msec >> ?6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212 >> msec 224 msec >> ?7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216 >> msec 232 msec >> ?8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 msec 80 >> msec >> ?9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 msec >> 80 msec >> ?10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144 >> msec 164 msec >> ?11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 >> msec >> ? ?vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec >> ?12 2001:1900:5:3::11E 160 msec 156 msec 160 msec >> ?13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344 >> msec 208 msec 200 msec >> ?14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276 >> msec 260 msec 268 msec >> ?15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272 >> msec 272 msec 324 msec >> ?16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec >> 272 msec 276 msec >> ?17 ?* ?* ?* >> ?18 ?* ?* ?* >> >> Confirmed by L3's looking glasses ( >> >> http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true >> ) and my own corporate IPv6 connection from Level 3. >> >> I opened a ticket with Level 3. Anyone else seen this? >> >> -Dave >> > From me at anuragbhatia.com Thu Apr 12 10:38:35 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 12 Apr 2012 21:08:35 +0530 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: References: <4F867829.8060404@he.net> Message-ID: Oh thanks for sharing I was very curious to know that. Routing world is interesting! (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Apr 12, 2012 9:05 PM, "Dave Sotnick" wrote: > Yep, looks much better now. > > This is what Level3 had to say: > > "David, > > You should see this repaired at this time, looks like the peering > between L3 and HE crashed in > stateside when the ipv6 max prefix limits exceeded the router > configurations. > > Please let us know if any further questions. > > Regards, > > Level 3 Communications" > > Thanks all, > -Dave > > On Wed, Apr 11, 2012 at 11:37 PM, Mike Leber wrote: > > Was fixed a short while ago, please retest. > > > > Mike. > > > > > > On 4/11/12 9:08 PM, Dave Sotnick wrote: > >> > >> Hello Nanog, > >> > >> Looks like Level3's only IPv6 route to HE is via London right now: > >> > >> Show Level 3 (Las Vegas, NV) Traceroute to www.he.net > >> 1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 > msec > >> 2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec 0 > >> msec > >> 3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228 > >> msec 224 msec > >> 4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 msec > 20 > >> msec > >> 5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 > msec > >> 44 msec > >> 6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212 > >> msec 224 msec > >> 7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216 > >> msec 232 msec > >> 8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 > msec 80 > >> msec > >> 9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 > msec > >> 80 msec > >> 10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144 > >> msec 164 msec > >> 11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 > >> msec > >> vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec > >> 12 2001:1900:5:3::11E 160 msec 156 msec 160 msec > >> 13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344 > >> msec 208 msec 200 msec > >> 14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276 > >> msec 260 msec 268 msec > >> 15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272 > >> msec 272 msec 324 msec > >> 16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec > >> 272 msec 276 msec > >> 17 * * * > >> 18 * * * > >> > >> Confirmed by L3's looking glasses ( > >> > >> > http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true > >> ) and my own corporate IPv6 connection from Level 3. > >> > >> I opened a ticket with Level 3. Anyone else seen this? > >> > >> -Dave > >> > > > > From cdel at firsthand.net Thu Apr 12 10:52:13 2012 From: cdel at firsthand.net (Christian de Larrinaga) Date: Thu, 12 Apr 2012 16:52:13 +0100 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: References: <4F867829.8060404@he.net> Message-ID: <85E55F57-1A92-4D58-9C82-EC78D779E835@firsthand.net> v6 traffic picking up through L3/HE? /C On 12 Apr 2012, at 16:35, Dave Sotnick wrote: > Yep, looks much better now. > > This is what Level3 had to say: > > "David, > > You should see this repaired at this time, looks like the peering > between L3 and HE crashed in > stateside when the ipv6 max prefix limits exceeded the router configurations. > > Please let us know if any further questions. > > Regards, > > Level 3 Communications" > > Thanks all, > -Dave > > On Wed, Apr 11, 2012 at 11:37 PM, Mike Leber wrote: >> Was fixed a short while ago, please retest. >> >> Mike. >> >> >> On 4/11/12 9:08 PM, Dave Sotnick wrote: >>> >>> Hello Nanog, >>> >>> Looks like Level3's only IPv6 route to HE is via London right now: >>> >>> Show Level 3 (Las Vegas, NV) Traceroute to www.he.net >>> 1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec >>> 2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec 0 >>> msec >>> 3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228 >>> msec 224 msec >>> 4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 msec 20 >>> msec >>> 5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 msec >>> 44 msec >>> 6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212 >>> msec 224 msec >>> 7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216 >>> msec 232 msec >>> 8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 msec 80 >>> msec >>> 9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 msec >>> 80 msec >>> 10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144 >>> msec 164 msec >>> 11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 >>> msec >>> vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec >>> 12 2001:1900:5:3::11E 160 msec 156 msec 160 msec >>> 13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344 >>> msec 208 msec 200 msec >>> 14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276 >>> msec 260 msec 268 msec >>> 15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272 >>> msec 272 msec 324 msec >>> 16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec >>> 272 msec 276 msec >>> 17 * * * >>> 18 * * * >>> >>> Confirmed by L3's looking glasses ( >>> >>> http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true >>> ) and my own corporate IPv6 connection from Level 3. >>> >>> I opened a ticket with Level 3. Anyone else seen this? >>> >>> -Dave >>> >> > From me at anuragbhatia.com Thu Apr 12 10:54:35 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 12 Apr 2012 21:24:35 +0530 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: <85E55F57-1A92-4D58-9C82-EC78D779E835@firsthand.net> References: <4F867829.8060404@he.net> <85E55F57-1A92-4D58-9C82-EC78D779E835@firsthand.net> Message-ID: Yes it is. You can cross check via looking glass of both networks. (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Apr 12, 2012 9:23 PM, "Christian de Larrinaga" wrote: > v6 traffic picking up through L3/HE? > /C > On 12 Apr 2012, at 16:35, Dave Sotnick wrote: > > > Yep, looks much better now. > > > > This is what Level3 had to say: > > > > "David, > > > > You should see this repaired at this time, looks like the peering > > between L3 and HE crashed in > > stateside when the ipv6 max prefix limits exceeded the router > configurations. > > > > Please let us know if any further questions. > > > > Regards, > > > > Level 3 Communications" > > > > Thanks all, > > -Dave > > > > On Wed, Apr 11, 2012 at 11:37 PM, Mike Leber wrote: > >> Was fixed a short while ago, please retest. > >> > >> Mike. > >> > >> > >> On 4/11/12 9:08 PM, Dave Sotnick wrote: > >>> > >>> Hello Nanog, > >>> > >>> Looks like Level3's only IPv6 route to HE is via London right now: > >>> > >>> Show Level 3 (Las Vegas, NV) Traceroute to www.he.net > >>> 1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 > msec > >>> 2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec > 0 > >>> msec > >>> 3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228 > >>> msec 224 msec > >>> 4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 > msec 20 > >>> msec > >>> 5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 > msec > >>> 44 msec > >>> 6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212 > >>> msec 224 msec > >>> 7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216 > >>> msec 232 msec > >>> 8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 > msec 80 > >>> msec > >>> 9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 > msec > >>> 80 msec > >>> 10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144 > >>> msec 164 msec > >>> 11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 > >>> msec > >>> vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec > >>> 12 2001:1900:5:3::11E 160 msec 156 msec 160 msec > >>> 13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344 > >>> msec 208 msec 200 msec > >>> 14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276 > >>> msec 260 msec 268 msec > >>> 15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272 > >>> msec 272 msec 324 msec > >>> 16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec > >>> 272 msec 276 msec > >>> 17 * * * > >>> 18 * * * > >>> > >>> Confirmed by L3's looking glasses ( > >>> > >>> > http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true > >>> ) and my own corporate IPv6 connection from Level 3. > >>> > >>> I opened a ticket with Level 3. Anyone else seen this? > >>> > >>> -Dave > >>> > >> > > > > > From Valdis.Kletnieks at vt.edu Thu Apr 12 11:28:13 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 12 Apr 2012 12:28:13 -0400 Subject: Level3 IPv6 peering with HE only in London? In-Reply-To: Your message of "Thu, 12 Apr 2012 08:35:13 -0700." References: <4F867829.8060404@he.net> Message-ID: <49093.1334248093@turing-police.cc.vt.edu> On Thu, 12 Apr 2012 08:35:13 -0700, Dave Sotnick said: > You should see this repaired at this time, looks like the peering > between L3 and HE crashed in > stateside when the ipv6 max prefix limits exceeded the router configurations. Unless it was some bozo deaggregating, this is actually a good sign for IPv6 adoption. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From myeaddress at gmail.com Thu Apr 12 15:25:59 2012 From: myeaddress at gmail.com (Maverick) Date: Thu, 12 Apr 2012 16:25:59 -0400 Subject: Network Storage Message-ID: Hello Everyone, Can you please comment on what is best solution for storing network traffic. We have been graciously granted access by our network administrator to capture traffic but the one Tera byte disk space is no match with the data that we are seeing, so it fills up quickly. We can't get additional space on the server itself so I am looking for some external solutions. Can you please suggest something that would be best for Gbps speeds . Best, Ali From joelja at bogus.com Thu Apr 12 15:43:49 2012 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 12 Apr 2012 13:43:49 -0700 Subject: Network Storage In-Reply-To: References: Message-ID: <4F873E85.8010505@bogus.com> Depends on the duration and goals of your capture... 1TB is 2.276 hours at 1Gb/s If you need to capture it all and store it forever well sorry. If you just need the flows and not the packets sampled netflow can reduce youre requirements by many orders of magnitude, ultimately it really depends on your goals. if you need to capture more data for a shorter duration probably write speed rather than capcity is the issue 20Gb/s is 2.5GB/s which requires a pretty healthy disk array to write to disk... On 4/12/12 13:25 , Maverick wrote: > Hello Everyone, > > Can you please comment on what is best solution for storing network > traffic. We have been graciously granted access by our network > administrator to capture traffic but the one Tera byte disk space is > no match with the data that we are seeing, so it fills up quickly. We > can't get additional space on the server itself so I am looking for > some external solutions. Can you please suggest something that would > be best for Gbps speeds . > > > Best, > Ali > From mike at m5computersecurity.com Thu Apr 12 16:06:40 2012 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Thu, 12 Apr 2012 14:06:40 -0700 Subject: Network Storage In-Reply-To: References: Message-ID: <1334264800.7862.15277.camel@mike-desktop> Ali, Do you need to capture the whole packet, including the payload? You will save a lot of space by just capturing the headers. For example, tcpdump doesn't capture the whole packet by default anyway. You may not be able to capture at line rate anyway depending on what you are using to capture with (drivers, libraries, software, etc). See the -s option in tcpdump man page for info. Good luck, Mike On Thu, 2012-04-12 at 16:25 -0400, Maverick wrote: > Hello Everyone, > > Can you please comment on what is best solution for storing network > traffic. We have been graciously granted access by our network > administrator to capture traffic but the one Tera byte disk space is > no match with the data that we are seeing, so it fills up quickly. We > can't get additional space on the server itself so I am looking for > some external solutions. Can you please suggest something that would > be best for Gbps speeds . > > > Best, > Ali > -- ************************************************************ Michael J. McCafferty CEO M5 Hosting http://www.m5hosting.com Like us on Facebook for updates and photos: https://www.facebook.com/m5hosting ************************************************************ From myeaddress at gmail.com Thu Apr 12 16:16:27 2012 From: myeaddress at gmail.com (Maverick) Date: Thu, 12 Apr 2012 17:16:27 -0400 Subject: Network Storage In-Reply-To: <1334264800.7862.15277.camel@mike-desktop> References: <1334264800.7862.15277.camel@mike-desktop> Message-ID: Thank you very much for your suggestions. 1) My goal is to store the traffic may be fore ever, and analyze it in the future for security related incidents detected by ids/ips. 2) I am storing just header and initial few bytes but still it gets filled up quite quickly. 3) Netflow approach is nice but I also want to have traces available for reasons mentioned in 1). 4) Are there any issues having an external storage as a solution for this problem. Best, Ali On Thu, Apr 12, 2012 at 5:06 PM, Michael J McCafferty wrote: > Ali, > ? ? ? ?Do you need to capture the whole packet, including the payload? You > will save a lot of space by just capturing the headers. For example, > tcpdump doesn't capture the whole packet by default anyway. You may not > be able to capture at line rate anyway depending on what you are using > to capture with (drivers, libraries, software, etc). See the -s option > in tcpdump man page for info. > > Good luck, > Mike > > On Thu, 2012-04-12 at 16:25 -0400, Maverick wrote: >> Hello Everyone, >> >> Can you please comment on what is best solution for storing network >> traffic. We have been graciously granted access by our network >> administrator to capture traffic but the one Tera byte disk space is >> no match with the data that we are seeing, so it fills up quickly. We >> can't get additional space on the server itself so I am looking for >> some external solutions. Can you please suggest something that would >> be best for Gbps speeds . >> >> >> Best, >> Ali >> > > -- > ************************************************************ > Michael J. McCafferty > CEO > M5 Hosting > http://www.m5hosting.com > > Like us on Facebook for updates and photos: > https://www.facebook.com/m5hosting > ************************************************************ > From iam at st-andrews.ac.uk Thu Apr 12 16:18:05 2012 From: iam at st-andrews.ac.uk (Ian McDonald) Date: Thu, 12 Apr 2012 21:18:05 +0000 Subject: Network Storage In-Reply-To: References: Message-ID: Hi, You'll need to build an array that'll random read/write upwards of 200MB/s if you want to get a semi-reliable capture to disk. That means SSD if you're very rich, or many spindles (preferably 15k's) in a stripe/ raid10 if you're building from your scrap pile. Bear in mind that write cache won't help you, as the io isn't going to be bursty, rather a continuous stream. Another great help is scoping what you're looking for and pre-processing before writing out only the 'interesting' bits, thus reducing the io requirement. It does depend what you're trying to do, as headers can be adequate for many applications. Aligning your partitions with the physical disk geometry can produce surprising speedups, as can stripe block size changes, but that's generally empirical, and depends on your workload. -- ian -----Original Message----- From: Maverick Sent: 12/04/2012, 21:27 To: nanog at nanog.org Subject: Network Storage Hello Everyone, Can you please comment on what is best solution for storing network traffic. We have been graciously granted access by our network administrator to capture traffic but the one Tera byte disk space is no match with the data that we are seeing, so it fills up quickly. We can't get additional space on the server itself so I am looking for some external solutions. Can you please suggest something that would be best for Gbps speeds . Best, Ali From john.yocum at fluidhosting.com Thu Apr 12 16:18:30 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Thu, 12 Apr 2012 14:18:30 -0700 Subject: Network Storage In-Reply-To: References: <1334264800.7862.15277.camel@mike-desktop> Message-ID: <4F8746A6.6070401@fluidhosting.com> In that case, just keep adding disks to you capture system, or use a NAS to do it. --John On 4/12/2012 2:16 PM, Maverick wrote: > Thank you very much for your suggestions. > > 1) My goal is to store the traffic may be fore ever, and analyze it in > the future for security related incidents detected by ids/ips. > > 2) I am storing just header and initial few bytes but still it gets > filled up quite quickly. > > 3) Netflow approach is nice but I also want to have traces available > for reasons mentioned in 1). > > 4) Are there any issues having an external storage as a solution for > this problem. > > Best, > Ali > > On Thu, Apr 12, 2012 at 5:06 PM, Michael J McCafferty > wrote: >> Ali, >> Do you need to capture the whole packet, including the payload? You >> will save a lot of space by just capturing the headers. For example, >> tcpdump doesn't capture the whole packet by default anyway. You may not >> be able to capture at line rate anyway depending on what you are using >> to capture with (drivers, libraries, software, etc). See the -s option >> in tcpdump man page for info. >> >> Good luck, >> Mike >> >> On Thu, 2012-04-12 at 16:25 -0400, Maverick wrote: >>> Hello Everyone, >>> >>> Can you please comment on what is best solution for storing network >>> traffic. We have been graciously granted access by our network >>> administrator to capture traffic but the one Tera byte disk space is >>> no match with the data that we are seeing, so it fills up quickly. We >>> can't get additional space on the server itself so I am looking for >>> some external solutions. Can you please suggest something that would >>> be best for Gbps speeds . >>> >>> >>> Best, >>> Ali >>> >> >> -- >> ************************************************************ >> Michael J. McCafferty >> CEO >> M5 Hosting >> http://www.m5hosting.com >> >> Like us on Facebook for updates and photos: >> https://www.facebook.com/m5hosting >> ************************************************************ >> > From Valdis.Kletnieks at vt.edu Thu Apr 12 16:34:22 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 12 Apr 2012 17:34:22 -0400 Subject: Network Storage In-Reply-To: Your message of "Thu, 12 Apr 2012 14:18:30 -0700." <4F8746A6.6070401@fluidhosting.com> References: <1334264800.7862.15277.camel@mike-desktop> <4F8746A6.6070401@fluidhosting.com> Message-ID: <63739.1334266462@turing-police.cc.vt.edu> On Thu, 12 Apr 2012 14:18:30 -0700, "John T. Yocum" said: > In that case, just keep adding disks to you capture system, or use a NAS > to do it. On Thu, 12 Apr 2012 13:43:49 -0700, Joel jaeggli said: > 1TB is 2.276 hours at 1Gb/s If he's got a gigabit of traffic, he's going to be adding another shelf of 12 1T drives to that NAS - every day. If he gets the high-density shelves with 60 drives, he's only adding one a week. He's going to have to work smarter, not harder. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From john.yocum at fluidhosting.com Thu Apr 12 16:37:38 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Thu, 12 Apr 2012 14:37:38 -0700 Subject: Network Storage In-Reply-To: <63739.1334266462@turing-police.cc.vt.edu> References: <1334264800.7862.15277.camel@mike-desktop> <4F8746A6.6070401@fluidhosting.com> <63739.1334266462@turing-police.cc.vt.edu> Message-ID: <4F874B22.7020200@fluidhosting.com> On 4/12/2012 2:34 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 12 Apr 2012 14:18:30 -0700, "John T. Yocum" said: >> In that case, just keep adding disks to you capture system, or use a NAS >> to do it. > > On Thu, 12 Apr 2012 13:43:49 -0700, Joel jaeggli said: >> 1TB is 2.276 hours at 1Gb/s > > If he's got a gigabit of traffic, he's going to be adding another shelf of 12 1T > drives to that NAS - every day. If he gets the high-density shelves with 60 drives, > he's only adding one a week. > > He's going to have to work smarter, not harder. He did indicate he's only storing the headers and a few bytes, not the full payload. --John From dolson at mcs.anl.gov Thu Apr 12 16:44:41 2012 From: dolson at mcs.anl.gov (Dan Olson) Date: Thu, 12 Apr 2012 16:44:41 -0500 (CDT) Subject: Network Storage In-Reply-To: <4F874B22.7020200@fluidhosting.com> Message-ID: <769285662.136409.1334267081369.JavaMail.root@zimbra-mb2.anl.gov> If this is just for post analysis and you have another system (IDS) to identify the timeframe, a tape based system might be a better approach, esp if you want to retain forever. Maybe "Library LTFS" ----- Original Message ----- From: "John T. Yocum" To: "Valdis Kletnieks" Cc: nanog at nanog.org Sent: Thursday, April 12, 2012 5:37:38 PM Subject: Re: Network Storage On 4/12/2012 2:34 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 12 Apr 2012 14:18:30 -0700, "John T. Yocum" said: >> In that case, just keep adding disks to you capture system, or use a NAS >> to do it. > > On Thu, 12 Apr 2012 13:43:49 -0700, Joel jaeggli said: >> 1TB is 2.276 hours at 1Gb/s > > If he's got a gigabit of traffic, he's going to be adding another shelf of 12 1T > drives to that NAS - every day. If he gets the high-density shelves with 60 drives, > he's only adding one a week. > > He's going to have to work smarter, not harder. He did indicate he's only storing the headers and a few bytes, not the full payload. --John From mjl at luckie.org.nz Thu Apr 12 16:47:52 2012 From: mjl at luckie.org.nz (Matthew Luckie) Date: Thu, 12 Apr 2012 14:47:52 -0700 Subject: Network Storage In-Reply-To: Message-ID: <20120412214752.GA44566@spandex.luckie.org.nz> > 1) My goal is to store the traffic may be fore ever, and analyze it in > the future for security related incidents detected by ids/ips. Take a look at "Building a Time Machine for Efficient Recording and Retrieval of High-Volume Network Traffic" https://www.usenix.org/conference/imc-05/building-time-machine-efficient-recording-and-retrieval-high-volume-network From Joel.Snyder at Opus1.COM Thu Apr 12 16:53:18 2012 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Thu, 12 Apr 2012 14:53:18 -0700 Subject: Network Storage Message-ID: <4F874ECE.8000605@opus1.com> >Can you please comment on what is best solution for storing network >traffic. Well, "best" is kind of a hard word to use here. There are lots of different solutions depending on exactly why and where you want to capture this. As far as I know, there are really two credible companies who are thrashing it out in this space right now, NetWitness (now part of RSA) and Solera. I think that Niksun is still out there, but they haven't done much recently or maybe they just concentrate on particular sectors and so I never see them. Of course, you can also just tcpdump it yourself, but the commercial products do a lot of the metadata analysis and creation for you, so it's a lot easier to understand what is happening in your traffic than just having piles of tcpdumps. I bought a NetWitness box and was profoundly unimpressed. So I guess my advice would be to start with Solera and then look at NetWitness if you don't like Solera. This assumes you have budget. If this is a back-of-the-envelope "hey, let's grab some packets and do something with them" kind of exercise, then filter your tcpdumps a lot better. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From mike at m5computersecurity.com Thu Apr 12 17:01:41 2012 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Thu, 12 Apr 2012 15:01:41 -0700 Subject: Network Storage In-Reply-To: References: <1334264800.7862.15277.camel@mike-desktop> Message-ID: <1334268101.7862.15405.camel@mike-desktop> more in-line... On Thu, 2012-04-12 at 17:16 -0400, Maverick wrote: > Thank you very much for your suggestions. > > 1) My goal is to store the traffic may be fore ever, and analyze it in > the future for security related incidents detected by ids/ips. > The poor man's way to do this is to use the space you have and use the -C and -W options in tcpdump. You have as much history as you have disk space. Maybe make 500M files, and a count of 1800 to use 900G of disk space. When you have an event, you copy off the files that are relevant to the time period of the events, to a workstation. Another option is -G for rotating the files by time instead of size. > 2) I am storing just header and initial few bytes but still it gets > filled up quite quickly. You can use the -z option to gzip compress the files to save space. However, I don't know how this will affect your disk io... will it be fast enough to keep up with the writing of the raw data and doing a concurrent gzip of the last file. If you have enough hardware performance, but are limited on space, then it's worth a shot. > > 3) Netflow approach is nice but I also want to have traces available > for reasons mentioned in 1). > > 4) Are there any issues having an external storage as a solution for > this problem. There is also some advice in the man page for tcpdump regarding the -z option. You can write a shell script that takes the capture file as the only argument, to do other stuff you want done... in this case, copy the file off to another drive. It could be a network location too... of course, don't forget to not capture *that* traffic (feedback!). > > Best, > Ali > > On Thu, Apr 12, 2012 at 5:06 PM, Michael J McCafferty > wrote: > > Ali, > > Do you need to capture the whole packet, including the payload? You > > will save a lot of space by just capturing the headers. For example, > > tcpdump doesn't capture the whole packet by default anyway. You may not > > be able to capture at line rate anyway depending on what you are using > > to capture with (drivers, libraries, software, etc). See the -s option > > in tcpdump man page for info. > > > > Good luck, > > Mike > > > > On Thu, 2012-04-12 at 16:25 -0400, Maverick wrote: > >> Hello Everyone, > >> > >> Can you please comment on what is best solution for storing network > >> traffic. We have been graciously granted access by our network > >> administrator to capture traffic but the one Tera byte disk space is > >> no match with the data that we are seeing, so it fills up quickly. We > >> can't get additional space on the server itself so I am looking for > >> some external solutions. Can you please suggest something that would > >> be best for Gbps speeds . > >> > >> > >> Best, > >> Ali > >> > > > > -- > > ************************************************************ > > Michael J. McCafferty > > CEO > > M5 Hosting > > http://www.m5hosting.com > > > > Like us on Facebook for updates and photos: > > https://www.facebook.com/m5hosting > > ************************************************************ > > -- ************************************************************ Michael J. McCafferty CEO M5 Hosting http://www.m5hosting.com Like us on Facebook for updates and photos: https://www.facebook.com/m5hosting ************************************************************ From nathan at robotics.net Thu Apr 12 17:03:41 2012 From: nathan at robotics.net (Nathan Stratton) Date: Thu, 12 Apr 2012 17:03:41 -0500 (CDT) Subject: Network Storage In-Reply-To: References: Message-ID: On Thu, 12 Apr 2012, Maverick wrote: > Hello Everyone, > > Can you please comment on what is best solution for storing network > traffic. We have been graciously granted access by our network > administrator to capture traffic but the one Tera byte disk space is > no match with the data that we are seeing, so it fills up quickly. We > can't get additional space on the server itself so I am looking for > some external solutions. Can you please suggest something that would > be best for Gbps speeds . I have done this two ways in the past, first is the simple way, LSI raid card with lots of disks and some nice 10 gig capture cards. The 2nd way is to use Gluster, over a large number of hosts with infiniband connecting them together. ><> Nathan Stratton nathan at robotics.net http://www.robotics.net From jared at puck.nether.net Thu Apr 12 17:19:59 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 12 Apr 2012 18:19:59 -0400 Subject: Network Storage In-Reply-To: <20120412214752.GA44566@spandex.luckie.org.nz> References: <20120412214752.GA44566@spandex.luckie.org.nz> Message-ID: You can also look at a machine like this: http://www.supermicro.com/products/chassis/4U/417/SC417E16-R1400U.cfm Jared Mauch On Apr 12, 2012, at 5:47 PM, Matthew Luckie wrote: >> 1) My goal is to store the traffic may be fore ever, and analyze it in >> the future for security related incidents detected by ids/ips. > > Take a look at "Building a Time Machine for Efficient Recording and > Retrieval of High-Volume Network Traffic" > > https://www.usenix.org/conference/imc-05/building-time-machine-efficient-recording-and-retrieval-high-volume-network From juicewvu at gmail.com Thu Apr 12 20:22:17 2012 From: juicewvu at gmail.com (Josh Smith) Date: Thu, 12 Apr 2012 21:22:17 -0400 Subject: Comcast DNS contact Message-ID: Can some from Comcast DNS contact me off list. A colleague made a mistake in one of our DNS zones and the incorrect data is cached on your end and causing our users fits. Thanks, Josh -- Josh Smith KD8HRX email/jabber: juicewvu at gmail.com phone: 304.237.9369(c) From tknchris at gmail.com Thu Apr 12 20:51:34 2012 From: tknchris at gmail.com (chris) Date: Thu, 12 Apr 2012 21:51:34 -0400 Subject: Comcast DNS contact In-Reply-To: References: Message-ID: nanog: a personal army? On Thu, Apr 12, 2012 at 9:22 PM, Josh Smith wrote: > Can some from Comcast DNS contact me off list. A colleague made a mistake > in one of our DNS zones and the incorrect data is cached on your end and > causing our users fits. > > Thanks, > Josh > > > -- > Josh Smith > KD8HRX > email/jabber: juicewvu at gmail.com > phone: 304.237.9369(c) > From mysidia at gmail.com Fri Apr 13 00:45:57 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 13 Apr 2012 00:45:57 -0500 Subject: Network Storage In-Reply-To: References: Message-ID: On Thu, Apr 12, 2012 at 4:18 PM, Ian McDonald wrote: > You'll need to build an array that'll random read/write upwards of 200MB/s if you > want to get a semi-reliable capture to disk. That means SSD if you're very rich, or many spindles Hey, Saving packet captures to file is a ~98% asynchronous write, 2% read; ~95% sequential activity. And maybe you think about applying some variant of header compression to the packets during capture, to trade a little CPU and increased RAM requirements for storage efficiency. The format used by PCAP and saving raw packet header bits directly to disk is not necessarily among the most I/O or space efficient on disk storage formats to pick. Random writes should only occur if you are saving your captures to a fragmented file system, which is not recommended; avoiding fragmentation is important. Random reads aren't involved for archiving data, only for analyzing it. Do you make random reads into your saved capture files? Possibly you're more likely to be doing a sequential scan, even during analysis; random reads imply you have already indexed a dataset and you are seeking a smaller number of specific records, to collect information about them. Read requirements are totally dependent on your analysis workload, e.g. Table scan vs Index search. Depending on what the analysis is, it may make sense to even make extra filtered copies of the data, using more disk space, in order to avoid a random access pattern. If you are building a database of analysis results from raw data, you can and use a separate random IO optimized disk subsystem for the stats database. If you really need approximately 200 MB/s with some random read performance for analysis, you should probably be looking at building a RAID50 with several 4-drive sets and 1gb+ of writeback cache. RAID10 makes more sense in situations where write requirements are not sequential, when external storage is actually shared with multiple applications, or when there is a requirement for a disk drive failure to be truly transparent, but there is a huge capacity sacrifice in choosing mirroring over parity. There is a Time vs Cost tradeoff with regards to the analysis of the data. When your 'analysis tools' start reading data, the reads increase the disk access time, and therefore reduce write performance; therefore the reads should be throttled, the higher the capacity the disk subsystem, the higher the cost. Performing your analysis ahead of time via pre-caching, or at least indexing newly captured data in small chunks on a continuous basis may be useful, to minimize the amount of searching of the raw dataset later. A small SSD or separate mirrored drive pair for that function, would avoid adding load to the "raw capture storage" disk system, if your analysis requirements are amenable to that pattern. Modern OSes cache some recent filesystem data in RAM. So if the server capturing data has sufficient SDRAM, analyzing data while it's still hot in the page cache, and saving that analysis in an efficient index for later use, can be useful. >(preferably 15k's) in a stripe/ raid10 if you're building from your scrap pile. Bear in mind that write >cache won't help you, as the io isn't going to be bursty, rather a continuous stream. Not really... A good read cache is more important for the analysis, but Efficient write cache on your array and OS page cache is still highly beneficial, especially because it can ensure that your RAID subsystem is performing full stripe writes, for maximal efficiency of sequential write activity, and it can delay the media write until the optimal moment based on platter position, and sequence the read/write requests; as long as the performance of the storage system behind the cache is such that the storage system can on average successfully drain the cache at a faster rate than you can fill it with data a sufficient amount of the time, the write cache serves an important function. Your I/O may be a continuous stream, but there are most certainly variations and spikes in the rate of packets and the performance of mechanical disk drives. > Aligning your partitions with the physical disk geometry can produce surprising speedups, as can >stripe block size changes, but that's generally empirical, and depends on your workload. For RAID systems partitions should absolutely be aligned if the OS install defaults don't align them correctly; on a modern OS, the defaults are normally OK. Having an unaligned or improperly aligned partition is just a misconfiguration; A track crossing for every other sector read is an easy way of doubling the size of small I/Os. You won't notice with this particular use case when you are writing large blocks, you're writing a 100Mb chunk, asynchronously, you won't notice a 63kB difference, it's less than .0001% of your transfer size; this is primarily a concern during analysis or database searching which may involve small random reads and small synchronous random writes. In other words, you will probably get away just ignoring partition alignment and filesystem block size, so there are other aspects of the configuration to be more concerned about (YMMV). -- -JH From graham at apolix.co.za Fri Apr 13 00:59:43 2012 From: graham at apolix.co.za (Graham Beneke) Date: Fri, 13 Apr 2012 07:59:43 +0200 Subject: facebook ipv6 is down? In-Reply-To: <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> Message-ID: <4F87C0CF.8000307@apolix.co.za> On 11/04/2012 09:16, Frank Bulk wrote: > It's been down three times today, first from 2:58 pm to 5:58 pm Central, and > then again from 7:59 pm to 9:58 pm, and then again from 10:59 pm till now. > > Interesting that the up and downs have been one to two minutes before the > hour. I've been seeing the same thing - up and down for the last 3 days. The site has been unreachable approximately 50% of the time according to my monitoring system. The other interesting thing is that the failures did not occur at the same time for all regions. Two of my monitoring nodes are seeing completely different patterns of outages. -- Graham Beneke From james.braunegg at micron21.com Fri Apr 13 07:40:42 2012 From: james.braunegg at micron21.com (James Braunegg) Date: Fri, 13 Apr 2012 12:40:42 +0000 Subject: International Transit Provider - Delivered locally to Melbourne Australia Message-ID: Dear All Just wondering if I can get some recommendations for international transit providers who can provide international transit delivered in Melbourne Australia at 55 Crockford Street or 55 King street ie transit without any local domestic Australian routes. Looking forward to hearing from you / suggestions Kindest Regards James Braunegg W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braunegg at micron21.com | ABN: 12 109 977 666 [Description: Description: Description: Description: Description: M21.jpg] This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2683 bytes Desc: image001.jpg URL: From bmanning at vacation.karoshi.com Fri Apr 13 07:49:15 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 13 Apr 2012 12:49:15 +0000 Subject: International Transit Provider - Delivered locally to Melbourne Australia In-Reply-To: References: Message-ID: <20120413124915.GA16479@vacation.karoshi.com.> unless you cross connect in the landing shack, there will -always- be a domestic local loop. (you don't like Telstra?) /bill On Fri, Apr 13, 2012 at 12:40:42PM +0000, James Braunegg wrote: > Dear All > > Just wondering if I can get some recommendations for international transit providers who can provide international transit delivered in Melbourne Australia at 55 Crockford Street or 55 King street ie transit without any local domestic Australian routes. > > Looking forward to hearing from you / suggestions > > Kindest Regards > > James Braunegg > W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 > E: james.braunegg at micron21.com | ABN: 12 109 977 666 > > [Description: Description: Description: Description: Description: M21.jpg] > > This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. > From james.braunegg at micron21.com Fri Apr 13 07:50:56 2012 From: james.braunegg at micron21.com (James Braunegg) Date: Fri, 13 Apr 2012 12:50:56 +0000 Subject: International Transit Provider - Delivered locally to Melbourne Australia In-Reply-To: <20120413124915.GA16479@vacation.karoshi.com.> References: <20120413124915.GA16479@vacation.karoshi.com.> Message-ID: A local loop is fine ... As long as it is only a loop with no local peering transit. Kindest regards James Sent from my iPhone On Apr 13, 2012, at 10:48 PM, "bmanning at vacation.karoshi.com" wrote: > > unless you cross connect in the landing shack, there will -always- be a domestic local loop. > (you don't like Telstra?) > > /bill > > > On Fri, Apr 13, 2012 at 12:40:42PM +0000, James Braunegg wrote: >> Dear All >> >> Just wondering if I can get some recommendations for international transit providers who can provide international transit delivered in Melbourne Australia at 55 Crockford Street or 55 King street ie transit without any local domestic Australian routes. >> >> Looking forward to hearing from you / suggestions >> >> Kindest Regards >> >> James Braunegg >> W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 >> E: james.braunegg at micron21.com | ABN: 12 109 977 666 >> >> [Description: Description: Description: Description: Description: M21.jpg] >> >> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. >> > > From deric.kwok2000 at gmail.com Fri Apr 13 11:42:25 2012 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Fri, 13 Apr 2012 12:42:25 -0400 Subject: packet question Message-ID: Hi Can I know what tools can investigate the small packets? Thank you From shortdudey123 at gmail.com Fri Apr 13 12:27:44 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 13 Apr 2012 12:27:44 -0500 Subject: packet question In-Reply-To: References: Message-ID: Hi I am not sure what you mean by "small packets" but i use Wireshark to look at traffic captures. -Grant Sent from my iPhone On Apr 13, 2012, at 11:42 AM, Deric Kwok wrote: > Hi > > Can I know what tools can investigate the small packets? > > Thank you > From cscora at apnic.net Fri Apr 13 13:43:24 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Apr 2012 04:43:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201204131843.q3DIhOuW010251@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 Apr, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 405834 Prefixes after maximum aggregation: 172344 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 196881 Total ASes present in the Internet Routing Table: 40680 Prefixes per ASN: 9.98 Origin-only ASes present in the Internet Routing Table: 33028 Origin ASes announcing only one prefix: 15596 Transit ASes present in the Internet Routing Table: 5439 Transit-only ASes present in the Internet Routing Table: 140 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 69 Max AS path prepend of ASN ( 9902) 61 Prefixes from unregistered ASNs in the Routing Table: 386 Unregistered ASNs in the Routing Table: 124 Number of 32-bit ASNs allocated by the RIRs: 2561 Number of 32-bit ASNs visible in the Routing Table: 2213 Prefixes from 32-bit ASNs in the Routing Table: 5503 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 114 Number of addresses announced to Internet: 2536440016 Equivalent to 151 /8s, 47 /16s and 0 /24s Percentage of available address space announced: 68.4 Percentage of allocated address space announced: 68.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.3 Total number of prefixes smaller than registry allocations: 173014 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 99593 Total APNIC prefixes after maximum aggregation: 32244 APNIC Deaggregation factor: 3.09 Prefixes being announced from the APNIC address blocks: 96034 Unique aggregates announced from the APNIC address blocks: 39546 APNIC Region origin ASes present in the Internet Routing Table: 4672 APNIC Prefixes per ASN: 20.56 APNIC Region origin ASes announcing only one prefix: 1235 APNIC Region transit ASes present in the Internet Routing Table: 729 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 181 Number of APNIC addresses announced to Internet: 643217632 Equivalent to 38 /8s, 86 /16s and 184 /24s Percentage of available APNIC address space announced: 81.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 149618 Total ARIN prefixes after maximum aggregation: 76108 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120921 Unique aggregates announced from the ARIN address blocks: 50252 ARIN Region origin ASes present in the Internet Routing Table: 15025 ARIN Prefixes per ASN: 8.05 ARIN Region origin ASes announcing only one prefix: 5723 ARIN Region transit ASes present in the Internet Routing Table: 1582 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 807007168 Equivalent to 48 /8s, 25 /16s and 243 /24s Percentage of available ARIN address space announced: 64.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 101433 Total RIPE prefixes after maximum aggregation: 53576 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 93324 Unique aggregates announced from the RIPE address blocks: 58041 RIPE Region origin ASes present in the Internet Routing Table: 16482 RIPE Prefixes per ASN: 5.66 RIPE Region origin ASes announcing only one prefix: 8037 RIPE Region transit ASes present in the Internet Routing Table: 2629 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1489 Number of RIPE addresses announced to Internet: 509292424 Equivalent to 30 /8s, 91 /16s and 47 /24s Percentage of available RIPE address space announced: 82.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 40582 Total LACNIC prefixes after maximum aggregation: 8239 LACNIC Deaggregation factor: 4.93 Prefixes being announced from the LACNIC address blocks: 40429 Unique aggregates announced from the LACNIC address blocks: 20124 LACNIC Region origin ASes present in the Internet Routing Table: 1583 LACNIC Prefixes per ASN: 25.54 LACNIC Region origin ASes announcing only one prefix: 435 LACNIC Region transit ASes present in the Internet Routing Table: 296 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 521 Number of LACNIC addresses announced to Internet: 99314568 Equivalent to 5 /8s, 235 /16s and 107 /24s Percentage of available LACNIC address space announced: 65.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8935 Total AfriNIC prefixes after maximum aggregation: 2109 AfriNIC Deaggregation factor: 4.24 Prefixes being announced from the AfriNIC address blocks: 7015 Unique aggregates announced from the AfriNIC address blocks: 2152 AfriNIC Region origin ASes present in the Internet Routing Table: 527 AfriNIC Prefixes per ASN: 13.31 AfriNIC Region origin ASes announcing only one prefix: 166 AfriNIC Region transit ASes present in the Internet Routing Table: 117 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 31657216 Equivalent to 1 /8s, 227 /16s and 13 /24s Percentage of available AfriNIC address space announced: 47.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2488 11113 1009 Korea Telecom (KIX) 17974 1799 503 63 PT TELEKOMUNIKASI INDONESIA 7545 1663 301 86 TPG Internet Pty Ltd 4755 1590 388 166 TATA Communications formerly 9583 1245 95 542 Sify Limited 9829 1235 1041 30 BSNL National Internet Backbo 7552 1170 1062 11 Vietel Corporation 4808 1090 2050 316 CNCGROUP IP network: China169 24560 1023 385 167 Bharti Airtel Ltd., Telemedia 18101 947 131 160 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3428 3807 195 bellsouth.net, inc. 7029 3385 985 157 Windstream Communications Inc 18566 2091 382 179 Covad Communications 1785 1896 680 129 PaeTec Communications, Inc. 20115 1642 1565 619 Charter Communications 4323 1600 1044 380 Time Warner Telecom 22773 1576 2910 111 Cox Communications, Inc. 30036 1446 263 757 Mediacom Communications Corp 7018 1278 9774 828 AT&T WorldNet Services 11492 1185 216 365 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1759 544 16 Corbina telecom 2118 1304 97 14 EUnet/RELCOM Autonomous Syste 34984 681 188 175 BILISIM TELEKOM 31148 679 37 9 FreeNet ISP 12479 655 660 61 Uni2 Autonomous System 20940 641 204 494 Akamai Technologies European 6830 639 1943 410 UPC Distribution Services 8551 574 360 81 Bezeq International 3320 533 8442 399 Deutsche Telekom AG 2578 501 33 7 Demos, Moscow, Russia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1803 326 174 TVCABLE BOGOTA 28573 1777 1107 59 NET Servicos de Comunicao S.A 6503 1533 418 65 AVANTEL, S.A. 8151 1481 3020 349 UniNet S.A. de C.V. 7303 1357 827 190 Telecom Argentina Stet-France 26615 903 697 32 Tim Brasil S.A. 27947 686 74 99 Telconet S.A 11172 637 91 73 Servicios Alestra S.A de C.V 22047 583 326 15 VTR PUNTO NET S.A. 3816 571 242 100 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1303 958 13 TEDATA 24863 848 274 35 LINKdotNET AS number 6713 490 649 18 Itissalat Al-MAGHRIB 3741 265 921 223 The Internet Solution 12258 197 28 62 Vodacom Internet Company 33776 195 12 24 Starcomms Nigeria Limited 24835 179 80 8 RAYA Telecom - Egypt 16637 173 666 83 MTN Network Solutions 15706 169 32 6 Sudatel Internet Exchange Aut 29571 161 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3428 3807 195 bellsouth.net, inc. 7029 3385 985 157 Windstream Communications Inc 4766 2488 11113 1009 Korea Telecom (KIX) 18566 2091 382 179 Covad Communications 1785 1896 680 129 PaeTec Communications, Inc. 10620 1803 326 174 TVCABLE BOGOTA 17974 1799 503 63 PT TELEKOMUNIKASI INDONESIA 28573 1777 1107 59 NET Servicos de Comunicao S.A 8402 1759 544 16 Corbina telecom 7545 1663 301 86 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3385 3228 Windstream Communications Inc 18566 2091 1912 Covad Communications 1785 1896 1767 PaeTec Communications, Inc. 8402 1759 1743 Corbina telecom 17974 1799 1736 PT TELEKOMUNIKASI INDONESIA 28573 1777 1718 NET Servicos de Comunicao S.A 10620 1803 1629 TVCABLE BOGOTA 7545 1663 1577 TPG Internet Pty Ltd 4766 2488 1479 Korea Telecom (KIX) 6503 1533 1468 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 37.230.96.0/21 35470 XL Network Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:235 /13:460 /14:832 /15:1480 /16:12201 /17:6274 /18:10515 /19:20631 /20:28864 /21:29877 /22:40551 /23:37803 /24:212316 /25:1200 /26:1424 /27:777 /28:158 /29:60 /30:17 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3043 3385 Windstream Communications Inc 6389 2146 3428 bellsouth.net, inc. 18566 2040 2091 Covad Communications 8402 1736 1759 Corbina telecom 10620 1695 1803 TVCABLE BOGOTA 30036 1392 1446 Mediacom Communications Corp 6503 1291 1533 AVANTEL, S.A. 11492 1148 1185 Cable One 8452 1111 1303 TEDATA 7011 1068 1183 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:532 2:726 4:14 6:3 8:400 12:1990 13:1 14:600 15:12 16:3 17:7 20:8 23:159 24:1769 27:1270 31:978 32:57 33:2 34:2 36:8 37:342 38:795 40:120 41:3147 42:134 44:3 46:1463 47:3 49:383 50:535 52:13 54:7 55:9 56:3 57:31 58:962 59:521 60:282 61:1263 62:977 63:1990 64:4158 65:2253 66:4496 67:2029 68:1152 69:3153 70:906 71:472 72:1819 74:2596 75:494 76:318 77:964 78:1006 79:490 80:1190 81:903 82:661 83:548 84:490 85:1207 86:406 87:925 88:351 89:1631 90:297 91:4723 92:521 93:1389 94:1469 95:1146 96:355 97:318 98:892 99:37 100:7 101:169 103:969 106:105 107:185 108:226 109:1309 110:751 111:920 112:454 113:593 114:623 115:871 116:899 117:717 118:900 119:1217 120:349 121:806 122:1672 123:1089 124:1371 125:1265 128:561 129:190 130:253 131:599 132:173 133:21 134:242 135:62 136:212 137:177 138:355 139:147 140:489 141:244 142:386 143:396 144:514 145:69 146:490 147:277 148:765 149:301 150:160 151:176 152:464 153:172 154:7 155:429 156:215 157:379 158:177 159:522 160:337 161:259 162:352 163:190 164:572 165:395 166:571 167:463 168:816 169:127 170:856 171:127 172:4 173:1727 174:586 175:430 176:484 177:648 178:1333 180:1177 181:73 182:797 183:285 184:452 185:1 186:2209 187:1027 188:1190 189:1798 190:5495 192:5997 193:5545 194:4637 195:3580 196:1247 197:120 198:3624 199:4495 200:5795 201:1917 202:8512 203:8606 204:4343 205:2488 206:2748 207:2777 208:4046 209:3585 210:2761 211:1478 212:2002 213:1906 214:887 215:104 216:5092 217:1539 218:543 219:343 220:1225 221:556 222:323 223:334 End of report From jeroen at mompl.net Fri Apr 13 14:06:22 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 13 Apr 2012 12:06:22 -0700 Subject: Most energy efficient (home) setup In-Reply-To: <20120223152935.GA8659@ussenterprise.ufp.org> References: <4F455A8B.80809@mompl.net> <20120223152935.GA8659@ussenterprise.ufp.org> Message-ID: <4F88792E.5030406@mompl.net> Leo Bicknell wrote: > But what's really missing is storage management. RAID5 (and similar) > require all drives to be online all the time. I'd love an intelligent > file system that could spin down drives when not in use, and even for > many workloads spin up only a portion of the drives. It's easy to > imagine a system with a small SSD and a pair of disks. Reads spin one > disk. Writes go to that disk and the SSD until there are enough, which > spins up the second drive and writes them out as a proper mirror. In a > home file server drive motors, time you have 4-6 drives, eat most of the > power. CPU's speed step down nicely, drives don't. Late reply by me, but excellent points. A combination of mdadm and hdparm on linux should suffice to have a raid that will spin down the disks when not in use. I have used for years a G4 system with a mdadm raid1 (and a separate boot disk) and hdparm configured to spin the raid disks down after 10 minutes and it worked great. I think in a raid10 this would only spin up the disk pair that has the data you need, but leave the rest asleep. But I didn't try that yet. What I'd like is to have small disk enclosuer that includes a whole (low power) computer capable of having linux installed on some flash memory. Say you have an enclosure with space for 4 2.5 inch disks, install linux, set it up as a raid10, connect through USB to your computer for back up purposes. Greetings, Jeroen -- Earthquake Magnitude: 3.0 Date: Friday, April 13, 2012 17:45:06 UTC Location: Central Alaska Latitude: 64.0464; Longitude: -148.9850 Depth: 1.80 km From paul4004 at gmail.com Fri Apr 13 14:59:52 2012 From: paul4004 at gmail.com (PC) Date: Fri, 13 Apr 2012 13:59:52 -0600 Subject: Most energy efficient (home) setup In-Reply-To: <4F88792E.5030406@mompl.net> References: <4F455A8B.80809@mompl.net> <20120223152935.GA8659@ussenterprise.ufp.org> <4F88792E.5030406@mompl.net> Message-ID: It exists. Google for "unRAID" It uses something like Raid4 for Parity data, but stores entire files on single spindles. It's designed for home media server type environments. This way, when you watch a video, only the drive you are using needs to power up. It also lets you add/remove mismatched disks with no rebuild needed. http://lime-technology.com/technology * Better power management: not all hard drives are required to be spinning in order to access data normally; hard drives not in use may be spun down. However modern "green" drives don't take that much power. On Fri, Apr 13, 2012 at 1:06 PM, Jeroen van Aart wrote: > Leo Bicknell wrote: > >> But what's really missing is storage management. RAID5 (and similar) >> require all drives to be online all the time. I'd love an intelligent >> file system that could spin down drives when not in use, and even for >> many workloads spin up only a portion of the drives. It's easy to >> imagine a system with a small SSD and a pair of disks. Reads spin one >> disk. Writes go to that disk and the SSD until there are enough, which >> spins up the second drive and writes them out as a proper mirror. In a >> home file server drive motors, time you have 4-6 drives, eat most of the >> power. CPU's speed step down nicely, drives don't. >> > > Late reply by me, but excellent points. > > A combination of mdadm and hdparm on linux should suffice to have a raid > that will spin down the disks when not in use. I have used for years a G4 > system with a mdadm raid1 (and a separate boot disk) and hdparm configured > to spin the raid disks down after 10 minutes and it worked great. > > I think in a raid10 this would only spin up the disk pair that has the > data you need, but leave the rest asleep. But I didn't try that yet. > > What I'd like is to have small disk enclosuer that includes a whole (low > power) computer capable of having linux installed on some flash memory. Say > you have an enclosure with space for 4 2.5 inch disks, install linux, set > it up as a raid10, connect through USB to your computer for back up > purposes. > > Greetings, > Jeroen > > -- > Earthquake Magnitude: 3.0 > Date: Friday, April 13, 2012 17:45:06 UTC > Location: Central Alaska > Latitude: 64.0464; Longitude: -148.9850 > Depth: 1.80 km > > From mazzid at gmail.com Fri Apr 13 15:59:27 2012 From: mazzid at gmail.com (Justin Zipkin) Date: Fri, 13 Apr 2012 16:59:27 -0400 Subject: altdb? Message-ID: Anybody know what the scoop is with ALTDB? It's been down since yesterday. From jeroen at mompl.net Fri Apr 13 16:11:47 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 13 Apr 2012 14:11:47 -0700 Subject: Most energy efficient (home) setup In-Reply-To: References: <4F455A8B.80809@mompl.net> <20120223152935.GA8659@ussenterprise.ufp.org> <4F88792E.5030406@mompl.net> Message-ID: <4F889693.4050401@mompl.net> PC wrote: > It exists. Google for "unRAID" It uses something like Raid4 for Parity > data, but stores entire files on single spindles. It's designed for home > media server type environments. This way, when you watch a video, only the There may be a performance penalty using raid4, because it uses one parity disk. Although that system looks like it can be useful for some purposes it looks less ideal for home use. Also I don't see how it would allow you to install your own OS. Regards, Jeroen -- Earthquake Magnitude: 4.7 Date: Friday, April 13, 2012 19:52:07 UTC Location: North Indian Ocean Latitude: 1.6006; Longitude: 91.2505 Depth: 16.80 km From cidr-report at potaroo.net Fri Apr 13 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Apr 2012 22:00:00 GMT Subject: BGP Update Report Message-ID: <201204132200.q3DM00ta074016@wattle.apnic.net> BGP Update Report Interval: 05-Apr-12 -to- 12-Apr-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14374 83320 4.5% 2450.6 -- AGRI-VALLEY - Agri-Valley Services Inc. 2 - AS1273 70309 3.8% 1528.5 -- CW Cable and Wireless Worldwide plc 3 - AS8402 60941 3.3% 33.9 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS9829 42739 2.3% 49.4 -- BSNL-NIB National Internet Backbone 5 - AS12479 27970 1.5% 42.4 -- UNI2-AS France Telecom Espana SA 6 - AS32528 23005 1.2% 4601.0 -- ABBOTT Abbot Labs 7 - AS7552 17365 0.9% 18.8 -- VIETEL-AS-AP Vietel Corporation 8 - AS5800 16673 0.9% 50.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 9 - AS45899 16603 0.9% 50.8 -- VNPT-AS-VN VNPT Corp 10 - AS26615 16250 0.9% 18.9 -- Tim Celular S.A. 11 - AS4538 14831 0.8% 35.9 -- ERX-CERNET-BKB China Education and Research Network Center 12 - AS24560 14790 0.8% 28.9 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 13 - AS6503 12804 0.7% 21.1 -- Axtel, S.A.B. de C.V. 14 - AS18566 12465 0.7% 7.1 -- COVAD - Covad Communications Co. 15 - AS7029 12249 0.7% 8.8 -- WINDSTREAM - Windstream Communications Inc 16 - AS44798 10958 0.6% 10958.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 17 - AS5976 10116 0.6% 80.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS17974 10026 0.5% 11.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS3225 9288 0.5% 147.4 -- GULFNET-KUWAIT Gulfnet Kuwait 20 - AS8452 8759 0.5% 12.2 -- TE-AS TE-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS44798 10958 0.6% 10958.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 2 - AS25600 7596 0.4% 7596.0 -- MATRIKON-1 - Matrikon Inc. 3 - AS21271 5969 0.3% 5969.0 -- SOTELMABGP 4 - AS32528 23005 1.2% 4601.0 -- ABBOTT Abbot Labs 5 - AS14374 83320 4.5% 2450.6 -- AGRI-VALLEY - Agri-Valley Services Inc. 6 - AS33377 4500 0.2% 2250.0 -- FHLBC - Federal Home Loan Bank of Chicago 7 - AS1273 70309 3.8% 1528.5 -- CW Cable and Wireless Worldwide plc 8 - AS17408 3179 0.2% 1059.7 -- ABOVE-AS-AP AboveNet Communications Taiwan 9 - AS55665 969 0.1% 969.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 10 - AS4658 900 0.1% 900.0 -- NETFRONT-AS Netfront Information Technology Limited, 11 - AS32040 878 0.1% 878.0 -- TRENTON-TELEPHONE - Trenton Telephone Company 12 - AS28666 6063 0.3% 866.1 -- HOSTLOCATION LTDA 13 - AS29933 2576 0.1% 858.7 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 14 - AS57767 828 0.0% 828.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network 15 - AS13263 3660 0.2% 732.0 -- HAYATNET-AS HayatNet Bilgi ve Iletisim Hizmetleri A.S 16 - AS8657 725 0.0% 725.0 -- CPRM CPRM Autonomous System 17 - AS32837 1742 0.1% 580.7 -- WCL-50-AS - Williams & Connolly, LLP 18 - AS27169 578 0.0% 578.0 -- TRIDENTAS - Trident Systems, Inc. 19 - AS32807 554 0.0% 554.0 -- ASN-INTERFACE-INC - INTERFACE INCORPORATED 20 - AS38857 1101 0.1% 550.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 11493 0.6% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 11493 0.6% AS32528 -- ABBOTT Abbot Labs 3 - 91.202.212.0/22 10958 0.6% AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 4 - 62.36.252.0/22 8436 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 5 - 206.75.46.0/24 7596 0.4% AS25600 -- MATRIKON-1 - Matrikon Inc. 6 - 122.161.0.0/16 7052 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 62.36.249.0/24 6450 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 217.64.96.0/20 5969 0.3% AS21271 -- SOTELMABGP 9 - 62.36.241.0/24 5934 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 194.63.9.0/24 5764 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 11 - 62.36.210.0/24 5704 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 204.234.0.0/17 5516 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc 13 - 202.56.215.0/24 3389 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 14 - 202.153.174.0/24 3175 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 15 - 194.63.112.0/24 2803 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 16 - 194.63.16.0/24 2803 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 17 - 194.63.119.0/24 2803 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 18 - 194.63.20.0/24 2803 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 19 - 194.63.118.0/24 2803 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 20 - 194.63.0.0/24 2803 0.1% AS1273 -- CW Cable and Wireless Worldwide plc Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 13 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Apr 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201204132200.q3DM00WG074011@wattle.apnic.net> This report has been generated at Fri Apr 13 21:12:42 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-04-12 407232 237597 07-04-12 407420 237582 08-04-12 407440 237687 09-04-12 407549 238057 10-04-12 408024 238327 11-04-12 408106 238627 12-04-12 408289 238528 13-04-12 408593 238813 AS Summary 40811 Number of ASes in routing system 17058 Number of ASes announcing only one prefix 3428 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 111779104 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 13Apr12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 408839 238792 170047 41.6% All ASes AS6389 3428 198 3230 94.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3426 1837 1589 46.4% WINDSTREAM - Windstream Communications Inc AS4766 2492 1033 1459 58.5% KIXS-AS-KR Korea Telecom AS22773 1577 120 1457 92.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2091 705 1386 66.3% COVAD - Covad Communications Co. AS2118 1304 14 1290 98.9% RELCOM-AS OOO "NPO Relcom" AS28573 1777 492 1285 72.3% NET Servicos de Comunicao S.A. AS4323 1601 382 1219 76.1% TWTC - tw telecom holdings, inc. AS1785 1901 808 1093 57.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1589 543 1046 65.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS10620 1803 792 1011 56.1% Telmex Colombia S.A. AS7552 1170 230 940 80.3% VIETEL-AS-AP Vietel Corporation AS7303 1357 440 917 67.6% Telecom Argentina S.A. AS26615 903 32 871 96.5% Tim Celular S.A. AS8151 1485 664 821 55.3% Uninet S.A. de C.V. AS18101 948 164 784 82.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1090 347 743 68.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17974 1799 1107 692 38.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS9394 897 212 685 76.4% CRNET CHINA RAILWAY Internet(CRNET) AS30036 1429 774 655 45.8% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS3356 1095 458 637 58.2% LEVEL3 Level 3 Communications AS17676 688 76 612 89.0% GIGAINFRA Softbank BB Corp. AS17908 826 214 612 74.1% TCISL Tata Communications AS19262 996 401 595 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1023 433 590 57.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8402 1693 1111 582 34.4% CORBINA-AS OJSC "Vimpelcom" AS3549 1017 440 577 56.7% GBLX Global Crossing Ltd. AS22561 983 406 577 58.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS4804 662 96 566 85.5% MPX-AS Microplex PTY LTD AS4780 820 263 557 67.9% SEEDNET Digital United Inc. Total 43870 14792 29078 66.3% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 37.233.0.0/18 AS31252 STARNET-AS StarNet Moldova 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 201.158.116.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 201.158.117.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 201.158.118.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 201.158.119.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From johnl at iecc.com Fri Apr 13 17:01:14 2012 From: johnl at iecc.com (John Levine) Date: 13 Apr 2012 22:01:14 -0000 Subject: The day SORBS goes away ... In-Reply-To: Message-ID: <20120413220114.25335.qmail@joyce.lan> > dnslists = dialups.mail-abuse.org \ > : rbl-plus.mail-abuse.org \ Are you paying Trend for access to these? If not, you're not getting any answers from them and they're not blocking anything. R's, John From javier at kjsl.org Fri Apr 13 18:41:49 2012 From: javier at kjsl.org (Javier Henderson) Date: Fri, 13 Apr 2012 19:41:49 -0400 Subject: altdb? In-Reply-To: References: Message-ID: <04173697-1BBD-4485-9A13-034A85BD0D4E@kjsl.org> On Apr 13, 2012, at 4:59 PM, Justin Zipkin wrote: > Anybody know what the scoop is with ALTDB? It's been down since yesterday. I just fixed it. -jav From randy at psg.com Fri Apr 13 20:26:22 2012 From: randy at psg.com (Randy Bush) Date: Sat, 14 Apr 2012 03:26:22 +0200 Subject: The day SORBS goes away ... In-Reply-To: <20120413220114.25335.qmail@joyce.lan> References: <20120413220114.25335.qmail@joyce.lan> Message-ID: >> dnslists = dialups.mail-abuse.org \ >> : rbl-plus.mail-abuse.org \ > > Are you paying Trend for access to these? yes, i have an arrangement randy From Valdis.Kletnieks at vt.edu Sat Apr 14 01:08:49 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 14 Apr 2012 02:08:49 -0400 Subject: The day SORBS goes away ... In-Reply-To: Your message of "13 Apr 2012 22:01:14 -0000." <20120413220114.25335.qmail@joyce.lan> References: <20120413220114.25335.qmail@joyce.lan> Message-ID: <69634.1334383729@turing-police.cc.vt.edu> On 13 Apr 2012 22:01:14 -0000, "John Levine" said: > > dnslists = dialups.mail-abuse.org \ > > : rbl-plus.mail-abuse.org \ > > Are you paying Trend for access to these? If not, you're not getting > any answers from them and they're not blocking anything. Do they return a canned answer that says "don't block", or do you get to wait for a DNS timeout? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mukom.tamon at gmail.com Sat Apr 14 03:38:35 2012 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sat, 14 Apr 2012 12:38:35 +0400 Subject: IPv6 Launch day preparation In-Reply-To: References: Message-ID: Interesting setup you have there!! From the session, do you have configs for the different scenarios that were tested and what kind of 'issues' were unearthed? Regards On Wed, Apr 11, 2012 at 10:03 PM, Pierre-Yves Maunier wrote: > http://g6.asso.fr/wp-content/uploads/2012/03/ipv6-launch-lab.pdf -- Mukom Akong [Tamon] ______________ ?We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.? [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence From johnl at iecc.com Sat Apr 14 04:42:28 2012 From: johnl at iecc.com (John R. Levine) Date: 14 Apr 2012 09:42:28 +0000 Subject: The day SORBS goes away ... In-Reply-To: References: <20120413220114.25335.qmail@joyce.lan> Message-ID: >>> dnslists = dialups.mail-abuse.org \ >>> : rbl-plus.mail-abuse.org \ >> >> Are you paying Trend for access to these? > > yes, i have an arrangement I used to pay (not very much) but realized several years ago that after using the Spamhaus lists, MAPS didn't catch anything useful. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From randy at psg.com Sat Apr 14 04:44:02 2012 From: randy at psg.com (Randy Bush) Date: Sat, 14 Apr 2012 11:44:02 +0200 Subject: The day SORBS goes away ... In-Reply-To: References: <20120413220114.25335.qmail@joyce.lan> Message-ID: i have not tested to see who catches what. not really into spam research. just trying to reduce it for a server. randy From johnl at iecc.com Sat Apr 14 09:19:27 2012 From: johnl at iecc.com (John Levine) Date: 14 Apr 2012 14:19:27 -0000 Subject: The day SORBS goes away ... In-Reply-To: <69634.1334383729@turing-police.cc.vt.edu> Message-ID: <20120414141927.70420.qmail@joyce.lan> >> Are you paying Trend for access to these? If not, you're not getting >> any answers from them and they're not blocking anything. > >Do they return a canned answer that says "don't block", or do you get >to wait for a DNS timeout? Is there some reason you're asking random people rather than spending the 30 seconds needed to find out for yourself? R's, John From cmadams at hiwaay.net Sat Apr 14 10:04:49 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 14 Apr 2012 10:04:49 -0500 Subject: Most energy efficient (home) setup In-Reply-To: <4F889693.4050401@mompl.net> References: <4F455A8B.80809@mompl.net> <20120223152935.GA8659@ussenterprise.ufp.org> <4F88792E.5030406@mompl.net> <4F889693.4050401@mompl.net> Message-ID: <20120414150449.GA25347@hiwaay.net> Once upon a time, Jeroen van Aart said: > There may be a performance penalty using raid4, because it uses one > parity disk. Although that system looks like it can be useful for some > purposes it looks less ideal for home use. Also I don't see how it would > allow you to install your own OS. For read-mostly storage, there's no penalty as long as there's no disk failure. The parity drive wouldn't even spin up for reads. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mysidia at gmail.com Sat Apr 14 16:26:22 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 14 Apr 2012 16:26:22 -0500 Subject: Most energy efficient (home) setup In-Reply-To: <201202222148.q1MLmgKF051917@aurora.sol.net> References: <4F455A8B.80809@mompl.net> <201202222148.q1MLmgKF051917@aurora.sol.net> Message-ID: On Wed, Feb 22, 2012 at 3:48 PM, Joe Greco wrote: > The current Mac mini "Server" model sports an i7 2.0GHz quad-core CPU > and up to 16GB RAM (see OWC for that, IIRC). ?Two drives, up to 750GB > each, or SSD's if you prefer. The Mac mini server is quite intringuing with that low power requirement . Unfortunately... 16 GB _Non-ECC_ memory. I sure would not want to run a NAS VM on a server with non-ECC memory that cannot correct single-bit errors, at least with any data I cared much about.. When you have such a large quantity of RAM, single-bit/fade errors caused by background irradiation happen often, although at a fairly low rate. Usually on a workstation it's not an issue, because there is not a massive quantity of idle memory. If you're running this 24x7 with VMs and Non-ECC memory, it's only a question of time, before silent memory corruption results in one of the VMs. And silent memory corruption can make its way to the filesystem, or applications' internal saved data structures (such as the contents of a VM's registry database). True can be partially mitigated with backups; but the idea of VMs blue-screening or ESXi crashing with purple screen every 3 or 4 months sounds annoying. > 12 frickin' watts when idle. ?Or thereabouts. ?Think about 40 watts > when running full tilt, maybe a bit more. -- -JH From kyle.creyts at gmail.com Sun Apr 15 01:43:43 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sun, 15 Apr 2012 02:43:43 -0400 Subject: Network Storage In-Reply-To: References: Message-ID: Storage capable of keeping up with 10G/20G packet capture doesn't have to be extremely expensive... We build this with a commodity host, multiple 10G, multiple SAS HBAs each attached to a JBOD enclosure of at least 36 4TB 7.2k commodity sata3 disks. In our configuration, this delivers 58 TB per JBOD enclosure. Properly tuned, and with a little commodity SSD cache, it delivers synchronous sequential reads and writes over 2.5GB/sec, (and incredible random speeds which I can't recall off the top of my head) and all for under $25k. It could yield less or much more, depending on your redundancy/striping choices. Run out of room? Fill another JBOD shelf for ~18k. You could opt for lower parity than we did, or fewer stripes. Either one would stretch the space out by quite a bit. (At least 20 TB.) I didn't want to be constantly changing drives out, however. On Apr 13, 2012 1:46 AM, "Jimmy Hess" wrote: > On Thu, Apr 12, 2012 at 4:18 PM, Ian McDonald > wrote: > > You'll need to build an array that'll random read/write upwards of > 200MB/s if you > > want to get a semi-reliable capture to disk. That means SSD if you're > very rich, or many spindles > > Hey, Saving packet captures to file is a ~98% asynchronous write, 2% > read; ~95% sequential activity. And maybe you think about applying > some variant of header compression to the packets during capture, to > trade a little CPU and increased RAM requirements for storage > efficiency. > > The format used by PCAP and saving raw packet header bits directly to > disk is not necessarily among the most I/O or space efficient on disk > storage formats to pick. > > > Random writes should only occur if you are saving your captures to a > fragmented file system, which is not recommended; avoiding > fragmentation is important. Random reads aren't involved for > archiving data, only for analyzing it. > > Do you make random reads into your saved capture files? Possibly > you're more likely to be doing a sequential scan, even during > analysis; random reads imply you have already indexed a dataset and > you are seeking a smaller number of specific records, to collect > information about them. > > Read requirements are totally dependent on your analysis workload, > e.g. Table scan vs Index search. Depending on what the analysis is, > it may make sense to even make extra filtered copies of the data, > using more disk space, in order to avoid a random access pattern. > > If you are building a database of analysis results from raw data, you > can and use a separate random IO optimized disk subsystem for the > stats database. > > > If you really need approximately 200 MB/s with some random read > performance for analysis, you should probably be looking at building > a RAID50 with several 4-drive sets and 1gb+ of writeback cache. > > RAID10 makes more sense in situations where write requirements are not > sequential, when external storage is actually shared with multiple > applications, or when there is a requirement for a disk drive failure > to be truly transparent, but there is a huge capacity sacrifice in > choosing mirroring over parity. > > > There is a Time vs Cost tradeoff with regards to the analysis of the data. > > When your 'analysis tools' start reading data, the reads increase > the disk access time, and therefore reduce write performance; > therefore the reads should be throttled, the higher the capacity the > disk subsystem, the higher the cost. > > > Performing your analysis ahead of time via pre-caching, or at least > indexing newly captured data in small chunks on a continuous basis may > be useful, to minimize the amount of searching of the raw dataset > later. A small SSD or separate mirrored drive pair for that > function, would avoid adding load to the "raw capture storage" > disk system, if your analysis requirements are amenable to that > pattern. > > Modern OSes cache some recent filesystem data in RAM. So if the > server capturing data has sufficient SDRAM, analyzing data while > it's still hot in the page cache, and saving that analysis in an > efficient index for later use, can be useful. > > >(preferably 15k's) in a stripe/ raid10 if you're building from your scrap > pile. Bear in mind that write >cache won't help you, as the io isn't going > to be bursty, rather a continuous stream. > > Not really... A good read cache is more important for the analysis, > but Efficient write cache on your array and OS page cache is still > highly beneficial, especially because it can ensure that your RAID > subsystem is performing full stripe writes, for maximal efficiency of > sequential write activity, and it can delay the media write until the > optimal moment based on platter position, and sequence the read/write > requests; > > as long as the performance of the storage system behind the cache is > such that the storage system can on average successfully drain the > cache at a faster rate than you can fill it with data a sufficient > amount of the time, the write cache serves an important function. > > > Your I/O may be a continuous stream, but there are most certainly > variations and spikes in the rate of packets and the performance of > mechanical disk drives. > > > > Aligning your partitions with the physical disk geometry can produce > surprising speedups, as can >stripe block size changes, but that's > generally empirical, and depends on your workload. > > > For RAID systems partitions should absolutely be aligned if the OS > install defaults don't align them correctly; on a modern OS, the > defaults are normally OK. Having an unaligned or improperly aligned > partition is just a misconfiguration; A track crossing for every > other sector read is an easy way of doubling the size of small I/Os. > > You won't notice with this particular use case when you are writing > large blocks, you're writing a 100Mb chunk, asynchronously, you > won't notice a 63kB difference, it's less than .0001% of your > transfer size; this is primarily a concern during analysis or > database searching which may involve small random reads and small > synchronous random writes. > > In other words, you will probably get away just ignoring partition > alignment and filesystem block size, > so there are other aspects of the configuration to be more concerned about > (YMMV). > > -- > -JH > > From kyle.creyts at gmail.com Sun Apr 15 01:44:53 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sun, 15 Apr 2012 02:44:53 -0400 Subject: facebook ipv6 is down? In-Reply-To: <4F87C0CF.8000307@apolix.co.za> References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> <4F87C0CF.8000307@apolix.co.za> Message-ID: Could they be testing switching to v6 on the regular domain? On Apr 13, 2012 2:00 AM, "Graham Beneke" wrote: > On 11/04/2012 09:16, Frank Bulk wrote: > >> It's been down three times today, first from 2:58 pm to 5:58 pm Central, >> and >> then again from 7:59 pm to 9:58 pm, and then again from 10:59 pm till now. >> >> Interesting that the up and downs have been one to two minutes before the >> hour. >> > > I've been seeing the same thing - up and down for the last 3 days. The > site has been unreachable approximately 50% of the time according to my > monitoring system. > > The other interesting thing is that the failures did not occur at the same > time for all regions. Two of my monitoring nodes are seeing completely > different patterns of outages. > > -- > Graham Beneke > > From jgreco at ns.sol.net Sun Apr 15 01:46:29 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 15 Apr 2012 01:46:29 -0500 (CDT) Subject: Most energy efficient (home) setup In-Reply-To: Message-ID: <201204150646.q3F6kTsk061467@aurora.sol.net> > On Wed, Feb 22, 2012 at 3:48 PM, Joe Greco wrote: > > The current Mac mini "Server" model sports an i7 2.0GHz quad-core CPU > > and up to 16GB RAM (see OWC for that, IIRC). =A0Two drives, up to 750GB > > each, or SSD's if you prefer. > > The Mac mini server is quite intringuing with that low power > requirement . Unfortunately... 16 GB _Non-ECC_ memory. I sure > would not want to run a NAS VM on a server with non-ECC memory that > cannot correct single-bit errors, at least with any data I cared > much about.. > > When you have such a large quantity of RAM, single-bit/fade errors > caused by background irradiation happen often, although at a fairly > low rate. Usually on a workstation it's not an issue, because there > is not a massive quantity of idle memory. > > If you're running this 24x7 with VMs and Non-ECC memory, it's only a > question of time, > before silent memory corruption results in one of the VMs. > > And silent memory corruption can make its way to the filesystem, or > applications' internal saved data structures (such as the contents > of a VM's registry database). > > True can be partially mitigated with backups; but the idea of VMs > blue-screening or ESXi crashing with purple screen every 3 or 4 > months sounds annoying. While I don't disagree with the general thought, one could also say it's just a matter of time before your server's power supply fails, or a fan fails, or a hard drive fails. Since we don't hear about Mac mini server users screaming about how their servers are constantly crashing, the severity and frequency of memory corruption events may not be anywhere near what you suggest. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "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. From shortdudey123 at gmail.com Sun Apr 15 01:52:36 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 15 Apr 2012 01:52:36 -0500 Subject: facebook ipv6 is down? In-Reply-To: References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> <4F87C0CF.8000307@apolix.co.za> Message-ID: I doubt it since no v6 address is listed in dns for facebook.com or www.facebook.com -Grant On Sun, Apr 15, 2012 at 1:44 AM, Kyle Creyts wrote: > Could they be testing switching to v6 on the regular domain? > On Apr 13, 2012 2:00 AM, "Graham Beneke" wrote: > > > On 11/04/2012 09:16, Frank Bulk wrote: > > > >> It's been down three times today, first from 2:58 pm to 5:58 pm Central, > >> and > >> then again from 7:59 pm to 9:58 pm, and then again from 10:59 pm till > now. > >> > >> Interesting that the up and downs have been one to two minutes before > the > >> hour. > >> > > > > I've been seeing the same thing - up and down for the last 3 days. The > > site has been unreachable approximately 50% of the time according to my > > monitoring system. > > > > The other interesting thing is that the failures did not occur at the > same > > time for all regions. Two of my monitoring nodes are seeing completely > > different patterns of outages. > > > > -- > > Graham Beneke > > > > > From nanog at maunier.org Sun Apr 15 03:46:25 2012 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Sun, 15 Apr 2012 10:46:25 +0200 Subject: facebook ipv6 is down? In-Reply-To: References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> <4F87C0CF.8000307@apolix.co.za> Message-ID: Le 15 avril 2012 08:52, Grant Ridder a ?crit : > I doubt it since no v6 address is listed in dns for facebook.com or > www.facebook.com > > -Grant > > Actually www.facebook.com has a AAAA entry when your DNS is whitelisted like with Free.fr $ host www.facebook.com www.facebook.com has address 69.171.242.70 www.facebook.com has IPv6 address 2620:0:1c18:0:face:b00c:: -- Pierre-Yves Maunier From Valdis.Kletnieks at vt.edu Sun Apr 15 04:54:51 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Apr 2012 05:54:51 -0400 Subject: Most energy efficient (home) setup In-Reply-To: Your message of "Sun, 15 Apr 2012 01:46:29 -0500." <201204150646.q3F6kTsk061467@aurora.sol.net> References: <201204150646.q3F6kTsk061467@aurora.sol.net> Message-ID: <161121.1334483691@turing-police.cc.vt.edu> On Sun, 15 Apr 2012 01:46:29 -0500, Joe Greco said: > Since we don't hear about Mac mini server users screaming about how > their servers are constantly crashing, the severity and frequency of Googling for 'mac mini server crash' gets about 11.6M hits. I gave up after 10 pages of results, but up till that point most did in fact seem to be about crashes on Mac mini servers (the mail you replied to was on page 8 at the time). > memory corruption events may not be anywhere near what you suggest. "the severity and frequency of *noticed* memory corruption events". FTFY. (Keep in mind that if the box doesn't have ECC or at least parity, you *won't know* you had a bit fllip until you dereference that memory location. At which point if you're *lucky* you'll get a random crash that forces ou to reboot right away. If you're unlucky, you won't notice till you try to re-mount the disks after a reboot 2-3 months later....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From george.herbert at gmail.com Sun Apr 15 06:28:26 2012 From: george.herbert at gmail.com (George Herbert) Date: Sun, 15 Apr 2012 04:28:26 -0700 Subject: Most energy efficient (home) setup In-Reply-To: <20120414150449.GA25347@hiwaay.net> References: <4F455A8B.80809@mompl.net> <20120223152935.GA8659@ussenterprise.ufp.org> <4F88792E.5030406@mompl.net> <4F889693.4050401@mompl.net> <20120414150449.GA25347@hiwaay.net> Message-ID: <62E67BF4-D4E6-47FD-96D0-D697543F837A@gmail.com> With RAID 4, the parity disk IOPS on write will rate-limit the whole LUN... No big deal on a 4-drive LUN; terror on a 15-drive LUN... George William Herbert Sent from my iPhone On Apr 14, 2012, at 8:04, Chris Adams wrote: > Once upon a time, Jeroen van Aart said: >> There may be a performance penalty using raid4, because it uses one >> parity disk. Although that system looks like it can be useful for some >> purposes it looks less ideal for home use. Also I don't see how it would >> allow you to install your own OS. > > For read-mostly storage, there's no penalty as long as there's no disk > failure. The parity drive wouldn't even spin up for reads. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > From nanog at studio442.com.au Sun Apr 15 07:01:04 2012 From: nanog at studio442.com.au (Julien Goodwin) Date: Sun, 15 Apr 2012 22:01:04 +1000 Subject: Network Storage In-Reply-To: References: Message-ID: <4F8AB880.4090202@studio442.com.au> On 13/04/12 06:25, Maverick wrote: > Can you please comment on what is best solution for storing network > traffic. We have been graciously granted access by our network > administrator to capture traffic but the one Tera byte disk space is > no match with the data that we are seeing, so it fills up quickly. We > can't get additional space on the server itself so I am looking for > some external solutions. Can you please suggest something that would > be best for Gbps speeds . In terms of tools, something shiny that I've not had a chance to play with yet that is designed for this is Security Onion, which is an Ubuntu based linux distribution that groups a bunch of tools for doing this sort of thing. http://securityonion.blogspot.com/ From bicknell at ufp.org Sun Apr 15 08:38:28 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 15 Apr 2012 06:38:28 -0700 Subject: Network Storage In-Reply-To: References: <1334264800.7862.15277.camel@mike-desktop> Message-ID: <20120415133828.GA37221@ussenterprise.ufp.org> In a message written on Thu, Apr 12, 2012 at 05:16:27PM -0400, Maverick wrote: > 1) My goal is to store the traffic may be fore ever, and analyze it in > the future for security related incidents detected by ids/ips. Let's just assume you have enough disk space that you can write out every packet, or even just packet header. That's a hard problem, but you've received plenty of suggestions on how to go down that path. Once you have that data, how are you going to process it? Yes, disk reads are faster than disk writes, but not by that much. If it takes you 24 hours to write a day of data to disk, it might take you 12 hours just to read it all back off and process it. Processing a weeks worth of back data could take days. I'm also not even starting to count the CPU and memory necessary to build state tables and statistical analysis tables to generate useful data. There's a reason why most network traffic tools summarize early, as early as on the network device when using Netflow type collection. It's not just to save storage space on disk, but it's to make the processing of the data fast enough that it can be done in a short enough time that the data is still relevant when the processing is complete. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From cmorris at cs.odu.edu Sun Apr 15 10:45:06 2012 From: cmorris at cs.odu.edu (Charles Morris) Date: Sun, 15 Apr 2012 11:45:06 -0400 Subject: Most energy efficient (home) setup In-Reply-To: <201204150646.q3F6kTsk061467@aurora.sol.net> References: <201204150646.q3F6kTsk061467@aurora.sol.net> Message-ID: >> And silent memory corruption can make its way to the filesystem, or >> applications' internal saved data structures (such as the contents >> of a VM's registry database). > Since we don't hear about Mac mini server users screaming about how > their servers are constantly crashing, the severity and frequency of > memory corruption events may not be anywhere near what you suggest. > ECC is an absolute MUST. Case closed- unless you like corrupt encryption keys that blow away an entire volume. From mysidia at gmail.com Sun Apr 15 10:52:51 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 15 Apr 2012 10:52:51 -0500 Subject: Most energy efficient (home) setup In-Reply-To: <201204150646.q3F6kTsk061467@aurora.sol.net> References: <201204150646.q3F6kTsk061467@aurora.sol.net> Message-ID: On Sun, Apr 15, 2012 at 1:46 AM, Joe Greco wrote: > Since we don't hear about Mac mini server users screaming about how Do you hear of lots of Mac mini server users loading up 16GB of RAM? ---- > it's just a matter of time before your server's power supply fails, or The difference is power supplies don't fail nearly as often as 1-bit DRAM errors, except when subject to harsh conditions. HDD errors are comparably rare also; and yet, the drive surface of any HDD has error correction codes, because disk surfaces are subject to similar problems. Consumer desktop hard drives use non-ECC memory inside the drive for the cache/buffer memory, to save $$$: but it's typically only 12MB or so of memory, so it's approximately 300 days before you have a 50% chance of a single bit error caused by background radiation, and those are good odds, but nevertheless, people get corrupted files, so maybe they aren't that good. Consider that the probability 16GB of SDRAM experiences at least one single bit error at sea level, in a given 6 hour period exceeds 66% = 1 - (1 - 1.3e-12 * 6)^(16 * 2^30 * 8). In any given 24 hour period, the probability of at least one single bit error exceeds 98%. Assuming the memory is good and functioning correctly; It's expected to see on average approximately 3 to 4 1-bit errors per day. More are frequently seen. Now if most of this 16GB of memory is unused, you will never notice that over 30 days, 120 or so bits have been flipped from their proper value.. On the other hand, if you have some filesystem read cache for a NAS VM or database application in the effected space, and moderately important data is being damaged well, that's just plain uncool > > ... JG -- -JH From laurent at guerby.net Sun Apr 15 16:26:06 2012 From: laurent at guerby.net (Laurent GUERBY) Date: Sun, 15 Apr 2012 23:26:06 +0200 Subject: Most energy efficient (home) setup In-Reply-To: References: <201204150646.q3F6kTsk061467@aurora.sol.net> Message-ID: <1334525166.3887.1012.camel@pc2> On Sun, 2012-04-15 at 10:52 -0500, Jimmy Hess wrote: > In any given 24 hour period, the probability of at least > one single bit error exceeds 98%. Assuming the memory is good and > functioning correctly; > > It's expected to see on average approximately 3 to 4 1-bit errors > per day. More are frequently seen. > > Now if most of this 16GB of memory is unused, you will never notice > that over 30 days, 120 or so bits have been flipped from their > proper value.. Hi, I've been operating 4 desktop PCs with each the following configuration: 16 GB of RAM (4x4GB Kingston) running Linux about 15 VM (KVM) on DRBD disks using more than 10 GB of RAM for nearly a year now in a room without cooling. Over the year I've got one dead HDD and one dead SSD (both replaced) but no data corruption or host or VM crash. Do you have reference to recent papers with experimental data about non ECC memory errors? It should be fairly easy to do (write and read scan memory in a loop) and given your computations you should get bit errors in less than a day. I remember this paper in 2003 but this was using abnormal heat: http://www.cs.princeton.edu/~sudhakar/papers/memerr-slashdot-commentary.html Thanks in advance, Sincerely, Laurent From ispbuilder at gmail.com Sun Apr 15 17:35:01 2012 From: ispbuilder at gmail.com (Mike) Date: Sun, 15 Apr 2012 19:35:01 -0300 Subject: Most energy efficient (home) setup In-Reply-To: References: <201204150646.q3F6kTsk061467@aurora.sol.net> <1334525166.3887.1012.camel@pc2> Message-ID: I think the simple test for this problem is to take a non-ECC machine, boot from a CD/USB Key/etc with memtest or memtest86+ on it, and see if you get errors over the course of a few days. Getting errors will certainly prove that this problem exists (or that you have bad ram). From george.herbert at gmail.com Sun Apr 15 18:18:53 2012 From: george.herbert at gmail.com (George Herbert) Date: Sun, 15 Apr 2012 16:18:53 -0700 Subject: Network Storage In-Reply-To: References: <20120412214752.GA44566@spandex.luckie.org.nz> Message-ID: On Thu, Apr 12, 2012 at 3:19 PM, Jared Mauch wrote: > You can also look at a machine like this: > > http://www.supermicro.com/products/chassis/4U/417/SC417E16-R1400U.cfm > > Jared Mauch > > On Apr 12, 2012, at 5:47 PM, Matthew Luckie wrote: > >>> 1) My goal is to store the traffic may be fore ever, and analyze it in >>> the future for security related incidents detected by ids/ips. >> >> Take a look at "Building a Time Machine for Efficient Recording and >> Retrieval of High-Volume Network Traffic" >> >> https://www.usenix.org/conference/imc-05/building-time-machine-efficient-recording-and-retrieval-high-volume-network Just FYI, it's somewhat of a tossup on large large arrays with 3.5" and 2.5" models. Equivalent 3.5" units hold 36-48 HDDs, and drive sizes for enterprise SAS drives are 3 TB in 3.5" vs 1 TB in 2.5" now, so you get more per box with 3.5" drives. Also a lot cheaper in the end. About six months ago I purchased two similar boxes for nearline backups purposes (lower bandwidth) with 3.5" drives; 34 x 3 TB plus a couple of much faster 2.5" 15k boot drives, post-RAID-10-and-hotspare-and-filesystem usable space was about 42 TB. About $22k each. One can go somewhat cheaper than that but the VAR had a good support story and "just fixed it" the next day when a RAID card model didn't quite work out. -- -george william herbert george.herbert at gmail.com From andrew at networklabs.co.nz Sun Apr 15 18:43:23 2012 From: andrew at networklabs.co.nz (Andrew Thrift) Date: Mon, 16 Apr 2012 11:43:23 +1200 Subject: Network Storage In-Reply-To: References: <20120412214752.GA44566@spandex.luckie.org.nz> Message-ID: <4F8B5D1B.3070705@networklabs.co.nz> If you want something from a Tier1 the new Dell R720XD's will take 24x 900GB SAS disks and have 16 cores. If you order it with a SAS6-HBA you can add up to 8 trays of 24 x 900GB SAS disks to provide 194TB of raw space at quite a reasonable cost. Alternatively, you could have a couple of "probe" servers connected to some nice fast SAN backend with redundant controllers. This will provide failover at the probe and storage levels but will cost a fair bit more :) Regards, Andrew On 16/04/2012 11:18 a.m., George Herbert wrote: > On Thu, Apr 12, 2012 at 3:19 PM, Jared Mauch wrote: >> You can also look at a machine like this: >> >> http://www.supermicro.com/products/chassis/4U/417/SC417E16-R1400U.cfm >> >> Jared Mauch >> >> On Apr 12, 2012, at 5:47 PM, Matthew Luckie wrote: >> >>>> 1) My goal is to store the traffic may be fore ever, and analyze it in >>>> the future for security related incidents detected by ids/ips. >>> Take a look at "Building a Time Machine for Efficient Recording and >>> Retrieval of High-Volume Network Traffic" >>> >>> https://www.usenix.org/conference/imc-05/building-time-machine-efficient-recording-and-retrieval-high-volume-network > Just FYI, it's somewhat of a tossup on large large arrays with 3.5" > and 2.5" models. Equivalent 3.5" units hold 36-48 HDDs, and drive > sizes for enterprise SAS drives are 3 TB in 3.5" vs 1 TB in 2.5" now, > so you get more per box with 3.5" drives. Also a lot cheaper in the > end. > > About six months ago I purchased two similar boxes for nearline > backups purposes (lower bandwidth) with 3.5" drives; 34 x 3 TB plus a > couple of much faster 2.5" 15k boot drives, > post-RAID-10-and-hotspare-and-filesystem usable space was about 42 TB. > About $22k each. One can go somewhat cheaper than that but the VAR > had a good support story and "just fixed it" the next day when a RAID > card model didn't quite work out. > > From mysidia at gmail.com Sun Apr 15 19:12:55 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 15 Apr 2012 19:12:55 -0500 Subject: Most energy efficient (home) setup In-Reply-To: References: <201204150646.q3F6kTsk061467@aurora.sol.net> <1334525166.3887.1012.camel@pc2> Message-ID: On Sun, Apr 15, 2012 at 5:35 PM, Mike wrote: It's not like ECC memory requires a lot of power, a full-blown ATX board or something; there is the Intel S1200KP Mini-ITX board. See, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.5936&rep=rep1&type=pdf But the exact rate of single bit errors in non-ECC memory today is not necessarily predictable based on past studies from the 90s, and depends on environment also -- local lightning, solar activity, which is increasing lately; how much extra shielding you have in place (Server placed inside a Faraday cage/Lead box ?), etc --- you'd need measurements for your specific hardware; there are likely dependencies on the size of the memory cells, the vertical cross section, other components in the system. > I think the simple test for this problem is to take a non-ECC machine, boot > from a CD/USB Key/etc with memtest or memtest86+ on it, and see if you get > errors over the course of a few days. Memtest86+ contains a series of tests that help uncover specific kinds of common memory faults; at any particular point in time, during a memtest, there is only a confined range of physical memory addresses under test, a bit flip anywhere else won't be detected. Which means that Memtest is not likely to detect the error. Test #11 Bit-Fade with modifications could have some promise; you need a 24 hour delay instead of a 5 minute delay. You need to have close to the entire physical address space under test. And you need truly random bit values stored to some "reliable" medium, instead of the shortcut of storing known bit patterns. *Memtest86+ itself and the system BIOS have to be stored in memory or CPU cache somewhere. But then again, a random bit flip in non-ECC CPU L2 cache is a possibility, but software like memtest if suitably modified could be made to detect a 1-bit error that showed up in the majority of the memory addresses. -- -JH From lsc at prgmr.com Sun Apr 15 20:54:14 2012 From: lsc at prgmr.com (Luke S. Crawford) Date: Sun, 15 Apr 2012 21:54:14 -0400 Subject: Most energy efficient (home) setup In-Reply-To: References: <201204150646.q3F6kTsk061467@aurora.sol.net> Message-ID: <20120416015413.GE24826@luke.xen.prgmr.com> On Sun, Apr 15, 2012 at 10:52:51AM -0500, Jimmy Hess wrote: > Consider that the probability 16GB of SDRAM experiences at least one > single bit error at sea level, > in a given 6 hour period exceeds 66% = 1 - (1 - 1.3e-12 * 6)^(16 * > 2^30 * 8). In any given 24 hour period, the probability of at least > one single bit error exceeds 98%. Assuming the memory is good and > functioning correctly; > > It's expected to see on average approximately 3 to 4 1-bit errors > per day. More are frequently seen. > > Now if most of this 16GB of memory is unused, you will never notice > that over 30 days, 120 or so bits have been flipped from their > proper value.. I think that is an overestimate, at least if single-bit (corrected) ecc errors are as common as flipped bits on non-ecc ram. Now, First, count me in the "ECC is a must, full stop." crowd. I insist on ecc for even my customer's dedicated servers, even though most of the customers don't care that much. "It's not for you, it's for me." With ECC? if you have EDAC/bluesmoke setup correctly on a supported motherboard, you get console spew whenever you have a single-bit error. This means I can do a very simple grep on the box conserver logs to and I can find all the failing ram modules I am responsible for. Without ecc, I have no real way of telling the difference between broken software and broken ram. That said, I still think the 120 bits a month estimate is large; I believe that ECC ram should report correctable errors (assuming a correctly configured EDAC/bluesmoke module and supported chipset) about as often as non-ecc ram would get a bit flip. In a past role, I did spend the time grepping through such a properly configured cluster, with tens of thousands of nodes, looking for failing hardware. I should have done a proper paper with statistics, but I did not. The vast majority of servers had zero correctable ecc errors, while a few had a lot, which is consistent with the theory that ECC errors are more often caused by bad ram. (Of course, all these servers were in proper cases in a proper data center, which probably gives you a fair bit of shielding.) On my current fleet (well under 100 servers) single bit errors are so rare that if I get one, I schedule that machine for removal from production. From jgreco at ns.sol.net Sun Apr 15 21:00:48 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 15 Apr 2012 21:00:48 -0500 (CDT) Subject: Most energy efficient (home) setup In-Reply-To: Message-ID: <201204160200.q3G20m6j075567@aurora.sol.net> > >> And silent memory corruption can make its way to the filesystem, or > >> applications' internal saved data structures (such as the contents > >> of a VM's registry database). > > > Since we don't hear about Mac mini server users screaming about how > > their servers are constantly crashing, the severity and frequency of > > memory corruption events may not be anywhere near what you suggest. > > ECC is an absolute MUST. Case closed- > unless you like corrupt encryption keys that blow away an entire volume. You might want to go tell that to all those Mac users who have full disk encryption... ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "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. From frnkblk at iname.com Sun Apr 15 21:05:15 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 15 Apr 2012 21:05:15 -0500 Subject: facebook ipv6 is down? In-Reply-To: References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> <4F87C0CF.8000307@apolix.co.za> Message-ID: <002b01cd1b75$5d9d83e0$18d88ba0$@iname.com> You're using a DNS resolver or coming from a network that's facebook blessed. Note the difference: server:# dig AAAA www.facebook.com @ordns.he.net +short 2620:0:1c18:0:face:b00c:0:3 server:# dig AAAA www.facebook.com @8.8.8.8 +short server:# Frank -----Original Message----- From: Pierre-Yves Maunier [mailto:nanog at maunier.org] Sent: Sunday, April 15, 2012 3:46 AM To: Grant Ridder Cc: nanog at nanog.org Subject: Re: facebook ipv6 is down? Le 15 avril 2012 08:52, Grant Ridder a ?crit : > I doubt it since no v6 address is listed in dns for facebook.com or > www.facebook.com > > -Grant > > Actually www.facebook.com has a AAAA entry when your DNS is whitelisted like with Free.fr $ host www.facebook.com www.facebook.com has address 69.171.242.70 www.facebook.com has IPv6 address 2620:0:1c18:0:face:b00c:: -- Pierre-Yves Maunier From jgreco at ns.sol.net Sun Apr 15 21:15:29 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 15 Apr 2012 21:15:29 -0500 (CDT) Subject: Most energy efficient (home) setup In-Reply-To: <20120416015413.GE24826@luke.xen.prgmr.com> Message-ID: <201204160215.q3G2FTJZ075724@aurora.sol.net> > In a past role, I did spend the time grepping through such a properly > configured cluster, with tens of thousands of nodes, looking for failing > hardware. I should have done a proper paper with statistics, but > I did not. The vast majority of servers had zero correctable ecc errors, > while a few had a lot, which is consistent with the theory that ECC errors > are more often caused by bad ram. I'd have to say that that's been the experience here as well, ECC is great, yes, but it just doesn't seem to be something that is "absolutely vital" on an ongoing basis, as some of the other posters here have implied, to correct the constant bit errors that are(n't) showing up. Maybe I'll get bored one of these days and find some devtools to stick on one of the Macs. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "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. From shortdudey123 at gmail.com Sun Apr 15 22:15:19 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 15 Apr 2012 22:15:19 -0500 Subject: facebook ipv6 is down? In-Reply-To: <002b01cd1b75$5d9d83e0$18d88ba0$@iname.com> References: <7A848D4888ADA94B8A46A17296740133BABCF25E35@DEXTER.oasis-tech.local> <037801cd17b2$fff92cf0$ffeb86d0$@iname.com> <4F87C0CF.8000307@apolix.co.za> <002b01cd1b75$5d9d83e0$18d88ba0$@iname.com> Message-ID: Interesting. I was using google DNS (8.8.8.8) when i made my previous statement. -Grant On Sun, Apr 15, 2012 at 9:05 PM, Frank Bulk wrote: > You're using a DNS resolver or coming from a network that's facebook > blessed. Note the difference: > > server:# dig AAAA www.facebook.com @ordns.he.net +short > 2620:0:1c18:0:face:b00c:0:3 > server:# dig AAAA www.facebook.com @8.8.8.8 +short > server:# > > Frank > > -----Original Message----- > From: Pierre-Yves Maunier [mailto:nanog at maunier.org] > Sent: Sunday, April 15, 2012 3:46 AM > To: Grant Ridder > Cc: nanog at nanog.org > Subject: Re: facebook ipv6 is down? > > Le 15 avril 2012 08:52, Grant Ridder a ?crit : > > > I doubt it since no v6 address is listed in dns for facebook.com or > > www.facebook.com > > > > -Grant > > > > > Actually www.facebook.com has a AAAA entry when your DNS is whitelisted > like with Free.fr > > $ host www.facebook.com > www.facebook.com has address 69.171.242.70 > www.facebook.com has IPv6 address 2620:0:1c18:0:face:b00c:: > > -- > Pierre-Yves Maunier > > > > From simon.leinen at switch.ch Mon Apr 16 04:37:34 2012 From: simon.leinen at switch.ch (Simon Leinen) Date: Mon, 16 Apr 2012 11:37:34 +0200 Subject: Network Storage In-Reply-To: <4F8B5D1B.3070705@networklabs.co.nz> (Andrew Thrift's message of "Mon, 16 Apr 2012 11:43:23 +1200") References: <20120412214752.GA44566@spandex.luckie.org.nz> <4F8B5D1B.3070705@networklabs.co.nz> Message-ID: Andrew Thrift writes: > If you want something from a Tier1 the new Dell R720XD's will take 24x > 900GB SAS disks or 12x 2TB 3.5" cheap & slow SATA disks or 12x 3TB 3.5" more expensive & slightly faster SAS disks - if you take the (cheaper) 3.5"-disk variant of the R720xd chassis. or 12x 3TB 3.5" cheap&slow SATA disks if you buy them directly rather than from Dell. (Presumably you'd have to buy Dell "hot-swap trays") -- Simon. > and have 16 cores. If you order it with a SAS6-HBA you can add up to > 8 trays of 24 x 900GB SAS disks to provide 194TB of raw space at quite > a reasonable cost. From jamie at photon.com Mon Apr 16 07:08:25 2012 From: jamie at photon.com (Jamie Bowden) Date: Mon, 16 Apr 2012 12:08:25 +0000 Subject: Most energy efficient (home) setup In-Reply-To: <201204160215.q3G2FTJZ075724@aurora.sol.net> References: <20120416015413.GE24826@luke.xen.prgmr.com> <201204160215.q3G2FTJZ075724@aurora.sol.net> Message-ID: <465966A5F5B867419F604CD3E604C1E50525BEAF@pra-dca-mail.pra.ray.com> > From: Joe Greco [mailto:jgreco at ns.sol.net] > I'd have to say that that's been the experience here as well, ECC is > great, yes, but it just doesn't seem to be something that is > "absolutely > vital" on an ongoing basis, as some of the other posters here have > implied, to correct the constant bit errors that are(n't) showing up. > > Maybe I'll get bored one of these days and find some devtools to stick > on one of the Macs. In all the years I've been playing with high end hardware, the best sample machine I have is an SGI Origin 200 that I had in production for over ten years, with the only downtime during that time being once to add more memory, once to replace a failed drive, once to move the rack and the occasional OS upgrade (I tended to skip a 6.5.x release or two between updates, and after 6.5.30 there were of course no more). That machine was down less than 24 hours cumulative for that entire period. In that ten year span, I saw TWO ECC parity errors (both single bit correctable). On any machine that saw regular ECC errors it was a sign of failing hardware (usually, but not necessarily the memory, there are other parts in there that have to carry that data too). As much as I prefer ECC, it's not a show stopper for me if it's not there. Jamie From bicknell at ufp.org Mon Apr 16 07:39:34 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 16 Apr 2012 05:39:34 -0700 Subject: Most energy efficient (home) setup In-Reply-To: <20120416015413.GE24826@luke.xen.prgmr.com> References: <201204150646.q3F6kTsk061467@aurora.sol.net> <20120416015413.GE24826@luke.xen.prgmr.com> Message-ID: <20120416123934.GA82926@ussenterprise.ufp.org> In a message written on Sun, Apr 15, 2012 at 09:54:14PM -0400, Luke S. Crawford wrote: > On my current fleet (well under 100 servers) single bit errors are so rare > that if I get one, I schedule that machine for removal from production. In a previous life, in a previous time, I worked at a place that had a bunch of Cisco's with parity RAM. For the time, these boxes had a lot of RAM, as they had distributed line cards each with their own processor memory. Cisco was rather famous for these parity errors, mostly because of their stock answer: sunspots. The answer was in fact largely correct, but it's just not a great response from a vendor. They had a bunch of statistics though, collected from many of these deployed boxes. We ran the statistics, and given hundreds of routers, each with many line cards the math told us we should have approximately 1 router every 9-10 months get one parity error from sunspots and other random activity (e.g. not a failing RAM module with hundreds of repeatable errors). This was, in fact, close to what we observed. This experience gave me two takeaways. First, single bit flips are rare, but when you have enough boxes rare shows up often. It's very similar to anyone with petabytes of storage, disks fail every couple of days because you have so many of them. At the same time a home user might not see a failure in their lifetime (of disk or memory). Second though, if you're running a business, ECC is a must because the message is so bad. "This was caused by sunspots" is not a customer inspiring response, no matter how correct. "We could have prevented this by spending an extra $50 on proper RAM for your $1M box" is even worse. Some quick looking at Newegg, 4GB DDR3 1333 ECC DIMM, $33.99. 4GB DDR3 1333 Non-ECC DIMM, $21.99. Savings, $12. (Yes, I realize the Motherboard also needs some extra circuitry, I expect it's less than $1 in quantity though). Pretty much everyone I know values their data at more than $12 if it is lost. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jgreco at ns.sol.net Mon Apr 16 08:14:08 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Apr 2012 08:14:08 -0500 (CDT) Subject: Most energy efficient (home) setup In-Reply-To: <20120416123934.GA82926@ussenterprise.ufp.org> Message-ID: <201204161314.q3GDE8UQ086062@aurora.sol.net> > Some quick looking at Newegg, 4GB DDR3 1333 ECC DIMM, $33.99. 4GB > DDR3 1333 Non-ECC DIMM, $21.99. Savings, $12. (Yes, I realize the > Motherboard also needs some extra circuitry, I expect it's less than $1 > in quantity though). > > Pretty much everyone I know values their data at more than $12 if it > is lost. The problem is that if you want to move past the 4GB modules, things can get expensive. Bearing in mind the subject line, consider for example the completely awesome Intel Sandy Bridge E3-1230 with a board like the Supermicro X9SCL+-F, which can be built into a low power system that idles around 45W if you're careful. Problem is, the 8GB modules tend to cost an arm and a leg; http://www.google.com/products/catalog?q=MEM-DR380L-CL01-EU13&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&hl=en&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&biw=1043&bih=976&ie=UTF-8&tbm=shop&cid=8556948603121267780&sa=X&ei=HxmMT5btB8_PgAfLs5TvCQ&ved=0CD8Q8wIwAA to outfit a machine with 32GB several months ago cost around *$400* per module, or $1600 for the machine, whereas the average cost for a 4GB module was only around $30. So then you start looking at the less expensive options. When the average going price for 8GB non-ECC modules is between $50 and $100, then you're "only" looking at a cost premium of $1200 for ECC. For $1200, I'm willing to at least consider non-ECC. You can infer from this message that I'm actually waiting for more reasonable ECC prices to show up; we're finally seeing somewhat more reasonable prices, but by that I mean "only" around $130/8GB. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "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. From rbonica at juniper.net Mon Apr 16 09:05:15 2012 From: rbonica at juniper.net (Ronald Bonica) Date: Mon, 16 Apr 2012 10:05:15 -0400 Subject: Communal Dining Message-ID: <13205C286662DE4387D9AF3AC30EF456D76A4A4A70@EMBX01-WF.jnpr.net> Folks, You are all invited to an extremely informal dinner at our house at 6PM on Saturday, April 21. Spouses and children are all invited. I will bake bread and put on a huge pot of soup. If your kids are picky eaters, feel free to bring whatever they will eat. Our house is located at: 241 West Meadowland Lane Sterling, Virgina 20164 703 430 8379 -------------------------- Ron and Nancy Bonica vcard: www.bonica.org/ron/ronbonica.vcf From rbonica at juniper.net Mon Apr 16 09:11:44 2012 From: rbonica at juniper.net (Ronald Bonica) Date: Mon, 16 Apr 2012 10:11:44 -0400 Subject: FW: Communal Dining Message-ID: <13205C286662DE4387D9AF3AC30EF456D76A4A4A99@EMBX01-WF.jnpr.net> Folks, Sorry, you are not all invited to dinner. I apologize for the spam. MS mail address completion helped me a little more than I wanted. Ron > -----Original Message----- > From: Ronald Bonica > Sent: Monday, April 16, 2012 10:05 AM > To: 'FRBILLS at aol.com'; 'Nicholas Hinko'; 'Susan Hinko'; jay cuasay; > 'William Richey'; Will Ress; 'maria torres'; 'landreyko at gmail.com'; > nanog at nanog.org > Subject: Communal Dining > > Folks, > > You are all invited to an extremely informal dinner at our house at 6PM > on Saturday, April 21. Spouses and children are all invited. I will > bake bread and put on a huge pot of soup. If your kids are picky > eaters, feel free to bring whatever they will eat. > > Our house is located at: > > 241 West Meadowland Lane > Sterling, Virgina 20164 > 703 430 8379 > > -------------------------- > Ron and Nancy Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > From jhellenthal at dataix.net Mon Apr 16 09:58:20 2012 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 16 Apr 2012 10:58:20 -0400 Subject: FW: Communal Dining In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76A4A4A99@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D76A4A4A99@EMBX01-WF.jnpr.net> Message-ID: <20120416145820.GA59587@DataIX.net> Shoot I was half way there already! :-) On Mon, Apr 16, 2012 at 10:11:44AM -0400, Ronald Bonica wrote: > Folks, > > Sorry, you are not all invited to dinner. I apologize for the spam. > > MS mail address completion helped me a little more than I wanted. > > Ron > > > > -----Original Message----- > > From: Ronald Bonica > > Sent: Monday, April 16, 2012 10:05 AM > > To: 'FRBILLS at aol.com'; 'Nicholas Hinko'; 'Susan Hinko'; jay cuasay; > > 'William Richey'; Will Ress; 'maria torres'; 'landreyko at gmail.com'; > > nanog at nanog.org > > Subject: Communal Dining > > > > Folks, > > > > You are all invited to an extremely informal dinner at our house at 6PM > > on Saturday, April 21. Spouses and children are all invited. I will > > bake bread and put on a huge pot of soup. If your kids are picky > > eaters, feel free to bring whatever they will eat. > > > > Our house is located at: > > > > 241 West Meadowland Lane > > Sterling, Virgina 20164 > > 703 430 8379 > > > > -------------------------- > > Ron and Nancy Bonica > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > From leigh.porter at ukbroadband.com Mon Apr 16 10:05:28 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 16 Apr 2012 15:05:28 +0000 Subject: Communal Dining In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76A4A4A70@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D76A4A4A70@EMBX01-WF.jnpr.net> Message-ID: Is this going to be like when teenagers advertise their parties on facebook? > -----Original Message----- > From: Ronald Bonica [mailto:rbonica at juniper.net] > Sent: 16 April 2012 15:09 > To: FRBILLS at aol.com; Nicholas Hinko; Susan Hinko; jay cuasay; William > Richey; Will Ress; maria torres; landreyko at gmail.com; nanog at nanog.org > Subject: Communal Dining > > Folks, > > You are all invited to an extremely informal dinner at our house at 6PM > on Saturday, April 21. Spouses and children are all invited. I will > bake bread and put on a huge pot of soup. If your kids are picky > eaters, feel free to bring whatever they will eat. > > Our house is located at: > > 241 West Meadowland Lane > Sterling, Virgina 20164 > 703 430 8379 > > -------------------------- > Ron and Nancy Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From drew.weaver at thenap.com Mon Apr 16 10:56:40 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 16 Apr 2012 11:56:40 -0400 Subject: Communal Dining In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D76A4A4A70@EMBX01-WF.jnpr.net> Message-ID: There used to be a modification to the WWIV BBS software that when you entered the 'boards' section (wow I am so old, by the way) it would display 'Party at my house' and show all of the user's information in it's best "ascii" representation; of course it showed only that user's information to themselves so it looked like everyone was having a party, many complaints were filed =) -----Original Message----- From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] Sent: Monday, April 16, 2012 11:05 AM To: Ronald Bonica; nanog at nanog.org Subject: RE: Communal Dining Is this going to be like when teenagers advertise their parties on facebook? > -----Original Message----- > From: Ronald Bonica [mailto:rbonica at juniper.net] > Sent: 16 April 2012 15:09 > To: FRBILLS at aol.com; Nicholas Hinko; Susan Hinko; jay cuasay; William > Richey; Will Ress; maria torres; landreyko at gmail.com; nanog at nanog.org > Subject: Communal Dining > > Folks, > > You are all invited to an extremely informal dinner at our house at > 6PM on Saturday, April 21. Spouses and children are all invited. I > will bake bread and put on a huge pot of soup. If your kids are picky > eaters, feel free to bring whatever they will eat. > > Our house is located at: > > 241 West Meadowland Lane > Sterling, Virgina 20164 > 703 430 8379 > > -------------------------- > Ron and Nancy Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From drew.weaver at thenap.com Mon Apr 16 10:58:08 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 16 Apr 2012 11:58:08 -0400 Subject: Network Storage In-Reply-To: References: <20120412214752.GA44566@spandex.luckie.org.nz> <4F8B5D1B.3070705@networklabs.co.nz> Message-ID: I'd like to point out that you can actually do 26 2.5" disks on an R720xd if you use the flexbay +1 SD card for your os install if you're being a maximalist. =) -Drew -----Original Message----- From: Simon Leinen [mailto:simon.leinen at switch.ch] Sent: Monday, April 16, 2012 5:38 AM To: Andrew Thrift Cc: nanog at nanog.org Subject: Re: Network Storage Andrew Thrift writes: > If you want something from a Tier1 the new Dell R720XD's will take 24x > 900GB SAS disks or 12x 2TB 3.5" cheap & slow SATA disks or 12x 3TB 3.5" more expensive & slightly faster SAS disks - if you take the (cheaper) 3.5"-disk variant of the R720xd chassis. or 12x 3TB 3.5" cheap&slow SATA disks if you buy them directly rather than from Dell. (Presumably you'd have to buy Dell "hot-swap trays") -- Simon. > and have 16 cores. If you order it with a SAS6-HBA you can add up to > 8 trays of 24 x 900GB SAS disks to provide 194TB of raw space at quite > a reasonable cost. From me at anuragbhatia.com Mon Apr 16 13:09:46 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 16 Apr 2012 23:39:46 +0530 Subject: Automatic IPv6 due to broadcast Message-ID: Hello everyone Just got a awfully crazy issue. I heard from our support team about failure of whois during domain registration. Initially I thought of port 43 TCP block or something but found it was all ok. Later when ran whois manually on server via terminal it failed. Found problem that server was connecting to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6 and not just that one - almost all. This was scary - partial IPv6 setup and it was breaking things. In routing tables, routes were all going to a router which I recently setup for testing. That router and other servers are under same switch but by no means I ever configured that router as default gateway for IPv6. I found option of "broadcast" was enabled on router for local fe80... address and I guess router broadcasted IPv6 and somehow (??) all servers found that they have a IPv6 router on LAN and started using it - automated DHCP IPv6? I wonder if anyone else also had similar issues? Also, if my guesses are correct then how can we disable Red Hat distro oriented servers from taking such automated configuration - simple DHCP in IPv6 disable? Thanks -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From nanog at voipro.nl Mon Apr 16 13:22:20 2012 From: nanog at voipro.nl (Henk Hesselink) Date: Mon, 16 Apr 2012 11:22:20 -0700 Subject: Most energy efficient (home) setup In-Reply-To: <4F88792E.5030406@mompl.net> References: <4F455A8B.80809@mompl.net> <20120223152935.GA8659@ussenterprise.ufp.org> <4F88792E.5030406@mompl.net> Message-ID: <4F8C635C.1050408@voipro.nl> Have you looked at the HP ProLiant MicroServer? Cheers, Henk On 13-04-12 12:06, Jeroen van Aart wrote: > Leo Bicknell wrote: >> But what's really missing is storage management. RAID5 (and similar) >> require all drives to be online all the time. I'd love an intelligent >> file system that could spin down drives when not in use, and even for >> many workloads spin up only a portion of the drives. It's easy to >> imagine a system with a small SSD and a pair of disks. Reads spin one >> disk. Writes go to that disk and the SSD until there are enough, which >> spins up the second drive and writes them out as a proper mirror. In a >> home file server drive motors, time you have 4-6 drives, eat most of the >> power. CPU's speed step down nicely, drives don't. > > Late reply by me, but excellent points. > > A combination of mdadm and hdparm on linux should suffice to have a raid > that will spin down the disks when not in use. I have used for years a > G4 system with a mdadm raid1 (and a separate boot disk) and hdparm > configured to spin the raid disks down after 10 minutes and it worked > great. > > I think in a raid10 this would only spin up the disk pair that has the > data you need, but leave the rest asleep. But I didn't try that yet. > > What I'd like is to have small disk enclosuer that includes a whole (low > power) computer capable of having linux installed on some flash memory. > Say you have an enclosure with space for 4 2.5 inch disks, install > linux, set it up as a raid10, connect through USB to your computer for > back up purposes. > > Greetings, > Jeroen > From mhuff at ox.com Mon Apr 16 13:24:51 2012 From: mhuff at ox.com (Matthew Huff) Date: Mon, 16 Apr 2012 14:24:51 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: Message-ID: <483E6B0272B0284BA86D7596C40D29F901928A894BE7@PUR-EXCH07.ox.com> To completely disable ipv6 in Redhat: 1) Modify /etc/modprobe.conf (add) alias ipv6 off alias net-pf-10 off options ipv6 disable=1 2) Modify /etc/sysconfig/network (add) NETWORKING_IPV6=no I usually also add NOZEROCONF=yes That should completely disable ipv6 in Redhat 5.x ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Anurag Bhatia [mailto:me at anuragbhatia.com] > Sent: Monday, April 16, 2012 2:10 PM > To: NANOG Mailing List > Subject: Automatic IPv6 due to broadcast > > Hello everyone > > > > Just got a awfully crazy issue. I heard from our support team about > failure of whois during domain registration. Initially I thought of > port 43 TCP block or something but found it was all ok. Later when ran > whois manually on server via terminal it failed. Found problem that > server was connecting to whois server - whois.verisign-grs.com. I was > stunned! Server got IPv6 and not just that one - almost all. This was > scary - partial IPv6 setup and it was breaking things. > > In routing tables, routes were all going to a router which I recently > setup for testing. That router and other servers are under same switch > but by no means I ever configured that router as default gateway for > IPv6. I found option of "broadcast" was enabled on router for local > fe80... address and I guess router broadcasted IPv6 and somehow (??) > all servers found that they have a IPv6 router on LAN and started using > it - automated DHCP IPv6? > > I wonder if anyone else also had similar issues? Also, if my guesses > are correct then how can we disable Red Hat distro oriented servers > from taking such automated configuration - simple DHCP in IPv6 disable? > > > > > Thanks > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5339 bytes Desc: not available URL: From seth.mos at dds.nl Mon Apr 16 13:43:30 2012 From: seth.mos at dds.nl (Seth Mos) Date: Mon, 16 Apr 2012 20:43:30 +0200 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: Message-ID: Hi Anurag, Op 16 apr 2012, om 20:09 heeft Anurag Bhatia het volgende geschreven: > Hello everyone > I wonder if anyone else also had similar issues? Also, if my guesses are > correct then how can we disable Red Hat distro oriented servers from taking > such automated configuration - simple DHCP in IPv6 disable? Instead of disabling IPv6 on all the nodes in question you might be better off switching off Router Advertisements and investing a little bit of your time into what this IPv6 thing is. Something on your network is advertising itself as the router, I suggest looking at it now, it won't magically fix itself. If what is advertising itself as a IPv6 router is not the right device, disable. And while you are at it, setup one of which you know it is supposed to be one. It's really not all that hard anymore. http://lists.pfsense.org/pipermail/list/2012-April/001942.html And as I discovered a few days ago, I can't access github.com from my IPv6 only connection, which is a problem for software development. And for those wondering, the circuit is brand new, and no, it really doesn't have any IPv4. Good thing that Google works though, and the website of my local Grocery store does too. Regards, Seth From Valdis.Kletnieks at vt.edu Mon Apr 16 13:50:44 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 16 Apr 2012 14:50:44 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: Your message of "Mon, 16 Apr 2012 23:39:46 +0530." References: Message-ID: <15509.1334602244@turing-police.cc.vt.edu> On Mon, 16 Apr 2012 23:39:46 +0530, Anurag Bhatia said: More a host config issue than a NANOG issue, but what the heck... > I wonder if anyone else also had similar issues? Also, if my guesses are > correct then how can we disable Red Hat distro oriented servers from taking > such automated configuration - simple DHCP in IPv6 disable? The *right* answer is, of course, to hurry up and deploy proper IPv6. It sounds like the distro is shipping some apps that don't do happy-eyeballs yet - you probably want to file bug reports about that. (It's easy enough to disable IPv6 if you haven't deployed it - in /etc/sysconfig/network-scripts/ifcfg- add: IPV6INIT=no then ifdown/ifup the interface and you should be good to go. Make sure you remember to take that line out when you get around to deploying IPv6. (The difference between this and Matthew Huff's suggestion is that this way, it disables IPv6 on the interface, and leaves the ::1 loopback address in place.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From eugen at leitl.org Mon Apr 16 14:21:36 2012 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 16 Apr 2012 21:21:36 +0200 Subject: Most energy efficient (home) setup In-Reply-To: <4F8C635C.1050408@voipro.nl> References: <4F455A8B.80809@mompl.net> <20120223152935.GA8659@ussenterprise.ufp.org> <4F88792E.5030406@mompl.net> <4F8C635C.1050408@voipro.nl> Message-ID: <20120416192136.GR28282@leitl.org> On Mon, Apr 16, 2012 at 11:22:20AM -0700, Henk Hesselink wrote: > Have you looked at the HP ProLiant MicroServer? Notice it takes up to 8 GByte ECC memory and supports zfs via napp-it/Illumos. A hacked BIOS was required to use the 5th internal SATA port in AHCI mode, maybe that's no longer necessary with N40L. From arturo.servin at gmail.com Mon Apr 16 14:32:22 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 16 Apr 2012 16:32:22 -0300 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: Message-ID: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> Anurag, You have a rogue RA in your network. Now is just an annoying DoS, but it can easily be turned in a real security concern. I suggest to either deploy properly IPv6 or disable it. I am more on the former, but it is your choice. Regards -as On 16 Apr 2012, at 15:09, Anurag Bhatia wrote: > Hello everyone > > > > Just got a awfully crazy issue. I heard from our support team about failure > of whois during domain registration. Initially I thought of port 43 TCP > block or something but found it was all ok. Later when ran whois manually > on server via terminal it failed. Found problem that server was connecting > to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6 > and not just that one - almost all. This was scary - partial IPv6 setup and > it was breaking things. > > In routing tables, routes were all going to a router which I recently setup > for testing. That router and other servers are under same switch but by no > means I ever configured that router as default gateway for IPv6. I found > option of "broadcast" was enabled on router for local fe80... address and I > guess router broadcasted IPv6 and somehow (??) all servers found that they > have a IPv6 router on LAN and started using it - automated DHCP IPv6? > > I wonder if anyone else also had similar issues? Also, if my guesses are > correct then how can we disable Red Hat distro oriented servers from taking > such automated configuration - simple DHCP in IPv6 disable? > > > > > Thanks > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com From jgreco at ns.sol.net Mon Apr 16 14:38:18 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Apr 2012 14:38:18 -0500 (CDT) Subject: Most energy efficient (home) setup In-Reply-To: <20120416192136.GR28282@leitl.org> Message-ID: <201204161938.q3GJcIRr090497@aurora.sol.net> > On Mon, Apr 16, 2012 at 11:22:20AM -0700, Henk Hesselink wrote: > > Have you looked at the HP ProLiant MicroServer? > > Notice it takes up to 8 GByte ECC memory and supports zfs > via napp-it/Illumos. A hacked BIOS was required to use > the 5th internal SATA port in AHCI mode, maybe that's > no longer necessary with N40L. The MicroServer is actually a nice little platform, one little bright spot in the small-home-server market. It does have some other issues though: 1) It's not particularly low-power, as in, I managed to build some Xeon based systems that run rings around it for only maybe a dozen watts more, and some of the NAShead guys over at one of the Linux based projects have a similar but lower-power platform for a lower price, 2) While it has a remote management card available, it's known to not work with certain things, including FreeBSD, 3) Various problems noted with the eSATA port, such as the inability to use an external port multiplier. On the flip side, some people have tossed one of those 4-2.5"-in-a-5.25" bay racks into the optical bay, along with a PCI controller, to allow the addition of SSD's or whatever for NAS use. Pretty cool and the thing *is* pretty compact. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "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. From bpenglase-nanog at SpaceServices.net Mon Apr 16 16:38:07 2012 From: bpenglase-nanog at SpaceServices.net (Brandon Penglase) Date: Mon, 16 Apr 2012 17:38:07 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: Message-ID: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> I know you mentioned RedHat, but not if it was the router or other servers. Were you playing with Microsoft's Direct Access and turn on the dns entry (isatap.domain.com) internally? At my current place of employment, we had a security student (at the direction of our security analyst) turn up a DA test server. When they enabled the DNS entry, just about every Windows 7 and 2008 server setup a v6 tunnel back to this little tiny VM. This also included the DNS entries in AD, so all of the sudden, servers have v6 addresses. Needless to say, everything was horribly slow, and some things even flat out broke. Sadly this event left a really sour taste for IPv6 with Networking department (whom I was occasionally bugging about v6). If you weren't testing this, did you possibly setup something similar where it would automatically generate a tunnel? Brandon Penglase On Mon, 16 Apr 2012 23:39:46 +0530 Anurag Bhatia wrote: > Hello everyone > > > > Just got a awfully crazy issue. I heard from our support team about > failure of whois during domain registration. Initially I thought of > port 43 TCP block or something but found it was all ok. Later when > ran whois manually on server via terminal it failed. Found problem > that server was connecting to whois server - whois.verisign-grs.com. > I was stunned! Server got IPv6 and not just that one - almost all. > This was scary - partial IPv6 setup and it was breaking things. > > In routing tables, routes were all going to a router which I recently > setup for testing. That router and other servers are under same > switch but by no means I ever configured that router as default > gateway for IPv6. I found option of "broadcast" was enabled on router > for local fe80... address and I guess router broadcasted IPv6 and > somehow (??) all servers found that they have a IPv6 router on LAN > and started using it - automated DHCP IPv6? > > I wonder if anyone else also had similar issues? Also, if my guesses > are correct then how can we disable Red Hat distro oriented servers > from taking such automated configuration - simple DHCP in IPv6 > disable? > > > > > Thanks > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > From Valdis.Kletnieks at vt.edu Mon Apr 16 21:59:05 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 16 Apr 2012 22:59:05 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: Your message of "Mon, 16 Apr 2012 17:38:07 -0400." <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> Message-ID: <5308.1334631545@turing-police.cc.vt.edu> On Mon, 16 Apr 2012 17:38:07 -0400, Brandon Penglase said: > flat out broke. Sadly this event left a really sour taste for IPv6 with > Networking department (whom I was occasionally bugging about v6). Talking point: "If you guys had deployed a proper IPv6 infrastructure, those tunnels wouldn't have happened and there would have been no problem". The best defense against a user accidentally deploying some infrastructure incorrectly is to do a pre-emptive correct deployment. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mansaxel at besserwisser.org Tue Apr 17 01:42:00 2012 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Tue, 17 Apr 2012 08:42:00 +0200 Subject: Automatic IPv6 due to broadcast In-Reply-To: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> Message-ID: --On 16 april 2012 17.38.07 -0400 Brandon Penglase wrote: > direction of our security analyst) turn up a DA test server. > Needless to say, everything was horribly slow, and some things even > flat out broke. To be expected when DNS is given the r?le of routing packets munged by tunneling in several layers of indirection. > Sadly this event left a really sour taste for IPv6 with > Networking department (whom I was occasionally bugging about v6). The Notworking department should be driving the v6 deploy, if they want to network in the future. If they don't, replace them with a working Networking department. -- M?ns, somewhat inspired by a recent stray down (non-ECC) memory lane. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From carlosm3011 at gmail.com Tue Apr 17 03:33:55 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 17 Apr 2012 10:33:55 +0200 Subject: Automatic IPv6 due to broadcast In-Reply-To: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> References: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> Message-ID: <4F8D2AF3.4060609@gmail.com> IMO it's much easier to disable one rogue than to disable IPv6 on the whole network. That is if you can find it, but with some proper tcpdumping and/or CLI commands (depending on the switches that you have) it should be relatively easy. Not to mention that, as pointed by others, this provides a wonderful opportunity to look into this new (*grin*) protocol. Cheers! ~Carlos On 4/16/12 9:32 PM, Arturo Servin wrote: > Anurag, > > You have a rogue RA in your network. Now is just an annoying DoS, but it can easily be turned in a real security concern. > > I suggest to either deploy properly IPv6 or disable it. I am more on the former, but it is your choice. > > Regards > -as > > On 16 Apr 2012, at 15:09, Anurag Bhatia wrote: > >> Hello everyone >> >> >> >> Just got a awfully crazy issue. I heard from our support team about failure >> of whois during domain registration. Initially I thought of port 43 TCP >> block or something but found it was all ok. Later when ran whois manually >> on server via terminal it failed. Found problem that server was connecting >> to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6 >> and not just that one - almost all. This was scary - partial IPv6 setup and >> it was breaking things. >> >> In routing tables, routes were all going to a router which I recently setup >> for testing. That router and other servers are under same switch but by no >> means I ever configured that router as default gateway for IPv6. I found >> option of "broadcast" was enabled on router for local fe80... address and I >> guess router broadcasted IPv6 and somehow (??) all servers found that they >> have a IPv6 router on LAN and started using it - automated DHCP IPv6? >> >> I wonder if anyone else also had similar issues? Also, if my guesses are >> correct then how can we disable Red Hat distro oriented servers from taking >> such automated configuration - simple DHCP in IPv6 disable? >> >> >> >> >> Thanks >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected >> network! >> >> Twitter: @anurag_bhatia >> Linkedin: http://linkedin.anuragbhatia.com > From carlosm3011 at gmail.com Tue Apr 17 03:37:29 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 17 Apr 2012 10:37:29 +0200 Subject: Automatic IPv6 due to broadcast In-Reply-To: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> Message-ID: <4F8D2BC9.20708@gmail.com> I don't understand why a problem with a tunnel 'leaves a bad taste with IPv6'. Since when a badly configured DNS zone left people with a 'bad taste for DNS', or a badly configured switch left people with 'a bad taste for spanning tree' or 'a bad taste for vlan trunking' ? It seems to me that what are perceived as operational mistakes and/or plain lack of knowledge for some technologies is perceived as a fault of the protocol itself in the case of IPv6. People need to get their acts together. ~Carlos On 4/16/12 11:38 PM, Brandon Penglase wrote: > I know you mentioned RedHat, but not if it was the router or other > servers. Were you playing with Microsoft's Direct Access and turn on > the dns entry (isatap.domain.com) internally? > At my current place of employment, we had a security student (at the > direction of our security analyst) turn up a DA test server. When they > enabled the DNS entry, just about every Windows 7 and 2008 server setup > a v6 tunnel back to this little tiny VM. This also included the DNS > entries in AD, so all of the sudden, servers have v6 addresses. > Needless to say, everything was horribly slow, and some things even > flat out broke. Sadly this event left a really sour taste for IPv6 with > Networking department (whom I was occasionally bugging about v6). > > If you weren't testing this, did you possibly setup something similar > where it would automatically generate a tunnel? > > Brandon Penglase > > On Mon, 16 Apr 2012 23:39:46 +0530 > Anurag Bhatia wrote: > >> Hello everyone >> >> >> >> Just got a awfully crazy issue. I heard from our support team about >> failure of whois during domain registration. Initially I thought of >> port 43 TCP block or something but found it was all ok. Later when >> ran whois manually on server via terminal it failed. Found problem >> that server was connecting to whois server - whois.verisign-grs.com. >> I was stunned! Server got IPv6 and not just that one - almost all. >> This was scary - partial IPv6 setup and it was breaking things. >> >> In routing tables, routes were all going to a router which I recently >> setup for testing. That router and other servers are under same >> switch but by no means I ever configured that router as default >> gateway for IPv6. I found option of "broadcast" was enabled on router >> for local fe80... address and I guess router broadcasted IPv6 and >> somehow (??) all servers found that they have a IPv6 router on LAN >> and started using it - automated DHCP IPv6? >> >> I wonder if anyone else also had similar issues? Also, if my guesses >> are correct then how can we disable Red Hat distro oriented servers >> from taking such automated configuration - simple DHCP in IPv6 >> disable? >> >> >> >> >> Thanks >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected >> network! >> >> Twitter: @anurag_bhatia >> Linkedin: http://linkedin.anuragbhatia.com >> From seth.mos at dds.nl Tue Apr 17 04:21:54 2012 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 17 Apr 2012 11:21:54 +0200 Subject: Automatic IPv6 due to broadcast In-Reply-To: <4F8D2AF3.4060609@gmail.com> References: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> <4F8D2AF3.4060609@gmail.com> Message-ID: <4F8D3632.8010905@dds.nl> Op 17-4-2012 10:33, Carlos Martinez-Cagnazzo schreef: > IMO it's much easier to disable one rogue than to disable IPv6 on the > whole network. That is if you can find it, but with some proper > tcpdumping and/or CLI commands (depending on the switches that you have) > it should be relatively easy. Even better, the IPv6 gateway you got assigned is based on the MAC address. That means you can also find what brand of device is advertising. http://standards.ieee.org/develop/regauth/oui/public.html You can most likely find which IPv4 address the MAC corresponds too as well. Was that so hard? > Not to mention that, as pointed by others, this provides a wonderful > opportunity to look into this new (*grin*) protocol. Indeed! > > Cheers! > > ~Carlos Cheers, Seth From rps at maine.edu Tue Apr 17 05:54:27 2012 From: rps at maine.edu (Ray Soucy) Date: Tue, 17 Apr 2012 06:54:27 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: <4F8D3632.8010905@dds.nl> References: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> <4F8D2AF3.4060609@gmail.com> <4F8D3632.8010905@dds.nl> Message-ID: You have a rogue IPv6 router on your network. It's not a host problem. It's along the lines of having a rogue DHCP server on your network but faster propagation. It needs to be tracked down and disabled. You can use tcpdump (as root) to capture IPv6 RA and see who's doing it, and what's being advertised: tcpdump -ni eth0 'ip6 dst ff02::1' 06:48:48.044409 IP6 fe80::2d0:1ff:fedf:8400 > ff02::1: ICMP6, router advertisement, length 64 Then look at your IPv6 neighbor table for the MAC of that host: ip -6 neigh show fe80::2d0:1ff:fedf:8400 dev eth0 lladdr 00:d0:01:df:84:00 router REACHABLE Once you have the MAC, track it down and disable it. On a Cisco device "show mac address-table" (or "show mac-address-table" on older hardware). -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jared at puck.nether.net Tue Apr 17 06:06:17 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Apr 2012 07:06:17 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> <4F8D2AF3.4060609@gmail.com> <4F8D3632.8010905@dds.nl> Message-ID: tcpdump -e will show source and dest mac address. On Apr 17, 2012, at 6:54 AM, Ray Soucy wrote: > tcpdump -ni eth0 'ip6 dst ff02::1' > > 06:48:48.044409 IP6 fe80::2d0:1ff:fedf:8400 > ff02::1: ICMP6, router > advertisement, length 64 From mkorourke+nanog at gmail.com Tue Apr 17 06:55:29 2012 From: mkorourke+nanog at gmail.com (Mick O'Rourke) Date: Tue, 17 Apr 2012 21:55:29 +1000 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> <4F8D2AF3.4060609@gmail.com> <4F8D3632.8010905@dds.nl> Message-ID: RA guard is useful if your tcam capacity and or switching platform allows - http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-01 An older yet still a good read from Cisco on some IPv6 first hop security: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html#wp1054246 Mick From nanog at luftivennad.com Tue Apr 17 08:19:55 2012 From: nanog at luftivennad.com (A.T.) Date: Tue, 17 Apr 2012 16:19:55 +0300 Subject: trouble with Paradyne Bitstorm 2600 DSLAM Message-ID: <1334668795.2695.15.camel@kasutaja-desktop> Hello, all! I have Paradyne Bitstorm 2600 DSLAM, but no password. Is it possible to reset this device to factory configuration? Manuals don't say much, only specified way to restore factory settings assume logged in administrator. Thanks! From nanog at luftivennad.com Tue Apr 17 10:40:17 2012 From: nanog at luftivennad.com (A.T.) Date: Tue, 17 Apr 2012 18:40:17 +0300 Subject: trouble with Paradyne Bitstorm 2600 DSLAM In-Reply-To: References: <1334668795.2695.15.camel@kasutaja-desktop> Message-ID: <1334677217.3197.8.camel@kasutaja-desktop> Thanks. I have already tried interrupting boot process. Booting up with parameter 0x00020 (disable login security) don't seem affect outcome, both serial and management ethernet still asks login. On Tue, 2012-04-17 at 09:09 -0500, Chris Boyd wrote: > Try pressing enter several times after powering the system up. > > --Chris > > On Apr 17, 2012, at 8:19 AM, A.T. wrote: > > > Hello, all! > > > > > > I have Paradyne Bitstorm 2600 DSLAM, but no password. Is it possible to > > reset this device to factory configuration? Manuals don't say much, only > > specified way to restore factory settings assume logged in > > administrator. > > > > Thanks! > > > > > > > > > > > > > > !DSPAM:1001,4f8d6e61937107248971901! > From eugen at leitl.org Tue Apr 17 11:37:25 2012 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 17 Apr 2012 18:37:25 +0200 Subject: OpenFlow @ GOOG Message-ID: <20120417163725.GC28282@leitl.org> http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/all/1 Going With The Flow: Google?s Secret Switch To The Next Wave Of Networking By Steven Levy April 17, 2012 | 11:45 am | Categories: Data Centers, Networking In early 1999, an associate computer science professor at UC Santa Barbara climbed the steps to the second floor headquarters of a small startup in Palo Alto, and wound up surprising himself by accepting a job offer. Even so, Urs H?lzle hedged his bet by not resigning from his university post, but taking a year-long leave. He would never return. H?lzle became a fixture in the company ? called Google. As its czar of infrastructure, H?lzle oversaw the growth of its network operations from a few cages in a San Jose co-location center to a massive internet power; a 2010 study by Arbor Networks concluded that if Google was an ISP it would be the second largest in the world (the largest is Tier 3, which services over 2,700 major corporations in 450 markets over 100,000 fiber miles.) ?You have all those multiple devices on a network but you?re not really interested in the devices ? you?re interested in the fabric, and the functions the network performs for you,? H?lzle says. Google treats its infrastructure like a state secret, so H?lzle rarely speaks about it in public. Today is one of those rare days: at the Open Networking Summit in Santa Clara, California, H?lzle is announcing that Google essentially has remade a major part of its massive internal network, providing the company a bonanza in savings and efficiency. Google has done this by brashly adopting a new and radical open-source technology called OpenFlow. H?lzle says that the idea behind this advance is the most significant change in networking in the entire lifetime of Google. In the course of his presentation H?lzle will also confirm for the first time that Google ? already famous for making its own servers ? has been designing and manufacturing much of its own networking equipment as well. ?It?s not hard to build networking hardware,? says H?lzle, in an advance briefing provided exclusively to Wired. ?What?s hard is to build the software itself as well.? In this case, Google has used its software expertise to overturn the current networking paradigm. If any company has potential to change the networking game, it is Google. The company has essentially two huge networks: the one that connects users to Google services (Search, Gmail, YouTube, etc.) and another that connects Google data centers to each other. It makes sense to bifurcate the information that way because the data flow in each case has different characteristics and demand. The user network has a smooth flow, generally adopting a diurnal pattern as users in a geographic region work and sleep. The performance of the user network also has higher standards, as users will get impatient (or leave!) if services are slow. In the user-facing network you also need every packet to arrive intact ? customers would be pretty unhappy if a key sentence in a document or e-mail was dropped. The internal backbone, in contrast, has wild swings in demand ? it is ?bursty? rather than steady. Google is in control of scheduling internal traffic, but it faces difficulties in traffic engineering. Often Google has to move many petabytes of data (indexes of the entire web, millions of backup copies of user Gmail) from one place to another. When Google updates or creates a new service, it wants it available worldwide in a timely fashion ? and it wants to be able to predict accurately how quickly the process will take. ?There?s a lot of data center to data center traffic that has different business priorities,? says Stephen Stuart, a Google distinguished engineer who specializes in infrastructure. ?Figuring out the right thing to move out of the way so that more important traffic could go through was a challenge.? But Google found an answer in OpenFlow, an open source system jointly devised by scientists at Stanford and the University of California at Berkeley. Adopting an approach known as Software Defined Networking (SDN), OpenFlow gives network operators a dramatically increased level of control by separating the two functions of networking equipment: packet switching and management. OpenFlow moves the control functions to servers, allowing for more complexity, efficiency and flexibility. ?We were already going down that path, working on an inferior way of doing software-defined networking,? says H?lzle. ?But once we looked at OpenFlow, it was clear that this was the way to go. Why invent your own if you don?t have to?? Google became one of several organizations to sign on to the Open Networking Foundation, which is devoted to promoting OpenFlow. (Other members include Yahoo, Microsoft, Facebook, Verizon and Deutsche Telekom, and an innovative startup called Nicira.) But none of the partners so far have announced any implementation as extensive as Google?s. Why is OpenFlow so advantageous to a company like Google? In the traditional model you can think of routers as akin to taxicabs getting passengers from one place to another. If a street is blocked, the taxi driver takes another route ? but the detour may be time-consuming. If the weather is lousy, the taxi driver has to go slower. In short, the taxi driver will get you there, but you don?t want to bet the house on your exact arrival time. With the software-defined network Google has implemented, the taxi situation no longer resembles the decentralized model of drivers making their own decisions. Instead you have a system like the one envisioned when all cars are autonomous, and can report their whereabouts and plans to some central repository which also knows of weather conditions and aggregate traffic information. Such a system doesn?t need independent taxi drivers, because the system knows where the quickest routes are and what streets are blocked, and can set an ideal route from the outset. The system knows all the conditions and can institute a more sophisticated set of rules that determines how the taxis proceed, and even figure whether some taxis should stay in their garages while fire trucks pass. Therefore, operators can slate trips with confidence that everyone will get to their destinations in the shortest times, and precisely on schedule. Continue reading ?Going With The Flow: Google?s Secret Switch To The Next Wave Of Networking? ? Making Google?s entire internal network work with SDN thus provides all sorts of advantages. In planning big data moves, Google can simulate everything offline with pinpoint accuracy, without having to access a single networking switch. Products can be rolled out more quickly. And since ?the control plane? is the element in routers that most often needs updating, networking equipment is simpler and enduring, requiring less labor to service. Most important, the move makes network management much easier. By early this year, all of Google?s internal network was running on OpenFlow. ?Soon we will able to get very close to 100 percent utilization of our network,? H?lzle says. ?You have all those multiple devices on a network but you?re not really interested in the devices ? you?re interested in the fabric, and the functions the network performs for you,? says H?lzle. ?Now we don?t have to worry about those devices ? we manage the network as an overall thing. The network just sort of understands.? The routers Google built to accommodate OpenFlow on what it is calling ?the G-Scale Network? probably did not mark not the company?s first effort in making such devices. (One former Google employee has told Wired?s Cade Metz that the company was designing its own equipment as early as 2005. Google hasn?t confirmed this, but its job postings in the field over the past few years have provided plenty of evidence of such activities.) With SDN, though, Google absolutely had to go its own way in that regard. ?In 2010, when we were seriously starting the project, you could not buy any piece of equipment that was even remotely suitable for this task,? says Hotzle. ?It was not an option.? The process was conducted, naturally, with stealth ? even the academics who were Google?s closest collaborators in hammering out the OpenFlow standards weren?t briefed on the extent of the implementation. In early 2010, Google established its first SDN links, among its triangle of data centers in North Carolina, South Carolina and Georgia. Then it began replacing the old internal network with G-Scale machines and software ? a tricky process since everything had to be done without disrupting normal business operations. As H?lzle explains in his speech, the method was to pre-deploy the equipment at a site, take down half the site?s networking machines, and hook them up to the new system. After testing to see if the upgrade worked, Google?s engineers would then repeat the process for the remaining 50 percent of the networking in the site. The process went briskly in Google?s data centers around the world. By early this year, all of Google?s internal network was running on OpenFlow. Though Google says it?s too soon to get a measurement of the benefits, H?lzle does confirm that they are considerable. ?Soon we will able to get very close to 100 percent utilization of our network,? he says. In other words, all the lanes in Google?s humongous internal data highway can be occupied, with information moving at top speed. The industry considers thirty or forty percent utilization a reasonable payload ? so this implementation is like boosting network capacity two or three times. (This doesn?t apply to the user-facing network, of course.) Though Google has made a considerable investment in the transformation ? hundreds of engineers were involved, and the equipment itself (when design and engineering expenses are considered) may cost more than buying vendor equipment ? H?lzle clearly thinks it?s worth it. H?lzle doesn?t want people to make too big a deal of the confirmation that Google is making its own networking switches ? and he emphatically says that it would be wrong to conclude that because of this announcement Google intends to compete with Cisco and Juniper. ?Our general philosophy is that we?ll only build something ourselves if there?s an advantage to do it ? which means that we?re getting something we can?t get elsewhere.? To H?lzle, this news is all about the new paradigm. He does acknowledge that challenges still remain in the shift to SDN, but thinks they are all surmountable. If SDN is widely adopted across the industry, that?s great for Google, because virtually anything that happens to make the internet run more efficiently is a boon for the company. As for Cisco and Juniper, he hopes that as more big operations seek to adopt OpenFlow, those networking manufacturers will design equipment that supports it. If so, H?lzle says, Google will probably be a customer. ?That?s actually part of the reason for giving the talk and being open,? he says. ?To encourage the industry ? hardware, software and ISP?s ? to look down this path and say, ?I can benefit from this.?? For proof, big players in networking can now look to Google. The search giant claims that it?s already reaping benefits from its bet on the new revolution in networking. Big time. Steven Levy Steven Levy's deep dive into Google, In The Plex: How Google Thinks, Works And Shapes Our Lives, was published in April, 2011. Steven also blogs at StevenLevy.com. Check out Steve's Google+ Profile . Read more by Steven Levy Follow @StevenLevy on Twitter. From marshall.eubanks at gmail.com Tue Apr 17 12:08:49 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Tue, 17 Apr 2012 13:08:49 -0400 Subject: OpenFlow @ GOOG In-Reply-To: <20120417163725.GC28282@leitl.org> References: <20120417163725.GC28282@leitl.org> Message-ID: I wonder if this will be contributed to the DC (DataCenter) work currently gearing up in the IETF. Regards Marshall On Tue, Apr 17, 2012 at 12:37 PM, Eugen Leitl wrote: > > http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/all/1 > > Going With The Flow: Google?s Secret Switch To The Next Wave Of Networking > > By Steven Levy April 17, 2012 | 11:45 am | > > Categories: Data Centers, Networking > > In early 1999, an associate computer science professor at UC Santa Barbara > climbed the steps to the second floor headquarters of a small startup in Palo > Alto, and wound up surprising himself by accepting a job offer. Even so, Urs > H?lzle hedged his bet by not resigning from his university post, but taking a > year-long leave. > > He would never return. H?lzle became a fixture in the company ? called > Google. As its czar of infrastructure, H?lzle oversaw the growth of its > network operations from a few cages in a San Jose co-location center to a > massive internet power; a 2010 study by Arbor Networks concluded that if > Google was an ISP it would be the second largest in the world (the largest is > Tier 3, which services over 2,700 major corporations in 450 markets over > 100,000 fiber miles.) ?You have all those multiple devices on a network but > you?re not really interested in the devices ? you?re interested in the > fabric, and the functions the network performs for you,? H?lzle says. > > Google treats its infrastructure like a state secret, so H?lzle rarely speaks > about it in public. Today is one of those rare days: at the Open Networking > Summit in Santa Clara, California, H?lzle is announcing that Google > essentially has remade a major part of its massive internal network, > providing the company a bonanza in savings and efficiency. Google has done > this by brashly adopting a new and radical open-source technology called > OpenFlow. > > H?lzle says that the idea behind this advance is the most significant change > in networking in the entire lifetime of Google. > > In the course of his presentation H?lzle will also confirm for the first time > that Google ? already famous for making its own servers ? has been designing > and manufacturing much of its own networking equipment as well. > > ?It?s not hard to build networking hardware,? says H?lzle, in an advance > briefing provided exclusively to Wired. ?What?s hard is to build the software > itself as well.? > > In this case, Google has used its software expertise to overturn the current > networking paradigm. > > If any company has potential to change the networking game, it is Google. The > company has essentially two huge networks: the one that connects users to > Google services (Search, Gmail, YouTube, etc.) and another that connects > Google data centers to each other. It makes sense to bifurcate the > information that way because the data flow in each case has different > characteristics and demand. The user network has a smooth flow, generally > adopting a diurnal pattern as users in a geographic region work and sleep. > The performance of the user network also has higher standards, as users will > get impatient (or leave!) if services are slow. In the user-facing network > you also need every packet to arrive intact ? customers would be pretty > unhappy if a key sentence in a document or e-mail was dropped. > > The internal backbone, in contrast, has wild swings in demand ? it is > ?bursty? rather than steady. Google is in control of scheduling internal > traffic, but it faces difficulties in traffic engineering. Often Google has > to move many petabytes of data (indexes of the entire web, millions of backup > copies of user Gmail) from one place to another. When Google updates or > creates a new service, it wants it available worldwide in a timely fashion ? > and it wants to be able to predict accurately how quickly the process will > take. > > ?There?s a lot of data center to data center traffic that has different > business priorities,? says Stephen Stuart, a Google distinguished engineer > who specializes in infrastructure. ?Figuring out the right thing to move out > of the way so that more important traffic could go through was a challenge.? > > But Google found an answer in OpenFlow, an open source system jointly devised > by scientists at Stanford and the University of California at Berkeley. > Adopting an approach known as Software Defined Networking (SDN), OpenFlow > gives network operators a dramatically increased level of control by > separating the two functions of networking equipment: packet switching and > management. OpenFlow moves the control functions to servers, allowing for > more complexity, efficiency and flexibility. > > ?We were already going down that path, working on an inferior way of doing > software-defined networking,? says H?lzle. ?But once we looked at OpenFlow, > it was clear that this was the way to go. Why invent your own if you don?t > have to?? > > Google became one of several organizations to sign on to the Open Networking > Foundation, which is devoted to promoting OpenFlow. (Other members include > Yahoo, Microsoft, Facebook, Verizon and Deutsche Telekom, and an innovative > startup called Nicira.) But none of the partners so far have announced any > implementation as extensive as Google?s. > > Why is OpenFlow so advantageous to a company like Google? In the traditional > model you can think of routers as akin to taxicabs getting passengers from > one place to another. If a street is blocked, the taxi driver takes another > route ? but the detour may be time-consuming. If the weather is lousy, the > taxi driver has to go slower. In short, the taxi driver will get you there, > but you don?t want to bet the house on your exact arrival time. > > With the software-defined network Google has implemented, the taxi situation > no longer resembles the decentralized model of drivers making their own > decisions. Instead you have a system like the one envisioned when all cars > are autonomous, and can report their whereabouts and plans to some central > repository which also knows of weather conditions and aggregate traffic > information. Such a system doesn?t need independent taxi drivers, because the > system knows where the quickest routes are and what streets are blocked, and > can set an ideal route from the outset. The system knows all the conditions > and can institute a more sophisticated set of rules that determines how the > taxis proceed, and even figure whether some taxis should stay in their > garages while fire trucks pass. > > Therefore, operators can slate trips with confidence that everyone will get > to their destinations in the shortest times, and precisely on schedule. > > Continue reading ?Going With The Flow: Google?s Secret Switch To The Next > Wave Of Networking? ? > > Making Google?s entire internal network work with SDN thus provides all sorts > of advantages. In planning big data moves, Google can simulate everything > offline with pinpoint accuracy, without having to access a single networking > switch. Products can be rolled out more quickly. And since ?the control > plane? is the element in routers that most often needs updating, networking > equipment is simpler and enduring, requiring less labor to service. > > Most important, the move makes network management much easier. ?By early this > year, all of Google?s internal network was running on OpenFlow. ?Soon we will > able to get very close to 100 percent utilization of our network,? H?lzle > says. > > ?You have all those multiple devices on a network but you?re not really > interested in the devices ? you?re interested in the fabric, and the > functions the network performs for you,? says H?lzle. ?Now we don?t have to > worry about those devices ? we manage the network as an overall thing. The > network just sort of understands.? > > The routers Google built to accommodate OpenFlow on what it is calling ?the > G-Scale Network? probably did not mark not the company?s first effort in > making such devices. (One former Google employee has told Wired?s Cade Metz > that the company was designing its own equipment as early as 2005. Google > hasn?t confirmed this, but its job postings in the field over the past few > years have provided plenty of evidence of such activities.) With SDN, though, > Google absolutely had to go its own way in that regard. > > ?In 2010, when we were seriously starting the project, you could not buy any > piece of equipment that was even remotely suitable for this task,? says > Hotzle. ?It was not an option.? > > The process was conducted, naturally, with stealth ? even the academics who > were Google?s closest collaborators in hammering out the OpenFlow standards > weren?t briefed on the extent of the implementation. In early 2010, Google > established its first SDN links, among its triangle of data centers in North > Carolina, South Carolina and Georgia. Then it began replacing the old > internal network with G-Scale machines and software ? a tricky process since > everything had to be done without disrupting normal business operations. > > As H?lzle explains in his speech, the method was to pre-deploy the equipment > at a site, take down half the site?s networking machines, and hook them up to > the new system. After testing to see if the upgrade worked, Google?s > engineers would then repeat the process for the remaining 50 percent of the > networking in the site. The process went briskly in Google?s data centers > around the world. By early this year, all of Google?s internal network was > running on OpenFlow. > > Though Google says it?s too soon to get a measurement of the benefits, H?lzle > does confirm that they are considerable. ?Soon we will able to get very close > to 100 percent utilization of our network,? he says. In other words, all the > lanes in Google?s humongous internal data highway can be occupied, with > information moving at top speed. The industry considers thirty or forty > percent utilization a reasonable payload ? so this implementation is like > boosting network capacity two or three times. (This doesn?t apply to the > user-facing network, of course.) > > Though Google has made a considerable investment in the transformation ? > hundreds of engineers were involved, and the equipment itself (when design > and engineering expenses are considered) may cost more than buying vendor > equipment ? H?lzle clearly thinks it?s worth it. > > H?lzle doesn?t want people to make too big a deal of the confirmation that > Google is making its own networking switches ? and he emphatically says that > it would be wrong to conclude that because of this announcement Google > intends to compete with Cisco and Juniper. ?Our general philosophy is that > we?ll only build something ourselves if there?s an advantage to do it ? which > means that we?re getting something we can?t get elsewhere.? > > To H?lzle, this news is all about the new paradigm. He does acknowledge that > challenges still remain in the shift to SDN, but thinks they are all > surmountable. If SDN is widely adopted across the industry, that?s great for > Google, because virtually anything that happens to make the internet run more > efficiently is a boon for the company. > > As for Cisco and Juniper, he hopes that as more big operations seek to adopt > OpenFlow, those networking manufacturers will design equipment that supports > it. If so, H?lzle says, Google will probably be a customer. > > ?That?s actually part of the reason for giving the talk and being open,? he > says. ?To encourage the industry ? hardware, software and ISP?s ? to look > down this path and say, ?I can benefit from this.?? > > For proof, big players in networking can now look to Google. The search giant > claims that it?s already reaping benefits from its bet on the new revolution > in networking. Big time. > > Steven Levy > > Steven Levy's deep dive into Google, In The Plex: How Google Thinks, Works > And Shapes Our Lives, was published in April, 2011. Steven also blogs at > StevenLevy.com. ?Check out Steve's Google+ Profile . > > Read more by Steven Levy > > Follow @StevenLevy on Twitter. > From andrew.koch at gawul.net Tue Apr 17 14:16:27 2012 From: andrew.koch at gawul.net (Andrew Koch) Date: Tue, 17 Apr 2012 14:16:27 -0500 Subject: [c-nsp] Possible T1 clocking problem. Message-ID: On 4/17/12 13:46 AM, Joseph Mays wrote: > The interface on the remote end (t1 WIC port in a 2600 shows a lot more errors, including a lot of frame errors, for the same time period. [snip] Are these T1 frame errors, or a higher level? If you believe this to be a T1 concern, you should be checking at the T1 level - "show controller T1 1/0:24" for the AS5400 and "show service-module serial x/y performance-statistics" for the WIC on the 2600. Both of these commands will display the T1 statistics in 15min intervals. If you see errors there, most HDSL4 smart-jacks have a serial port for pulling stats and levels, if they are your smart-jacks to be checking. HTH, Andy From carlos at race.com Tue Apr 17 14:43:34 2012 From: carlos at race.com (Carlos Alcantar) Date: Tue, 17 Apr 2012 19:43:34 +0000 Subject: [c-nsp] Possible T1 clocking problem. In-Reply-To: Message-ID: You might want to put a t1 test set on the line and check and see if the clock frequency is moving. Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: Andrew Koch Date: Tue, 17 Apr 2012 14:16:27 -0500 To: , "nanog at nanog.org" Subject: Re: [c-nsp] Possible T1 clocking problem. On 4/17/12 13:46 AM, Joseph Mays wrote: > The interface on the remote end (t1 WIC port in a 2600 shows a lot more >errors, including a lot of frame errors, for the same time period. [snip] Are these T1 frame errors, or a higher level? If you believe this to be a T1 concern, you should be checking at the T1 level - "show controller T1 1/0:24" for the AS5400 and "show service-module serial x/y performance-statistics" for the WIC on the 2600. Both of these commands will display the T1 statistics in 15min intervals. If you see errors there, most HDSL4 smart-jacks have a serial port for pulling stats and levels, if they are your smart-jacks to be checking. HTH, Andy From dan at eff.org Tue Apr 17 20:02:00 2012 From: dan at eff.org (Dan Auerbach) Date: Tue, 17 Apr 2012 18:02:00 -0700 Subject: letter opposing cybersecurity legislation: looking for signers Message-ID: <4F8E1288.7060104@eff.org> Dear NANOGers, EFF is looking for sign-ons to a letter expressing concern about some of the proposed "cybersecurity" legislation currently being debated in the US Congress. This legislation has a number of alarming provisions, including incentives for recording massive amounts of network traffic and sharing it with federal agencies; nullification of existing wiretapping and privacy laws; in some cases, new kinds of bureaucracy for backbone and other ISPs who are designated as "critical infrastructure", and provisions that establish intellectual property enforcement as a "cybersecurity" objective. We realize this is potentially a complicated topic in the NANOG community, and we'd prefer not to start a giant OT flamewar, so: if you agree with our concerns and would like to sign on to our letter, let us know by private email by Thursday morning 9am Pacific US time. If you think we have the wrong perspective, you can let us know off-list, or write your own letters, or work with your various policy departments on this. Because there are many "cybersecurity" bills currently being debated in the US House and Senate, the letter is generally framed in opposition to bad aspects of the bills, though it calls out two current proposals that are particularly bad and close to passing: CISPA (H.R. 3523) in the House, and "Secure IT Act" (S. 2151) in the Senate. The letter also is intended to be simple and focused on the civil liberties issues that stem from the broadness of the bills. It does not talk about technical problems with deploying IDS/IPS in the private sector (for a discussion of this, see, e.g. http://harvardnsj.org/wp-content/uploads/2012/01/Vol.-3_Bellovin_Bradner_Diffie_Landau_Rexford1.pdf) or other legitimate technical concerns about effectiveness. We certainly encourage people to raise these concerns separately. The text of the letter is below in triple quotes: """ Dear Lawmakers, We are writing you today as professionals, academics, and experts who have researched, analyzed, and defended against security threats to the Internet and its infrastructure. We have devoted our careers to building security technologies, and to protecting networks, computers, and critical infrastructure against attacks of many stripes. We take security very seriously, but we fervently believe that strong computer and network security does not require Internet users to sacrifice their privacy and civil liberties. The opposite, in fact, is true. The bills currently under consideration, including Rep. Rogers' /Cyber Intelligence Sharing and Protection Act of 2011 /(H.R. 3523) and Sen. McCain's/SECURE IT Act /(S. 2151)/, /are drafted to allow entities who participate in relaying or receiving Internet traffic to freely monitor and redistribute those network communications. The bills nullify current legal protections against wiretapping and similar civil liberties violations for that kind of broad data sharing. By encouraging the transfer of users' private communications to US Federal agencies, and lacking any form of public accountability or transparency, these "cybersecurity" bills falsely trade our civil liberties for the promise of improved network security. As experts in the field, we reject this false trade-off and urge you to oppose any cybersecurity initiative that does not explicitly include appropriate methods to ensure the protection of users' civil liberties. In summary, we urge you to reject legislation that: * Uses vague language to describe network security attacks, threat indicators, and countermeasures, allowing for the possibility that innocuous online activities could be construed as "cybersecurity" threats. * Exempts "cybersecurity" activities from existing laws that protect individuals' privacy and devices, such as the Wiretap Act, the Stored Communications Act, and the Computer Fraud and Abuse Act. * Gives sweeping immunity from liability to companies even if they violate individuals' privacy without good reason. * Allows data originally collected through "cybersecurity" programs to be used to prosecute unrelated crimes. * Includes provisions suggesting a back door for intellectual property enforcement. Computer security is too important an issue to let it be hijacked for the sectional interests of unrelated industries. We appreciate your interest in making our networks more secure, but passing legislation that suffers from the problems above would be a grave mistake for privacy and civil liberties, and will not be a step forward in making us safer. Sincerely, """ For a more detailed discussion of some of the civil liberties implications and other analyses, please see the following articles: https://www.eff.org/deeplinks/2012/03/dangerously-vague-cybersecurity-legislation https://www.eff.org/deeplinks/2012/03/rogers-cybersecurity-bill-broad-enough-use-against-wikileaks-and-pirate-bay https://www.eff.org/deeplinks/2012/03/four-unanswered-questions-about-cybersecurity-bills For discussions of CISPA in particular, see: https://www.eff.org/deeplinks/2012/04/cybersecurity-bill-faq-disturbing-privacy-dangers-cispa-and-how-you-stop-it https://cyberspying.eff.org/ Sincerely, Dan Auerbach dan at eff.org Staff Technologist Electronic Frontier Foundation Peter Eckersley pde at eff.org Technology Projects Director Electronic Frontier Foundation From jeroen at mompl.net Tue Apr 17 20:05:26 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 17 Apr 2012 18:05:26 -0700 Subject: Most energy efficient (home) setup In-Reply-To: References: <201204150646.q3F6kTsk061467@aurora.sol.net> Message-ID: <4F8E1356.3040103@mompl.net> Jimmy Hess wrote: > Consider that the probability 16GB of SDRAM experiences at least one > single bit error at sea level, > in a given 6 hour period exceeds 66% = 1 - (1 - 1.3e-12 * 6)^(16 * > 2^30 * 8). In any given 24 hour period, the probability of at least > one single bit error exceeds 98%. Assuming the memory is good and > functioning correctly; > application in the effected space, and moderately important data is > being damaged > well, that's just plain uncool Having limited knowledge of which consumer devices support ECC memory and which don't I was pleasantly surprised to find out the always on IBM thinkpad I ran for years refused to work with non-ECC memory. Greetings, Jeroen -- Earthquake Magnitude: 6.2 Date: Tuesday, April 17, 2012 19:03:55 UTC Location: east of the South Sandwich Islands Latitude: -59.0988; Longitude: -16.6928 Depth: 1.00 km From me at anuragbhatia.com Tue Apr 17 20:47:58 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 18 Apr 2012 07:17:58 +0530 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: <9DF89F89-B7AC-45C8-843A-4FCAA642E3D9@gmail.com> <4F8D2AF3.4060609@gmail.com> <4F8D3632.8010905@dds.nl> Message-ID: Thanks for useful reply everyone! As I mentioned - I applied quick temporary fix by stop broadcast from router and clearing of routing table on servers. Will apply disabling of autoconfig now. On Tue, Apr 17, 2012 at 5:25 PM, Mick O'Rourke wrote: > RA guard is useful if your tcam capacity and or switching platform allows - > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-01 > > An older yet still a good read from Cisco on some IPv6 first hop security: > > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html#wp1054246 > > Mick > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From rmaunier at neotelecoms.com Wed Apr 18 10:15:49 2012 From: rmaunier at neotelecoms.com (Raphael MAUNIER) Date: Wed, 18 Apr 2012 15:15:49 +0000 Subject: How to xconnect in 111 8th NYC Message-ID: Hello, We are trying to connect our carrier in 111 8th NYC. Our carrier is located in Zayo space and we are located in Telx space. We already have our panel to Telx MMR and have a bunch of position available. Our carrier seems to be unable to connect from Zayo MMR to Telx MMR and it seems to be very complicated to both Telx and Zayo to give a real answer. The last time we had to do it, it was half xconnect to the MMR ( telx ) and the other part was Zayo to our carrier. Now, the carrier have to connect to us ( xconnect included in the price) but ZAYO claims more $$$ ( about twice the price of the other way ) and this is exactly the same path !!! So how does it work really in this building ? Honestly, telx and Zayo are doing this for year and each time it's like they are discovering the wheel ( not sure if this expression exist in English). Raphael Maunier Neo Telecoms From deric.kwok2000 at gmail.com Wed Apr 18 11:42:12 2012 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Wed, 18 Apr 2012 12:42:12 -0400 Subject: any sites about interent networkissue Message-ID: Hi Yesterday I have internet nework issue. I checked our interent providers but their answers are fine But the traceroute can't reach to some desintations. eg: gogle and stopped somewhere Any websites can provide about network issue Thank you From daffy at daffy.za.net Wed Apr 18 11:46:39 2012 From: daffy at daffy.za.net (Kieran Murphy) Date: Wed, 18 Apr 2012 17:46:39 +0100 Subject: any sites about interent networkissue In-Reply-To: References: Message-ID: Are you sure you didn't just mis-type the URL? ;) On Apr 18, 2012 5:43 PM, "Deric Kwok" wrote: > Hi > > Yesterday I have internet nework issue. I checked our interent > providers but their answers are fine > > But the traceroute can't reach to some desintations. eg: gogle > and stopped somewhere > > Any websites can provide about network issue > > Thank you > > From axisml at gmail.com Wed Apr 18 12:01:03 2012 From: axisml at gmail.com (Chris Stone) Date: Wed, 18 Apr 2012 11:01:03 -0600 Subject: any sites about interent networkissue In-Reply-To: References: Message-ID: > On Apr 18, 2012 5:43 PM, "Deric Kwok" wrote: >> Any websites can provide about network issue http://www.outages.org/index.php/Dashboard -- Chris Stone AxisInternet, Inc. www.axint.net From mailinglists.chk at gmail.com Wed Apr 18 14:24:28 2012 From: mailinglists.chk at gmail.com (chk) Date: Wed, 18 Apr 2012 12:24:28 -0700 Subject: Comcast Admin Message-ID: <4F8F14EC.9000307@gmail.com> We are having issues with one of our sites being blocked for Comcast home users and going the normal channels is not working. If there is anyone that can contact me off list to get this resolved I would appreciate it. From tvhawaii at shaka.com Wed Apr 18 14:29:08 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 18 Apr 2012 09:29:08 -1000 Subject: any sites about interent networkissue References: Message-ID: Deric Kwok wrote: > Any websites can provide about network issue http://www.internettrafficreport.com/ From jeroen at mompl.net Wed Apr 18 14:35:16 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 18 Apr 2012 12:35:16 -0700 Subject: Most energy efficient (home) setup In-Reply-To: <1334525166.3887.1012.camel@pc2> References: <201204150646.q3F6kTsk061467@aurora.sol.net> <1334525166.3887.1012.camel@pc2> Message-ID: <4F8F1774.2000203@mompl.net> Laurent GUERBY wrote: > Do you have reference to recent papers with experimental data about non > ECC memory errors? It should be fairly easy to do Maybe this provides some information: http://en.wikipedia.org/wiki/ECC_memory#Problem_background "Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10?10?10?17 error/bit?h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per century, per gigabyte of memory.[2][4][5] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance?09 conference.[4] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 3?10?10?9 error/bit?h), and more than 8% of DIMM memory modules affected by errors per year." -- Earthquake Magnitude: 4.9 Date: Wednesday, April 18, 2012 16:21:41 UTC Location: Solomon Islands Latitude: -7.4630; Longitude: 156.7916 Depth: 414.30 km From caldcv at gmail.com Wed Apr 18 15:03:47 2012 From: caldcv at gmail.com (Chris) Date: Wed, 18 Apr 2012 16:03:47 -0400 Subject: Comcast Admin In-Reply-To: <4F8F14EC.9000307@gmail.com> References: <4F8F14EC.9000307@gmail.com> Message-ID: Usually if you make a jab at Comcast in a joke, by saying _______, this guy will respond shortly. I'll look him up and contact you offlist -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From dan at eff.org Wed Apr 18 16:44:07 2012 From: dan at eff.org (Dan Auerbach) Date: Wed, 18 Apr 2012 14:44:07 -0700 Subject: letter opposing cybersecurity legislation: looking for signers In-Reply-To: <4F8E1288.7060104@eff.org> References: <4F8E1288.7060104@eff.org> Message-ID: <4F8F35A7.8080605@eff.org> Thanks to everyone who has responded so far, and apologies for the terrible formatting of the actual letter. Just a reminder to let me know by tomorrow morning if you would be interesting in signing -- if you've replied to me already, no need to do so again, I will respond to you tomorrow. Also, if anyone has good leads about large mailing lists that might be a good place to solicit professionals, academics, or security experts, please let me know as soon as possible. And feel free to circulate this request yourself to colleagues, and tell them to email me. We are aiming to get the letter together by Thursday or Friday, but have yet to determine the exact time line for publication. On 04/17/2012 06:02 PM, Dan Auerbach wrote: > Dear NANOGers, > > EFF is looking for sign-ons to a letter expressing concern about some of the proposed "cybersecurity" legislation currently being debated in the US Congress. This legislation has a number of alarming provisions, including incentives for recording massive amounts of network traffic and sharing it with federal agencies; nullification of existing wiretapping and privacy laws; in some cases, new kinds of bureaucracy for backbone and other ISPs who are designated as "critical infrastructure", and provisions that establish intellectual property enforcement as a "cybersecurity" objective. > > We realize this is potentially a complicated topic in the NANOG community, and we'd prefer not to start a giant OT flamewar, so: if you agree with our concerns and would like to sign on to our letter, let us know by private email by Thursday morning 9am Pacific US time. If you think we have the wrong perspective, you can let us know off-list, or write your own letters, or work with your various policy departments on this. > > Because there are many "cybersecurity" bills currently being debated in the US House and Senate, the letter is generally framed in opposition to bad aspects of the bills, though it calls out two current proposals that are particularly bad and close to passing: CISPA (H.R. 3523) in the House, and "Secure IT Act" (S. 2151) in the Senate. The letter also is intended to be simple and focused on the civil liberties issues that stem from the broadness of the bills. It does not talk about technical problems with deploying IDS/IPS in the private sector (for a discussion of this, see, e.g. http://harvardnsj.org/wp-content/uploads/2012/01/Vol.-3_Bellovin_Bradner_Diffie_Landau_Rexford1.pdf) or other legitimate technical concerns about effectiveness. We certainly encourage people to raise these concerns separately. The text of the letter is below in triple quotes: > > """ > > Dear Lawmakers, > > > We are writing you today as professionals, academics, and experts who > have researched, analyzed, and defended against security threats to the > Internet and its infrastructure. We have devoted our careers to building > security technologies, and to protecting networks, computers, and > critical infrastructure against attacks of many stripes. > > We take security very seriously, but we fervently believe that strong > computer and network security does not require Internet users to > sacrifice their privacy and civil liberties. The opposite, in fact, is true. > > The bills currently under consideration, including Rep. Rogers' /Cyber > Intelligence Sharing and Protection Act of 2011 /(H.R. 3523) and Sen. > McCain's/SECURE IT Act /(S. 2151)/, /are drafted to allow entities who > participate in relaying or receiving Internet traffic to freely monitor > and redistribute those network communications. The bills nullify current > legal protections against wiretapping and similar civil liberties > violations for that kind of broad data sharing. By encouraging the > transfer of users' private communications to US Federal agencies, and > lacking any form of public accountability or transparency, these > "cybersecurity" bills falsely trade our civil liberties for the promise > of improved network security. As experts in the field, we reject this > false trade-off and urge you to oppose any cybersecurity initiative that > does not explicitly include appropriate methods to ensure the protection > of users' civil liberties. > > In summary, we urge you to reject legislation that: > > * > > Uses vague language to describe network security attacks, threat > indicators, and countermeasures, allowing for the possibility that > innocuous online activities could be construed as "cybersecurity" > threats. > > * > > Exempts "cybersecurity" activities from existing laws that protect > individuals' privacy and devices, such as the Wiretap Act, the > Stored Communications Act, and the Computer Fraud and Abuse Act. > > * > > Gives sweeping immunity from liability to companies even if they > violate individuals' privacy without good reason. > > * > > Allows data originally collected through "cybersecurity" programs to > be used to prosecute unrelated crimes. > > * > > Includes provisions suggesting a back door for intellectual property > enforcement. Computer security is too important an issue to let it > be hijacked for the sectional interests of unrelated industries. > > We appreciate your interest in making our networks more secure, but > passing legislation that suffers from the problems above would be a > grave mistake for privacy and civil liberties, and will not be a step > forward in making us safer. > > Sincerely, > > > > """ > > For a more detailed discussion of some of the civil liberties implications and other analyses, please see the following articles: > > https://www.eff.org/deeplinks/2012/03/dangerously-vague-cybersecurity-legislation > > https://www.eff.org/deeplinks/2012/03/rogers-cybersecurity-bill-broad-enough-use-against-wikileaks-and-pirate-bay > > https://www.eff.org/deeplinks/2012/03/four-unanswered-questions-about-cybersecurity-bills > > For discussions of CISPA in particular, see: > > https://www.eff.org/deeplinks/2012/04/cybersecurity-bill-faq-disturbing-privacy-dangers-cispa-and-how-you-stop-it > > https://cyberspying.eff.org/ > > > Sincerely, > > Dan Auerbach > dan at eff.org > Staff Technologist > Electronic Frontier Foundation > > Peter Eckersley > pde at eff.org > Technology Projects Director > Electronic Frontier Foundation > > -- Dan Auerbach Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x134 From dotis at mail-abuse.org Wed Apr 18 16:55:32 2012 From: dotis at mail-abuse.org (Douglas Otis) Date: Wed, 18 Apr 2012 14:55:32 -0700 Subject: Most energy efficient (home) setup In-Reply-To: <4F8F1774.2000203@mompl.net> References: <201204150646.q3F6kTsk061467@aurora.sol.net> <1334525166.3887.1012.camel@pc2> <4F8F1774.2000203@mompl.net> Message-ID: <4F8F3854.3030208@mail-abuse.org> On 4/18/12 12:35 PM, Jeroen van Aart wrote: > Laurent GUERBY wrote: > > Do you have reference to recent papers with experimental data about > > non ECC memory errors? It should be fairly easy to do > Maybe this provides some information: > > http://en.wikipedia.org/wiki/ECC_memory#Problem_background > > "Work published between 2007 and 2009 showed widely varying error > rates with over 7 orders of magnitude difference, ranging from > 10?10?10?17 error/bit?h, roughly one bit error, per hour, per > gigabyte of memory to one bit error, per century, per gigabyte of > memory.[2][4][5] A very large-scale study based on Google's very > large number of servers was presented at the > SIGMETRICS/Performance?09 conference.[4] The actual error rate found > was several orders of magnitude higher than previous small-scale or > laboratory studies, with 25,000 to 70,000 errors per billion device > hours per megabit (about 3?10?10?9 error/bit?h), and more than 8% of > DIMM memory modules affected by errors per year." Dear Jeroen, In the work that led up to RFC3309, many of the errors found on the Internet pertained to single interface bits, and not single data bits. Working at a large chip manufacturer that removed internal memory error detection to foolishly save space, cost them dearly in then needing to do far more exhaustive four corner testing. Checksums used by TCP and UDP are able to detect single bit data errors, but may miss as much as 2% of single interface bit errors. It would be surprising to find memory designs lacking internal error detection logic. Regards, Douglas Otis From jneiberger at gmail.com Wed Apr 18 17:41:59 2012 From: jneiberger at gmail.com (John Neiberger) Date: Wed, 18 Apr 2012 16:41:59 -0600 Subject: Comcast Admin In-Reply-To: <4F8F14EC.9000307@gmail.com> References: <4F8F14EC.9000307@gmail.com> Message-ID: On Wed, Apr 18, 2012 at 1:24 PM, chk wrote: > We are having issues with one of our sites being blocked for Comcast home > users and going the normal channels is not working. If there is anyone that > can contact me off list to get this resolved I would appreciate it. > I'm not sure who the right channels would be, but I'm asking around to see if I can find the right people to help you resolve this quickly. I'll let you know what I find out. John From mailinglists.chk at gmail.com Wed Apr 18 19:53:19 2012 From: mailinglists.chk at gmail.com (chk) Date: Wed, 18 Apr 2012 17:53:19 -0700 Subject: Comcast Admin In-Reply-To: References: <4F8F14EC.9000307@gmail.com> Message-ID: <4F8F61FF.2090608@gmail.com> Looks like this issue has been resolved. We are waiting for a post-mortem to figure out what the issue was but thanks everyone for looking into this. On 4/18/12 3:41 PM, John Neiberger wrote: > On Wed, Apr 18, 2012 at 1:24 PM, chk wrote: >> We are having issues with one of our sites being blocked for Comcast home >> users and going the normal channels is not working. If there is anyone that >> can contact me off list to get this resolved I would appreciate it. >> > I'm not sure who the right channels would be, but I'm asking around to > see if I can find the right people to help you resolve this quickly. > I'll let you know what I find out. > > John > From smb at cs.columbia.edu Wed Apr 18 22:09:44 2012 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 18 Apr 2012 23:09:44 -0400 Subject: Most energy efficient (home) setup In-Reply-To: <4F8F3854.3030208@mail-abuse.org> References: <201204150646.q3F6kTsk061467@aurora.sol.net> <1334525166.3887.1012.camel@pc2> <4F8F1774.2000203@mompl.net> <4F8F3854.3030208@mail-abuse.org> Message-ID: On Apr 18, 2012, at 5:55 32PM, Douglas Otis wrote: > On 4/18/12 12:35 PM, Jeroen van Aart wrote: >> Laurent GUERBY wrote: >> > Do you have reference to recent papers with experimental data about >> > non ECC memory errors? It should be fairly easy to do >> Maybe this provides some information: >> >> http://en.wikipedia.org/wiki/ECC_memory#Problem_background >> >> "Work published between 2007 and 2009 showed widely varying error >> rates with over 7 orders of magnitude difference, ranging from >> 10?10?10?17 error/bit?h, roughly one bit error, per hour, per >> gigabyte of memory to one bit error, per century, per gigabyte of >> memory.[2][4][5] A very large-scale study based on Google's very >> large number of servers was presented at the >> SIGMETRICS/Performance?09 conference.[4] The actual error rate found >> was several orders of magnitude higher than previous small-scale or >> laboratory studies, with 25,000 to 70,000 errors per billion device >> hours per megabit (about 3?10?10?9 error/bit?h), and more than 8% of >> DIMM memory modules affected by errors per year." > Dear Jeroen, > > In the work that led up to RFC3309, many of the errors found on the Internet pertained to single interface bits, and not single data bits. Working at a large chip manufacturer that removed internal memory error detection to foolishly save space, cost them dearly in then needing to do far more exhaustive four corner testing. Checksums used by TCP and UDP are able to detect single bit data errors, but may miss as much as 2% of single interface bit errors. It would be surprising to find memory designs lacking internal error detection logic. mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed 2,5d; date Request for Comments: 3309 Stanford September 2002 Wed Apr 18 23:07:53 EDT 2012 We are not in a static field... (3309 is one of my favorite RFCs -- but the specific findings (errors happen more often than you think), as opposed the general lesson (understand your threat model) may be OBE. --Steve Bellovin, https://www.cs.columbia.edu/~smb From aaron.davies at gmail.com Wed Apr 18 22:22:27 2012 From: aaron.davies at gmail.com (Aaron Davies) Date: Wed, 18 Apr 2012 23:22:27 -0400 Subject: Four Lit-tle Bytes (an IPv4 song) Message-ID: <2CAD5A04-A2E5-4B2F-B3C3-65723E0235D7@gmail.com> This is a song I've been working on on and off over the last couple years; when I sang it recently at a filk convention, I was told I should post it here. I hope it?s not too OT (or too technically inaccurate!). Sheet music, MIDI, and ABC source are available at http://songs.q-ist.com/. Four Lit-tle Bytes of Ad-dress Code by Aaron Davies ttto ?Two Lit-tle Bytes? by Amy Fass after ?Three Little Maids from School? by Gilbert & Sullivan chorus: Four little bytes of address code Couldn?t spare any more bandwidth load To indicate the network node Four little bytes of code Four little bytes, all allocated IPv6 is anticipated Sixteen years we?ve already waited! Four little bytes of code (chorus) Four little bytes, a space all used up Fridges and toasters IPs have chewed up When will the ISPs get clued-up? Four little bytes of code (chorus) Four little bytes, a space exhausted Plenty of room, once, but now we?ve lost it v4 is dead, man, it?s time we tossed it[1] Four little bytes of code Four little by???tes of code! Save on your subnets?four bytes! END [1] Thanks to Bob Kanefsky for the rhyme! -- Aaron Davies aaron.davies at gmail.com From CAsensio at nexica.com Thu Apr 19 02:58:21 2012 From: CAsensio at nexica.com (Carlos Asensio) Date: Thu, 19 Apr 2012 09:58:21 +0200 Subject: [IPv6] Monitoring BGP IPv6 Sesions In-Reply-To: References: Message-ID: Hi all, We're trying to monitor our BGP IPv6 sessions on our 6500. * It's look like Cisco MIB's doesn't support it: o http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/12-2sx/ip6-mng-apps.html#GUID-F646C4CE-BCE5-4144-A8AA-ABF743FAAD55 * Searching on Nagios' plugins, I don't see how (I suppose it's by the reason above): o http://exchange.nagios.org/index.php?option=com_mtree&task=search&Itemid=74&searchword=bgp Anyone can help us on that matter? Thanks in advance, Carlos. From nick at foobar.org Thu Apr 19 03:24:16 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 19 Apr 2012 10:24:16 +0200 Subject: [IPv6] Monitoring BGP IPv6 Sesions In-Reply-To: References: Message-ID: <4F8FCBB0.3010009@foobar.org> On 19/04/2012 09:58, Carlos Asensio wrote: > Anyone can help us on that matter? We need BGP4MIBv2. We've needed it for years. I am tired of screen-scraping terminal sessions looking for signs that ipv6 sessions are down or broken. Nick From sander at steffann.nl Thu Apr 19 04:41:59 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 19 Apr 2012 11:41:59 +0200 Subject: [IPv6] Monitoring BGP IPv6 Sesions In-Reply-To: <4F8FCBB0.3010009@foobar.org> References: <4F8FCBB0.3010009@foobar.org> Message-ID: <280060E1-5481-47F7-9288-E5A01911449F@steffann.nl> > On 19/04/2012 09:58, Carlos Asensio wrote: >> Anyone can help us on that matter? > > We need BGP4MIBv2. We've needed it for years. > > I am tired of screen-scraping terminal sessions looking for signs that ipv6 > sessions are down or broken. +1 Sander From CAsensio at nexica.com Thu Apr 19 04:43:30 2012 From: CAsensio at nexica.com (Carlos Asensio) Date: Thu, 19 Apr 2012 11:43:30 +0200 Subject: [IPv6] Monitoring BGP IPv6 Sesions In-Reply-To: <4F8FCBB0.3010009@foobar.org> References: <4F8FCBB0.3010009@foobar.org> Message-ID: Hi Nick, Taking your comment into consideration, while we don't have the support for IPv6 on the BGP MIB, I'm afraid we'll have to monitor it "by hand". Best regards, Carlos. -----Mensaje original----- De: Nick Hilliard [mailto:nick at foobar.org] Enviado el: jueves, 19 de abril de 2012 10:24 Para: Carlos Asensio CC: nanog at nanog.org Asunto: Re: [IPv6] Monitoring BGP IPv6 Sesions On 19/04/2012 09:58, Carlos Asensio wrote: > Anyone can help us on that matter? We need BGP4MIBv2. We've needed it for years. I am tired of screen-scraping terminal sessions looking for signs that ipv6 sessions are down or broken. Nick From achikhdaho at iweb.com Thu Apr 19 10:01:22 2012 From: achikhdaho at iweb.com (Abdelkader Chikh Daho) Date: Thu, 19 Apr 2012 11:01:22 -0400 Subject: Colocation in New York for a POP Message-ID: <4F9028C2.4080900@iweb.com> Hi everyone, Can some one please tell us what is the best Colo in New york to set up a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). Best regards, -- Abdelkader Chikh Daho Network Architect iWeb Technologies Email : achikhdaho at iweb.com Web : www.iweb.com Tel : 514-286-4242 ext 2309 From chip.gwyn at gmail.com Thu Apr 19 10:12:01 2012 From: chip.gwyn at gmail.com (chip) Date: Thu, 19 Apr 2012 11:12:01 -0400 Subject: [IPv6] Monitoring BGP IPv6 Sesions In-Reply-To: References: <4F8FCBB0.3010009@foobar.org> Message-ID: There's new mib support in new IOS's and ASR9k stuffs but there's still not feature parity with IPv4. It seems the current prevailing winds indicate less support for SNMP and more for NETCONF. So maybe we should all get cozy with XML rather than OIDs... --chip On Thu, Apr 19, 2012 at 5:43 AM, Carlos Asensio wrote: > Hi Nick, > > Taking your comment into consideration, while we don't have the support for IPv6 on the BGP MIB, I'm afraid we'll have to monitor it "by hand". > > Best regards, > Carlos. > > -----Mensaje original----- > De: Nick Hilliard [mailto:nick at foobar.org] > Enviado el: jueves, 19 de abril de 2012 10:24 > Para: Carlos Asensio > CC: nanog at nanog.org > Asunto: Re: [IPv6] Monitoring BGP IPv6 Sesions > > On 19/04/2012 09:58, Carlos Asensio wrote: >> Anyone can help us on that matter? > > We need BGP4MIBv2. ?We've needed it for years. > > I am tired of screen-scraping terminal sessions looking for signs that ipv6 > sessions are down or broken. > > Nick > > -- Just my $.02, your mileage may vary,? batteries not included, etc.... From marshall.eubanks at gmail.com Thu Apr 19 10:15:10 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Thu, 19 Apr 2012 11:15:10 -0400 Subject: Colocation in New York for a POP In-Reply-To: <4F9028C2.4080900@iweb.com> References: <4F9028C2.4080900@iweb.com> Message-ID: On Thu, Apr 19, 2012 at 11:01 AM, Abdelkader Chikh Daho wrote: > Hi everyone, > > Can some one please tell us what is the best Colo in New york to set up a > POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). > What are you trying to optimize ? If it is cash outlay, you might want to look at 165 Halsey Street in Newark, New Jersey. It isn't physically New York, but it offers good connectivity to it at (in my experience) a lower price. Regards Marshall > Best regards, > > -- > Abdelkader Chikh Daho > Network Architect > iWeb Technologies > Email : achikhdaho at iweb.com > Web : www.iweb.com > Tel : 514-286-4242 ext 2309 > > From p.lynch at netappliant.com Thu Apr 19 10:22:17 2012 From: p.lynch at netappliant.com (Pierce Lynch) Date: Thu, 19 Apr 2012 15:22:17 +0000 Subject: Colocation in New York for a POP In-Reply-To: <4F9028C2.4080900@iweb.com> References: <4F9028C2.4080900@iweb.com> Message-ID: Abdelkader, I have had good experiences with TeleHouse America and their 25 Broadway facility, with some solid peering options - although being central New York, co-location can be a little more expensive there. As an alternative, they have an impressive facility in Staten Island, NY which I understand can accommodate for smaller requirements as well. Hope that helps... Kind regards, P. ________________________________________ From: Abdelkader Chikh Daho [achikhdaho at iweb.com] Sent: 19 April 2012 16:01 To: nanog at nanog.org Subject: Colocation in New York for a POP Hi everyone, Can some one please tell us what is the best Colo in New york to set up a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). Best regards, -- Abdelkader Chikh Daho Network Architect iWeb Technologies Email : achikhdaho at iweb.com Web : www.iweb.com Tel : 514-286-4242 ext 2309 From alex at corp.nac.net Thu Apr 19 10:31:39 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 19 Apr 2012 11:31:39 -0400 Subject: Colocation in New York for a POP Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB815DD393AF2@EXCHMBX.hq.nac.net> 25 B'way is in the process of being shuttered. ----- Original Message ----- From: Pierce Lynch To: Abdelkader Chikh Daho Cc: nanog at nanog.org Sent: Thu Apr 19 11:22:17 2012 Subject: RE: Colocation in New York for a POP Abdelkader, I have had good experiences with TeleHouse America and their 25 Broadway facility, with some solid peering options - although being central New York, co-location can be a little more expensive there. As an alternative, they have an impressive facility in Staten Island, NY which I understand can accommodate for smaller requirements as well. Hope that helps... Kind regards, P. ________________________________________ From: Abdelkader Chikh Daho [achikhdaho at iweb.com] Sent: 19 April 2012 16:01 To: nanog at nanog.org Subject: Colocation in New York for a POP Hi everyone, Can some one please tell us what is the best Colo in New york to set up a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). Best regards, -- Abdelkader Chikh Daho Network Architect iWeb Technologies Email : achikhdaho at iweb.com Web : www.iweb.com Tel : 514-286-4242 ext 2309 From sthaug at nethelp.no Thu Apr 19 13:35:42 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 19 Apr 2012 20:35:42 +0200 (CEST) Subject: [IPv6] Monitoring BGP IPv6 Sesions In-Reply-To: References: <4F8FCBB0.3010009@foobar.org> Message-ID: <20120419.203542.74702543.sthaug@nethelp.no> > There's new mib support in new IOS's and ASR9k stuffs but there's > still not feature parity with IPv4. It seems the current prevailing > winds indicate less support for SNMP and more for NETCONF. So maybe > we should all get cozy with XML rather than OIDs... All I've seen of Netconf so far indicates that it noticeably more heavyweight than SNMP. But I could be wrong... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From Vinny_Abello at Dell.com Thu Apr 19 15:10:42 2012 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 19 Apr 2012 20:10:42 +0000 Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> Message-ID: I've been informed that 165 Halsey (Equinix) may be difficult to get into due to limited space, just an FYI... -Vinny -----Original Message----- From: Marshall Eubanks [mailto:marshall.eubanks at gmail.com] Sent: Thursday, April 19, 2012 11:15 AM To: Abdelkader Chikh Daho Cc: nanog at nanog.org Subject: Re: Colocation in New York for a POP On Thu, Apr 19, 2012 at 11:01 AM, Abdelkader Chikh Daho wrote: > Hi everyone, > > Can some one please tell us what is the best Colo in New york to set up a > POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). > What are you trying to optimize ? If it is cash outlay, you might want to look at 165 Halsey Street in Newark, New Jersey. It isn't physically New York, but it offers good connectivity to it at (in my experience) a lower price. Regards Marshall > Best regards, > > -- > Abdelkader Chikh Daho > Network Architect > iWeb Technologies > Email : achikhdaho at iweb.com > Web : www.iweb.com > Tel : 514-286-4242 ext 2309 > > From Vinny_Abello at Dell.com Thu Apr 19 15:14:14 2012 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 19 Apr 2012 20:14:14 +0000 Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> Message-ID: The Telehouse 25 Broadway facility (last I heard) is currently planned to be shut down by somewhere around June 2013 if I remember correctly... so you'll want to keep that in mind. They have plenty of other options including a new facility and other existing ones as well as other colo providers in the area (Equinix, Telx, etc.). There are lots of choices. "Best" is relative to your specific requirements which is why there is competition. :) -Vinny -----Original Message----- From: Pierce Lynch [mailto:p.lynch at netappliant.com] Sent: Thursday, April 19, 2012 11:22 AM To: Abdelkader Chikh Daho Cc: nanog at nanog.org Subject: RE: Colocation in New York for a POP Abdelkader, I have had good experiences with TeleHouse America and their 25 Broadway facility, with some solid peering options - although being central New York, co-location can be a little more expensive there. As an alternative, they have an impressive facility in Staten Island, NY which I understand can accommodate for smaller requirements as well. Hope that helps... Kind regards, P. ________________________________________ From: Abdelkader Chikh Daho [achikhdaho at iweb.com] Sent: 19 April 2012 16:01 To: nanog at nanog.org Subject: Colocation in New York for a POP Hi everyone, Can some one please tell us what is the best Colo in New york to set up a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). Best regards, -- Abdelkader Chikh Daho Network Architect iWeb Technologies Email : achikhdaho at iweb.com Web : www.iweb.com Tel : 514-286-4242 ext 2309 From joly at punkcast.com Thu Apr 19 15:19:07 2012 From: joly at punkcast.com (Joly MacFie) Date: Thu, 19 Apr 2012 16:19:07 -0400 Subject: Colocation in New York for a POP In-Reply-To: <4F9028C2.4080900@iweb.com> References: <4F9028C2.4080900@iweb.com> Message-ID: http://www.nyi.net/nyi_solutions/more/colocation On Thu, Apr 19, 2012 at 11:01 AM, Abdelkader Chikh Daho wrote: > Hi everyone, > > Can some one please tell us what is the best Colo in New york to set up a > POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). > > Best regards, > > -- > Abdelkader Chikh Daho > Network Architect > iWeb Technologies > Email : achikhdaho at iweb.com > Web : www.iweb.com > Tel : 514-286-4242 ext 2309 > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From pauldotwall at gmail.com Thu Apr 19 15:50:46 2012 From: pauldotwall at gmail.com (Paul WALL) Date: Thu, 19 Apr 2012 16:50:46 -0400 Subject: Colocation in New York for a POP In-Reply-To: <4F9028C2.4080900@iweb.com> References: <4F9028C2.4080900@iweb.com> Message-ID: Stay away from the NYIIX. It goes down every month or two, and its current management is not competent. There are plenty of competitive options, including Equinix and Telx/TIE (which is free or close to it). Drive Slow, Paul Wall On 4/19/12, Abdelkader Chikh Daho wrote: > Hi everyone, > > Can some one please tell us what is the best Colo in New york to set up > a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). > > Best regards, > > -- > Abdelkader Chikh Daho > Network Architect > iWeb Technologies > Email : achikhdaho at iweb.com > Web : www.iweb.com > Tel : 514-286-4242 ext 2309 > > > From andy-nanog at bash.sh Thu Apr 19 16:02:56 2012 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Thu, 19 Apr 2012 23:02:56 +0200 Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> Message-ID: at $JOB-2 we had a couple of racks in 60 Hudson St, which worked well On Thu, Apr 19, 2012 at 10:50 PM, Paul WALL wrote: > Stay away from the NYIIX. It goes down every month or two, and its > current management is not competent. There are plenty of competitive > options, including Equinix and Telx/TIE (which is free or close to > it). > > Drive Slow, > Paul Wall > > On 4/19/12, Abdelkader Chikh Daho wrote: > > Hi everyone, > > > > Can some one please tell us what is the best Colo in New york to set up > > a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). > > > > Best regards, > > > > -- > > Abdelkader Chikh Daho > > Network Architect > > iWeb Technologies > > Email : achikhdaho at iweb.com > > Web : www.iweb.com > > Tel : 514-286-4242 ext 2309 > > > > > > > > From Bill.Ingrum at t-systems.com Thu Apr 19 16:08:41 2012 From: Bill.Ingrum at t-systems.com (Bill.Ingrum at t-systems.com) Date: Thu, 19 Apr 2012 17:08:41 -0400 Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> Message-ID: <972EE2ECC5BFF44CA991510B8EDA469C0DF51D71@S4USJVSYAIC.ts-na.t-systems.com> +1 for 60 Hudson -----Original Message----- From: Andrew Mulholland [mailto:andy-nanog at bash.sh] Sent: Thursday, April 19, 2012 4:03 PM To: Paul WALL Cc: nanog at nanog.org Subject: Re: Colocation in New York for a POP at $JOB-2 we had a couple of racks in 60 Hudson St, which worked well On Thu, Apr 19, 2012 at 10:50 PM, Paul WALL wrote: > Stay away from the NYIIX. It goes down every month or two, and its > current management is not competent. There are plenty of competitive > options, including Equinix and Telx/TIE (which is free or close to > it). > > Drive Slow, > Paul Wall > > On 4/19/12, Abdelkader Chikh Daho wrote: > > Hi everyone, > > > > Can some one please tell us what is the best Colo in New york to set up > > a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). > > > > Best regards, > > > > -- > > Abdelkader Chikh Daho > > Network Architect > > iWeb Technologies > > Email : achikhdaho at iweb.com > > Web : www.iweb.com > > Tel : 514-286-4242 ext 2309 > > > > > > > > From golson at markettools.com Thu Apr 19 16:48:53 2012 From: golson at markettools.com (Greg Olson) Date: Thu, 19 Apr 2012 21:48:53 +0000 Subject: fiber cut in California? Message-ID: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> Anyone hear of a fiber cut in California today? From Bill.Ingrum at t-systems.com Thu Apr 19 16:56:19 2012 From: Bill.Ingrum at t-systems.com (Bill.Ingrum at t-systems.com) Date: Thu, 19 Apr 2012 17:56:19 -0400 Subject: fiber cut in California? In-Reply-To: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> References: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> Message-ID: <972EE2ECC5BFF44CA991510B8EDA469C0DF51DC1@S4USJVSYAIC.ts-na.t-systems.com> https://puck.nether.net/pipermail/outages/2012-April/003852.html -----Original Message----- From: Greg Olson [mailto:golson at markettools.com] Sent: Thursday, April 19, 2012 4:49 PM To: nanog at nanog.org Subject: fiber cut in California? Anyone hear of a fiber cut in California today? From brandon at burn.net Thu Apr 19 16:58:04 2012 From: brandon at burn.net (Brandon Applegate) Date: Thu, 19 Apr 2012 17:58:04 -0400 (EDT) Subject: fiber cut in California? In-Reply-To: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> References: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> Message-ID: On Thu, 19 Apr 2012, Greg Olson wrote: > Anyone hear of a fiber cut in California today? > I have a customer complaint about degraded performance to a site in China and the path appears to exit Qwest to China Netcom in the LA area. Also this thread on outages: https://puck.nether.net/pipermail/outages/2012-April/003844.html I tried calling Qwest (sorry, Centurylink) NOC/support and there was a preemptive recording basically saying there was a huge outage and that hold times may be long. I had to hang up before they came on to deal with some other things though. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 8779 B023 7637 CEC8 C5C6 4052 664D 7E08 3CBB 1739 "SH1-0151. This is the serial number, of our orbital gun." From nathan at robotics.net Thu Apr 19 17:15:24 2012 From: nathan at robotics.net (Nathan Stratton) Date: Thu, 19 Apr 2012 17:15:24 -0500 (CDT) Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> Message-ID: On Thu, 19 Apr 2012, Andrew Mulholland wrote: > at $JOB-2 we had a couple of racks in 60 Hudson St, which worked well I just took a few racks on the 9th floor, I know there are some others that are free. ><> Nathan Stratton nathan at robotics.net http://www.robotics.net From smeuse at mara.org Thu Apr 19 17:26:05 2012 From: smeuse at mara.org (Steve Meuse) Date: Thu, 19 Apr 2012 18:26:05 -0400 Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> Message-ID: <4F9090FD.9090809@mara.org> On 4/19/2012 4:10 PM, Vinny_Abello at Dell.com wrote: > I've been informed that 165 Halsey (Equinix) may be difficult to get into due to limited space, just an FYI... > > -Vinny Equinix is not the only space provider in that building... http://www.165halseyst.com/home.asp http://www.peeringdb.com -Steve From dotis at mail-abuse.org Thu Apr 19 17:31:43 2012 From: dotis at mail-abuse.org (Douglas Otis) Date: Thu, 19 Apr 2012 15:31:43 -0700 Subject: Most energy efficient (home) setup In-Reply-To: References: <201204150646.q3F6kTsk061467@aurora.sol.net> <1334525166.3887.1012.camel@pc2> <4F8F1774.2000203@mompl.net> <4F8F3854.3030208@mail-abuse.org> Message-ID: <4F90924F.6030300@mail-abuse.org> On 4/18/12 8:09 PM, Steven Bellovin wrote: > > On Apr 18, 2012, at 5:55 32PM, Douglas Otis wrote: > > Dear Jeroen, > > > > In the work that led up to RFC3309, many of the errors found on the > > Internet pertained to single interface bits, and not single data > > bits. Working at a large chip manufacturer that removed internal > > memory error detection to foolishly save space, cost them dearly in > > then needing to do far more exhaustive four corner testing. > > Checksums used by TCP and UDP are able to detect single bit data > > errors, but may miss as much as 2% of single interface bit errors. > > It would be surprising to find memory designs lacking internal > > error detection logic. > > mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed > 2,5d; date Request for Comments: 3309 > Stanford September 2002 > > Wed Apr 18 23:07:53 EDT 2012 > > We are not in a static field... (3309 is one of my favorite RFCs -- > but the specific findings (errors happen more often than you think), > as opposed the general lesson (understand your threat model) may be > OBE. Dear Steve, You may be right. However back then most were also only considering random single bit errors as well. Although there was plentiful evidence for where errors might be occurring, it seems many worked hard to ignore the clues. Reminiscent of a drunk searching for keys dropped in the dark under a light post, mathematics for random single bit errors offer easier calculations and simpler solutions. While there are indeed fewer parallel buses today, these structures still exist in memory modules and other networking components. Manufactures confront increasingly temperamental bit storage elements, where most include internal error correction to minimize manufacturing and testing costs. Error sources are not easily ascertained with simple checksums when errors are not random. Regards, Douglas Otis From smb at cs.columbia.edu Thu Apr 19 17:37:32 2012 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 19 Apr 2012 18:37:32 -0400 Subject: Most energy efficient (home) setup In-Reply-To: <4F90924F.6030300@mail-abuse.org> References: <201204150646.q3F6kTsk061467@aurora.sol.net> <1334525166.3887.1012.camel@pc2> <4F8F1774.2000203@mompl.net> <4F8F3854.3030208@mail-abuse.org> <4F90924F.6030300@mail-abuse.org> Message-ID: <24783DCD-C958-4A97-AD93-60ACBFB9F760@cs.columbia.edu> On Apr 19, 2012, at 6:31 43PM, Douglas Otis wrote: > On 4/18/12 8:09 PM, Steven Bellovin wrote: >> >> On Apr 18, 2012, at 5:55 32PM, Douglas Otis wrote: >> > Dear Jeroen, >> > >> > In the work that led up to RFC3309, many of the errors found on the >> > Internet pertained to single interface bits, and not single data >> > bits. Working at a large chip manufacturer that removed internal >> > memory error detection to foolishly save space, cost them dearly in >> > then needing to do far more exhaustive four corner testing. >> > Checksums used by TCP and UDP are able to detect single bit data >> > errors, but may miss as much as 2% of single interface bit errors. >> > It would be surprising to find memory designs lacking internal >> > error detection logic. >> >> mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed >> 2,5d; date Request for Comments: 3309 >> Stanford September 2002 >> >> Wed Apr 18 23:07:53 EDT 2012 >> >> We are not in a static field... (3309 is one of my favorite RFCs -- >> but the specific findings (errors happen more often than you think), >> as opposed the general lesson (understand your threat model) may be >> OBE. > Dear Steve, > > You may be right. However back then most were also only considering random single bit errors as well. Although there was plentiful evidence for where errors might be occurring, it seems many worked hard to ignore the clues. > > Reminiscent of a drunk searching for keys dropped in the dark under a light post, mathematics for random single bit errors offer easier calculations and simpler solutions. While there are indeed fewer parallel buses today, these structures still exist in memory modules and other networking components. Manufactures confront increasingly temperamental bit storage elements, where most include internal error correction to minimize manufacturing and testing costs. Error sources are not easily ascertained with simple checksums when errors are not random. > Yes -- that's precisely why I like that RFC so much. --Steve Bellovin, https://www.cs.columbia.edu/~smb From joly at punkcast.com Thu Apr 19 17:40:10 2012 From: joly at punkcast.com (Joly MacFie) Date: Thu, 19 Apr 2012 18:40:10 -0400 Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> Message-ID: Just to be clear, NYIIX is operated by Telehouse, and has nothing to do with nyi.net. j On Thu, Apr 19, 2012 at 4:50 PM, Paul WALL wrote: > Stay away from the NYIIX. ?It goes down every month or two, and its > current management is not competent. ?There are plenty of competitive > options, including Equinix and Telx/TIE (which is free or close to > it). > > Drive Slow, > Paul Wall > > On 4/19/12, Abdelkader Chikh Daho wrote: >> Hi everyone, >> >> Can some one please tell us what is the best Colo in New york to set up >> a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). >> >> Best regards, >> >> -- >> Abdelkader Chikh Daho >> Network Architect >> iWeb Technologies >> Email : achikhdaho at iweb.com >> Web : www.iweb.com >> Tel : 514-286-4242 ext 2309 >> >> >> > -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ?VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From aaron at heyaaron.com Thu Apr 19 17:40:36 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 19 Apr 2012 15:40:36 -0700 Subject: fiber cut in California? In-Reply-To: References: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> Message-ID: On Thu, Apr 19, 2012 at 14:58, Brandon Applegate wrote: > I tried calling Qwest (sorry, Centurylink) NOC/support and there was a > preemptive recording basically saying there was a huge outage and that hold > times may be long. ?I had to hang up before they came on to deal with some > other things though. On Twitter, LastCenturyLink told me its a fiber cut in Spokane, WA. -A From jvanoppen at spectrumnet.us Thu Apr 19 18:36:40 2012 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 19 Apr 2012 23:36:40 +0000 Subject: fiber cut in California? In-Reply-To: References: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> Message-ID: We saw the issues on the AS209 backbone as well from our vantage point here in Seattle but we also show a circuit we have down (that rides Qwest) between Yakima, WA and Spokane, WA. The outage corresponds to the IP issues so I would think that it is probably the same cut affecting both the wave we are seeing as out and the IP issues (which mostly seem better now). Thanks, John @ AS11404 here in Seattle. From sparctacus at gmail.com Thu Apr 19 19:23:27 2012 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 19 Apr 2012 17:23:27 -0700 Subject: fiber cut in California? In-Reply-To: References: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> Message-ID: Yes. There was a fiber cut. Apparently a construction crew was doing some boring and went through some cables. Sent from my iPhone On Apr 19, 2012, at 2:58 PM, Brandon Applegate wrote: > On Thu, 19 Apr 2012, Greg Olson wrote: > >> Anyone hear of a fiber cut in California today? >> > > I have a customer complaint about degraded performance to a site in China and the path appears to exit Qwest to China Netcom in the LA area. Also this thread on outages: > > https://puck.nether.net/pipermail/outages/2012-April/003844.html > > I tried calling Qwest (sorry, Centurylink) NOC/support and there was a preemptive recording basically saying there was a huge outage and that hold times may be long. I had to hang up before they came on to deal with some other things though. > > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 8779 B023 7637 CEC8 C5C6 4052 664D 7E08 3CBB 1739 > "SH1-0151. This is the serial number, of our orbital gun." > > > From frnkblk at iname.com Thu Apr 19 20:46:52 2012 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 19 Apr 2012 20:46:52 -0500 Subject: fiber cut in California? In-Reply-To: References: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> Message-ID: <005b01cd1e97$75e43f00$61acbd00$@iname.com> If that's the case, then it sounds like there are two cuts, one in the CA, one in WA. Frank -----Original Message----- From: John van Oppen [mailto:jvanoppen at spectrumnet.us] Sent: Thursday, April 19, 2012 6:37 PM To: nanog at nanog.org Subject: RE: fiber cut in California? We saw the issues on the AS209 backbone as well from our vantage point here in Seattle but we also show a circuit we have down (that rides Qwest) between Yakima, WA and Spokane, WA. The outage corresponds to the IP issues so I would think that it is probably the same cut affecting both the wave we are seeing as out and the IP issues (which mostly seem better now). Thanks, John @ AS11404 here in Seattle. From shortdudey123 at gmail.com Thu Apr 19 21:00:42 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 19 Apr 2012 21:00:42 -0500 Subject: fiber cut in California? In-Reply-To: <005b01cd1e97$75e43f00$61acbd00$@iname.com> References: <4D9535BECBA6144C9E481866FB3F964B0E15EC01@WDCCPMAIL01.markettools.com> <005b01cd1e97$75e43f00$61acbd00$@iname.com> Message-ID: There was also one in the UP of Michigan early this morning but it only affected phone traffic. On Thu, Apr 19, 2012 at 8:46 PM, Frank Bulk wrote: > If that's the case, then it sounds like there are two cuts, one in the CA, > one in WA. > > Frank > > -----Original Message----- > From: John van Oppen [mailto:jvanoppen at spectrumnet.us] > Sent: Thursday, April 19, 2012 6:37 PM > To: nanog at nanog.org > Subject: RE: fiber cut in California? > > We saw the issues on the AS209 backbone as well from our vantage point > here in Seattle but we also show a circuit we have down (that rides Qwest) > between Yakima, WA and Spokane, WA. The outage corresponds to the IP > issues so I would think that it is probably the same cut affecting both the > wave we are seeing as out and the IP issues (which mostly seem better now). > > Thanks, > John @ AS11404 here in Seattle. > > > > From tvhawaii at shaka.com Thu Apr 19 21:07:48 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 19 Apr 2012 16:07:48 -1000 Subject: Wireless Liability: Liability Concerns for Operators of Unsecured Wireless Networks Message-ID: <4BAC405241EF433A87118B4A863A1A00@owner59e1f1502> As ISP safe harbor, etc., has been discussed here in the past, this paper from Rutgers may be of interest to some. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2035633 From fernando at gont.com.ar Fri Apr 20 02:08:50 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 20 Apr 2012 04:08:50 -0300 Subject: Fwd: Host scanning in IPv6 Networks Message-ID: <4F910B82.8040505@gont.com.ar> FYI -------- Original Message -------- Subject: IPv6 host scanning in IPv6 Date: Fri, 20 Apr 2012 03:57:48 -0300 From: Fernando Gont Organization: SI6 Networks To: IPv6 Hackers Mailing List Folks, We've just published an IETF internet-draft about IPv6 host scanning attacks. The aforementioned document is available at: The Abstract of the document is: ---- cut here ---- IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible. ---- cut here ---- Any comments will be very welcome (note: this is a drafty initial version, with lots of stuff still to be added... but hopefully a good starting point, and a nice reading ;-) ). Thanks! Best regards, From oscar.vives at gmail.com Fri Apr 20 07:17:21 2012 From: oscar.vives at gmail.com (Tei) Date: Fri, 20 Apr 2012 14:17:21 +0200 Subject: Host scanning in IPv6 Networks In-Reply-To: <4F910B82.8040505@gont.com.ar> References: <4F910B82.8040505@gont.com.ar> Message-ID: It would be a very fast dictionary attack :D accede bade dad decade face axed babe deaf bed Abe bee Decca exec fade bead bedded deed exceed Abba deface efface feed On 20 April 2012 09:08, Fernando Gont wrote: > FYI > > -------- Original Message -------- > Subject: IPv6 host scanning in IPv6 > Date: Fri, 20 Apr 2012 03:57:48 -0300 > From: Fernando Gont > Organization: SI6 Networks > To: IPv6 Hackers Mailing List > > Folks, > > We've just published an IETF internet-draft about IPv6 host scanning > attacks. > > The aforementioned document is available at: > > > The Abstract of the document is: > ---- cut here ---- > ? IPv6 offers a much larger address space than that of its IPv4 > ? counterpart. ?The standard /64 IPv6 subnets can (in theory) > ? accommodate approximately 1.844 * 10^19 hosts, thus resulting in a > ? much lower host density (#hosts/#addresses) than their IPv4 > ? counterparts. ?As a result, it is widely assumed that it would take a > ? tremendous effort to perform host scanning attacks against IPv6 > ? networks, and therefore IPv6 host scanning attacks have long been > ? considered unfeasible. ?This document analyzes the IPv6 address > ? configuration policies implemented in most popular IPv6 stacks, and > ? identifies a number of patterns in the resulting addresses lead to a > ? tremendous reduction in the host address search space, thus > ? dismantling the myth that IPv6 host scanning attacks are unfeasible. > ---- cut here ---- > > Any comments will be very welcome (note: this is a drafty initial > version, with lots of stuff still to be added... but hopefully a good > starting point, and a nice reading ;-) ). > > Thanks! > > Best regards, > -- -- ?in del ?ensaje. From betty at newnog.org Fri Apr 20 08:32:18 2012 From: betty at newnog.org (Betty Burke ) Date: Fri, 20 Apr 2012 09:32:18 -0400 Subject: [NANOG-announce] 2012 Postel Scholarship Message-ID: Colleagues: On behalf of the North American Network Operators' Group (NANOG) and the American Registry for Internet Numbers (ARIN), we would like to take this opportunity to draw your attention to the 2012 Postel Network Operator's Scholarship. The Postel Network Operator's Scholarship targets personnel from developing countries who are actively involved in Internet development, in any of the following roles: ?Engineers (Network Builders) ?Operational and Infrastructure Support Personnel ?Educators and Trainers This is not a postgraduate fellowship or academic scholarship. Individuals may nominate themselves for the Scholarship via email or online form. The Scholarship will be awarded annually to a recipient selected by a committee comprising representatives from the NANOG Board of Directors and the ARIN Board of Trustees. The selection committee will "whimsically" select the annual recipient exclusively in response to the question: "What Would Jon Do?" if he were asked to select a recipient. The successful applicant will be provided with transportation to and from the NANOG and ARIN joint meeting October 21-26, 2012, in Dallas, Texas, USA, and a reasonable (local host standard) allowance for food and accommodation. In addition, all fees for participation in both meetings' events will be waived. The final grant size is determined according to final costs and available funding. The chosen recipient will be advised at least 2 months prior to the fall meeting date. Applications from qualified individuals are now being accepted. The deadline for application is June 1, 2012, and the awardees will be informed by July 16, 2012. Please read full information about the scholarship at: http://www.nanog.org/scholarships/postel.php Please pass along this information and encourage those interested to apply by completing the web-based application form that is linked from the information page. Optionally, submissions are accepted via email PLAIN ASCII in the BODY of the message, not as an attachment nor as a Word document, PDF, or any other form, to PostelNOS at nanog.org. Please be sure to include the following: ? Full name and contact info ? Your brief biography, including current and recent jobs held ? A description of why you need and deserve this Scholarship to attend the NANOG and ARIN meetings ? A description of how you plan to leverage your attendance at the meetings in your work ? A brief abstract of a presentation you would give at the NANOG and/or ARIN meetings, if selected as a Scholarship winner Kind regards, Steve Gibbard and Paul Vixie, on behalf of the Postel Scholarship Selection Committee -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 Office (810) 214-1218 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From sclark at netwolves.com Fri Apr 20 09:24:25 2012 From: sclark at netwolves.com (Steve Clark) Date: Fri, 20 Apr 2012 10:24:25 -0400 Subject: Host scanning in IPv6 Networks In-Reply-To: References: <4F910B82.8040505@gont.com.ar> Message-ID: <4F917199.8040400@netwolves.com> On 04/20/2012 08:17 AM, Tei wrote: > It would be a very fast dictionary attack :D > > accede > bade > dad > decade > face > axed > babe > deaf > bed > Abe > bee > Decca > exec > fade > bead > bedded > deed > exceed > Abba > deface > efface > feed > > > On 20 April 2012 09:08, Fernando Gont wrote: >> FYI >> >> -------- Original Message -------- >> Subject: IPv6 host scanning in IPv6 >> Date: Fri, 20 Apr 2012 03:57:48 -0300 >> From: Fernando Gont >> Organization: SI6 Networks >> To: IPv6 Hackers Mailing List >> >> Folks, >> >> We've just published an IETF internet-draft about IPv6 host scanning >> attacks. >> >> The aforementioned document is available at: >> >> >> The Abstract of the document is: >> ---- cut here ---- >> IPv6 offers a much larger address space than that of its IPv4 >> counterpart. The standard /64 IPv6 subnets can (in theory) >> accommodate approximately 1.844 * 10^19 hosts, thus resulting in a >> much lower host density (#hosts/#addresses) than their IPv4 >> counterparts. As a result, it is widely assumed that it would take a >> tremendous effort to perform host scanning attacks against IPv6 >> networks, and therefore IPv6 host scanning attacks have long been >> considered unfeasible. This document analyzes the IPv6 address >> configuration policies implemented in most popular IPv6 stacks, and >> identifies a number of patterns in the resulting addresses lead to a >> tremendous reduction in the host address search space, thus >> dismantling the myth that IPv6 host scanning attacks are unfeasible. >> ---- cut here ---- >> >> Any comments will be very welcome (note: this is a drafty initial >> version, with lots of stuff still to be added... but hopefully a good >> starting point, and a nice reading ;-) ). >> >> Thanks! >> >> Best regards, >> > > exec ? exceed ? -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From owen at delong.com Fri Apr 20 10:16:45 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Apr 2012 08:16:45 -0700 Subject: Host scanning in IPv6 Networks In-Reply-To: <4F917199.8040400@netwolves.com> References: <4F910B82.8040505@gont.com.ar> <4F917199.8040400@netwolves.com> Message-ID: <0A949077-BC84-4CF7-B20B-53CED70C32E6@delong.com> >> > exec ? > exceed ? > Not a lot of x's in hexidecimal numbers outside of C-style formatting (0xnnnn). IPv6 addresses are not generally notated in said style and certainly don't include said x in a suitable context for that to be part of a dictionary attack. However, he also left out the common use of 7(t), 6/9(g), 1/7(I/L/T), 2(Z), 5(S), and 0(O). c is also often substituted for k (as in face:b00c). Owen From p.lynch at netappliant.com Fri Apr 20 10:35:03 2012 From: p.lynch at netappliant.com (Pierce Lynch) Date: Fri, 20 Apr 2012 15:35:03 +0000 Subject: Colocation in New York for a POP In-Reply-To: References: <4F9028C2.4080900@iweb.com> , Message-ID: Interesting, I wasn't aware of that - thanks for the heads up! I knew Telx, 60 Hudson Street was consider to be an alternative to TH 25B at the time (approx 24 months ago), as mentioned by a few others in this thread. Kind regards, P. -----Original Message----- From: Vinny_Abello at Dell.com [Vinny_Abello at Dell.com] Sent: 19 April 2012 21:14 To: Pierce Lynch; achikhdaho at iweb.com Cc: nanog at nanog.org Subject: RE: Colocation in New York for a POP The Telehouse 25 Broadway facility (last I heard) is currently planned to be shut down by somewhere around June 2013 if I remember correctly... so you'll want to keep that in mind. They have plenty of other options including a new facility and other existing ones as well as other colo providers in the area (Equinix, Telx, etc.). There are lots of choices. "Best" is relative to your specific requirements which is why there is competition. :) -Vinny From achikhdaho at iweb.com Fri Apr 20 11:39:10 2012 From: achikhdaho at iweb.com (Abdelkader Chikh Daho) Date: Fri, 20 Apr 2012 12:39:10 -0400 Subject: Colocation in New York for a POP In-Reply-To: <4F9028C2.4080900@iweb.com> References: <4F9028C2.4080900@iweb.com> Message-ID: <4F91912E.9020401@iweb.com> Hi, Thanks a lot for all your inputs and feedback. My goal is to peer with a lot of networks especially ISPs. We are mainly a content provider. Tlex and Equinix seem to be the obvioius choice for a neutral colocation facility. According to your experience, between 60 Hudson and 111 8th Avenue, which one I should choose? Best regards, Abdelkader Chikh Daho Network Architect iWeb Technologies Email : achikhdaho at iweb.com Web : www.iweb.com Tel : 514-286-4242 ext 2309 On 19/04/2012 11:01 AM, Abdelkader Chikh Daho wrote: > Hi everyone, > > Can some one please tell us what is the best Colo in New york to set > up a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc). > > Best regards, > From mc3401 at columbia.edu Fri Apr 20 12:00:18 2012 From: mc3401 at columbia.edu (Michael Costello) Date: Fri, 20 Apr 2012 13:00:18 -0400 Subject: Colocation in New York for a POP In-Reply-To: <4F91912E.9020401@iweb.com> References: <4F9028C2.4080900@iweb.com> <4F91912E.9020401@iweb.com> Message-ID: <4F919622.2030606@columbia.edu> On 04/20/2012 12:39 PM, Abdelkader Chikh Daho wrote: > Hi, > > Thanks a lot for all your inputs and feedback. > My goal is to peer with a lot of networks especially ISPs. We are mainly > a content provider. Tlex and Equinix seem to be the obvioius choice for > a neutral colocation facility. According to your experience, between 60 > Hudson and 111 8th Avenue, which one I should choose? I don't think anyone mentioned it yet, but there is also The Hub at 32 Sixth. http://www.thehubat32sixth.com/ I've only ever purchased transit from one provider there through another and never colocated any equipment. It's a beautiful building, by the way. mc From dgolding at ragingwire.com Fri Apr 20 12:52:30 2012 From: dgolding at ragingwire.com (Dan Golding) Date: Fri, 20 Apr 2012 10:52:30 -0700 Subject: Colocation in New York for a POP In-Reply-To: <4F91912E.9020401@iweb.com> References: <4F9028C2.4080900@iweb.com> <4F91912E.9020401@iweb.com> Message-ID: <1C7B96053DD7814496A0D1E71661B68302AC13CD@SMF-ENTXM-001.sac.ragingwire.net> 111 8th Avenue is probably your best choice for straight-up Internet peering and transit. However, this largely depends on your traffic. If you do a lot of long distance voice, for example, 60 Hudson can be a better choice. There is also a good amount of peering at 165 Halsey in NJ, right across the river. Whichever you choose - there is inexpensive transport between these locations. In a choice between Equinix and Telx, I think there are many factors to choose from - price, level of customer service, contract length, ability to expand, and facility quality. How you weigh these factors depends on your own business. - Dan As far as which specific pr > From: Abdelkader Chikh Daho [mailto:achikhdaho at iweb.com] > > Hi, > > Thanks a lot for all your inputs and feedback. > My goal is to peer with a lot of networks especially ISPs. We are > mainly > a content provider. Tlex and Equinix seem to be the obvioius choice for > a neutral colocation facility. According to your experience, between 60 > Hudson and 111 8th Avenue, which one I should choose? > > > Best regards, > > Abdelkader Chikh Daho > Network Architect > iWeb Technologies > Email : achikhdaho at iweb.com > Web : www.iweb.com > Tel : 514-286-4242 ext 2309 From cscora at apnic.net Fri Apr 20 13:44:07 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Apr 2012 04:44:07 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201204201844.q3KIi7qB021765@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Apr, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 406332 Prefixes after maximum aggregation: 172729 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 197504 Total ASes present in the Internet Routing Table: 40749 Prefixes per ASN: 9.97 Origin-only ASes present in the Internet Routing Table: 33074 Origin ASes announcing only one prefix: 15626 Transit ASes present in the Internet Routing Table: 5448 Transit-only ASes present in the Internet Routing Table: 136 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 64 Max AS path prepend of ASN ( 9902) 56 Prefixes from unregistered ASNs in the Routing Table: 391 Unregistered ASNs in the Routing Table: 128 Number of 32-bit ASNs allocated by the RIRs: 2611 Number of 32-bit ASNs visible in the Routing Table: 2227 Prefixes from 32-bit ASNs in the Routing Table: 5570 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 119 Number of addresses announced to Internet: 2538235344 Equivalent to 151 /8s, 74 /16s and 101 /24s Percentage of available address space announced: 68.5 Percentage of allocated address space announced: 68.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.4 Total number of prefixes smaller than registry allocations: 173084 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 99600 Total APNIC prefixes after maximum aggregation: 32224 APNIC Deaggregation factor: 3.09 Prefixes being announced from the APNIC address blocks: 96078 Unique aggregates announced from the APNIC address blocks: 39691 APNIC Region origin ASes present in the Internet Routing Table: 4681 APNIC Prefixes per ASN: 20.53 APNIC Region origin ASes announcing only one prefix: 1238 APNIC Region transit ASes present in the Internet Routing Table: 729 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 185 Number of APNIC addresses announced to Internet: 644102752 Equivalent to 38 /8s, 100 /16s and 58 /24s Percentage of available APNIC address space announced: 81.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 149874 Total ARIN prefixes after maximum aggregation: 76295 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 121117 Unique aggregates announced from the ARIN address blocks: 50365 ARIN Region origin ASes present in the Internet Routing Table: 15044 ARIN Prefixes per ASN: 8.05 ARIN Region origin ASes announcing only one prefix: 5734 ARIN Region transit ASes present in the Internet Routing Table: 1585 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 29 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 807297728 Equivalent to 48 /8s, 30 /16s and 98 /24s Percentage of available ARIN address space announced: 64.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 101440 Total RIPE prefixes after maximum aggregation: 53739 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 93359 Unique aggregates announced from the RIPE address blocks: 58202 RIPE Region origin ASes present in the Internet Routing Table: 16502 RIPE Prefixes per ASN: 5.66 RIPE Region origin ASes announcing only one prefix: 8044 RIPE Region transit ASes present in the Internet Routing Table: 2626 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1495 Number of RIPE addresses announced to Internet: 509709960 Equivalent to 30 /8s, 97 /16s and 142 /24s Percentage of available RIPE address space announced: 82.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 40646 Total LACNIC prefixes after maximum aggregation: 8266 LACNIC Deaggregation factor: 4.92 Prefixes being announced from the LACNIC address blocks: 40505 Unique aggregates announced from the LACNIC address blocks: 20214 LACNIC Region origin ASes present in the Internet Routing Table: 1586 LACNIC Prefixes per ASN: 25.54 LACNIC Region origin ASes announcing only one prefix: 441 LACNIC Region transit ASes present in the Internet Routing Table: 299 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 525 Number of LACNIC addresses announced to Internet: 99324808 Equivalent to 5 /8s, 235 /16s and 147 /24s Percentage of available LACNIC address space announced: 65.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9028 Total AfriNIC prefixes after maximum aggregation: 2137 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 7079 Unique aggregates announced from the AfriNIC address blocks: 2166 AfriNIC Region origin ASes present in the Internet Routing Table: 534 AfriNIC Prefixes per ASN: 13.26 AfriNIC Region origin ASes announcing only one prefix: 169 AfriNIC Region transit ASes present in the Internet Routing Table: 116 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 31771648 Equivalent to 1 /8s, 228 /16s and 204 /24s Percentage of available AfriNIC address space announced: 47.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2497 11113 1012 Korea Telecom (KIX) 17974 1799 503 63 PT TELEKOMUNIKASI INDONESIA 7545 1677 301 88 TPG Internet Pty Ltd 4755 1587 388 166 TATA Communications formerly 9829 1249 1069 30 BSNL National Internet Backbo 9583 1227 94 528 Sify Limited 7552 1170 1062 11 Vietel Corporation 4808 1105 2049 318 CNCGROUP IP network: China169 24560 1024 385 167 Bharti Airtel Ltd., Telemedia 9498 947 291 64 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3427 3807 195 bellsouth.net, inc. 7029 3369 985 157 Windstream Communications Inc 18566 2091 382 179 Covad Communications 1785 1903 680 130 PaeTec Communications, Inc. 20115 1640 1566 619 Charter Communications 4323 1601 1044 381 Time Warner Telecom 22773 1576 2910 111 Cox Communications, Inc. 30036 1412 258 763 Mediacom Communications Corp 7018 1260 9775 819 AT&T WorldNet Services 11492 1186 216 364 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1745 544 16 Corbina telecom 2118 1304 97 14 EUnet/RELCOM Autonomous Syste 31148 680 37 9 FreeNet ISP 34984 679 188 175 BILISIM TELEKOM 6830 657 2215 426 UPC Distribution Services 20940 649 206 501 Akamai Technologies European 12479 647 666 63 Uni2 Autonomous System 8551 572 360 81 Bezeq International 3320 533 8442 399 Deutsche Telekom AG 2578 501 33 7 Demos, Moscow, Russia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1810 327 176 TVCABLE BOGOTA 28573 1781 1107 59 NET Servicos de Comunicao S.A 6503 1533 418 65 AVANTEL, S.A. 8151 1490 3018 350 UniNet S.A. de C.V. 7303 1362 829 191 Telecom Argentina Stet-France 26615 902 697 32 Tim Brasil S.A. 27947 683 74 98 Telconet S.A 11172 637 91 73 Servicios Alestra S.A de C.V 22047 582 326 15 VTR PUNTO NET S.A. 3816 572 242 100 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1314 958 13 TEDATA 24863 840 274 35 LINKdotNET AS number 6713 490 649 18 Itissalat Al-MAGHRIB 3741 265 921 223 The Internet Solution 12258 197 28 62 Vodacom Internet Company 24835 180 80 8 RAYA Telecom - Egypt 16637 171 666 83 MTN Network Solutions 33776 171 11 21 Starcomms Nigeria Limited 15706 169 32 6 Sudatel Internet Exchange Aut 29571 159 15 15 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3427 3807 195 bellsouth.net, inc. 7029 3369 985 157 Windstream Communications Inc 4766 2497 11113 1012 Korea Telecom (KIX) 18566 2091 382 179 Covad Communications 1785 1903 680 130 PaeTec Communications, Inc. 10620 1810 327 176 TVCABLE BOGOTA 17974 1799 503 63 PT TELEKOMUNIKASI INDONESIA 28573 1781 1107 59 NET Servicos de Comunicao S.A 8402 1745 544 16 Corbina telecom 7545 1677 301 88 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3369 3212 Windstream Communications Inc 18566 2091 1912 Covad Communications 1785 1903 1773 PaeTec Communications, Inc. 17974 1799 1736 PT TELEKOMUNIKASI INDONESIA 8402 1745 1729 Corbina telecom 28573 1781 1722 NET Servicos de Comunicao S.A 10620 1810 1634 TVCABLE BOGOTA 7545 1677 1589 TPG Internet Pty Ltd 4766 2497 1485 Korea Telecom (KIX) 6503 1533 1468 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 37.252.112.0/21 35094 Bredbandsfylket Troms AS Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:235 /13:459 /14:829 /15:1484 /16:12227 /17:6271 /18:10543 /19:20619 /20:28937 /21:29930 /22:40516 /23:37836 /24:212630 /25:1194 /26:1429 /27:786 /28:166 /29:65 /30:17 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3027 3369 Windstream Communications Inc 6389 2145 3427 bellsouth.net, inc. 18566 2040 2091 Covad Communications 8402 1722 1745 Corbina telecom 10620 1695 1810 TVCABLE BOGOTA 30036 1358 1412 Mediacom Communications Corp 6503 1291 1533 AVANTEL, S.A. 11492 1149 1186 Cable One 8452 1116 1314 TEDATA 1785 1071 1903 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:538 2:755 4:14 6:3 8:402 12:2007 13:1 14:599 15:12 16:3 17:7 20:22 23:167 24:1770 27:1257 31:981 32:57 33:2 34:2 36:8 37:366 38:798 40:120 41:3164 42:134 44:3 46:1495 47:3 49:371 50:530 52:13 54:8 55:8 56:3 57:31 58:960 59:519 60:281 61:1265 62:981 63:1992 64:4169 65:2251 66:4491 67:2019 68:1167 69:3189 70:902 71:486 72:1819 74:2594 75:494 76:318 77:944 78:1006 79:485 80:1209 81:903 82:667 83:550 84:473 85:1209 86:412 87:922 88:345 89:1625 90:291 91:4737 92:525 93:1352 94:1463 95:1166 96:360 97:316 98:902 99:36 100:7 101:174 103:1007 106:102 107:188 108:235 109:1287 110:756 111:921 112:445 113:597 114:642 115:880 116:908 117:714 118:906 119:1231 120:354 121:798 122:1638 123:1079 124:1352 125:1248 128:546 129:193 130:252 131:591 132:179 133:22 134:242 135:62 136:212 137:176 138:355 139:147 140:491 141:245 142:387 143:400 144:523 145:69 146:494 147:280 148:758 149:295 150:158 151:175 152:464 153:171 154:9 155:435 156:215 157:380 158:174 159:523 160:338 161:262 162:350 163:187 164:571 165:394 166:573 167:466 168:822 169:127 170:858 171:126 172:2 173:1745 174:563 175:433 176:427 177:666 178:1334 180:1180 181:75 182:810 183:288 184:453 185:1 186:2211 187:1041 188:1183 189:1779 190:5507 192:5999 193:5544 194:4646 195:3593 196:1292 197:130 198:3652 199:4521 200:5801 201:1927 202:8520 203:8588 204:4327 205:2494 206:2752 207:2793 208:4055 209:3611 210:2763 211:1475 212:2017 213:1907 214:834 215:104 216:5110 217:1538 218:539 219:344 220:1227 221:556 222:322 223:336 End of report From deepak at ai.net Fri Apr 20 14:09:41 2012 From: deepak at ai.net (Deepak Jain) Date: Fri, 20 Apr 2012 15:09:41 -0400 Subject: Assymetric routing L3/VZ (FIOS) Message-ID: <4F91B475.9020706@ai.net> Is anyone else seeing this? DC - DFW back to DC? AFAIK, Verizon-GNI is a customer of L3, so no weird peering issues should be afoot. This adds about 40ms to the R/T time. The path leaving Verizon-GNI (FIOS) goes (seemingly) DC-DC and has lower times (<5ms) unidirectionally. Tracing the route to pool-173-79-242-218.washdc.fios.verizon.net (173.79.242.218 ) [...] 3 ge-6-16.car1.Baltimore1.Level3.net (4.59.244.85) [AS 65518] 4 msec 0 msec 4 msec 4 ae-11-11.car2.Baltimore1.Level3.net (4.69.134.110) [AS 65518] 0 msec 4 msec 0 msec 5 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) [AS 65518] 4 msec 4 msec 4 msec 6 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS 65518] 4 msec ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) [AS 65518] 8 msec 8 msec 7 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) [AS 65518] 4 msec ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) [AS 65518] 4 msec ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) [AS 65518] 4 msec 8 ae-2-2.ebr3.Atlanta2.Level3.net (4.69.132.85) [AS 65518] 16 msec 16 msec 16 msec 9 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) [AS 65518] 36 msec 36 msec 36 m sec 10 ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145) [AS 65518] 40 msec ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133) [AS 65518] 40 msec 40 msec 11 ae-4-90.edge2.Dallas3.Level3.net (4.69.145.204) [AS 65518] 44 msec ae-3-80.edge2.Dallas3.Level3.net (4.69.145.140) [AS 65518] 36 msec ae-1-60.edge2.Dallas3.Level3.net (4.69.145.12) [AS 65518] 36 msec 12 MCI-level3-ae.dallas3.level3.net (4.68.62.34) [AS 65518] 36 msec mci-level3-30g.dallas3.level3.net (4.68.62.166) [AS 65518] 36 msec MCI-level3-ae.dallas3.level3.net (4.68.62.34) [AS 65518] 36 msec 13 0.ge-0-0-0.DFW01-BB-RTR1.verizon-gni.net (152.63.2.146) [AS 65518] 36 msec 3 6 msec 0.ae2.DFW01-BB-RTR2.verizon-gni.net (152.63.2.229) [AS 65518] 36 msec 14 * * * We're opening a ticket with them, but figured NANOG is an often better place for these resolutions. Thanks in advance, Deepak Jain AiNET Home of CyberNAP www.ai.net From morrowc.lists at gmail.com Fri Apr 20 14:29:29 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Apr 2012 15:29:29 -0400 Subject: Assymetric routing L3/VZ (FIOS) In-Reply-To: <4F91B475.9020706@ai.net> References: <4F91B475.9020706@ai.net> Message-ID: On Fri, Apr 20, 2012 at 3:09 PM, Deepak Jain wrote: > > Is anyone else seeing this? DC - DFW back to DC? AFAIK, Verizon-GNI is a why would GNI still be a customer 5 yrs on after GNI bought a transit provider with worldwide reach? (uunet's network) From surfer at mauigateway.com Fri Apr 20 16:58:50 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 20 Apr 2012 14:58:50 -0700 Subject: Host scanning in IPv6 Networks Message-ID: <20120420145850.CDE436E1@m0005311.ppops.net> > -------- Original Message -------- > From: Fernando Gont > We've just published an IETF internet-draft about IPv6 host scanning > attacks. --- oscar.vives at gmail.com wrote: From: Tei It would be a very fast dictionary attack :D accede bade feed ---------------------------------------- Just some Friday fun... To find firewalls quickly, look for: f0c:0ff >;-) scott From cidr-report at potaroo.net Fri Apr 20 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Apr 2012 22:00:00 GMT Subject: BGP Update Report Message-ID: <201204202200.q3KM00WC094923@wattle.apnic.net> BGP Update Report Interval: 12-Apr-12 -to- 19-Apr-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 52684 3.3% 31.4 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS9829 39059 2.5% 44.6 -- BSNL-NIB National Internet Backbone 3 - AS12479 27357 1.7% 132.8 -- UNI2-AS France Telecom Espana SA 4 - AS24186 25455 1.6% 454.6 -- RAILTEL-AS-IN RailTel Corporation of India Ltd., Internet Service Provider, New Delhi 5 - AS32528 25445 1.6% 12722.5 -- ABBOTT Abbot Labs 6 - AS5976 18740 1.2% 164.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - AS5800 18194 1.1% 57.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS7552 16539 1.0% 13.1 -- VIETEL-AS-AP Vietel Corporation 9 - AS24560 16017 1.0% 22.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - AS15399 14025 0.9% 122.0 -- WANANCHI-KE 11 - AS54600 13078 0.8% 4359.3 -- PEGTECHINC - PEG TECH INC 12 - AS16960 12901 0.8% 248.1 -- Cablevision Red, S.A de C.V. 13 - AS12396 12438 0.8% 460.7 -- INAR-ARKHNAGELSK-AS OJSC MegaFon 14 - AS6713 12426 0.8% 27.3 -- IAM-AS 15 - AS44798 11731 0.7% 11731.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 16 - AS786 10862 0.7% 54.0 -- JANET The JNT Association 17 - AS28306 9444 0.6% 277.8 -- TC Net Inform?tica e Telecomunica??es LTDA 18 - AS29049 9229 0.6% 22.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 19 - AS2697 8991 0.6% 45.4 -- ERX-ERNET-AS Education and Research Network 20 - AS28573 8589 0.5% 10.4 -- NET Servicos de Comunicao S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 25445 1.6% 12722.5 -- ABBOTT Abbot Labs 2 - AS44798 11731 0.7% 11731.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 3 - AS54600 13078 0.8% 4359.3 -- PEGTECHINC - PEG TECH INC 4 - AS17408 3141 0.2% 3141.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 5 - AS4658 1582 0.1% 1582.0 -- NETFRONT-AS Netfront Information Technology Limited, 6 - AS36980 1033 0.1% 1033.0 -- JOHNHOLT-ASN 7 - AS21271 1017 0.1% 1017.0 -- SOTELMABGP 8 - AS55665 947 0.1% 947.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 9 - AS8657 780 0.1% 780.0 -- CPRM CPRM Autonomous System 10 - AS57767 747 0.1% 747.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network 11 - AS34043 726 0.1% 726.0 -- RISS Internet Security Systems SRL 12 - AS25600 688 0.0% 688.0 -- MATRIKON-1 - Matrikon Inc. 13 - AS27169 548 0.0% 548.0 -- TRIDENTAS - Trident Systems, Inc. 14 - AS38857 1020 0.1% 510.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 15 - AS51825 932 0.1% 466.0 -- TELZAR-ASN TELZAR INTERNATIONAL TELECOMINICATIONS LTD 16 - AS12396 12438 0.8% 460.7 -- INAR-ARKHNAGELSK-AS OJSC MegaFon 17 - AS56094 920 0.1% 460.0 -- ITENET-SG 10 Dover Drive 18 - AS24029 455 0.0% 455.0 -- NIXI-IN-AS NIXI is an IXP in India 19 - AS24186 25455 1.6% 454.6 -- RAILTEL-AS-IN RailTel Corporation of India Ltd., Internet Service Provider, New Delhi 20 - AS57201 421 0.0% 421.0 -- EDF-AS Estonian Defence Forces TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 12723 0.7% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 12722 0.7% AS32528 -- ABBOTT Abbot Labs 3 - 91.202.212.0/22 11731 0.7% AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 4 - 205.107.121.0/24 8935 0.5% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 5 - 62.36.252.0/22 8013 0.5% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 72.31.221.0/24 7137 0.4% AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 7 - 122.161.0.0/16 6970 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - 62.36.249.0/24 6434 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.241.0/24 6065 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 62.36.210.0/24 5921 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 11 - 205.106.248.0/24 5896 0.3% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - 194.63.9.0/24 5891 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 199.180.100.0/23 4383 0.2% AS54600 -- PEGTECHINC - PEG TECH INC 14 - 199.180.100.0/24 4348 0.2% AS54600 -- PEGTECHINC - PEG TECH INC 15 - 199.180.101.0/24 4347 0.2% AS54600 -- PEGTECHINC - PEG TECH INC 16 - 202.56.215.0/24 3384 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 17 - 202.153.174.0/24 3141 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 18 - 213.139.220.0/24 2414 0.1% AS13263 -- HAYATNET-AS HayatNet Bilgi ve Iletisim Hizmetleri A.S 19 - 85.235.80.0/24 2411 0.1% AS13263 -- HAYATNET-AS HayatNet Bilgi ve Iletisim Hizmetleri A.S 20 - 46.237.0.0/19 2332 0.1% AS13118 -- ASN-YARTELECOM OJSC Rostelecom Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 20 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Apr 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201204202200.q3KM00g9094918@wattle.apnic.net> This report has been generated at Fri Apr 20 21:12:51 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-04-12 408593 238754 14-04-12 408628 238808 15-04-12 408701 238734 16-04-12 408688 238611 17-04-12 408679 238737 18-04-12 409045 238610 19-04-12 409137 238827 20-04-12 409267 238963 AS Summary 40875 Number of ASes in routing system 17083 Number of ASes announcing only one prefix 3427 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 112041248 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20Apr12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 409399 238997 170402 41.6% All ASes AS6389 3427 198 3229 94.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3409 1784 1625 47.7% WINDSTREAM - Windstream Communications Inc AS4766 2497 1032 1465 58.7% KIXS-AS-KR Korea Telecom AS22773 1576 120 1456 92.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2091 705 1386 66.3% COVAD - Covad Communications Co. AS28573 1785 482 1303 73.0% NET Servicos de Comunicao S.A. AS2118 1304 14 1290 98.9% RELCOM-AS OOO "NPO Relcom" AS4323 1603 383 1220 76.1% TWTC - tw telecom holdings, inc. AS1785 1905 806 1099 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1587 543 1044 65.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS10620 1810 854 956 52.8% Telmex Colombia S.A. AS7552 1170 220 950 81.2% VIETEL-AS-AP Vietel Corporation AS7303 1363 440 923 67.7% Telecom Argentina S.A. AS26615 902 32 870 96.5% Tim Celular S.A. AS8151 1494 668 826 55.3% Uninet S.A. de C.V. AS18101 947 163 784 82.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS17908 826 60 766 92.7% TCISL Tata Communications AS4808 1105 349 756 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 894 197 697 78.0% CRNET CHINA RAILWAY Internet(CRNET) AS17974 1799 1102 697 38.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7545 1677 997 680 40.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS13977 762 125 637 83.6% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS3356 1097 461 636 58.0% LEVEL3 Level 3 Communications AS30036 1412 792 620 43.9% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17676 688 76 612 89.0% GIGAINFRA Softbank BB Corp. AS19262 996 401 595 59.7% VZGNI-TRANSIT - Verizon Online LLC AS22561 989 406 583 58.9% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 1013 437 576 56.9% GBLX Global Crossing Ltd. AS24560 1024 453 571 55.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4780 826 261 565 68.4% SEEDNET Digital United Inc. Total 43978 14561 29417 66.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 91.238.196.0/23 AS24916 ORBITAL-ASN OrbitalNet Ltd 91.238.198.0/24 AS24916 ORBITAL-ASN OrbitalNet Ltd 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 193.0.213.0/24 AS9070 ITD ITD Network Bulgarian ISP 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 201.158.116.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 201.158.117.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 201.158.118.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 201.158.119.0/24 AS28378 TV Rey de Occidente, S.A. de C.V. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From smb at cs.columbia.edu Fri Apr 20 17:37:56 2012 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 20 Apr 2012 18:37:56 -0400 Subject: Host scanning in IPv6 Networks In-Reply-To: <4F910B82.8040505@gont.com.ar> References: <4F910B82.8040505@gont.com.ar> Message-ID: <3DE62AC8-DAFD-44C4-ADDE-F15919EB6D95@cs.columbia.edu> Also see https://www.cs.columbia.edu/~smb/papers/v6worms.pdf (Worm propagation strategies in an IPv6 Internet. ;login:, pages 70-76, February 2006.) On Apr 20, 2012, at 3:08 50AM, Fernando Gont wrote: > FYI > > -------- Original Message -------- > Subject: IPv6 host scanning in IPv6 > Date: Fri, 20 Apr 2012 03:57:48 -0300 > From: Fernando Gont > Organization: SI6 Networks > To: IPv6 Hackers Mailing List > > Folks, > > We've just published an IETF internet-draft about IPv6 host scanning > attacks. > > The aforementioned document is available at: > > > The Abstract of the document is: > ---- cut here ---- > IPv6 offers a much larger address space than that of its IPv4 > counterpart. The standard /64 IPv6 subnets can (in theory) > accommodate approximately 1.844 * 10^19 hosts, thus resulting in a > much lower host density (#hosts/#addresses) than their IPv4 > counterparts. As a result, it is widely assumed that it would take a > tremendous effort to perform host scanning attacks against IPv6 > networks, and therefore IPv6 host scanning attacks have long been > considered unfeasible. This document analyzes the IPv6 address > configuration policies implemented in most popular IPv6 stacks, and > identifies a number of patterns in the resulting addresses lead to a > tremendous reduction in the host address search space, thus > dismantling the myth that IPv6 host scanning attacks are unfeasible. > ---- cut here ---- > > Any comments will be very welcome (note: this is a drafty initial > version, with lots of stuff still to be added... but hopefully a good > starting point, and a nice reading ;-) ). > > Thanks! > > Best regards, > > --Steve Bellovin, https://www.cs.columbia.edu/~smb From mysidia at gmail.com Fri Apr 20 19:22:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 20 Apr 2012 19:22:33 -0500 Subject: Host scanning in IPv6 Networks In-Reply-To: <3DE62AC8-DAFD-44C4-ADDE-F15919EB6D95@cs.columbia.edu> References: <4F910B82.8040505@gont.com.ar> <3DE62AC8-DAFD-44C4-ADDE-F15919EB6D95@cs.columbia.edu> Message-ID: For certain definitions of "host scanning" it is possible to achieve some level of that in IPv6. But massively far less efficient and far more limited than the brute force option that is available in IPv4. The mathematical argument in the draft doesn't really work, because it's too focused on there being "one specific site" that can be scanned. You can't just "pick a random 120 bit number" and have a good chance of that random IP happening to be a live host address. You can't just pick a random /64 and have a good chance of that random /64 happening to be part of a live site. How useful more informed attacks are, remains to be seen. For worm authors it will seem like a lot of sugar for a dime. Malware propagation against open ports doesn't work so well if your nodes can't effect wide scans efficiently. If you are so misguided as to not have a firewall preventing access to vulnerable services. The draft is unconvincing. The expected result is there will be very little preference for scanning, and those that will be launching attacks against networks will be utilizing simpler techniques that are still highly effective and do not require scanning. Such as the exploit of vulnerable HTTP clients who _navigate to the attacker controlled web page_, walking directly into their hands, instead of worms "searching for needles in haystacks". Any worms searching for needles in haystacks are likely to be utilizing a combination of search engines, common dictionary name lookups, and DNS to discover IP addresses of potential target web servers. -- -JH On 4/20/12, Steven Bellovin wrote: > Also see https://www.cs.columbia.edu/~smb/papers/v6worms.pdf > (Worm propagation strategies in an IPv6 Internet. ;login:, > pages 70-76, February 2006.) > > On Apr 20, 2012, at 3:08 50AM, Fernando Gont wrote: > >> FYI >> >> -------- Original Message -------- >> Subject: IPv6 host scanning in IPv6 >> Date: Fri, 20 Apr 2012 03:57:48 -0300 >> From: Fernando Gont >> Organization: SI6 Networks >> To: IPv6 Hackers Mailing List >> >> Folks, >> >> We've just published an IETF internet-draft about IPv6 host scanning >> attacks. >> >> The aforementioned document is available at: >> >> >> The Abstract of the document is: >> ---- cut here ---- >> IPv6 offers a much larger address space than that of its IPv4 >> counterpart. The standard /64 IPv6 subnets can (in theory) >> accommodate approximately 1.844 * 10^19 hosts, thus resulting in a >> much lower host density (#hosts/#addresses) than their IPv4 >> counterparts. As a result, it is widely assumed that it would take a >> tremendous effort to perform host scanning attacks against IPv6 >> networks, and therefore IPv6 host scanning attacks have long been >> considered unfeasible. This document analyzes the IPv6 address >> configuration policies implemented in most popular IPv6 stacks, and >> identifies a number of patterns in the resulting addresses lead to a >> tremendous reduction in the host address search space, thus >> dismantling the myth that IPv6 host scanning attacks are unfeasible. >> ---- cut here ---- >> >> Any comments will be very welcome (note: this is a drafty initial >> version, with lots of stuff still to be added... but hopefully a good >> starting point, and a nice reading ;-) ). >> >> Thanks! >> >> Best regards, >> >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > -- -Mysid From fernando at gont.com.ar Fri Apr 20 19:55:12 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 20 Apr 2012 21:55:12 -0300 Subject: Host scanning in IPv6 Networks In-Reply-To: References: <4F910B82.8040505@gont.com.ar> <3DE62AC8-DAFD-44C4-ADDE-F15919EB6D95@cs.columbia.edu> Message-ID: <4F920570.4000709@gont.com.ar> Hi, Jimmy, On 04/20/2012 09:22 PM, Jimmy Hess wrote: > The mathematical argument in the draft doesn't really work, because > it's too focused on there being "one specific site" that can be > scanned. Not sure what you mean. Clearly, in the IPv6 world you'd target specific networks. How could you know which networks to scan? -- Easy: the attacker is targeting a specific organization, are you gather possible target networks as this information leaks out all too often (e-mail headers, etc.). > You can't just "pick a random 120 bit number" and have a good chance > of that random IP happening to be a live host address. That would be pretty much a "brute force" attack, and the argument in this paper is that IPv6 host-scanning attacks will not be brute force (as we know them). > The draft is unconvincing. The expected result is there will be very > little preference for scanning, and those that will be launching > attacks against networks will be utilizing simpler techniques that > are still highly effective and do not require scanning. Not sure what you mean. Could you please clarify? > Such as the exploit of vulnerable HTTP clients who _navigate to the > attacker controlled web page_, walking directly into their hands, > instead of worms "searching for needles in haystacks". Well, this is part of alternative scanning techniques, which so far are not the subject of this draft. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From me at anuragbhatia.com Sat Apr 21 08:12:55 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 21 Apr 2012 18:42:55 +0530 Subject: Assymetric routing L3/VZ (FIOS) In-Reply-To: <4F91B475.9020706@ai.net> References: <4F91B475.9020706@ai.net> Message-ID: Verizon customer of Level 3? I thought since both are tier 1 providers - they would be exchanging routes in settlement free peering. Curious to know if that is not the case. (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Apr 21, 2012 12:40 AM, "Deepak Jain" wrote: > > Is anyone else seeing this? DC - DFW back to DC? AFAIK, Verizon-GNI is a > customer of L3, so no weird peering issues should be afoot. This adds about > 40ms to the R/T time. The path leaving Verizon-GNI (FIOS) goes (seemingly) > DC-DC and has lower times (<5ms) unidirectionally. > > Tracing the route to pool-173-79-242-218.washdc.**fios.verizon.net(173.79.242.218 ) > > [...] > > 3 ge-6-16.car1.Baltimore1.**Level3.net(4.59.244.85) [AS 65518] 4 msec 0 msec 4 > msec > 4 ae-11-11.car2.Baltimore1.**Level3.net(4.69.134.110) [AS 65518] 0 msec 4 msec 0 > msec > 5 ae-8-8.ebr2.Washington1.**Level3.net(4.69.134.105) [AS 65518] 4 msec 4 msec 4 > msec > 6 ae-72-72.csw2.Washington1.**Level3.net(4.69.134.150) [AS 65518] 4 msec > ae-82-82.csw3.Washington1.**Level3.net(4.69.134.154) [AS 65518] 8 msec 8 msec > 7 ae-61-61.ebr1.Washington1.**Level3.net(4.69.134.129) [AS 65518] 4 msec > ae-91-91.ebr1.Washington1.**Level3.net(4.69.134.141) [AS 65518] 4 msec > ae-71-71.ebr1.Washington1.**Level3.net(4.69.134.133) [AS 65518] 4 msec > 8 ae-2-2.ebr3.Atlanta2.Level3.**net(4.69.132.85) [AS 65518] 16 msec 16 msec 16 > msec > 9 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) [AS 65518] 36 msec 36 > msec 36 m sec > 10 ae-73-73.csw2.Dallas1.Level3.**net(4.69.151.145) [AS 65518] 40 msec > ae-63-63.csw1.Dallas1.Level3.**net(4.69.151.133) [AS 65518] 40 msec 40 msec > 11 ae-4-90.edge2.Dallas3.Level3.**net(4.69.145.204) [AS 65518] 44 msec > ae-3-80.edge2.Dallas3.Level3.**net(4.69.145.140) [AS 65518] 36 msec > ae-1-60.edge2.Dallas3.Level3.**net(4.69.145.12) [AS 65518] 36 msec > 12 MCI-level3-ae.dallas3.level3.**net(4.68.62.34) [AS 65518] 36 msec > mci-level3-30g.dallas3.level3.**net(4.68.62.166) [AS 65518] 36 msec > MCI-level3-ae.dallas3.level3.**net(4.68.62.34) [AS 65518] 36 msec > 13 0.ge-0-0-0.DFW01-BB-RTR1.**verizon-gni.net(152.63.2.146) [AS 65518] 36 msec 3 6 msec > 0.ae2.DFW01-BB-RTR2.verizon-**gni.net(152.63.2.229) [AS 65518] 36 msec > 14 * * * > > > We're opening a ticket with them, but figured NANOG is an often better > place for these resolutions. > > Thanks in advance, > > Deepak Jain > AiNET > Home of CyberNAP > www.ai.net > > From proitrisk at gmail.com Sun Apr 22 01:22:11 2012 From: proitrisk at gmail.com (B Jones) Date: Sat, 21 Apr 2012 23:22:11 -0700 Subject: Security Analyst - Seattle-Tacoma Area Message-ID: Hello all. I'm looking for a systems admin / security analyst. It's a permanent position in the Tacoma - Seattle area; good salary, benefits, management, training, etc... If interested, please respond directly to me? Thanks. C.H. From jvanoppen at spectrumnet.us Sun Apr 22 14:23:20 2012 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Sun, 22 Apr 2012 19:23:20 +0000 Subject: Assymetric routing L3/VZ (FIOS) In-Reply-To: References: <4F91B475.9020706@ai.net>, Message-ID: from Level3's looking glass (it sure looks like l3 is reaching the prefix in this email via AS701 as would be expected): BGP routing table entry for 173.79.0.0/16 Paths: (2 available, best #2) 701 19262 AS-path translation: { ALTERNET VZGNI-TRANSIT } edge2.Dallas3 (metric 3827) Origin IGP, metric 100000, localpref 86, valid, internal Community: North_America Lclprf_86 United_States Level3_Peer Dallas Originator: edge2.Dallas3 701 19262 AS-path translation: { ALTERNET VZGNI-TRANSIT } edge2.Dallas3 (metric 3827) Origin IGP, metric 100000, localpref 86, valid, internal, best Community: North_America Lclprf_86 United_States Level3_Peer Dallas Originator: edge2.Dallas3 John From jrjahangir at gmail.com Sun Apr 22 23:05:41 2012 From: jrjahangir at gmail.com (Md.Jahangir Hossain) Date: Mon, 23 Apr 2012 10:05:41 +0600 Subject: About Juniper MX10 router performance Message-ID: Dear valued member: Wishes all are fine. i need suggestion from you about Juniper MX10 router performance. i want to buy this router for IP Transit provider where i received all global routes . it would be nice please put your valued suggestion about this issue. -- Thanks ---------- Jahangir* * From jof at thejof.com Sun Apr 22 23:18:47 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Sun, 22 Apr 2012 21:18:47 -0700 Subject: About Juniper MX10 router performance In-Reply-To: References: Message-ID: On Sun, Apr 22, 2012 at 9:05 PM, Md.Jahangir Hossain wrote: > Dear valued member: > > > Wishes all are fine. > > > i need ? suggestion from you about Juniper MX10 router performance. i want > to buy ?this router for IP Transit provider where i received ?all global > routes . Do you have some specific questions about it? You should be able to comfortably take in one to two full BGP feeds as RIBs, and hold an Internet-sized FIB. It's basically an MX80 (internally), but with some software modifications to limit its performance. You probably need to make sure that you're also purchasing the S-MX80-ADV-R software license in your base bundle (to support the full-scale L3 routing), but the licensing is based on the honor system. Cheers, jof From joelja at bogus.com Sun Apr 22 23:32:04 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 22 Apr 2012 21:32:04 -0700 Subject: Automatic IPv6 due to broadcast In-Reply-To: <4F8D2BC9.20708@gmail.com> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> Message-ID: <4F94DB44.6030703@bogus.com> On 4/17/12 01:37 , Carlos Martinez-Cagnazzo wrote: > I don't understand why a problem with a tunnel 'leaves a bad taste with > IPv6'. Since when a badly configured DNS zone left people with a 'bad > taste for DNS', or a badly configured switch left people with 'a bad > taste for spanning tree' or 'a bad taste for vlan trunking' ? > > It seems to me that what are perceived as operational mistakes and/or > plain lack of knowledge for some technologies is perceived as a fault of > the protocol itself in the case of IPv6. rogue dhcp servers are sufficiently common that tools had to be developed to address their existence and they're still a nuisance after all that. > People need to get their acts together. indeed. From jrjahangir at gmail.com Sun Apr 22 23:48:14 2012 From: jrjahangir at gmail.com (Md.Jahangir Hossain) Date: Mon, 23 Apr 2012 10:48:14 +0600 Subject: About Juniper MX10 router performance In-Reply-To: References: Message-ID: Thanks jonathan for your reply . Actually i have not specific question , i need suggestion about this product if i purchase this as IP Transit provider. On Mon, Apr 23, 2012 at 10:18 AM, Jonathan Lassoff wrote: > On Sun, Apr 22, 2012 at 9:05 PM, Md.Jahangir Hossain > wrote: > > Dear valued member: > > > > > > Wishes all are fine. > > > > > > i need suggestion from you about Juniper MX10 router performance. i > want > > to buy this router for IP Transit provider where i received all global > > routes . > > Do you have some specific questions about it? You should be able to > comfortably take in one to two full BGP feeds as RIBs, and hold an > Internet-sized FIB. > > It's basically an MX80 (internally), but with some software > modifications to limit its performance. You probably need to make sure > that you're also purchasing the S-MX80-ADV-R software license in your > base bundle (to support the full-scale L3 routing), but the licensing > is based on the honor system. > > Cheers, > jof > -- Thanks ---------- Jahangir* * From jof at thejof.com Sun Apr 22 23:54:37 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Sun, 22 Apr 2012 21:54:37 -0700 Subject: About Juniper MX10 router performance In-Reply-To: References: Message-ID: On Sun, Apr 22, 2012 at 9:48 PM, Md.Jahangir Hossain wrote: > Thanks jonathan for your reply . > > Actually i have not specific question , i need suggestion about this product > if i purchase this? as IP Transit provider. Only someone with the knowledge of your business and requirements can answer this for you. If you'd like to take this up off-list, I'm happy to share what I know. Generally, we try to keep the discussion to the list (that is sent to the many subscribers) on topics that are of interest to all network operators. For Juniper-specific questions, the j-nsp mailing list is pretty great (http://puck.nether.net/mailman/listinfo/juniper-nsp). Cheers, jof From shortdudey123 at gmail.com Sun Apr 22 23:57:28 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 22 Apr 2012 23:57:28 -0500 Subject: Automatic IPv6 due to broadcast In-Reply-To: <4F94DB44.6030703@bogus.com> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> Message-ID: Most switches nowadays have dhcpv4 detection that can be enabled for port ranges. Not sure about v6. -Grant On Sun, Apr 22, 2012 at 11:32 PM, Joel jaeggli wrote: > On 4/17/12 01:37 , Carlos Martinez-Cagnazzo wrote: > > I don't understand why a problem with a tunnel 'leaves a bad taste with > > IPv6'. Since when a badly configured DNS zone left people with a 'bad > > taste for DNS', or a badly configured switch left people with 'a bad > > taste for spanning tree' or 'a bad taste for vlan trunking' ? > > > > It seems to me that what are perceived as operational mistakes and/or > > plain lack of knowledge for some technologies is perceived as a fault of > > the protocol itself in the case of IPv6. > > rogue dhcp servers are sufficiently common that tools had to be > developed to address their existence and they're still a nuisance after > all that. > > > People need to get their acts together. > > indeed. > > From jrjahangir at gmail.com Mon Apr 23 00:12:02 2012 From: jrjahangir at gmail.com (Md.Jahangir Hossain) Date: Mon, 23 Apr 2012 11:12:02 +0600 Subject: About Juniper MX10 router performance In-Reply-To: References: Message-ID: Thanks again Jonathan . On Mon, Apr 23, 2012 at 10:54 AM, Jonathan Lassoff wrote: > On Sun, Apr 22, 2012 at 9:48 PM, Md.Jahangir Hossain > wrote: > > Thanks jonathan for your reply . > > > > Actually i have not specific question , i need suggestion about this > product > > if i purchase this as IP Transit provider. > > Only someone with the knowledge of your business and requirements can > answer this for you. > > If you'd like to take this up off-list, I'm happy to share what I know. > Generally, we try to keep the discussion to the list (that is sent to > the many subscribers) on topics that are of interest to all network > operators. > > For Juniper-specific questions, the j-nsp mailing list is pretty great > (http://puck.nether.net/mailman/listinfo/juniper-nsp). > > Cheers, > jof > -- Thanks ---------- Jahangir* * From mysidia at gmail.com Mon Apr 23 00:30:09 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 23 Apr 2012 00:30:09 -0500 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> Message-ID: On 4/22/12, Grant Ridder wrote: > Most switches nowadays have dhcpv4 detection that can be enabled for port Yes. Many L2 switches have DHCPv4 "Snooping", where some port(s) can be so designated as trusted DHCP server ports, for certain Virtual LANs; and dhcp messages can be detected and suppressed from unauthorized edge ports. Particularly good L2 switches also have DAI or "IP Source guard" IPv4 functions, which when properly enabled, can foil certain L2 ARP and IPv4 source address spoofing attacks, respectively. e.g. Source IP address of packet does not match one of the DHCP leases issued to that port -- then drop the packet. As for IPv6; rfc6105; you have ipv6 nd raguard and IOS NDP inspection. However, there are caveats that should be noted. RA guard implementations can be trivially fooled by the use of crafted packets. These are potentially good protections against accidental configuration errors, but not malicious attack from a general purpose computer. Currently, IPv4 seems to win at L2 easily in regards to the level of hardware security features commonly available on L2 switches that pertain to IP. > -Grant -- -JH From owen at delong.com Mon Apr 23 02:24:53 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Apr 2012 00:24:53 -0700 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> Message-ID: <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: > On 4/22/12, Grant Ridder wrote: > >> Most switches nowadays have dhcpv4 detection that can be enabled for port > > Yes. Many L2 switches have DHCPv4 "Snooping", where some port(s) can > be so designated as trusted DHCP server ports, for certain Virtual > LANs; and dhcp messages can be detected and suppressed from > unauthorized edge ports. Sounds suspiciously like IPv6 RA Guard, no? > Particularly good L2 switches also have > DAI or "IP Source guard" IPv4 functions, which when properly > enabled, can foil certain L2 ARP and IPv4 source address spoofing > attacks, respectively. > > e.g. Source IP address of packet does not match one of the DHCP leases > issued to that port -- then drop the packet. > Meh... I can see many cases where that might be more of a bug than feature. Especially in environments where loops may be possible and the DHCP lease might have come over a different path than the port in question during some network event. > > As for IPv6; rfc6105; you have > ipv6 nd raguard > > and IOS NDP inspection. > > However, there are caveats that should be noted. RA guard > implementations can be trivially fooled by the use of crafted packets. > Frankly, I suggest dropping any RA that doesn't fit in a single packet as a simple solution to the crafted-packet issue. (The crafted packet attacks by and large depend on crafting it so that there are enough extension headers to put the RA header in the second or later fragment). > These are potentially good protections against accidental > configuration errors, but not malicious attack from a general purpose > computer. If you have a malicious attack from a general purpose computer on your own LAN, you've already lost on multiple levels to some extent or other. The most effective solution at that point is to identify, locate, and excise said attacker. > > > Currently, IPv4 seems to win at L2 easily in regards to the level of > hardware security features commonly available on L2 switches that > pertain to IP. > There was a time when one probably could have argued that Novell beat IP on that basis alone. IPv4 loses when you consider that there are more than 3.2 billion people in the world. That people likely will need a minimum of 5 IP addresses each. That we also need to number infrastructure, routers, servers, sensor grids, etc. IPv4 also loses when you consider the pervasiveness of debilitated IPv4 internetworking in favor of address conservation over the last 20 years. Owen > > >> -Grant > -- > -JH From eric at roxanne.org Mon Apr 23 07:40:03 2012 From: eric at roxanne.org (Eric) Date: Mon, 23 Apr 2012 08:40:03 -0400 Subject: Securing OOB Message-ID: Hello, It seems that the current practice is to use a DSL line, as opposed to a modem, for accessing an OOB a console server at a remote colo. From a security standpoint, what do people generally do - trust the console server, repurpose an old linksys box from my house or put in a full firewall? Eric :) From leigh.porter at ukbroadband.com Mon Apr 23 07:45:01 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 23 Apr 2012 12:45:01 +0000 Subject: Securing OOB In-Reply-To: References: Message-ID: <0C22BF8A-8D00-4DE1-9733-D5746BC0FF60@ukbroadband.com> I have juniper SRX110s that use the magic new multi site IPSec thing. -- Leigh Porter On 23 Apr 2012, at 13:43, "Eric" wrote: > Hello, > > It seems that the current practice is to use a DSL line, as opposed to a modem, for accessing an OOB a console server at a remote colo. From a security standpoint, what do people generally do - trust the console server, repurpose an old linksys box from my house or put in a full firewall? > > Eric :) > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From lathama at gmail.com Mon Apr 23 07:46:15 2012 From: lathama at gmail.com (Andrew Latham) Date: Mon, 23 Apr 2012 08:46:15 -0400 Subject: Securing OOB In-Reply-To: References: Message-ID: On Mon, Apr 23, 2012 at 8:40 AM, Eric wrote: > Hello, > > It seems that the current practice is to use a DSL line, as opposed to a modem, for accessing an OOB a console server at a remote colo. ?From a security standpoint, what do people generally do - trust the console server, repurpose an old linksys box from my house or put in a full firewall? > > Eric :) There are hardware solutions for this type of install. Often it is best to add/create networks for access from multiple points at once. My suggestion is http://www.lantronix.com/it-management/branch-office/securelinx-slb.html -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From blairs at isc.upenn.edu Mon Apr 23 07:58:16 2012 From: blairs at isc.upenn.edu (Steven C. Blair) Date: Mon, 23 Apr 2012 12:58:16 +0000 Subject: Securing OOB In-Reply-To: References: Message-ID: Thanks for starting this discussion Eric. We're just starting to look at upgrading our oob console network and wondering how to provide access from LAN based application monitoring platforms. We're currently looking at installing a VPN appliance between our production network and the "oob network". -Steve -----Original Message----- From: Eric [mailto:eric at roxanne.org] Sent: Monday, April 23, 2012 8:40 AM To: nanog at nanog.org Subject: Securing OOB Hello, It seems that the current practice is to use a DSL line, as opposed to a modem, for accessing an OOB a console server at a remote colo. From a security standpoint, what do people generally do - trust the console server, repurpose an old linksys box from my house or put in a full firewall? Eric :) From cra at WPI.EDU Mon Apr 23 08:25:25 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 23 Apr 2012 09:25:25 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> Message-ID: <20120423132525.GA27538@angus.ind.WPI.EDU> On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: > On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: > > Particularly good L2 switches also have > > DAI or "IP Source guard" IPv4 functions, which when properly > > enabled, can foil certain L2 ARP and IPv4 source address spoofing > > attacks, respectively. > > > > > e.g. Source IP address of packet does not match one of the DHCP leases > > issued to that port -- then drop the packet. > > > > Meh... I can see many cases where that might be more of a bug than feature. > > Especially in environments where loops may be possible and the DHCP lease might > have come over a different path than the port in question during some network event. You're only supposed to use those features on the port directly connected to the end-system, or to a few end-systems via an unmanaged office switch that doesn't have redundant uplinks. I.e. edge ports. From saku at ytti.fi Mon Apr 23 08:31:11 2012 From: saku at ytti.fi (Saku Ytti) Date: Mon, 23 Apr 2012 16:31:11 +0300 Subject: Securing OOB In-Reply-To: <0C22BF8A-8D00-4DE1-9733-D5746BC0FF60@ukbroadband.com> References: <0C22BF8A-8D00-4DE1-9733-D5746BC0FF60@ukbroadband.com> Message-ID: <20120423133111.GA18884@pob.ytti.fi> On (2012-04-23 12:45 +0000), Leigh Porter wrote: > I have juniper SRX110s that use the magic new multi site IPSec thing. +1. This is the way to roll OOB, CPE (Cisco ISR, Juniper SRX), RS232 console server (opengear, avocent) and switch if you happen to have modern gear which support proper OOB like Nexus7k, and not enough ports in the CPE. OOB CPE could be reused for other functions to justify cost, like DCN router, both SRX and ISR have models doing CLNS routing. With correct CPE, same CPE can do 3G, ADSL and ethernet, depending on what is available in given site. Some RS232 console servers do deliver subset of needed features, like 3G, IPSEC and Ethernet might be there. But that does not mean that it'll be OPEX nor CAPEX chaper to try to do it all in one box. -- ++ytti From owen at delong.com Mon Apr 23 08:38:09 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Apr 2012 06:38:09 -0700 Subject: Automatic IPv6 due to broadcast In-Reply-To: <20120423132525.GA27538@angus.ind.WPI.EDU> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> <20120423132525.GA27538@angus.ind.WPI.EDU> Message-ID: On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote: > On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: >> On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: >>> Particularly good L2 switches also have >>> DAI or "IP Source guard" IPv4 functions, which when properly >>> enabled, can foil certain L2 ARP and IPv4 source address spoofing >>> attacks, respectively. >>> >> >>> e.g. Source IP address of packet does not match one of the DHCP leases >>> issued to that port -- then drop the packet. >>> >> >> Meh... I can see many cases where that might be more of a bug than feature. >> >> Especially in environments where loops may be possible and the DHCP lease might >> have come over a different path than the port in question during some network event. > > You're only supposed to use those features on the port directly > connected to the end-system, or to a few end-systems via an unmanaged > office switch that doesn't have redundant uplinks. I.e. edge ports. In a lot of cases, enforcing that all address assignments are via DHCP can still be counter-productive. Especially in IPv6. Owen From paul4004 at gmail.com Mon Apr 23 09:14:28 2012 From: paul4004 at gmail.com (PC) Date: Mon, 23 Apr 2012 08:14:28 -0600 Subject: Securing OOB In-Reply-To: <20120423133111.GA18884@pob.ytti.fi> References: <0C22BF8A-8D00-4DE1-9733-D5746BC0FF60@ukbroadband.com> <20120423133111.GA18884@pob.ytti.fi> Message-ID: My preferred OOB solution is cellular where possible. (Many companies make such a dedicated product, or roll your own). Most cellular providers can provide a private APN with private IP addresses delivered back to you via a VPN tunnel. In many cases, telemetry (IE: 50Mb or less per month) data plans cost much less than DSL lines or analog lines. In some installations, it's also diverse to backhoe accidents due to it not riding the same copper bundle. Besides, it's easy to install and you don't have to deal with the copper analog handoff. Otherwise... DSL and IPSEC vpn also works. Analog is in the last option for me. On Mon, Apr 23, 2012 at 7:31 AM, Saku Ytti wrote: > On (2012-04-23 12:45 +0000), Leigh Porter wrote: > > > I have juniper SRX110s that use the magic new multi site IPSec thing. > > +1. This is the way to roll OOB, CPE (Cisco ISR, Juniper SRX), RS232 > console server (opengear, avocent) and switch if you happen to have modern > gear which support proper OOB like Nexus7k, and not enough ports in the > CPE. > OOB CPE could be reused for other functions to justify cost, like DCN > router, both SRX and ISR have models doing CLNS routing. > > With correct CPE, same CPE can do 3G, ADSL and ethernet, depending on what > is available in given site. > Some RS232 console servers do deliver subset of needed features, like 3G, > IPSEC and Ethernet might be there. But that does not mean that it'll be > OPEX nor CAPEX chaper to try to do it all in one box. > > -- > ++ytti > > From cra at WPI.EDU Mon Apr 23 10:23:14 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 23 Apr 2012 11:23:14 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> <20120423132525.GA27538@angus.ind.WPI.EDU> Message-ID: <20120423152314.GI23416@angus.ind.WPI.EDU> On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: > > On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote: > > > On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: > >> On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: > >>> Particularly good L2 switches also have > >>> DAI or "IP Source guard" IPv4 functions, which when properly > >>> enabled, can foil certain L2 ARP and IPv4 source address spoofing > >>> attacks, respectively. > >>> > >> > >>> e.g. Source IP address of packet does not match one of the DHCP leases > >>> issued to that port -- then drop the packet. > >>> > >> > >> Meh... I can see many cases where that might be more of a bug than feature. > >> > >> Especially in environments where loops may be possible and the DHCP lease might > >> have come over a different path than the port in question during some network event. > > > > You're only supposed to use those features on the port directly > > connected to the end-system, or to a few end-systems via an unmanaged > > office switch that doesn't have redundant uplinks. I.e. edge ports. > > In a lot of cases, enforcing that all address assignments are via DHCP can still be > counter-productive. Especially in IPv6. If a specific managed environment provides DHCPv6 and doesn't provide SLAAC, and the policies of said environment forbid static addressing, how can enforcing the use of DHCPv6 be counter-productive? From owen at delong.com Mon Apr 23 11:03:25 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 23 Apr 2012 09:03:25 -0700 Subject: Automatic IPv6 due to broadcast In-Reply-To: <20120423152314.GI23416@angus.ind.WPI.EDU> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> <20120423132525.GA27538@angus.ind.WPI.EDU> <20120423152314.GI23416@angus.ind.WPI.EDU> Message-ID: <3675034D-1523-4EDC-AB66-813A45CEC8F0@delong.com> On Apr 23, 2012, at 8:23 AM, Chuck Anderson wrote: > On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: >> >> On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote: >> >>> On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: >>>> On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: >>>>> Particularly good L2 switches also have >>>>> DAI or "IP Source guard" IPv4 functions, which when properly >>>>> enabled, can foil certain L2 ARP and IPv4 source address spoofing >>>>> attacks, respectively. >>>>> >>>> >>>>> e.g. Source IP address of packet does not match one of the DHCP leases >>>>> issued to that port -- then drop the packet. >>>>> >>>> >>>> Meh... I can see many cases where that might be more of a bug than feature. >>>> >>>> Especially in environments where loops may be possible and the DHCP lease might >>>> have come over a different path than the port in question during some network event. >>> >>> You're only supposed to use those features on the port directly >>> connected to the end-system, or to a few end-systems via an unmanaged >>> office switch that doesn't have redundant uplinks. I.e. edge ports. >> >> In a lot of cases, enforcing that all address assignments are via DHCP can still be >> counter-productive. Especially in IPv6. > > If a specific managed environment provides DHCPv6 and doesn't provide > SLAAC, and the policies of said environment forbid static addressing, > how can enforcing the use of DHCPv6 be counter-productive? That's a lot of ifs. I said in a lot of cases. I didn't say in all cases. If you satisfy all of your ifs, then it's not one of the cases of which I speak. Owen From Valdis.Kletnieks at vt.edu Mon Apr 23 11:27:53 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 23 Apr 2012 12:27:53 -0400 Subject: Automatic IPv6 due to broadcast In-Reply-To: Your message of "Mon, 23 Apr 2012 11:23:14 -0400." <20120423152314.GI23416@angus.ind.WPI.EDU> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> <20120423132525.GA27538@angus.ind.WPI.EDU> <20120423152314.GI23416@angus.ind.WPI.EDU> Message-ID: <4925.1335198473@turing-police.cc.vt.edu> On Mon, 23 Apr 2012 11:23:14 -0400, Chuck Anderson said: > > On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: >> In a lot of cases, enforcing that all address assignments are via DHCP can still be >> counter-productive. Especially in IPv6. > If a specific managed environment provides DHCPv6 and doesn't provide > SLAAC, and the policies of said environment forbid static addressing, That's totally different from Owen's "in a lot of cases". Incidentally, there's absolutely nothing preventing a DHCPv* server from being configured to always hand out the same IP address to a given MAC address, making it effectively static (in fact, I've seen more than one site that carries nailed down DHCP entries for servers, just to ensure that even if the server gets borked and decides to DHCP itself, it will still come up with the "right" address anyhow). > how can enforcing the use of DHCPv6 be counter-productive? Remember, Owen was talking about "in a lot of cases". I suspect Owen was saying that if you enforce that all source addresses are ones that the DHCPv6 server handed out, you just broke a host that tries to do RFC4941 addresses or other similar things. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From erey at ernw.de Mon Apr 23 11:49:15 2012 From: erey at ernw.de (Enno Rey) Date: Mon, 23 Apr 2012 18:49:15 +0200 Subject: Automatic IPv6 due to broadcast In-Reply-To: <4925.1335198473@turing-police.cc.vt.edu> References: <20120416173807.15be4390@Perona.wlmsprt.pa.neltia.net> <4F8D2BC9.20708@gmail.com> <4F94DB44.6030703@bogus.com> <432EAB18-387A-4EC3-8901-49A990FFAC7A@delong.com> <20120423132525.GA27538@angus.ind.WPI.EDU> <20120423152314.GI23416@angus.ind.WPI.EDU> <4925.1335198473@turing-police.cc.vt.edu> Message-ID: <20120423164915.GA54598@ernw.de> Hi, On Mon, Apr 23, 2012 at 12:27:53PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 23 Apr 2012 11:23:14 -0400, Chuck Anderson said: > > > On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: > >> In a lot of cases, enforcing that all address assignments are via DHCP can still be > >> counter-productive. Especially in IPv6. > > If a specific managed environment provides DHCPv6 and doesn't provide > > SLAAC, and the policies of said environment forbid static addressing, > > That's totally different from Owen's "in a lot of cases". Incidentally, > there's absolutely nothing except for LLT being the default DUID generation mechanism on pretty much every OS... thanks Enno preventing a DHCPv* server from being configured to > always hand out the same IP address to a given MAC address, making it > effectively static (in fact, I've seen more than one site that carries nailed down > DHCP entries for servers, just to ensure that even if the server gets borked and > decides to DHCP itself, it will still come up with the "right" address anyhow). > > > how can enforcing the use of DHCPv6 be counter-productive? > > Remember, Owen was talking about "in a lot of cases". I suspect Owen was saying > that if you enforce that all source addresses are ones that the DHCPv6 server > handed out, you just broke a host that tries to do RFC4941 addresses or other > similar things. > -- Enno Rey ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de ======================================================= From fernando at gont.com.ar Tue Apr 24 05:20:31 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 24 Apr 2012 07:20:31 -0300 Subject: New IETF I-D: Security Implications of IPv6 on IPv4 networks Message-ID: <4F967E6F.10209@gont.com.ar> Folks, We've published a new IETF I-D entitled "Security Implications of IPv6 on IPv4 networks". The I-D is available at: The Abstract of the I-D is: ---- cut here ---- This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. ---- cut here ---- Any feedback will be very welcome. Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ganbold at gmail.com Tue Apr 24 05:50:04 2012 From: ganbold at gmail.com (Ganbold Tsagaankhuu) Date: Tue, 24 Apr 2012 18:50:04 +0800 Subject: risk bearing/calculation for security service provider Message-ID: Hi, I have some questions related to the security service that security SP offers. Is it common for SP to include risk related calculation into the security service (in contract/SLA) they offer? The question or problem might arise when some incident happened even the customer got secure hosting service from security SP. The customer might complain that SP doesn't protect them well and ask for some penalty in this case. So how does SP protect themselves in this case? Is there any best practice for that? thanks a lot, Ganbold From eric at ericheather.com Tue Apr 24 08:22:00 2012 From: eric at ericheather.com (Eric C. Miller) Date: Tue, 24 Apr 2012 13:22:00 +0000 Subject: Partial Outage with TW Telecom and CenturyLink Message-ID: Morning Everyone, Yesterday between about 1900 and 2230 UTC, we had a partial drop with reaching various sites through TW Telecom from our circuit in Orlando, FL. The unavailable sites included Facebook, Newegg, and Godaddy. The outage did not affect our Atlanta TW Telecom. I confered with a colleague who manages a large customer in Apopka who said that they appeared not to be affected. His circuit and ours loop to the same TW Telecom POP. But even more Murphy than that, our Centurylink secondary circuit was having a routing loop issue at the same time, so while our BGP routes were being advertised to world through Centurylink, the circuit was useless. Centurylink aknowledged the existence of a bigger transport issue and said that we weren't the only customer affected. Anybody else notice these issues or have any other insight? Thanks! Eric Miller From oscar.vives at gmail.com Tue Apr 24 09:20:10 2012 From: oscar.vives at gmail.com (Tei) Date: Tue, 24 Apr 2012 16:20:10 +0200 Subject: Host scanning in IPv6 Networks In-Reply-To: <0A949077-BC84-4CF7-B20B-53CED70C32E6@delong.com> References: <4F910B82.8040505@gont.com.ar> <4F917199.8040400@netwolves.com> <0A949077-BC84-4CF7-B20B-53CED70C32E6@delong.com> Message-ID: On 20 April 2012 17:16, Owen DeLong wrote: >>> >> exec ? >> exceed ? >> > > Not a lot of x's in hexidecimal numbers outside of C-style formatting (0xnnnn). > > IPv6 addresses are not generally notated in said style and certainly don't include said x in a suitable context for that to be part of a dictionary attack. > > However, he also left out the common use of 7(t), 6/9(g), 1/7(I/L/T), 2(Z), 5(S), and 0(O). > > c is also often substituted for k (as in face:b00c). > > Owen > Sorry. I did a quick filter of the openoffice dictionary file. seems that I made a ugly mistake :-/ postdata: I have made a [0-9] to [aeioutnshrdlcmwf] conversor. http://jsbin.com/ibepup/ This convert a decimal number into a "hexadecimal" number not using the [0-9A-F] table, but the [aeioutnshrdlcmwf] table. The aeioutnshrdlcmwf table may allow a big number of numbers have a existing word of expression. postdata2: Using this conversor, 123442553445523 is the word NaouuScuch. -- -- ?in del ?ensaje. From chris at uplogon.com Tue Apr 24 11:14:08 2012 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 24 Apr 2012 11:14:08 -0500 Subject: Partial Outage with TW Telecom and CenturyLink In-Reply-To: References: Message-ID: <4F96D150.60801@uplogon.com> CenturyLink is reporting core routing issues at this time. Seeing the same issues with our DS-3, BGP stayed up, but traffic was not passing over the line. Had to manually shutdown the interface to get traffic flowing over our other providers link. What a mess. On 4/24/2012 8:22 AM, Eric C. Miller wrote: > Morning Everyone, > > > > Yesterday between about 1900 and 2230 UTC, we had a partial drop with reaching various sites through TW Telecom from our circuit in Orlando, FL. The unavailable sites included Facebook, Newegg, and Godaddy. The outage did not affect our Atlanta TW Telecom. I confered with a colleague who manages a large customer in Apopka who said that they appeared not to be affected. His circuit and ours loop to the same TW Telecom POP. > > > > But even more Murphy than that, our Centurylink secondary circuit was having a routing loop issue at the same time, so while our BGP routes were being advertised to world through Centurylink, the circuit was useless. Centurylink aknowledged the existence of a bigger transport issue and said that we weren't the only customer affected. > > > > Anybody else notice these issues or have any other insight? > > > > Thanks! > > > > Eric Miller -- ---- ---- ---- ---- Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. http://uplogon.com | +1 906 774 4847 | chris at uplogon.com From morrowc.lists at gmail.com Tue Apr 24 11:28:45 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Apr 2012 12:28:45 -0400 Subject: Partial Outage with TW Telecom and CenturyLink In-Reply-To: <4F96D150.60801@uplogon.com> References: <4F96D150.60801@uplogon.com> Message-ID: this belongs on outages@ no? On Tue, Apr 24, 2012 at 12:14 PM, Chris Gotstein wrote: > CenturyLink is reporting core routing issues at this time. ?Seeing the same > issues with our DS-3, BGP stayed up, but traffic was not passing over the > line. ?Had to manually shutdown the interface to get traffic flowing over > our other providers link. ?What a mess. > > > On 4/24/2012 8:22 AM, Eric C. Miller wrote: >> >> Morning Everyone, >> >> >> >> Yesterday between about 1900 and 2230 UTC, we had a partial drop with >> reaching various sites through TW Telecom from our circuit in Orlando, FL. >> The unavailable sites included Facebook, Newegg, and Godaddy. The outage did >> not affect our Atlanta TW Telecom. I confered with a colleague who manages a >> large customer in Apopka who said that they appeared not to be affected. His >> circuit and ours loop to the same TW Telecom POP. >> >> >> >> But even more Murphy than that, our Centurylink secondary circuit was >> having a routing loop issue at the same time, so while our BGP routes were >> being advertised to world through Centurylink, the circuit was useless. >> Centurylink aknowledged the existence of a bigger transport issue and said >> that we weren't the only customer affected. >> >> >> >> Anybody else notice these issues or have any other insight? >> >> >> >> Thanks! >> >> >> >> Eric Miller > > > -- > ---- ---- ---- ---- > Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com > From davidpeahi at gmail.com Tue Apr 24 11:35:34 2012 From: davidpeahi at gmail.com (david peahi) Date: Tue, 24 Apr 2012 09:35:34 -0700 Subject: Partial Outage with TW Telecom and CenturyLink In-Reply-To: References: Message-ID: Yesterday at about 3 pm PDT DNS resolution problems were experienced through Centurylink. Apparently their Phoenix DNS servers were unreachable for some time. These types of incidents never happened with Qwest. Anyone else report a service degradation since Centurylink took over? On Tue, Apr 24, 2012 at 6:22 AM, Eric C. Miller wrote: > Morning Everyone, > > > > Yesterday between about 1900 and 2230 UTC, we had a partial drop with > reaching various sites through TW Telecom from our circuit in Orlando, FL. > The unavailable sites included Facebook, Newegg, and Godaddy. The outage > did not affect our Atlanta TW Telecom. I confered with a colleague who > manages a large customer in Apopka who said that they appeared not to be > affected. His circuit and ours loop to the same TW Telecom POP. > > > > But even more Murphy than that, our Centurylink secondary circuit was > having a routing loop issue at the same time, so while our BGP routes were > being advertised to world through Centurylink, the circuit was useless. > Centurylink aknowledged the existence of a bigger transport issue and said > that we weren't the only customer affected. > > > > Anybody else notice these issues or have any other insight? > > > > Thanks! > > > > Eric Miller > From chris at uplogon.com Tue Apr 24 11:36:26 2012 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 24 Apr 2012 11:36:26 -0500 Subject: Partial Outage with TW Telecom and CenturyLink In-Reply-To: References: <4F96D150.60801@uplogon.com> Message-ID: <4F96D68A.8090808@uplogon.com> Already on outages. On 4/24/2012 11:28 AM, Christopher Morrow wrote: > this belongs on outages@ no? > > On Tue, Apr 24, 2012 at 12:14 PM, Chris Gotstein wrote: >> CenturyLink is reporting core routing issues at this time. Seeing the same >> issues with our DS-3, BGP stayed up, but traffic was not passing over the >> line. Had to manually shutdown the interface to get traffic flowing over >> our other providers link. What a mess. >> >> >> On 4/24/2012 8:22 AM, Eric C. Miller wrote: >>> >>> Morning Everyone, >>> >>> >>> >>> Yesterday between about 1900 and 2230 UTC, we had a partial drop with >>> reaching various sites through TW Telecom from our circuit in Orlando, FL. >>> The unavailable sites included Facebook, Newegg, and Godaddy. The outage did >>> not affect our Atlanta TW Telecom. I confered with a colleague who manages a >>> large customer in Apopka who said that they appeared not to be affected. His >>> circuit and ours loop to the same TW Telecom POP. >>> >>> >>> >>> But even more Murphy than that, our Centurylink secondary circuit was >>> having a routing loop issue at the same time, so while our BGP routes were >>> being advertised to world through Centurylink, the circuit was useless. >>> Centurylink aknowledged the existence of a bigger transport issue and said >>> that we weren't the only customer affected. >>> >>> >>> >>> Anybody else notice these issues or have any other insight? >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Eric Miller >> >> >> -- >> ---- ---- ---- ---- >> Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. >> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com >> -- ---- ---- ---- ---- Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. http://uplogon.com | +1 906 774 4847 | chris at uplogon.com From bret at getjive.com Tue Apr 24 11:37:04 2012 From: bret at getjive.com (Bret Palsson) Date: Tue, 24 Apr 2012 10:37:04 -0600 Subject: Partial Outage with TW Telecom and CenturyLink In-Reply-To: References: Message-ID: We have a ticket open with Level3. Our customers on the the west coast using CenturyLink are not receiving traffic. -Bret On Apr 24, 2012, at 10:35 AM, david peahi wrote: > Yesterday at about 3 pm PDT DNS resolution problems were experienced > through Centurylink. Apparently their Phoenix DNS servers were unreachable > for some time. These types of incidents never happened with Qwest. Anyone > else report a service degradation since Centurylink took over? > > On Tue, Apr 24, 2012 at 6:22 AM, Eric C. Miller wrote: > >> Morning Everyone, >> >> >> >> Yesterday between about 1900 and 2230 UTC, we had a partial drop with >> reaching various sites through TW Telecom from our circuit in Orlando, FL. >> The unavailable sites included Facebook, Newegg, and Godaddy. The outage >> did not affect our Atlanta TW Telecom. I confered with a colleague who >> manages a large customer in Apopka who said that they appeared not to be >> affected. His circuit and ours loop to the same TW Telecom POP. >> >> >> >> But even more Murphy than that, our Centurylink secondary circuit was >> having a routing loop issue at the same time, so while our BGP routes were >> being advertised to world through Centurylink, the circuit was useless. >> Centurylink aknowledged the existence of a bigger transport issue and said >> that we weren't the only customer affected. >> >> >> >> Anybody else notice these issues or have any other insight? >> >> >> >> Thanks! >> >> >> >> Eric Miller >> From bret at getjive.com Tue Apr 24 11:37:24 2012 From: bret at getjive.com (Bret Palsson) Date: Tue, 24 Apr 2012 10:37:24 -0600 Subject: Partial Outage with TW Telecom and CenturyLink In-Reply-To: <4F96D68A.8090808@uplogon.com> References: <4F96D150.60801@uplogon.com> <4F96D68A.8090808@uplogon.com> Message-ID: <920C5FDF-51CE-4F45-BF37-EA55EB43A5AA@getjive.com> Where is this outages list? On Apr 24, 2012, at 10:36 AM, Chris Gotstein wrote: > Already on outages. > > On 4/24/2012 11:28 AM, Christopher Morrow wrote: >> this belongs on outages@ no? >> >> On Tue, Apr 24, 2012 at 12:14 PM, Chris Gotstein wrote: >>> CenturyLink is reporting core routing issues at this time. Seeing the same >>> issues with our DS-3, BGP stayed up, but traffic was not passing over the >>> line. Had to manually shutdown the interface to get traffic flowing over >>> our other providers link. What a mess. >>> >>> >>> On 4/24/2012 8:22 AM, Eric C. Miller wrote: >>>> >>>> Morning Everyone, >>>> >>>> >>>> >>>> Yesterday between about 1900 and 2230 UTC, we had a partial drop with >>>> reaching various sites through TW Telecom from our circuit in Orlando, FL. >>>> The unavailable sites included Facebook, Newegg, and Godaddy. The outage did >>>> not affect our Atlanta TW Telecom. I confered with a colleague who manages a >>>> large customer in Apopka who said that they appeared not to be affected. His >>>> circuit and ours loop to the same TW Telecom POP. >>>> >>>> >>>> >>>> But even more Murphy than that, our Centurylink secondary circuit was >>>> having a routing loop issue at the same time, so while our BGP routes were >>>> being advertised to world through Centurylink, the circuit was useless. >>>> Centurylink aknowledged the existence of a bigger transport issue and said >>>> that we weren't the only customer affected. >>>> >>>> >>>> >>>> Anybody else notice these issues or have any other insight? >>>> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> Eric Miller >>> >>> >>> -- >>> ---- ---- ---- ---- >>> Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. >>> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com >>> > > -- > ---- ---- ---- ---- > Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com > From sethm at rollernet.us Tue Apr 24 11:39:13 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 24 Apr 2012 09:39:13 -0700 Subject: Partial Outage with TW Telecom and CenturyLink In-Reply-To: <920C5FDF-51CE-4F45-BF37-EA55EB43A5AA@getjive.com> References: <4F96D150.60801@uplogon.com> <4F96D68A.8090808@uplogon.com> <920C5FDF-51CE-4F45-BF37-EA55EB43A5AA@getjive.com> Message-ID: <4F96D731.9060906@rollernet.us> On 4/24/12 9:37 AM, Bret Palsson wrote: > Where is this outages list? https://puck.nether.net/mailman/listinfo/outages ~Seth From gih at apnic.net Tue Apr 24 11:41:17 2012 From: gih at apnic.net (Geoff Huston) Date: Wed, 25 Apr 2012 02:41:17 +1000 Subject: IPv6 dark traffic collection restarted Message-ID: <70E361BF-D593-48AE-822B-CC6466114B28@apnic.net> Hi, In 2010, and again in 2011, I ran an experiment to examine the "dark" traffic in IPv6. I did this by announcing the "superblock" 2400::/12 which has been allocated to APNIC for its IPv6 allocations. The superblock announcement is an aggregate and will not disrupt any IPv6 traffic - the packets that will head to this dark traffic collector were on their way to /dev/null in any case. We are about to run this experiment up again to collect a 2012 data profile for IPv6 dark traffic in 2012. Accordingly, 2400::/12 will be announced by AS3562 - please don't filter it! IPv6 packets are scarce enough already! :-) This time around we are being assisted by Sandia National Laboratories and ESnet, for which APNIC would like to acknowledge their assistance in this ongoing research activity. Some URLs: - ESnet news item is at: http://www.es.net/services/ipv6-network/esnet-supports-sandia-and-apnic-ipv6-background-radiation-research/ - LOA for the announcement: http://www.sandia.gov/apnic/authorization.pdf - Previous re[port: http://www.potaroo.net/ispcol/2010-07/dark6.pdf thanks, Geoff From marshall.eubanks at gmail.com Tue Apr 24 12:06:33 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Tue, 24 Apr 2012 13:06:33 -0400 Subject: IPv6 dark traffic collection restarted In-Reply-To: <70E361BF-D593-48AE-822B-CC6466114B28@apnic.net> References: <70E361BF-D593-48AE-822B-CC6466114B28@apnic.net> Message-ID: Dear Geoff; On Tue, Apr 24, 2012 at 12:41 PM, Geoff Huston wrote: > Hi, > > In 2010, and again in 2011, I ran an experiment to examine the "dark" traffic in IPv6. I did this by announcing the "superblock" 2400::/12 which has been allocated to APNIC for its IPv6 allocations. The superblock announcement is an aggregate and will not disrupt any IPv6 traffic - the packets that will head to this dark traffic collector were on their way to /dev/null in any case. > > We are about to run this experiment up again to collect a 2012 data profile for IPv6 dark traffic in 2012. Accordingly, 2400::/12 will be announced by AS3562 - please don't filter it! IPv6 packets are scarce enough already! :-) > As the IPv6 UDP Checksum relaxation effort gets instantiated (the draft http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-02 is now in WGLC), could you look at the existence (or lack thereof) of UDP checksums in IPV6 ? It would be good to have some baseline data to see, if these become a problem in the future, what the state was before they were adopted. Regards Marshall > This time around we are being assisted by Sandia National Laboratories and ESnet, for which APNIC would like to acknowledge their assistance in this ongoing research activity. > > Some URLs: > ?- ESnet news item is at: http://www.es.net/services/ipv6-network/esnet-supports-sandia-and-apnic-ipv6-background-radiation-research/ > ?- LOA for the announcement: http://www.sandia.gov/apnic/authorization.pdf > ?- Previous re[port: http://www.potaroo.net/ispcol/2010-07/dark6.pdf > > thanks, > > ? Geoff > > From admin at thecpaneladmin.com Tue Apr 24 12:32:17 2012 From: admin at thecpaneladmin.com (admin at thecpaneladmin.com) Date: Tue, 24 Apr 2012 13:32:17 -0400 Subject: Squeezing IPs out of ARIN Message-ID: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Anyone have any tips for getting IPs from ARIN? For an end-user allocation they are requesting that we provide customer names for existing allocations, which is information that will take a while to obtain. They are insisting that this is standard process and something that everyone does when requesting IPs. Has anyone actually had to do this? From jof at thejof.com Tue Apr 24 12:47:16 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 24 Apr 2012 10:47:16 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: On Tue, Apr 24, 2012 at 10:32 AM, wrote: > Anyone have any tips for getting IPs from ARIN? For an end-user allocation > they are requesting that we provide customer names for existing allocations, > which is information that will take a while to obtain. They are insisting > that this is standard process and something that everyone does when > requesting IPs. ?Has anyone actually had to do this? Indeed. It's worked this way for a long time. When starting a new organization, there's a bit of a chicken and egg problem with IP space. If anyone could get IP space just for asking for it, it would have been consumed too quickly. So, organizations must first get some space assigned to them from an upstream provider and begin using it. At some point the current usage and growth rate of the assigned space will justify a direct allocation. Then, you can renumber into your new space and be totally independent. Cheers, jof From streiner at cluebyfour.org Tue Apr 24 13:12:06 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 24 Apr 2012 14:12:06 -0400 (EDT) Subject: Squeezing IPs out of ARIN In-Reply-To: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: On Tue, 24 Apr 2012, admin at thecpaneladmin.com wrote: > Anyone have any tips for getting IPs from ARIN? For an end-user allocation > they are requesting that we provide customer names for existing allocations, > which is information that will take a while to obtain. They are insisting > that this is standard process and something that everyone does when > requesting IPs. Has anyone actually had to do this? Now that we're getting down to the bottom of the IPv4 barrel, the amount of documentation and justification needed to get v4 addresses from the RIRs has increased. Expect any v4 requests to be scrutinized closely. This is not news, and at this point, it should not come as a surprise to anyone. IPv6 address blocks are pretty easy to get ;) jms From owen at delong.com Tue Apr 24 13:14:29 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Apr 2012 11:14:29 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: On Apr 24, 2012, at 10:47 AM, Jonathan Lassoff wrote: > On Tue, Apr 24, 2012 at 10:32 AM, wrote: >> Anyone have any tips for getting IPs from ARIN? For an end-user allocation >> they are requesting that we provide customer names for existing allocations, >> which is information that will take a while to obtain. They are insisting >> that this is standard process and something that everyone does when >> requesting IPs. Has anyone actually had to do this? > > Indeed. It's worked this way for a long time. > > When starting a new organization, there's a bit of a chicken and egg > problem with IP space. If anyone could get IP space just for asking > for it, it would have been consumed too quickly. So, organizations > must first get some space assigned to them from an upstream provider > and begin using it. > At some point the current usage and growth rate of the assigned space > will justify a direct allocation. > > Then, you can renumber into your new space and be totally independent. > > Cheers, > jof That's not entirely true. What you say applies to one possible way for an ISP to get an allocation. It does not apply at all to end-users. Owen From jlewis at lewis.org Tue Apr 24 13:24:15 2012 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 24 Apr 2012 14:24:15 -0400 (EDT) Subject: Squeezing IPs out of ARIN In-Reply-To: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: On Tue, 24 Apr 2012 admin at thecpaneladmin.com wrote: > Anyone have any tips for getting IPs from ARIN? For an end-user allocation > they are requesting that we provide customer names for existing allocations, > which is information that will take a while to obtain. They are insisting > that this is standard process and something that everyone does when > requesting IPs. Has anyone actually had to do this? If you can't [easily] tell ARIN who's using your current IP space, then you're probably not doing a very good job of managing that space, which begs the question, do you really need more? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jof at thejof.com Tue Apr 24 13:38:34 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 24 Apr 2012 11:38:34 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: On Tue, Apr 24, 2012 at 11:14 AM, Owen DeLong wrote: > That's not entirely true. What you say applies to one possible way for an > ISP to get an allocation. It does not apply at all to end-users. Even for end-user allocations, they would still need to fulfill the requirements of 4.3.3 in the ARIN NRPM (https://www.arin.net/policy/nrpm.html#four33), no? I suppose for "immediate need" assignments, this can be short circuited, but from what I know those are pretty rare. Am I missing something? Cheers, jof From stephen at sprunk.org Tue Apr 24 13:58:55 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 24 Apr 2012 13:58:55 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: <4F96F7EF.4040408@sprunk.org> On 24-Apr-12 12:32, admin at thecpaneladmin.com wrote: > Anyone have any tips for getting IPs from ARIN? For an end-user > allocation they are requesting that we provide customer names for > existing allocations, which is information that will take a while to > obtain. There are no "end-user allocations". Allocations go to ISPs; assignments go to end-users. Which are you? From the sound of it, you're an ISP requesting an allocation, and ARIN is requesting documentation of the assignments you've made to end users from your previous allocation(s) to verify you really need more--as required by community policy. If you're doing an even marginally competent job of managing your previous allocation(s), this data should be readily available in /some/ form, and providing it to ARIN should require little more effort than pinging your lawyers to verify the appropriate NDA is in place. If you're /not/ doing a marginally competent job of managing your previous allocation(s), you're not going to get more until you learn to do a better job of it. In my experience, going through that learning experience will uncover a lot of unused space that will likely make your current request moot (for now). And that's a big part of the point. > They are insisting that this is standard process and something that > everyone does when requesting IPs. Has anyone actually had to do this? Everyone /should/ be required to provide documentation of justification for all requests to any RIR. If you're aware of anyone who /hasn't/, let us know so we can beat up the RIR in question. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Tue Apr 24 14:00:43 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Apr 2012 12:00:43 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> On Apr 24, 2012, at 11:38 AM, Jonathan Lassoff wrote: > On Tue, Apr 24, 2012 at 11:14 AM, Owen DeLong wrote: >> That's not entirely true. What you say applies to one possible way for an >> ISP to get an allocation. It does not apply at all to end-users. > > Even for end-user allocations, they would still need to fulfill the > requirements of 4.3.3 in the ARIN NRPM > (https://www.arin.net/policy/nrpm.html#four33), no? > Yes, but, that utilization can be documented need for X hosts to be numbered in an initial deployment, it does not have to be X existing hosts numbered from some other set of resources. It can also be made up of hosts numbered from RFC-1918 space which now need globally unique addresses for whatever reason. > I suppose for "immediate need" assignments, this can be short > circuited, but from what I know those are pretty rare. > Not all that rare, but, yes, relatively rare. > Am I missing something? > I'm not sure. I know that I have no trouble getting appropriate sized assignments for my end-user clients with appropriate justification of their needs without them necessarily having existing space from ARIN or any other entity. I know that the ARIN process can, on occasion be tricky to navigate if you don't understand the subtleties of how some of the terminology is defined and that people often use terms which have very specific meanings to ARIN staff members to have a much broader meaning in what they are intending to say. I know that often leads to misunderstandings which make the process even more difficult. Owen From bill at herrin.us Tue Apr 24 16:48:26 2012 From: bill at herrin.us (William Herrin) Date: Tue, 24 Apr 2012 17:48:26 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: On 4/24/12, admin at thecpaneladmin.com wrote: > Anyone have any tips for getting IPs from ARIN? For an end-user > allocation they are requesting that we provide customer names for > existing allocations, which is information that will take a while to > obtain. They are insisting that this is standard process and something > that everyone does when requesting IPs. Has anyone actually had to do > this? First, distinguish whether you're looking for an ISP allocation or an end-user assignment. If you're an end user then you're not allocating IP addresses to customers. I know you think you are, but trust me: you're not. You're assigning a block of addresses to 20 servers in the computer room and a block of addresses to 50 PCs on the LAN, and so forth. Where you claim servers connected to the Internet, expect to provide a list of current IPs or URLs which you claim will be moved onto the new addresses. You don't plan to use NAT anywhere because real IP addresses are better. Right? And if you have a customer at site B then you're doing the same thing at site B: X servers here, Y desktops there. Not at customer B, at _your site_ B. Also, you're multihoming. You already requested and received an ASN and you've provided a copy of bills from two different Internet vendors both listing your business name and location. Because if you're not multihoming then you have to have many many more computers. So many computers, in fact, that you'd have to be crazy not to multihome. If you're an ISP, the rules are a little different. A few of your addresses will be specified as above but most will be listed as "assigned to Customer XYZ, address, name, phone number." Expect to provide customer name, address, contact name, contact email and phone number. If you don't wanna, you don't get to play at national registry level. Go get IPs from your upstream. For your largest customer assignments, expect to also present some basic documentation of their use in the same form as above: 50 PCs on the LAN, 20 servers in the computer room, etc. Because that's what the customer gave you to justify receiving those addresses. Pursuant to ARIN policy which as an ISP you follow. Right? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nicotine at warningg.com Tue Apr 24 17:15:30 2012 From: nicotine at warningg.com (Brandon Ewing) Date: Tue, 24 Apr 2012 17:15:30 -0500 Subject: 10GBASE-LR SFP+ in Reston, VA Message-ID: <20120424221530.GD3903@radiological.warningg.com> Greetings, Anyone know how I can get my hands on a SFP-10G-LR in the Reston area, tonight? -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sfischer1967 at gmail.com Tue Apr 24 17:23:22 2012 From: sfischer1967 at gmail.com (Steven Fischer) Date: Tue, 24 Apr 2012 18:23:22 -0400 Subject: 10GBASE-LR SFP+ in Reston, VA In-Reply-To: <20120424221530.GD3903@radiological.warningg.com> References: <20120424221530.GD3903@radiological.warningg.com> Message-ID: not at this hour..Do you have a good relationship with your Cisco rep, assuming you have one? They might have one in their lab they could spot you...their lab is in Herndon. On Tue, Apr 24, 2012 at 6:15 PM, Brandon Ewing wrote: > Greetings, > > Anyone know how I can get my hands on a SFP-10G-LR in the Reston area, > tonight? > > -- > Brandon Ewing ( > nicotine at warningg.com) > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From rcarpen at network1.net Tue Apr 24 20:21:14 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 24 Apr 2012 21:21:14 -0400 (EDT) Subject: Juniper MX expert? In-Reply-To: Message-ID: <0a30f5fa-4096-4f42-b323-55ee0d75f46c@zimbra.network1.net> Any Juniper MX experts out there want to do some quick consulting for me (not for free)? I am working on implementing a couple of MX5 routers in a service provider setting, and have run into some issues. I am pretty proficient at the SRX and EX lines, but not as much with the MX. As the particulars of the issues go a little deeper than I feel comfortable asking for free help for, I will leave out the details on the list. Please contact me off list if you are willing and able to give me a hand. thanks, -Randy From jbates at brightok.net Tue Apr 24 23:57:04 2012 From: jbates at brightok.net (Jack Bates) Date: Tue, 24 Apr 2012 23:57:04 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> Message-ID: <4F978420.4040605@brightok.net> On 4/24/2012 2:00 PM, Owen DeLong wrote: > I know that the ARIN process can, on occasion be tricky to navigate if you don't > understand the subtleties of how some of the terminology is defined and that people > often use terms which have very specific meanings to ARIN staff members to have > a much broader meaning in what they are intending to say. I know that often leads > to misunderstandings which make the process even more difficult. Yeah. Let's not forget that if you have 120 management devices (wifi backhaul/switches/waps) and a ton of customers with /32 assignments and you are renumbering from provider assigned space you gathered over many years into your own initial ARIN assignment, they want: 1. equipment type and info for each management device 2. customer info for each /32 assignment Tell me what ISP can legally and ethically give out their customer base information? Don't get me wrong. I'm sure small guys don't think twice about it, accumulating all the information and handing it over to ARIN thinking they have no choice (the responses from ARIN leaves one with that impression; you want the address space, you WILL give us this). I sometimes wonder what happens to that information; if it sits around in an archive somewhere in the vast digital repositories of ARIN awaiting someone to steal it. Jack From dmiller at tiggee.com Wed Apr 25 01:10:47 2012 From: dmiller at tiggee.com (David Miller) Date: Wed, 25 Apr 2012 02:10:47 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F978420.4040605@brightok.net> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> Message-ID: <4F979567.2010503@tiggee.com> On 4/25/2012 12:57 AM, Jack Bates wrote: > On 4/24/2012 2:00 PM, Owen DeLong wrote: >> I know that the ARIN process can, on occasion be tricky to navigate >> if you don't >> understand the subtleties of how some of the terminology is defined >> and that people >> often use terms which have very specific meanings to ARIN staff >> members to have >> a much broader meaning in what they are intending to say. I know that >> often leads >> to misunderstandings which make the process even more difficult. > > Yeah. Let's not forget that if you have 120 management devices (wifi > backhaul/switches/waps) and a ton of customers with /32 assignments > and you are renumbering from provider assigned space you gathered over > many years into your own initial ARIN assignment, they want: > > 1. equipment type and info for each management device > 2. customer info for each /32 assignment > > Tell me what ISP can legally and ethically give out their customer > base information? Don't get me wrong. I'm sure small guys don't think > twice about it, accumulating all the information and handing it over > to ARIN thinking they have no choice (the responses from ARIN leaves > one with that impression; you want the address space, you WILL give us > this). > > I sometimes wonder what happens to that information; if it sits around > in an archive somewhere in the vast digital repositories of ARIN > awaiting someone to steal it. > > Jack > The ARIN Privacy Policy covers information submitted for address justifications: https://www.arin.net/privacy.html -DMM From alexb at ripe.net Wed Apr 25 03:47:18 2012 From: alexb at ripe.net (Alex Band) Date: Wed, 25 Apr 2012 10:47:18 +0200 Subject: RPKI production support on Cisco, also EFT Message-ID: <94411175-A667-4EA0-AFC2-8835D4AEBD74@ripe.net> I didn't see any post on this topic here, so I just want to mention that RPKI is officially supported on these Cisco platforms: ASR1000, 7600, ASR903 and ASR901 ? releases are 15.2(1)S or XE 3.5. Early Field Trial is available for the following platforms (contact bduvivie at cisco dot com): ASR9000, CRS1, CRS3 and c12K (IOS-XR). Source (in French): http://reseauxblog.cisco.fr/2012/04/23/jai-teste-pour-vous-securiser-le-routage-sur-internet/ The RIPE NCC also just released RPKI Validator 2.1.0 with some new features and improvements: https://www.ripe.net/certification/tools-and-resources Here are instructions on how to hook up our Validator toolset to one of the Ciscos above: https://www.ripe.net/certification/router-configuration Cheers, Alex Band RIPE NCC -------------- next part -------------- -- This message has been scanned by Kaspersky Anti-Virus. For more information about data security please visit http://www.kaspersky.com and http://www.viruslist.com From jmaimon at ttec.com Wed Apr 25 05:23:32 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 25 Apr 2012 06:23:32 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: <4F97D0A4.1020907@ttec.com> admin at thecpaneladmin.com wrote: > Anyone have any tips for getting IPs from ARIN? For an end-user > allocation they are requesting that we provide customer names for > existing allocations, which is information that will take a while to > obtain. They are insisting that this is standard process and something > that everyone does when requesting IPs. Has anyone actually had to do this? > > ARIN does not require you or your customers to use NAT. If you have customers, you are an ISP and need an allocation. SWIP everything you do. Produce a common format form that must be completed before any addresses are assigned to anyone. On this your fortitude will be tested without end. Justifiable, documented and responsible utilization is rewarded with additional resources (for the next 1-4 years), so give your customers what they can document their need for. Joe From kenneth.mcrae at dreamhost.com Wed Apr 25 10:22:33 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Wed, 25 Apr 2012 08:22:33 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: Negative.. I have never had to provide end user information. I have been required to provide utilization information. I am sure this "policy" is and add-on to make it more difficult to prevent hoarding.. On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff wrote: > On Tue, Apr 24, 2012 at 10:32 AM, wrote: > > Anyone have any tips for getting IPs from ARIN? For an end-user > allocation > > they are requesting that we provide customer names for existing > allocations, > > which is information that will take a while to obtain. They are insisting > > that this is standard process and something that everyone does when > > requesting IPs. Has anyone actually had to do this? > > Indeed. It's worked this way for a long time. > > When starting a new organization, there's a bit of a chicken and egg > problem with IP space. If anyone could get IP space just for asking > for it, it would have been consumed too quickly. So, organizations > must first get some space assigned to them from an upstream provider > and begin using it. > At some point the current usage and growth rate of the assigned space > will justify a direct allocation. > > Then, you can renumber into your new space and be totally independent. > > Cheers, > jof > > -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mcrae at dreamhost.com Ph: 323-375-3814 www.dreamhost.com From owen at delong.com Wed Apr 25 10:28:35 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Apr 2012 08:28:35 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F97D0A4.1020907@ttec.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> Message-ID: <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> On Apr 25, 2012, at 3:23 AM, Joe Maimon wrote: > > > admin at thecpaneladmin.com wrote: >> Anyone have any tips for getting IPs from ARIN? For an end-user >> allocation they are requesting that we provide customer names for >> existing allocations, which is information that will take a while to >> obtain. They are insisting that this is standard process and something >> that everyone does when requesting IPs. Has anyone actually had to do this? >> >> > > ARIN does not require you or your customers to use NAT. > > If you have customers, you are an ISP and need an allocation. > > SWIP everything you do. > RWHOIS is a perfectly valid alternative to SWIP. Owen From owen at delong.com Wed Apr 25 10:31:44 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Apr 2012 08:31:44 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F978420.4040605@brightok.net> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> Message-ID: <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> On Apr 24, 2012, at 9:57 PM, Jack Bates wrote: > On 4/24/2012 2:00 PM, Owen DeLong wrote: >> I know that the ARIN process can, on occasion be tricky to navigate if you don't >> understand the subtleties of how some of the terminology is defined and that people >> often use terms which have very specific meanings to ARIN staff members to have >> a much broader meaning in what they are intending to say. I know that often leads >> to misunderstandings which make the process even more difficult. > > Yeah. Let's not forget that if you have 120 management devices (wifi backhaul/switches/waps) and a ton of customers with /32 assignments and you are renumbering from provider assigned space you gathered over many years into your own initial ARIN assignment, they want: > > 1. equipment type and info for each management device > 2. customer info for each /32 assignment > > Tell me what ISP can legally and ethically give out their customer base information? Don't get me wrong. I'm sure small guys don't think twice about it, accumulating all the information and handing it over to ARIN thinking they have no choice (the responses from ARIN leaves one with that impression; you want the address space, you WILL give us this). > There is nothing whatsoever wrong with providing the information to ARIN under NDA. ARIN provides a very good (IMHO) plain English mutual NDA for just this purpose. What rational ethical ISP fails to include a provision for this process in their TOS? > I sometimes wonder what happens to that information; if it sits around in an archive somewhere in the vast digital repositories of ARIN awaiting someone to steal it. That's a very cynical view. I happen to know that ARIN takes the security of that data very seriously and I think they do a good job of protecting it. If you have any reason to believe otherwise, I invite you to offer some form of substantiation to support such a claim. Owen From owen at delong.com Wed Apr 25 10:34:30 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Apr 2012 08:34:30 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> There is not a new policy added on to prevent hoarding. What is required is what has been required for several years. Utilization information and proper justification. If you are seeking an ISP allocation, then, reassignment (customer) information is in fact part of that utilization information. Owen On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: > Negative.. I have never had to provide end user information. I have been > required to provide utilization information. I am sure this "policy" is > and add-on to make it more difficult to prevent hoarding.. > > On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff wrote: > >> On Tue, Apr 24, 2012 at 10:32 AM, wrote: >>> Anyone have any tips for getting IPs from ARIN? For an end-user >> allocation >>> they are requesting that we provide customer names for existing >> allocations, >>> which is information that will take a while to obtain. They are insisting >>> that this is standard process and something that everyone does when >>> requesting IPs. Has anyone actually had to do this? >> >> Indeed. It's worked this way for a long time. >> >> When starting a new organization, there's a bit of a chicken and egg >> problem with IP space. If anyone could get IP space just for asking >> for it, it would have been consumed too quickly. So, organizations >> must first get some space assigned to them from an upstream provider >> and begin using it. >> At some point the current usage and growth rate of the assigned space >> will justify a direct allocation. >> >> Then, you can renumber into your new space and be totally independent. >> >> Cheers, >> jof >> >> > > > -- > Best Regards, > > > > Kenneth McRae > *Sr. Network Engineer* > kenneth.mcrae at dreamhost.com > Ph: 323-375-3814 > www.dreamhost.com From kenneth.mcrae at dreamhost.com Wed Apr 25 10:46:09 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Wed, 25 Apr 2012 08:46:09 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> Message-ID: I have never provided the names of end users.. How the address space would be utilized? Definitely.. But not the names of end users... On Wed, Apr 25, 2012 at 8:34 AM, Owen DeLong wrote: > There is not a new policy added on to prevent hoarding. What is required > is what > has been required for several years. Utilization information and proper > justification. > > If you are seeking an ISP allocation, then, reassignment (customer) > information is > in fact part of that utilization information. > > Owen > > On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: > > > Negative.. I have never had to provide end user information. I have > been > > required to provide utilization information. I am sure this "policy" is > > and add-on to make it more difficult to prevent hoarding.. > > > > On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff > wrote: > > > >> On Tue, Apr 24, 2012 at 10:32 AM, wrote: > >>> Anyone have any tips for getting IPs from ARIN? For an end-user > >> allocation > >>> they are requesting that we provide customer names for existing > >> allocations, > >>> which is information that will take a while to obtain. They are > insisting > >>> that this is standard process and something that everyone does when > >>> requesting IPs. Has anyone actually had to do this? > >> > >> Indeed. It's worked this way for a long time. > >> > >> When starting a new organization, there's a bit of a chicken and egg > >> problem with IP space. If anyone could get IP space just for asking > >> for it, it would have been consumed too quickly. So, organizations > >> must first get some space assigned to them from an upstream provider > >> and begin using it. > >> At some point the current usage and growth rate of the assigned space > >> will justify a direct allocation. > >> > >> Then, you can renumber into your new space and be totally independent. > >> > >> Cheers, > >> jof > >> > >> > > > > > > -- > > Best Regards, > > > > > > > > Kenneth McRae > > *Sr. Network Engineer* > > kenneth.mcrae at dreamhost.com > > Ph: 323-375-3814 > > www.dreamhost.com > > -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mcrae at dreamhost.com Ph: 323-375-3814 www.dreamhost.com From cra at WPI.EDU Wed Apr 25 10:49:35 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 25 Apr 2012 11:49:35 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> Message-ID: <20120425154935.GE23416@angus.ind.WPI.EDU> On Wed, Apr 25, 2012 at 08:28:35AM -0700, Owen DeLong wrote: > > On Apr 25, 2012, at 3:23 AM, Joe Maimon wrote: > > > > > > > admin at thecpaneladmin.com wrote: > >> Anyone have any tips for getting IPs from ARIN? For an end-user > >> allocation they are requesting that we provide customer names for > >> existing allocations, which is information that will take a while to > >> obtain. They are insisting that this is standard process and something > >> that everyone does when requesting IPs. Has anyone actually had to do this? > >> > >> > > > > ARIN does not require you or your customers to use NAT. > > > > If you have customers, you are an ISP and need an allocation. > > > > SWIP everything you do. > > > RWHOIS is a perfectly valid alternative to SWIP. Can a downstream ISP SWIP records if their upstream ISP uses RWHOIS for the block that is further delegated to that downstream ISP? From streiner at cluebyfour.org Wed Apr 25 10:52:37 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 25 Apr 2012 11:52:37 -0400 (EDT) Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> Message-ID: On Wed, 25 Apr 2012, Kenneth McRae wrote: > I have never provided the names of end users.. How the address space would > be utilized? Definitely.. But not the names of end users... When I worked at an ISP, we provided the names of companies to whom we assigned address space, but not individual residential subs. Running an rwhois server that was tied into our customer provisioning system made the process of requesting more space from ARIN pretty painless, all things considered, and saved the overhead of having to SWIP every assignment. jms From bhmccie at gmail.com Wed Apr 25 10:54:39 2012 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 25 Apr 2012 10:54:39 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> Message-ID: <4F981E3F.4010703@gmail.com> I can say that I recently completed the purchase of a large IPv6 block. We've had several large V4 blocks for years and got them with very little effort. For this block, we had to provide a detailed list of all our physical locations as well as how the IP schema would be utilized. I also had to provide site drawings (scrubbed visios) showing my topology layout to justify my additional ASNs. It was not a harsh ordeal. ARIN was very professional about it. But it was a lot more paperwork than what I've needed in the past. None of it seemed unreasonable. We just had to work out NDAs and whatnot so I could share more detailed information with them. -Hammer- "I was a normal American nerd" -Jack Herer On 4/25/2012 10:34 AM, Owen DeLong wrote: > There is not a new policy added on to prevent hoarding. What is required is what > has been required for several years. Utilization information and proper justification. > > If you are seeking an ISP allocation, then, reassignment (customer) information is > in fact part of that utilization information. > > Owen > > On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: > >> Negative.. I have never had to provide end user information. I have been >> required to provide utilization information. I am sure this "policy" is >> and add-on to make it more difficult to prevent hoarding.. >> >> On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff wrote: >> >>> On Tue, Apr 24, 2012 at 10:32 AM, wrote: >>>> Anyone have any tips for getting IPs from ARIN? For an end-user >>> allocation >>>> they are requesting that we provide customer names for existing >>> allocations, >>>> which is information that will take a while to obtain. They are insisting >>>> that this is standard process and something that everyone does when >>>> requesting IPs. Has anyone actually had to do this? >>> Indeed. It's worked this way for a long time. >>> >>> When starting a new organization, there's a bit of a chicken and egg >>> problem with IP space. If anyone could get IP space just for asking >>> for it, it would have been consumed too quickly. So, organizations >>> must first get some space assigned to them from an upstream provider >>> and begin using it. >>> At some point the current usage and growth rate of the assigned space >>> will justify a direct allocation. >>> >>> Then, you can renumber into your new space and be totally independent. >>> >>> Cheers, >>> jof >>> >>> >> >> -- >> Best Regards, >> >> >> >> Kenneth McRae >> *Sr. Network Engineer* >> kenneth.mcrae at dreamhost.com >> Ph: 323-375-3814 >> www.dreamhost.com > > From streiner at cluebyfour.org Wed Apr 25 10:55:25 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 25 Apr 2012 11:55:25 -0400 (EDT) Subject: Squeezing IPs out of ARIN In-Reply-To: <20120425154935.GE23416@angus.ind.WPI.EDU> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> <20120425154935.GE23416@angus.ind.WPI.EDU> Message-ID: On Wed, 25 Apr 2012, Chuck Anderson wrote: >> RWHOIS is a perfectly valid alternative to SWIP. > > Can a downstream ISP SWIP records if their upstream ISP uses RWHOIS > for the block that is further delegated to that downstream ISP? I would think so, but it might also depend on how the space is delegated to you. The upstream should be able to put a note in the rwhois record stating that further assignments from a.b.c.0/xx have been SWIP'd or something to that effect. jms From jof at thejof.com Wed Apr 25 11:09:56 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Wed, 25 Apr 2012 09:09:56 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> Message-ID: On Wed, Apr 25, 2012 at 8:46 AM, Kenneth McRae wrote: > I have never provided the names of end users.. How the address space > would be utilized? Definitely.. But not the names of end users... > Probably because you are an "end user". If you're talking about AS26347, I don't think there is any re-assigned space in there. Do you ever "assign" users CIDR blocks of IP space for their own use? If it's just the transitory use of IPs in an operational network you control, then that sounds like "end user" use to me, even though you may sell the use of those IPs. If you have questions about this stuff, the ARIN NRPM is a great resource: https://www.arin.net/policy/nrpm.html Cheers, jof From Valdis.Kletnieks at vt.edu Wed Apr 25 11:13:52 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 25 Apr 2012 12:13:52 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: Your message of "Wed, 25 Apr 2012 10:54:39 -0500." <4F981E3F.4010703@gmail.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <4F981E3F.4010703@gmail.com> Message-ID: <8577.1335370432@turing-police.cc.vt.edu> On Wed, 25 Apr 2012 10:54:39 -0500, -Hammer- said: > I can say that I recently completed the purchase of a large IPv6 block. "purchase"??!? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From owen at delong.com Wed Apr 25 11:55:55 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Apr 2012 09:55:55 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F981E3F.4010703@gmail.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <4F981E3F.4010703@gmail.com> Message-ID: <94F2E03F-B36B-444C-91DB-FDC74E251371@delong.com> No, you didn't. You may have completed the acquisition of a large IPv6 block, but you did not purchase it. Number resources are not property and cannot be bought and/or sold. What you pay to ARIN pays for registration services (the registration of the numbers, not the numbers themselves). While I realize that in practice this may seem like a distinction without a difference, there are major legal and practical implications to this fact that are quite important to the very underpinnings of how the internet works. Owen On Apr 25, 2012, at 8:54 AM, -Hammer- wrote: > I can say that I recently completed the purchase of a large IPv6 block. We've had several large V4 blocks for years and got them with very little effort. For this block, we had to provide a detailed list of all our physical locations as well as how the IP schema would be utilized. I also had to provide site drawings (scrubbed visios) showing my topology layout to justify my additional ASNs. It was not a harsh ordeal. ARIN was very professional about it. But it was a lot more paperwork than what I've needed in the past. None of it seemed unreasonable. We just had to work out NDAs and whatnot so I could share more detailed information with them. > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 4/25/2012 10:34 AM, Owen DeLong wrote: >> There is not a new policy added on to prevent hoarding. What is required is what >> has been required for several years. Utilization information and proper justification. >> >> If you are seeking an ISP allocation, then, reassignment (customer) information is >> in fact part of that utilization information. >> >> Owen >> >> On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: >> >>> Negative.. I have never had to provide end user information. I have been >>> required to provide utilization information. I am sure this "policy" is >>> and add-on to make it more difficult to prevent hoarding.. >>> >>> On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff wrote: >>> >>>> On Tue, Apr 24, 2012 at 10:32 AM, wrote: >>>>> Anyone have any tips for getting IPs from ARIN? For an end-user >>>> allocation >>>>> they are requesting that we provide customer names for existing >>>> allocations, >>>>> which is information that will take a while to obtain. They are insisting >>>>> that this is standard process and something that everyone does when >>>>> requesting IPs. Has anyone actually had to do this? >>>> Indeed. It's worked this way for a long time. >>>> >>>> When starting a new organization, there's a bit of a chicken and egg >>>> problem with IP space. If anyone could get IP space just for asking >>>> for it, it would have been consumed too quickly. So, organizations >>>> must first get some space assigned to them from an upstream provider >>>> and begin using it. >>>> At some point the current usage and growth rate of the assigned space >>>> will justify a direct allocation. >>>> >>>> Then, you can renumber into your new space and be totally independent. >>>> >>>> Cheers, >>>> jof >>>> >>>> >>> >>> -- >>> Best Regards, >>> >>> >>> >>> Kenneth McRae >>> *Sr. Network Engineer* >>> kenneth.mcrae at dreamhost.com >>> Ph: 323-375-3814 >>> www.dreamhost.com >> >> From rcarpen at network1.net Wed Apr 25 12:17:06 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 25 Apr 2012 13:17:06 -0400 (EDT) Subject: Juniper MX expert? In-Reply-To: <0a30f5fa-4096-4f42-b323-55ee0d75f46c@zimbra.network1.net> Message-ID: <5d341722-26ac-4e8f-bcee-0f397e1e847a@zimbra.network1.net> Thanks everyone for all the responses. They were extremely helpful. -Randy ----- Original Message ----- > > Any Juniper MX experts out there want to do some quick consulting for > me (not for free)? > > I am working on implementing a couple of MX5 routers in a service > provider setting, and have run into some issues. I am pretty > proficient at the SRX and EX lines, but not as much with the MX. As > the particulars of the issues go a little deeper than I feel > comfortable asking for free help for, I will leave out the details > on the list. > > Please contact me off list if you are willing and able to give me a > hand. > > thanks, > -Randy From mylists at battleop.com Wed Apr 25 12:21:18 2012 From: mylists at battleop.com (Richey) Date: Wed, 25 Apr 2012 13:21:18 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> Message-ID: <295001cd2307$d3b91dc0$7b2b5940$@battleop.com> I got a new allocation about 18 months ago. I sent them a spread sheet of the users and their current IPs. I changed the real customer name to something that reflected what business they were in. So I had lots of "Hotel Customer 1" and "Dr. Office 112" with what IPs they were using. There was no way we were going to release a complete customer list to anyone. They didn't seem to have a problem with this. Richey -----Original Message----- From: Kenneth McRae [mailto:kenneth.mcrae at dreamhost.com] Sent: Wednesday, April 25, 2012 11:46 AM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: Squeezing IPs out of ARIN I have never provided the names of end users.. How the address space would be utilized? Definitely.. But not the names of end users... On Wed, Apr 25, 2012 at 8:34 AM, Owen DeLong wrote: > There is not a new policy added on to prevent hoarding. What is > required is what has been required for several years. Utilization > information and proper justification. > > If you are seeking an ISP allocation, then, reassignment (customer) > information is in fact part of that utilization information. > > Owen > > On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: > > > Negative.. I have never had to provide end user information. I > > have > been > > required to provide utilization information. I am sure this > > "policy" is and add-on to make it more difficult to prevent hoarding.. > > > > On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff > wrote: > > > >> On Tue, Apr 24, 2012 at 10:32 AM, wrote: > >>> Anyone have any tips for getting IPs from ARIN? For an end-user > >> allocation > >>> they are requesting that we provide customer names for existing > >> allocations, > >>> which is information that will take a while to obtain. They are > insisting > >>> that this is standard process and something that everyone does > >>> when requesting IPs. Has anyone actually had to do this? > >> > >> Indeed. It's worked this way for a long time. > >> > >> When starting a new organization, there's a bit of a chicken and > >> egg problem with IP space. If anyone could get IP space just for > >> asking for it, it would have been consumed too quickly. So, > >> organizations must first get some space assigned to them from an > >> upstream provider and begin using it. > >> At some point the current usage and growth rate of the assigned > >> space will justify a direct allocation. > >> > >> Then, you can renumber into your new space and be totally independent. > >> > >> Cheers, > >> jof > >> > >> > > > > > > -- > > Best Regards, > > > > > > > > Kenneth McRae > > *Sr. Network Engineer* > > kenneth.mcrae at dreamhost.com > > Ph: 323-375-3814 > > www.dreamhost.com > > -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mcrae at dreamhost.com Ph: 323-375-3814 www.dreamhost.com From bhmccie at gmail.com Wed Apr 25 12:59:34 2012 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 25 Apr 2012 12:59:34 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <8577.1335370432@turing-police.cc.vt.edu> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <4F981E3F.4010703@gmail.com> <8577.1335370432@turing-police.cc.vt.edu> Message-ID: <4F983B86.3040509@gmail.com> purchase/lease/rent/titlepawn/etc. We paid for and got a block of IPs. -Hammer- "I was a normal American nerd" -Jack Herer On 4/25/2012 11:13 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 25 Apr 2012 10:54:39 -0500, -Hammer- said: >> I can say that I recently completed the purchase of a large IPv6 block. > "purchase"??!? From bhmccie at gmail.com Wed Apr 25 13:00:18 2012 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 25 Apr 2012 13:00:18 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <94F2E03F-B36B-444C-91DB-FDC74E251371@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <4F981E3F.4010703@gmail.com> <94F2E03F-B36B-444C-91DB-FDC74E251371@delong.com> Message-ID: <4F983BB2.5080409@gmail.com> Sorry everyone. Bad choice of words. I simply meant they have their money and we have our allocation. Stand down. Move along. Nothing to see here. -Hammer- "I was a normal American nerd" -Jack Herer On 4/25/2012 11:55 AM, Owen DeLong wrote: > No, you didn't. You may have completed the acquisition of a large IPv6 block, but you did not purchase it. > > Number resources are not property and cannot be bought and/or sold. > > What you pay to ARIN pays for registration services (the registration of the numbers, not the numbers themselves). While I realize that in practice this may seem like a distinction without a difference, there are major legal and practical implications to this fact that are quite important to the very underpinnings of how the internet works. > > Owen > > On Apr 25, 2012, at 8:54 AM, -Hammer- wrote: > >> I can say that I recently completed the purchase of a large IPv6 block. We've had several large V4 blocks for years and got them with very little effort. For this block, we had to provide a detailed list of all our physical locations as well as how the IP schema would be utilized. I also had to provide site drawings (scrubbed visios) showing my topology layout to justify my additional ASNs. It was not a harsh ordeal. ARIN was very professional about it. But it was a lot more paperwork than what I've needed in the past. None of it seemed unreasonable. We just had to work out NDAs and whatnot so I could share more detailed information with them. >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 4/25/2012 10:34 AM, Owen DeLong wrote: >>> There is not a new policy added on to prevent hoarding. What is required is what >>> has been required for several years. Utilization information and proper justification. >>> >>> If you are seeking an ISP allocation, then, reassignment (customer) information is >>> in fact part of that utilization information. >>> >>> Owen >>> >>> On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: >>> >>>> Negative.. I have never had to provide end user information. I have been >>>> required to provide utilization information. I am sure this "policy" is >>>> and add-on to make it more difficult to prevent hoarding.. >>>> >>>> On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff wrote: >>>> >>>>> On Tue, Apr 24, 2012 at 10:32 AM, wrote: >>>>>> Anyone have any tips for getting IPs from ARIN? For an end-user >>>>> allocation >>>>>> they are requesting that we provide customer names for existing >>>>> allocations, >>>>>> which is information that will take a while to obtain. They are insisting >>>>>> that this is standard process and something that everyone does when >>>>>> requesting IPs. Has anyone actually had to do this? >>>>> Indeed. It's worked this way for a long time. >>>>> >>>>> When starting a new organization, there's a bit of a chicken and egg >>>>> problem with IP space. If anyone could get IP space just for asking >>>>> for it, it would have been consumed too quickly. So, organizations >>>>> must first get some space assigned to them from an upstream provider >>>>> and begin using it. >>>>> At some point the current usage and growth rate of the assigned space >>>>> will justify a direct allocation. >>>>> >>>>> Then, you can renumber into your new space and be totally independent. >>>>> >>>>> Cheers, >>>>> jof >>>>> >>>>> >>>> -- >>>> Best Regards, >>>> >>>> >>>> >>>> Kenneth McRae >>>> *Sr. Network Engineer* >>>> kenneth.mcrae at dreamhost.com >>>> Ph: 323-375-3814 >>>> www.dreamhost.com >>> > From owen at delong.com Wed Apr 25 13:15:54 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Apr 2012 11:15:54 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F983B86.3040509@gmail.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <4F981E3F.4010703@gmail.com> <8577.1335370432@turing-police.cc.vt.edu> <4F983B86.3040509@gmail.com> Message-ID: <08EA0A25-07A6-4360-8898-AD3DECF47B10@delong.com> Nope... You paid for and received registration services for a block of IP Addresses. Anyone can use those integers for many purposes, but, only you are registered to use them as topological identifiers on the internet according to ARIN and the other RIRs. Owen On Apr 25, 2012, at 10:59 AM, -Hammer- wrote: > purchase/lease/rent/titlepawn/etc. We paid for and got a block of IPs. > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 4/25/2012 11:13 AM, Valdis.Kletnieks at vt.edu wrote: >> On Wed, 25 Apr 2012 10:54:39 -0500, -Hammer- said: >>> I can say that I recently completed the purchase of a large IPv6 block. >> "purchase"??!? From bhmccie at gmail.com Wed Apr 25 13:28:49 2012 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 25 Apr 2012 13:28:49 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <08EA0A25-07A6-4360-8898-AD3DECF47B10@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <4F981E3F.4010703@gmail.com> <8577.1335370432@turing-police.cc.vt.edu> <4F983B86.3040509@gmail.com> <08EA0A25-07A6-4360-8898-AD3DECF47B10@delong.com> Message-ID: <4F984261.6040004@gmail.com> Killing me softly Owen.... -Hammer- "I was a normal American nerd" -Jack Herer On 4/25/2012 1:15 PM, Owen DeLong wrote: > Nope... You paid for and received registration services for a block of IP Addresses. > > Anyone can use those integers for many purposes, but, only you are registered to use them as > topological identifiers on the internet according to ARIN and the other RIRs. > > Owen > > On Apr 25, 2012, at 10:59 AM, -Hammer- wrote: > >> purchase/lease/rent/titlepawn/etc. We paid for and got a block of IPs. >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 4/25/2012 11:13 AM, Valdis.Kletnieks at vt.edu wrote: >>> On Wed, 25 Apr 2012 10:54:39 -0500, -Hammer- said: >>>> I can say that I recently completed the purchase of a large IPv6 block. >>> "purchase"??!? > From streiner at cluebyfour.org Wed Apr 25 13:35:04 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 25 Apr 2012 14:35:04 -0400 (EDT) Subject: Squeezing IPs out of ARIN In-Reply-To: <4F984261.6040004@gmail.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <4F981E3F.4010703@gmail.com> <8577.1335370432@turing-police.cc.vt.edu> <4F983B86.3040509@gmail.com> <08EA0A25-07A6-4360-8898-AD3DECF47B10@delong.com> <4F984261.6040004@gmail.com> Message-ID: On Wed, 25 Apr 2012, -Hammer- wrote: > Killing me softly Owen.... The difference is subtle, but important. jms From dhubbard at dino.hostasaurus.com Wed Apr 25 13:37:01 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 25 Apr 2012 14:37:01 -0400 Subject: internap route server/looking glass? Message-ID: Anyone know of, or have access to, a route server on Internap's (AS 12180) network? Trying to make sure a specific advertisement is being seen. Thanks, David From chip.gwyn at gmail.com Wed Apr 25 13:56:52 2012 From: chip.gwyn at gmail.com (chip) Date: Wed, 25 Apr 2012 14:56:52 -0400 Subject: internap route server/looking glass? In-Reply-To: References: Message-ID: Sure....whatcha need? Or feel free to email noc at internap.com and they'll be glad to help. If not, the beatings will commence! --chip On Wed, Apr 25, 2012 at 2:37 PM, David Hubbard wrote: > Anyone know of, or have access to, a route server on > Internap's (AS 12180) network? ?Trying to make sure a > specific advertisement is being seen. > > Thanks, > > David > -- Just my $.02, your mileage may vary,? batteries not included, etc.... From kenneth.mcrae at dreamhost.com Wed Apr 25 14:31:12 2012 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Wed, 25 Apr 2012 12:31:12 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> Message-ID: No I am speaking about my previous positons with large providers, telco, etc. On Wed, Apr 25, 2012 at 9:09 AM, Jonathan Lassoff wrote: > On Wed, Apr 25, 2012 at 8:46 AM, Kenneth McRae < > kenneth.mcrae at dreamhost.com> wrote: > >> I have never provided the names of end users.. How the address space >> would be utilized? Definitely.. But not the names of end users... >> > > Probably because you are an "end user". > If you're talking about AS26347, I don't think there is any re-assigned > space in there. > > Do you ever "assign" users CIDR blocks of IP space for their own use? If > it's just the transitory use of IPs in an operational network you control, > then that sounds like "end user" use to me, even though you may sell the > use of those IPs. > > If you have questions about this stuff, the ARIN NRPM is a great resource: > https://www.arin.net/policy/nrpm.html > > Cheers, > jof > -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mcrae at dreamhost.com Ph: 323-375-3814 www.dreamhost.com From kyle.creyts at gmail.com Wed Apr 25 15:05:26 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Wed, 25 Apr 2012 16:05:26 -0400 Subject: admin for fixedorbit.com Message-ID: The contact form appears to be down (503 bad gateway on submit), and if it is actively maintained, I would be very interested in talking to someone about how it works, and how its path tracing simulations or estimates compare with real-world numbers. (or if it is driven by real world numbers, how it compares to what we observe) Some of the information in the output of the path trace tool is less than verbose. -- Kyle Creyts From asusag at ifncom.net Wed Apr 25 16:28:25 2012 From: asusag at ifncom.net (Andy Susag) Date: Wed, 25 Apr 2012 17:28:25 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <295001cd2307$d3b91dc0$7b2b5940$@battleop.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <295001cd2307$d3b91dc0$7b2b5940$@battleop.com> Message-ID: <01245B4ABF809743A84B2F16C6598FEA01057639@hydrogen> We just recently "wrastled" with ARIN to get a whopping /22 from them, it wasn't very easy. Keeping record of what you have allocated downstream is important and I totally agree with ARIN insisting this be done. Luckily as long as you have an address, customer name, and a contact, you can issue reassign simples to hostmaster. You don't have to walk your customers through creating POCs and ORG-IDs. When you issue a reassign simple, it will automatically create all that. As long as your allocations are 80% full, you should be able to make a request. You might not get what you want though. Seems kind of counterproductive to ARIN though. I wouldn't think they'd like a database full of fudged SWIP info, but I guess they're OK with it... -----Original Message----- From: Richey [mailto:mylists at battleop.com] Sent: Wednesday, April 25, 2012 13:21 To: 'Kenneth McRae'; 'Owen DeLong' Cc: nanog at nanog.org Subject: RE: Squeezing IPs out of ARIN I got a new allocation about 18 months ago. I sent them a spread sheet of the users and their current IPs. I changed the real customer name to something that reflected what business they were in. So I had lots of "Hotel Customer 1" and "Dr. Office 112" with what IPs they were using. There was no way we were going to release a complete customer list to anyone. They didn't seem to have a problem with this. Richey -----Original Message----- From: Kenneth McRae [mailto:kenneth.mcrae at dreamhost.com] Sent: Wednesday, April 25, 2012 11:46 AM To: Owen DeLong Cc: nanog at nanog.org Subject: Re: Squeezing IPs out of ARIN I have never provided the names of end users.. How the address space would be utilized? Definitely.. But not the names of end users... On Wed, Apr 25, 2012 at 8:34 AM, Owen DeLong wrote: > There is not a new policy added on to prevent hoarding. What is > required is what has been required for several years. Utilization > information and proper justification. > > If you are seeking an ISP allocation, then, reassignment (customer) > information is in fact part of that utilization information. > > Owen > > On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: > > > Negative.. I have never had to provide end user information. I > > have > been > > required to provide utilization information. I am sure this > > "policy" is and add-on to make it more difficult to prevent hoarding.. > > > > On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoff > wrote: > > > >> On Tue, Apr 24, 2012 at 10:32 AM, wrote: > >>> Anyone have any tips for getting IPs from ARIN? For an end-user > >> allocation > >>> they are requesting that we provide customer names for existing > >> allocations, > >>> which is information that will take a while to obtain. They are > insisting > >>> that this is standard process and something that everyone does > >>> when requesting IPs. Has anyone actually had to do this? > >> > >> Indeed. It's worked this way for a long time. > >> > >> When starting a new organization, there's a bit of a chicken and > >> egg problem with IP space. If anyone could get IP space just for > >> asking for it, it would have been consumed too quickly. So, > >> organizations must first get some space assigned to them from an > >> upstream provider and begin using it. > >> At some point the current usage and growth rate of the assigned > >> space will justify a direct allocation. > >> > >> Then, you can renumber into your new space and be totally independent. > >> > >> Cheers, > >> jof > >> > >> > > > > > > -- > > Best Regards, > > > > > > > > Kenneth McRae > > *Sr. Network Engineer* > > kenneth.mcrae at dreamhost.com > > Ph: 323-375-3814 > > www.dreamhost.com > > -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mcrae at dreamhost.com Ph: 323-375-3814 www.dreamhost.com From rs at seastrom.com Wed Apr 25 16:59:35 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 25 Apr 2012 17:59:35 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <01245B4ABF809743A84B2F16C6598FEA01057639@hydrogen> (Andy Susag's message of "Wed, 25 Apr 2012 17:28:25 -0400") References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <295001cd2307$d3b91dc0$7b2b5940$@battleop.com> <01245B4ABF809743A84B2F16C6598FEA01057639@hydrogen> Message-ID: <86k413wjzs.fsf@seastrom.com> "Andy Susag" writes: > Seems kind of counterproductive to ARIN though. I wouldn't think they'd > like a database full of fudged SWIP info, but I guess they're OK with > it... They require an officer attestation. SWIP info that is made up out of whole cloth sounds suspiciously like fraud to me, but I'm neither a lawyer nor your CxO. Choose wisely. -r From marka at isc.org Wed Apr 25 17:02:01 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 26 Apr 2012 08:02:01 +1000 Subject: RPKI production support on Cisco, also EFT In-Reply-To: Your message of "Wed, 25 Apr 2012 10:47:18 +0200." <94411175-A667-4EA0-AFC2-8835D4AEBD74@ripe.net> References: <94411175-A667-4EA0-AFC2-8835D4AEBD74@ripe.net> Message-ID: <20120425220201.E05F71FEC69E@drugs.dv.isc.org> Alex, please get your postmaster to FIX the AV software so that it emits a valid Content-Transfer-Encoding for multipart/mixed. Content-Type: multipart/mixed; boundary="----61eecb4035fc4e8de429abf6d62cd728----" Content-Transfer-Encoding: quoted-printable drugs:~/git/bind9] marka% show (Message inbox:407773) mhshow: "multipart/mixed" type in message 407773 must be encoded in 7bit, 8bit, or binary, continuing... [drugs:~/git/bind9] marka% Mark In message <94411175-A667-4EA0-AFC2-8835D4AEBD74 at ripe.net>, Alex Band writes: > ------61eecb4035fc4e8de429abf6d62cd728---- > Content-Type: text/plain; > charset=windows-1252 > Content-Transfer-Encoding: quoted-printable > > I didn't see any post on this topic here, so I just want to mention that = > RPKI is officially supported on these Cisco platforms: > ASR1000, 7600, ASR903 and ASR901 =96 releases are 15.2(1)S or XE 3.5. > > Early Field Trial is available for the following platforms (contact = > bduvivie at cisco dot com):=20 > ASR9000, CRS1, CRS3 and c12K (IOS-XR).=20 > > Source (in French): = > http://reseauxblog.cisco.fr/2012/04/23/jai-teste-pour-vous-securiser-le-ro= > utage-sur-internet/ > > The RIPE NCC also just released RPKI Validator 2.1.0 with some new = > features and improvements: > https://www.ripe.net/certification/tools-and-resources > > Here are instructions on how to hook up our Validator toolset to one of = > the Ciscos above: > https://www.ripe.net/certification/router-configuration > > Cheers, > > Alex Band > RIPE NCC= > > ------61eecb4035fc4e8de429abf6d62cd728---- > Content-Type: text/plain; > charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: 7bit > > > -- > This message has been scanned by Kaspersky Anti-Virus. > For more information about data security please visit > http://www.kaspersky.com and http://www.viruslist.com > > ------61eecb4035fc4e8de429abf6d62cd728------ > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcurran at arin.net Wed Apr 25 17:19:07 2012 From: jcurran at arin.net (John Curran) Date: Wed, 25 Apr 2012 22:19:07 +0000 Subject: Squeezing IPs out of ARIN In-Reply-To: <01245B4ABF809743A84B2F16C6598FEA01057639@hydrogen> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <7923C361-5C5A-49B6-BFD2-83FCFF1BB7CB@delong.com> <295001cd2307$d3b91dc0$7b2b5940$@battleop.com> <01245B4ABF809743A84B2F16C6598FEA01057639@hydrogen> Message-ID: <611B623B-2819-4732-9BDE-19120A37FCF6@corp.arin.net> On Apr 25, 2012, at 2:28 PM, Andy Susag wrote: > We just recently "wrastled" with ARIN to get a whopping /22 from them, > it wasn't very easy. > > Keeping record of what you have allocated downstream is important and I > totally agree with ARIN insisting this be done. Luckily as long as you > have an address, customer name, and a contact, you can issue reassign > simples to hostmaster. You don't have to walk your customers through > creating POCs and ORG-IDs. When you issue a reassign simple, it will > automatically create all that. As long as your allocations are 80% full, > you should be able to make a request. You might not get what you want > though. > > Seems kind of counterproductive to ARIN though. I wouldn't think they'd > like a database full of fudged SWIP info, but I guess they're OK with > it... Andy - You're 90% right in your quick summary about reassignment data; more details are available here: If you've got concerns regarding privacy for residential subscribers, there are specific mechanisms for handling that, but otherwise you should be putting in accurate reassignment data (including organization) for each IPv4 assignment of /29 or more. To not do so would be very awkward for you and your customers if your network block were reported for Internet number resource fraud due to being "full of fudged SWIP info"... FYI, /John John Curran President and CEO ARIN From jbates at brightok.net Wed Apr 25 17:31:10 2012 From: jbates at brightok.net (Jack Bates) Date: Wed, 25 Apr 2012 17:31:10 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> Message-ID: <4F987B2E.4010707@brightok.net> This is the first time I've seen ARIN request actual individual names. I've had them requests SWIP and I've had them request exact user counts, and I generally get much larger allocations than what was being allocated. In addition, all their numbers matched up with all of my numbers and the allocated space matched what I had assigned them minus 1 /24 (they had 5 /23's from me). After their initial renumber into the /21, they had to return to get the additional /24. They reorganized some networks to squeeze off the tenth /24. On 4/25/2012 10:31 AM, Owen DeLong wrote: > There is nothing whatsoever wrong with providing the information to > ARIN under NDA. ARIN provides a very good (IMHO) plain English mutual > NDA for just this purpose. What rational ethical ISP fails to include > a provision for this process in their TOS? Sure, and small ISP techs immediately think of NDAs when talking to ARIN. ARIN didn't suggest it. In addition, the entire "provide all this customer detail information" was overkill as well, given that the /21 was justified without the last little bit of justification requiring customer names (or for that matter, the management equipment model/type info). >> I sometimes wonder what happens to that information; if it sits around in an archive somewhere in the vast digital repositories of ARIN awaiting someone to steal it. > That's a very cynical view. I happen to know that ARIN takes the security of that data very seriously and I think they do a good job of protecting it. If you have any reason to believe otherwise, I invite you to offer some form of substantiation to support such a claim. > > I would like to assume they do a good job protecting the data (although I have no proof that this is true). However, leaving unnecessary data laying around for no valid reason is careless. Historical information of customer names/addresses is not necessary, even if said information is provided to ARIN. A note on the account verifying that necessary information was seen by the ARIN representative is enough. Requiring this level of detail on the smallest fraction of the justified space makes it even worse. Of course, ARIN might delete the information. I've seen nothing in the documentation to suggest if they do or not. I never presume data is secure. The more unnecessary copies of it there are, the more likely it will be obtained by an unauthorized individual. Jack From mysidia at gmail.com Thu Apr 26 01:05:28 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 26 Apr 2012 01:05:28 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F987B2E.4010707@brightok.net> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> <4F987B2E.4010707@brightok.net> Message-ID: On 4/25/12, Jack Bates wrote: > On 4/25/2012 10:31 AM, Owen DeLong wrote: >> There is nothing whatsoever wrong with providing the information to >> ARIN under NDA. ARIN provides a very good (IMHO) plain English mutual -- > Sure, and small ISP techs immediately think of NDAs when talking to > ARIN. ARIN didn't suggest it. In addition, the entire "provide all this [snip] Before anyone received their first allocation from ARIN, they had to sign a Registration Services Agreement, which contains a section explaining that ARIN may review Holder's utilization of previously assigned resources to ensure the Holder is complying with the terms, when a transfer or additional IPs are requested. In other words, they have been forewarned, that ARIN may at any time require them to show thorough documentation proving the utilization of the resources, and exactly who or what resources have been reassigned or reallocated to, and eligibility for future resource transfers/allocations may be impacted. If resources are used to provide service to a customer, it is not unreasonable that ARIN require that this to be shown, what customer, etc -- the org. assigning or reallocating the resources is required to have documented this. In addition to this documentation, for reallocations of /29 or more IPs, SWIP or Rwhois is also required by policy. That is all discussed in the ARIN Number resource policy manual, that resource holders have agreed to be bound to by signing a RSA. The requirement to document utilization and maintain evidence for the justification for utilization at all times, does not start when applying for additional resources. The policy is in effect at all times. The requirement is that the justification be made and documented, before resources are reallocated. In short... please don't blame the registry for failure to adhere to the rules and advice "should" rules given in number resource policies by maintaining proper documentation. The ARIN policies are community developed; and the ARIN staff wouldn't be doing their job as steward of scarce IPv4 resources which will be exhausted before too long; if they didn't require sufficient details to prove the utilization in resource reviews for the new allocations. https://www.arin.net/policy/nrpm.html#four23 " 4.2.3. Reassigning Address Space to Customers 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. " The requirement for End users is even more stringent: https://www.arin.net/policy/nrpm.html#four33 " Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. " -- -JH From jmaimon at ttec.com Thu Apr 26 08:52:53 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 26 Apr 2012 09:52:53 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> Message-ID: <4F995335.1010005@ttec.com> Owen DeLong wrote: > >> > RWHOIS is a perfectly valid alternative to SWIP. > > Owen > I actually got RWHOIS working a while back. But then faced with the prospect of loading it up, I decided that ARIN templates were actually easier to use. And with their restful interface, even more so. Unless it is all prerolled for your and bundled with your ip management software that you are already using, dont bother. Joe From ops.lists at gmail.com Thu Apr 26 09:02:06 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Apr 2012 19:32:06 +0530 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F995335.1010005@ttec.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> <4F995335.1010005@ttec.com> Message-ID: It is an extremely rare ISP that has an rwhois server, and then ensures that it remains available, up and answering queries. And even rarer when the ISP ensures that its rwhois records are up to date and not hopelessly stale. On Thu, Apr 26, 2012 at 7:22 PM, Joe Maimon wrote: > > > Owen DeLong wrote: >> >> >>> >> RWHOIS is a perfectly valid alternative to SWIP. >> >> Owen >> > > > I actually got RWHOIS working a while back. But then faced with the prospect > of loading it up, I decided that ARIN templates were actually easier to use. > > And with their restful interface, even more so. > > Unless it is all prerolled for your and bundled with your ip management > software that you are already using, dont bother. > > Joe > -- Suresh Ramasubramanian (ops.lists at gmail.com) From owen at delong.com Thu Apr 26 09:37:49 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Apr 2012 07:37:49 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> <4F995335.1010005@ttec.com> Message-ID: <48067678-C7E2-4F7F-9951-729BAB874302@delong.com> Actually, most of the ISPs I know that use RWHOIS instead of SWIP do so tying the RWHOIS server into their IP management database through an automated process (if not just live queries). However, you are right that most ISPs use SWIP. Owen On Apr 26, 2012, at 7:02 AM, Suresh Ramasubramanian wrote: > It is an extremely rare ISP that has an rwhois server, and then > ensures that it remains available, up and answering queries. > > And even rarer when the ISP ensures that its rwhois records are up to > date and not hopelessly stale. > > On Thu, Apr 26, 2012 at 7:22 PM, Joe Maimon wrote: >> >> >> Owen DeLong wrote: >>> >>> >>>> >>> RWHOIS is a perfectly valid alternative to SWIP. >>> >>> Owen >>> >> >> >> I actually got RWHOIS working a while back. But then faced with the prospect >> of loading it up, I decided that ARIN templates were actually easier to use. >> >> And with their restful interface, even more so. >> >> Unless it is all prerolled for your and bundled with your ip management >> software that you are already using, dont bother. >> >> Joe >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Thu Apr 26 09:49:28 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Apr 2012 20:19:28 +0530 Subject: Squeezing IPs out of ARIN In-Reply-To: <48067678-C7E2-4F7F-9951-729BAB874302@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> <4F995335.1010005@ttec.com> <48067678-C7E2-4F7F-9951-729BAB874302@delong.com> Message-ID: They do, they do .. but there's all kinds of rwhois unfortunately. suresh at frodo 07:41:38 :~$ telnet rwhois.level3.net 4321 Trying 209.244.1.179... ^C [keeps timing out] suresh at frodo 07:48:17 :~$ telnet rwhois.hostnoc.net 4321 Trying 64.191.49.26... Connected to rwhois.hostnoc.net. Escape character is '^]'. %rwhois V-1.5:003fff:00 rwhois.hostnoc.net (by Network Solutions, Inc. V-1.5.9.5) [not particularly up to date] compared to, for example - suresh at frodo 07:47:13 :~$ telnet rwhois.cogentco.com 4321 Trying 66.28.3.252... Connected to plebe.sys.cogentco.com. Escape character is '^]'. %rwhois V-1.5:0010b0:00 rwhois.cogentco.com [fast, works great, accurate] suresh at frodo 07:47:22 :~$ telnet rwhois.softlayer.com 4321 Trying 66.228.118.79... Connected to rwhois.softlayer.com. Escape character is '^]'. %rwhois V-1.5:003fff:00 rwhois.softlayer.com (by Network Solutions, Inc. V-1.5.9.5) [ditto] On Thu, Apr 26, 2012 at 8:07 PM, Owen DeLong wrote: > Actually, most of the ISPs I know that use RWHOIS instead of SWIP do so tying > the RWHOIS server into their IP management database through an automated > process (if not just live queries). > > However, you are right that most ISPs use SWIP. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Thu Apr 26 09:49:59 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Apr 2012 20:19:59 +0530 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> <4F995335.1010005@ttec.com> <48067678-C7E2-4F7F-9951-729BAB874302@delong.com> Message-ID: Though to be fair that is probably legacy and level3 does swip its customers. On Thu, Apr 26, 2012 at 8:19 PM, Suresh Ramasubramanian wrote: > > suresh at frodo 07:41:38 :~$ telnet rwhois.level3.net 4321 > Trying 209.244.1.179... > ^C [keeps timing out] -- Suresh Ramasubramanian (ops.lists at gmail.com) From jbates at brightok.net Thu Apr 26 10:47:16 2012 From: jbates at brightok.net (Jack Bates) Date: Thu, 26 Apr 2012 10:47:16 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> <4F987B2E.4010707@brightok.net> Message-ID: <4F996E04.7090909@brightok.net> On 4/26/2012 1:05 AM, Jimmy Hess wrote: > If resources are used to provide service to a customer, it is not > unreasonable that ARIN require that this to be shown, what customer, > etc -- the org. assigning or reallocating the resources is required > to have documented this. > > In addition to this documentation, for reallocations of /29 or more > IPs, SWIP or Rwhois is also required by policy. It is unreasonable to require detailed customer information on /32 static assignments which make up the smallest fraction of space compared to the huge blocks of dhcp pools (pools which justify allocations on their own). In addition, a few show commands on a router displaying arp (with first 6 filtered) or ppp sessions (with username filtered) or dhcp pool printouts showing utilization would make much more sense and provide better "proof" of utilization then handing out private resident names of the <10% static /32 utilization pool. For management statics, the same applies. A couple arp table captures generally should provide enough proof of utilization. If ARIN really wants to be uptight about it, they can do what all the vendors do and set up a meeting session to watch us type the commands. This is probably the hardest method to forge. I have not argued about any /29 or greater assignment which should be SWIP'd. Someone else in the thread complained that someone would be vague information in a SWIP concerning a customer, but I see it's still listed under 4.2.3.7.3.2. So the NRPM still apparently recognizes the need for Residential privacy as long as upstream contacts are available to handle abuse/technical contact. I didn't see in the NRPM where SWIP was necessary for /32 assignments, nor that such contact information should be handed to ARIN. This is the difference between NRPM and ARIN implementation of NRPM. ARIN has always asked for dhcp pool counts versus actual customer counts, dialup counts, dialup ratios, etc. They have also always asked for SWIP/records for /29 or larger assignments. I've always been surprised that they don't ask for a few router/server captures as verification. Instead they ask for information which isn't pertinent to justification, the <10% assignments (when the 90% more than justifies on its own). Jack From bill at herrin.us Thu Apr 26 13:59:14 2012 From: bill at herrin.us (William Herrin) Date: Thu, 26 Apr 2012 14:59:14 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F995335.1010005@ttec.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <4F97D0A4.1020907@ttec.com> <4CD676B6-A09E-4C52-AAD5-A75C60AB7A2E@delong.com> <4F995335.1010005@ttec.com> Message-ID: On 4/26/12, Joe Maimon wrote: > Owen DeLong wrote: >> RWHOIS is a perfectly valid alternative to SWIP. > I actually got RWHOIS working a while back. But then faced with the > prospect of loading it up, I decided that ARIN templates were actually > easier to use. The rwhois software from about 10 years ago was very difficult to work with and it periodically crashed to boot. I used it because I already had my allocation data in a handy machine-readable form and could write software which would wholesale convert that database into what rwhois wanted to see. That way I didn't have to write something to detect changes and "update" the SWIP templates. I could just push a completely fresh database into rwhois. Had I needed to import the data by hand, there's no way: I would have used the SWIP templates. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Apr 26 14:14:13 2012 From: bill at herrin.us (William Herrin) Date: Thu, 26 Apr 2012 15:14:13 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F996E04.7090909@brightok.net> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> <4F987B2E.4010707@brightok.net> <4F996E04.7090909@brightok.net> Message-ID: On 4/26/12, Jack Bates wrote: > On 4/26/2012 1:05 AM, Jimmy Hess wrote: >> In addition to this documentation, for reallocations of /29 or more >> IPs, SWIP or Rwhois is also required by policy. > > It is unreasonable to require detailed customer information on /32 > static assignments which make up the smallest fraction of space compared > to the huge blocks of dhcp pools (pools which justify allocations on > their own). It depends. If you have a healthy mix of assignment sizes and your contact at ARIN is hassling you about the /32's, you may want to ask why he's seeking that information in light of the policy cut-off at /29. If the bulk of your assignment sizes are /32 then I suspect your ARIN contact is really saying: This fits a pattern consistent with careless and poorly tracked assignments which if audited would reveal enough dead assignments to put you in violation of policy. Show us that's not the case. If you have already provided a reasonable demonstration of the actual utilization of your /32's yet you're still getting hassled about identifying those customers that would seem, to my read anyway, to violate ARIN's written policy. In which case I'm confident that ARIN President John Curran would like to hear from you privately. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeroen at mompl.net Thu Apr 26 16:38:02 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 26 Apr 2012 14:38:02 -0700 Subject: Operation Ghost Click Message-ID: <4F99C03A.30506@mompl.net> Excuse the horrible subject :-) Anyone have anything insightful to say about it? Is it just lots of fuss about nothing or is it an actual substantial problem? http://www.fbi.gov/news/stories/2011/november/malware_110911 "Update on March 12, 2012: To assist victims affected by the DNSChanger malicious software, the FBI obtained a court order authorizing the Internet Systems Consortium (ISC) to deploy and maintain temporary clean DNS servers. This solution is temporary, providing additional time for victims to clean affected computers and restore their normal DNS settings. The clean DNS servers will be turned off on July 9, 2012, and computers still impacted by DNSChanger may lose Internet connectivity at that time." -- Earthquake Magnitude: 5.5 Date: Thursday, April 26, 2012 19:21:45 UTC Location: off the west coast of northern Sumatra Latitude: 2.6946; Longitude: 94.5307 Depth: 26.00 km From lathama at gmail.com Thu Apr 26 16:44:33 2012 From: lathama at gmail.com (Andrew Latham) Date: Thu, 26 Apr 2012 17:44:33 -0400 Subject: Operation Ghost Click In-Reply-To: <4F99C03A.30506@mompl.net> References: <4F99C03A.30506@mompl.net> Message-ID: On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart wrote: > Excuse the horrible subject :-) > > Anyone have anything insightful to say about it? Is it just lots of fuss > about nothing or is it an actual substantial problem? > > http://www.fbi.gov/news/stories/2011/november/malware_110911 > > "Update on March 12, 2012: To assist victims affected by the DNSChanger > malicious software, the FBI obtained a court order authorizing the Internet > Systems Consortium (ISC) to deploy and maintain temporary clean DNS servers. > This solution is temporary, providing additional time for victims to clean > affected computers and restore their normal DNS settings. The clean DNS > servers will be turned off on July 9, 2012, and computers still impacted by > DNSChanger may lose Internet connectivity at that time." > > -- > Earthquake Magnitude: 5.5 > Date: Thursday, April 26, 2012 19:21:45 UTC > Location: off the west coast of northern Sumatra > Latitude: 2.6946; Longitude: 94.5307 > Depth: 26.00 km > Yes its a major problem for the users unknowingly infected. To them it will look like their Internet connection is down. Expect ISPs to field lots of support calls. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From leigh.porter at ukbroadband.com Thu Apr 26 16:50:24 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 26 Apr 2012 21:50:24 +0000 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net>, Message-ID: <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> On 26 Apr 2012, at 22:47, "Andrew Latham" > wrote: On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart > wrote: Yes its a major problem for the users unknowingly infected. To them it will look like their Internet connection is down. Expect ISPs to field lots of support s Is there a list of these temporary servers so I can see what customers are using them (indicating infection) and head off a support call with some contact? -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From paul at paulgraydon.co.uk Thu Apr 26 16:47:52 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 26 Apr 2012 11:47:52 -1000 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net> Message-ID: <4F99C288.1030705@paulgraydon.co.uk> On 04/26/2012 11:44 AM, Andrew Latham wrote: > On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart wrote: >> Excuse the horrible subject :-) >> >> Anyone have anything insightful to say about it? Is it just lots of fuss >> about nothing or is it an actual substantial problem? >> >> http://www.fbi.gov/news/stories/2011/november/malware_110911 >> >> "Update on March 12, 2012: To assist victims affected by the DNSChanger >> malicious software, the FBI obtained a court order authorizing the Internet >> Systems Consortium (ISC) to deploy and maintain temporary clean DNS servers. >> This solution is temporary, providing additional time for victims to clean >> affected computers and restore their normal DNS settings. The clean DNS >> servers will be turned off on July 9, 2012, and computers still impacted by >> DNSChanger may lose Internet connectivity at that time." >> >> -- >> Earthquake Magnitude: 5.5 >> Date: Thursday, April 26, 2012 19:21:45 UTC >> Location: off the west coast of northern Sumatra >> Latitude: 2.6946; Longitude: 94.5307 >> Depth: 26.00 km >> > Yes its a major problem for the users unknowingly infected. To them > it will look like their Internet connection is down. Expect ISPs to > field lots of support calls. > Based on conversations on this list a month or so ago, ISPs were contacted with details of which of their IPs had compromised boxes behind them, but it seems the consensus is that ISP were going to just wait for users to phone support when it broke rather than be proactive about it. Paul From andrew.fried at gmail.com Thu Apr 26 16:56:01 2012 From: andrew.fried at gmail.com (Andrew Fried) Date: Thu, 26 Apr 2012 17:56:01 -0400 Subject: Operation Ghost Click In-Reply-To: <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> References: <4F99C03A.30506@mompl.net>, <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> Message-ID: <4F99C471.2070408@gmail.com> I suggest you reach out to Shadowserver or Team Cymru if you're a netblock owner. They can provide daily reports of infected IPs. Andy Andrew Fried andrew.fried at gmail.com On 4/26/12 5:50 PM, Leigh Porter wrote: > > On 26 Apr 2012, at 22:47, "Andrew Latham" > wrote: > > On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart > wrote: > > Yes its a major problem for the users unknowingly infected. To them > it will look like their Internet connection is down. Expect ISPs to > field lots of support s > > Is there a list of these temporary servers so I can see what customers are using them (indicating infection) and head off a support call with some contact? > > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ From kyle.creyts at gmail.com Thu Apr 26 16:57:36 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 26 Apr 2012 17:57:36 -0400 Subject: Operation Ghost Click In-Reply-To: <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> References: <4F99C03A.30506@mompl.net> <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> Message-ID: http://www.fbi.gov/news/stories/2011/november/malware_110911/DNS-changer-malware.pdf On Apr 26, 2012 5:48 PM, "Leigh Porter" wrote: > > On 26 Apr 2012, at 22:47, "Andrew Latham" lathama at gmail.com>> wrote: > > On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart jeroen at mompl.net>> wrote: > > Yes its a major problem for the users unknowingly infected. To them > it will look like their Internet connection is down. Expect ISPs to > field lots of support s > > Is there a list of these temporary servers so I can see what customers are > using them (indicating infection) and head off a support call with some > contact? > > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > From lathama at gmail.com Thu Apr 26 17:00:59 2012 From: lathama at gmail.com (Andrew Latham) Date: Thu, 26 Apr 2012 18:00:59 -0400 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net> <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> Message-ID: On Thu, Apr 26, 2012 at 5:57 PM, Kyle Creyts wrote: > http://www.fbi.gov/news/stories/2011/november/malware_110911/DNS-changer-malware.pdf > > On Apr 26, 2012 5:48 PM, "Leigh Porter" > wrote: >> >> >> On 26 Apr 2012, at 22:47, "Andrew Latham" >> > wrote: >> >> >> On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart >> > wrote: >> >> Yes its a major problem for the users unknowingly infected. ?To them >> it will look like their Internet connection is down. ?Expect ISPs to >> field lots of support s >> >> Is there a list of these temporary servers so I can see what customers are >> using them (indicating infection) and head off a support call with some >> contact? >> >> -- >> Leigh 85.255.112.0 through 85.255.127.255 67.210.0.0 through 67.210.15.255 93.188.160.0 through 93.188.167.255 77.67.83.0 through 77.67.83.255 213.109.64.0 through 213.109.79.255 64.28.176.0 through 64.28.191.255 -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From mpalmer at hezmatt.org Thu Apr 26 17:54:20 2012 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 27 Apr 2012 08:54:20 +1000 Subject: Squeezing IPs out of ARIN In-Reply-To: <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> Message-ID: <20120426225420.GD2056@hezmatt.org> On Wed, Apr 25, 2012 at 08:31:44AM -0700, Owen DeLong wrote: > On Apr 24, 2012, at 9:57 PM, Jack Bates wrote: > > I sometimes wonder what happens to that information; if it sits around > > in an archive somewhere in the vast digital repositories of ARIN > > awaiting someone to steal it. > > That's a very cynical view. I happen to know that ARIN takes the security > of that data very seriously and I think they do a good job of protecting > it. If you have any reason to believe otherwise, I invite you to offer > some form of substantiation to support such a claim. I'm sure that if you s/ARIN/Sony/, s/ARIN/Wordpress/, or s/ARIN/RSA/ (just to name a few), you'd have found people at some point in the past more than willing to stand behind the resulting statement. Just sayin'. - Matt From kyle.creyts at gmail.com Thu Apr 26 18:58:59 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 26 Apr 2012 19:58:59 -0400 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net> <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> Message-ID: Thanks, Andrew. I was out and about, and couldn't remember the prefixes off-hand. They should have been in that PDF, iirc On Apr 26, 2012 6:01 PM, "Andrew Latham" wrote: > On Thu, Apr 26, 2012 at 5:57 PM, Kyle Creyts > wrote: > > > http://www.fbi.gov/news/stories/2011/november/malware_110911/DNS-changer-malware.pdf > > > > On Apr 26, 2012 5:48 PM, "Leigh Porter" > > wrote: > >> > >> > >> On 26 Apr 2012, at 22:47, "Andrew Latham" > >> > wrote: > >> > >> > >> On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart > >> > wrote: > >> > >> Yes its a major problem for the users unknowingly infected. To them > >> it will look like their Internet connection is down. Expect ISPs to > >> field lots of support s > >> > >> Is there a list of these temporary servers so I can see what customers > are > >> using them (indicating infection) and head off a support call with some > >> contact? > >> > >> -- > >> Leigh > > 85.255.112.0 through 85.255.127.255 > 67.210.0.0 through 67.210.15.255 > 93.188.160.0 through 93.188.167.255 > 77.67.83.0 through 77.67.83.255 > 213.109.64.0 through 213.109.79.255 > 64.28.176.0 through 64.28.191.255 > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > From mysidia at gmail.com Thu Apr 26 19:09:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 26 Apr 2012 19:09:33 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F996E04.7090909@brightok.net> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> <4F987B2E.4010707@brightok.net> <4F996E04.7090909@brightok.net> Message-ID: On 4/26/12, Jack Bates wrote: >> In addition to this documentation, for reallocations of /29 or more >> IPs, SWIP or Rwhois is also required by policy. > It is unreasonable to require detailed customer information on /32 > static assignments which make up the smallest fraction of space compared It is not unreasonable to require detailed information be kept; it is standard business practice to maintain such documentation for support, incident handling, and billing purposes. If that customer stops paying for their service, exactly the right service will be determined. It is also required that exactly the right /32 be de-allocated; the previous customer's use of that /32 can no longer be used to consider the IP still utilized for justifying future allocations, until it is reassigned. If the provider failed to "unmark" that static /32 as utilized in their management system, in that case, it may be ARIN's job to detect the absence of proof of current utilization for those now-unused /32s. The provider is required to maintain that detailed level of documentation, but it is burdensome to publish documentation down to the /32 level, hence, one of the reasons that it is actually not required to RWHOIS or SWIP, unless the allocation is a /29 or larger. That doesn't excuse the provider from maintaining documentation, that ARIN may require at any time, it just reduces the operational burden of constantly updating external databases with single-IP assignments. > to the huge blocks of dhcp pools (pools which justify allocations on > their own). In addition, a few show commands on a router displaying arp Proof implies that you have provided independently verifiable information, that can be used to show that the applicant is providing truthful information. Some "show" commands will show DHCP server usage, but not conclusive proof of the utilization of the address space. Because the show commands are not independently verifiable -- for all the RIR knows, someone plugged in a big stack of $10 modems just to register with the DHCP server. -- -JH From frnkblk at iname.com Thu Apr 26 19:38:54 2012 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 26 Apr 2012 19:38:54 -0500 Subject: Operation Ghost Click In-Reply-To: <4F99C288.1030705@paulgraydon.co.uk> References: <4F99C03A.30506@mompl.net> <4F99C288.1030705@paulgraydon.co.uk> Message-ID: <002901cd240e$27d9a710$778cf530$@iname.com> The good folks at Shadowserver has been giving us a feed of IPs that are hitting those DNS server since November and last month we got the last of the customers cleaned up. Not all ISPs are non-proactive. Frank -----Original Message----- From: Paul Graydon [mailto:paul at paulgraydon.co.uk] Sent: Thursday, April 26, 2012 4:48 PM To: nanog at nanog.org Subject: Re: Operation Ghost Click On 04/26/2012 11:44 AM, Andrew Latham wrote: > On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart wrote: >> Excuse the horrible subject :-) >> >> Anyone have anything insightful to say about it? Is it just lots of fuss >> about nothing or is it an actual substantial problem? >> >> http://www.fbi.gov/news/stories/2011/november/malware_110911 >> >> "Update on March 12, 2012: To assist victims affected by the DNSChanger >> malicious software, the FBI obtained a court order authorizing the Internet >> Systems Consortium (ISC) to deploy and maintain temporary clean DNS servers. >> This solution is temporary, providing additional time for victims to clean >> affected computers and restore their normal DNS settings. The clean DNS >> servers will be turned off on July 9, 2012, and computers still impacted by >> DNSChanger may lose Internet connectivity at that time." >> >> -- >> Earthquake Magnitude: 5.5 >> Date: Thursday, April 26, 2012 19:21:45 UTC >> Location: off the west coast of northern Sumatra >> Latitude: 2.6946; Longitude: 94.5307 >> Depth: 26.00 km >> > Yes its a major problem for the users unknowingly infected. To them > it will look like their Internet connection is down. Expect ISPs to > field lots of support calls. > Based on conversations on this list a month or so ago, ISPs were contacted with details of which of their IPs had compromised boxes behind them, but it seems the consensus is that ISP were going to just wait for users to phone support when it broke rather than be proactive about it. Paul From owen at delong.com Thu Apr 26 20:05:36 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Apr 2012 18:05:36 -0700 Subject: Squeezing IPs out of ARIN In-Reply-To: <4F996E04.7090909@brightok.net> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> <4F987B2E.4010707@brightok.net> <4F996E04.7090909@brightok.net> Message-ID: <465C33C3-A9F4-4B8E-A031-F90880CCBBEF@delong.com> On Apr 26, 2012, at 8:47 AM, Jack Bates wrote: > On 4/26/2012 1:05 AM, Jimmy Hess wrote: >> If resources are used to provide service to a customer, it is not >> unreasonable that ARIN require that this to be shown, what customer, >> etc -- the org. assigning or reallocating the resources is required >> to have documented this. >> >> In addition to this documentation, for reallocations of /29 or more >> IPs, SWIP or Rwhois is also required by policy. > > It is unreasonable to require detailed customer information on /32 static assignments which make up the smallest fraction of space compared to the huge blocks of dhcp pools (pools which justify allocations on their own). In addition, a few show commands on a router displaying arp (with first 6 filtered) or ppp sessions (with username filtered) or dhcp pool printouts showing utilization would make much more sense and provide better "proof" of utilization then handing out private resident names of the <10% static /32 utilization pool. > /32s are not required. Get over it. /29 and larger. > For management statics, the same applies. A couple arp table captures generally should provide enough proof of utilization. > > If ARIN really wants to be uptight about it, they can do what all the vendors do and set up a meeting session to watch us type the commands. This is probably the hardest method to forge. > > I have not argued about any /29 or greater assignment which should be SWIP'd. > > Someone else in the thread complained that someone would be vague information in a SWIP concerning a customer, but I see it's still listed under 4.2.3.7.3.2. So the NRPM still apparently recognizes the need for Residential privacy as long as upstream contacts are available to handle abuse/technical contact. > The other person spoke of classes of businesses so the residential privacy policy would not apply. Owen From bill at herrin.us Thu Apr 26 20:14:55 2012 From: bill at herrin.us (William Herrin) Date: Thu, 26 Apr 2012 21:14:55 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <465C33C3-A9F4-4B8E-A031-F90880CCBBEF@delong.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> <4F987B2E.4010707@brightok.net> <4F996E04.7090909@brightok.net> <465C33C3-A9F4-4B8E-A031-F90880CCBBEF@delong.com> Message-ID: On 4/26/12, Owen DeLong wrote: > On Apr 26, 2012, at 8:47 AM, Jack Bates wrote: >> It is unreasonable to require detailed customer information on /32 static >> assignments which make up the smallest fraction of space compared to the >> huge blocks of dhcp pools (pools which justify allocations on their own). >> In addition, a few show commands on a router displaying arp (with first 6 >> filtered) or ppp sessions (with username filtered) or dhcp pool printouts >> showing utilization would make much more sense and provide better "proof" >> of utilization then handing out private resident names of the <10% static >> /32 utilization pool. > > /32s are not required. Get over it. Hi Owen, John Curran says otherwise. http://lists.arin.net/pipermail/arin-ppml/2012-April/024518.html http://lists.arin.net/pipermail/arin-ppml/2012-April/024523.html Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Thu Apr 26 20:30:56 2012 From: jbates at brightok.net (Jack Bates) Date: Thu, 26 Apr 2012 20:30:56 -0500 Subject: Squeezing IPs out of ARIN In-Reply-To: References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> <03A99701-FDE1-4C98-8B5F-3618C04774FC@delong.com> <4F978420.4040605@brightok.net> <281E89CB-A35F-47CE-8A2D-94B266717FFB@delong.com> <4F987B2E.4010707@brightok.net> <4F996E04.7090909@brightok.net> Message-ID: <4F99F6D0.40508@brightok.net> On 4/26/2012 7:09 PM, Jimmy Hess wrote: > ome "show" commands will show DHCP server usage, but not conclusive > proof of the utilization of the address space. Because the show > commands are not independently verifiable -- for all the RIR knows, > someone plugged in a big stack of $10 modems just to register with the > DHCP server. -- -JH I believe buying and connecting thousands of $10 modems to register with a DHCP server actually constitutes valid use of IP addresses. You would more likely need to create a script to spoof mac addresses in registering with the DHCP server over time to be in violation. Works about like a script that pulls names out of a phone book and assigns them to IP addresses in a report. The difference between the two is that it's easier to make the report than create a good dhcp script that will also utilize bandwidth and multiple interfaces or fill dhcp snooping tables and show up interfaces. The reason I'm completely for skipping all the extra paperwork and going straight to a meeting session is that it's easy to view the various screens depending on the ISP layout to show that a group of addresses are in use and much more difficult to cover all bases to defraud ARIN (not impossible, but much more difficult than forging customer names). Jack From jeff-kell at utc.edu Thu Apr 26 21:03:44 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 26 Apr 2012 22:03:44 -0400 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net> Message-ID: <4F99FE80.6010007@utc.edu> On 4/26/2012 5:44 PM, Andrew Latham wrote: > Yes its a major problem for the users unknowingly infected. To them > it will look like their Internet connection is down. Expect ISPs to > field lots of support calls. And what about the millions of users unknowingly infected with "something else" ?? These people need help, at least the "Ghost Click" victims will have a clue after July 9, unless we opt to extend our head-in-the-sand period. (We have enough trouble isolating/remediating issues among our relatively small user base, I'd hate to be facing a major ISP size support/remediation effort...) Does anyone have a plan? Jeff From thomas.m.king at gmail.com Thu Apr 26 23:45:28 2012 From: thomas.m.king at gmail.com (Thomas King) Date: Fri, 27 Apr 2012 06:45:28 +0200 Subject: Yahoo Mail: Contact Message-ID: Hi all, could someone from Yahoo Mail please contact me off-list? Thanks in advance, Thomas -- Dr. Thomas King audriga GmbH Spitalstr. 23A | 76227 Karlsruhe www.audriga.com | www.twitter.com/audriga +49 (0) 1577 1539262 Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Gesch?ftsf?hrer: Frank Dengler, Hans-J?rg Happel, Dr. Thomas King USt-ID: DE 279724142 From Michael_OReirdan at Cable.Comcast.com Fri Apr 27 05:41:34 2012 From: Michael_OReirdan at Cable.Comcast.com (O'Reirdan, Michael) Date: Fri, 27 Apr 2012 10:41:34 +0000 Subject: Operation Ghost Click In-Reply-To: <4F99FE80.6010007@utc.edu> References: <4F99C03A.30506@mompl.net> , <4F99FE80.6010007@utc.edu> Message-ID: Please look at www.dcwg.org Mike ________________________________________ From: Jeff Kell [jeff-kell at utc.edu] Sent: 26 April 2012 22:03 To: Andrew Latham Cc: NANOG list Subject: Re: Operation Ghost Click On 4/26/2012 5:44 PM, Andrew Latham wrote: > Yes its a major problem for the users unknowingly infected. To them > it will look like their Internet connection is down. Expect ISPs to > field lots of support calls. And what about the millions of users unknowingly infected with "something else" ?? These people need help, at least the "Ghost Click" victims will have a clue after July 9, unless we opt to extend our head-in-the-sand period. (We have enough trouble isolating/remediating issues among our relatively small user base, I'd hate to be facing a major ISP size support/remediation effort...) Does anyone have a plan? Jeff From cmadams at hiwaay.net Fri Apr 27 08:56:16 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 27 Apr 2012 08:56:16 -0500 Subject: JUNOS forwards IPv6 link-local packets Message-ID: <20120427135616.GA29251@hiwaay.net> I found out by accident yesterday that JUNOS routers will forward IPv6 packets with a link-local source address, in direct opposition of RFC 4291. To me, this seems to be a security hole that would be useful for DDoS attackers, giving them a way to send traffic that is difficult to trace back to the source. I try to be a good "net neighbor", using uRPF wherever possible (and other filters elsewhere) to make sure all packets coming from my network at least look valid, but this goes right by that. I posted over on juniper-nsp about this (more to see if I was just missing something) and got a response that it is a known thing. There's a closed Juniper PR, 556860, that says this affects all JUNOS devices except SRX (Trio platforms will get a fix starting with JUNOS 12.3). It doesn't sound like Juniper is going to fix this for the rest of us. I guess I'm mainly curious to see what others think about this. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jbates at brightok.net Fri Apr 27 09:16:17 2012 From: jbates at brightok.net (Jack Bates) Date: Fri, 27 Apr 2012 09:16:17 -0500 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <20120427135616.GA29251@hiwaay.net> References: <20120427135616.GA29251@hiwaay.net> Message-ID: <4F9AAA31.7010702@brightok.net> On 4/27/2012 8:56 AM, Chris Adams wrote: > I found out by accident yesterday that JUNOS routers will forward IPv6 > packets with a link-local source address, in direct opposition of RFC > 4291. To me, this seems to be a security hole that would be useful for > DDoS attackers, giving them a way to send traffic that is difficult to > trace back to the source. I try to be a good "net neighbor", using uRPF > wherever possible (and other filters elsewhere) to make sure all packets > coming from my network at least look valid, but this goes right by that. > Theoretically you can do a discard route and then uRPF should work with it. I'm not sure if it will kill the RE traffic, though. If it does, you'll have to have fail filters to allow it. :( Jack From cmadams at hiwaay.net Fri Apr 27 09:26:07 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 27 Apr 2012 09:26:07 -0500 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <4F9AAA31.7010702@brightok.net> References: <20120427135616.GA29251@hiwaay.net> <4F9AAA31.7010702@brightok.net> Message-ID: <20120427142607.GB29251@hiwaay.net> Once upon a time, Jack Bates said: > On 4/27/2012 8:56 AM, Chris Adams wrote: > >I found out by accident yesterday that JUNOS routers will forward IPv6 > >packets with a link-local source address, in direct opposition of RFC > >4291. To me, this seems to be a security hole that would be useful for > >DDoS attackers, giving them a way to send traffic that is difficult to > >trace back to the source. I try to be a good "net neighbor", using uRPF > >wherever possible (and other filters elsewhere) to make sure all packets > >coming from my network at least look valid, but this goes right by that. > > Theoretically you can do a discard route and then uRPF should work with > it. I'm not sure if it will kill the RE traffic, though. If it does, > you'll have to have fail filters to allow it. :( I don't think that will work, because there's an automatic direct route for fe80::/64 to all interfaces with family inet6 configured. The only way I see around it is to apply a firewall filter to all IPv6 interfaces that blocks anything with a source in fe80::/64 and destination _not_ in fe80::/64. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jbates at brightok.net Fri Apr 27 09:39:47 2012 From: jbates at brightok.net (Jack Bates) Date: Fri, 27 Apr 2012 09:39:47 -0500 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <20120427142607.GB29251@hiwaay.net> References: <20120427135616.GA29251@hiwaay.net> <4F9AAA31.7010702@brightok.net> <20120427142607.GB29251@hiwaay.net> Message-ID: <4F9AAFB3.7070609@brightok.net> On 4/27/2012 9:26 AM, Chris Adams wrote: > I don't think that will work, because there's an automatic direct > route for fe80::/64 to all interfaces with family inet6 configured. > The only way I see around it is to apply a firewall filter to all IPv6 > interfaces that blocks anything with a source in fe80::/64 and > destination _not_ in fe80::/64. fe80::/65 discard fe80:0:0:0:8000::/65 discard More specifics rule out over connected any day. Jack From bedard.phil at gmail.com Fri Apr 27 10:35:57 2012 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 27 Apr 2012 11:35:57 -0400 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <20120427135616.GA29251@hiwaay.net> Message-ID: Just since I had everything hooked up I did a quick test on IOS-XR 4.2.0 on an ASR9000 and found it also forwards v6 traffic with a link-local source address and a global destination address. The destination was a Juniper box which I tried to DoS using ICMPv6 echo requests. The 200:11ff:fe00:0 is an Ixia tester a couple IOS-XR hops away... 11:21:38.051256 In IP6 fe80::200:11ff:fe00:0 > 2001:578:101::2: ICMP6, echo request, seq 0, length 28 11:21:38.250659 In IP6 fe80::200:11ff:fe00:0 > 2001:578:101::2: ICMP6, echo request, seq 0, length 28 11:21:38.451093 In IP6 fe80::200:11ff:fe00:0 > 2001:578:101::2: ICMP6, echo request, seq 0, length 28 Which kicked in the junos ddos protection... Apr 27 11:29:12.527 2012 jddosd[1516]: DDOS_PROTOCOL_VIOLATION_SET: Protocol ICMPv6:aggregate is violated at fpc 7 for 1 times, started at 2012-04-27 11:29:07 EDT, last seen at 2012-04-27 11:29:07 EDT -Phil On 4/27/12 9:56 AM, "Chris Adams" wrote: >I found out by accident yesterday that JUNOS routers will forward IPv6 >packets with a link-local source address, in direct opposition of RFC >4291. To me, this seems to be a security hole that would be useful for >DDoS attackers, giving them a way to send traffic that is difficult to >trace back to the source. I try to be a good "net neighbor", using uRPF >wherever possible (and other filters elsewhere) to make sure all packets >coming from my network at least look valid, but this goes right by that. > >I posted over on juniper-nsp about this (more to see if I was just >missing something) and got a response that it is a known thing. There's >a closed Juniper PR, 556860, that says this affects all JUNOS devices >except SRX (Trio platforms will get a fix starting with JUNOS 12.3). It >doesn't sound like Juniper is going to fix this for the rest of us. > >I guess I'm mainly curious to see what others think about this. >-- >Chris Adams >Systems and Network Administrator - HiWAAY Internet Services >I don't speak for anybody but myself - that's enough trouble. > From randy at psg.com Fri Apr 27 11:17:36 2012 From: randy at psg.com (Randy Bush) Date: Fri, 27 Apr 2012 09:17:36 -0700 Subject: time sink 42 In-Reply-To: <4F3D712F.50304@blakjak.net> References: <4F3D712F.50304@blakjak.net> Message-ID: [ just reporting the conclusion ] > Many label makers (including Brother) use tapes that have a split up the > middle of the back layer, so you can peel it off half-at-a-time and not > fight with finding edges, etc. yesterday i was in the westin for the first time since my new cheapo label maker arrived. i got a brother PT-1290, $38 at newegg. for what i do, small and cheap and cheap are fine. the TZ style split-back label made life sooooo much easier. highly recommended. thanks to all who suggested. randy From cmadams at hiwaay.net Fri Apr 27 11:20:50 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 27 Apr 2012 11:20:50 -0500 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <4F9AAFB3.7070609@brightok.net> References: <20120427135616.GA29251@hiwaay.net> <4F9AAA31.7010702@brightok.net> <20120427142607.GB29251@hiwaay.net> <4F9AAFB3.7070609@brightok.net> Message-ID: <20120427162050.GC29251@hiwaay.net> Once upon a time, Jack Bates said: > fe80::/65 discard > fe80:0:0:0:8000::/65 discard > > More specifics rule out over connected any day. That would also kill any legitimate link-local traffic though. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jbates at brightok.net Fri Apr 27 11:31:32 2012 From: jbates at brightok.net (Jack Bates) Date: Fri, 27 Apr 2012 11:31:32 -0500 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <20120427162050.GC29251@hiwaay.net> References: <20120427135616.GA29251@hiwaay.net> <4F9AAA31.7010702@brightok.net> <20120427142607.GB29251@hiwaay.net> <4F9AAFB3.7070609@brightok.net> <20120427162050.GC29251@hiwaay.net> Message-ID: <4F9AC9E4.2070702@brightok.net> On 4/27/2012 11:20 AM, Chris Adams wrote: > Once upon a time, Jack Bates said: >> fe80::/65 discard >> fe80:0:0:0:8000::/65 discard >> >> More specifics rule out over connected any day. > That would also kill any legitimate link-local traffic though. Perhaps. I'm actually curious on that, as the rules for routing to link-local are very specialized. It might flag on uRPF for local traffic, but that can be overcome with a fail filter. Sending out from the RE could likely ignore the route, as it has to send to specific interfaces. Receiving on interfaces that don't have uRPF should still work as well. It's a theory and would have to be tested. Jack From tetherow at shwisp.net Fri Apr 27 12:22:10 2012 From: tetherow at shwisp.net (Sam Tetherow) Date: Fri, 27 Apr 2012 12:22:10 -0500 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net> <10BFFB88-881B-4C13-A039-C6A83C5943B1@ukbroadband.com> Message-ID: <4F9AD5C2.5030105@shwisp.net> On 04/26/2012 05:00 PM, Andrew Latham wrote: > On Thu, Apr 26, 2012 at 5:57 PM, Kyle Creyts wrote: >> http://www.fbi.gov/news/stories/2011/november/malware_110911/DNS-changer-malware.pdf >> >> On Apr 26, 2012 5:48 PM, "Leigh Porter" >> wrote: >>> >>> On 26 Apr 2012, at 22:47, "Andrew Latham" >>> > wrote: >>> >>> >>> On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart >>> > wrote: >>> >>> Yes its a major problem for the users unknowingly infected. To them >>> it will look like their Internet connection is down. Expect ISPs to >>> field lots of support s >>> >>> Is there a list of these temporary servers so I can see what customers are >>> using them (indicating infection) and head off a support call with some >>> contact? >>> >>> -- >>> Leigh > 85.255.112.0 through 85.255.127.255 > 67.210.0.0 through 67.210.15.255 > 93.188.160.0 through 93.188.167.255 > 77.67.83.0 through 77.67.83.255 > 213.109.64.0 through 213.109.79.255 > 64.28.176.0 through 64.28.191.255 > Or for those that don't want to do the math, here they are in CIDR notation 85.255.112.0/20 67.210.0.0/20 93.188.160.0/21 77.67.83.0/24 213.109.64.0/20 64.28.176.0/20 From betty at newnog.org Fri Apr 27 13:43:14 2012 From: betty at newnog.org (Betty Burke ) Date: Fri, 27 Apr 2012 14:43:14 -0400 Subject: [NANOG-announce] NANOG 55 Update Message-ID: Colleagues: NANOG 55 is just weeks away! NANOGers will be meeting June 3 ? 6, 2012 in Vancouver, Canada. Do not delay, be sure to register and take advantage of early Bird Registration which ends on April 29, 2012 (non-member $450, member $425, student $100). Also, make sure to have your Visa or valid passport to enter Canada, for more information click here . Be sure to visit the NANOG 55 highlightspage which features a list of activities planned thus far. The NANOG Program Committee received a number of great submissions and are very close to posting the tentative agenda, NANOG 55 will once again showcase a program packed with content of interest all. As you register for NANOG 55, be sure to reserve your hotel room at the Westin Bayshore . We look forward to a great meeting and seeing you in Vancouver! Should you have any questions, please direct them to nanog-support at nanog.org . Sincerely, Betty on behalf of the Board of Directors and Committees -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From cscora at apnic.net Fri Apr 27 13:44:27 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Apr 2012 04:44:27 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201204271844.q3RIiR2J014219@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Apr, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 407208 Prefixes after maximum aggregation: 172996 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 198106 Total ASes present in the Internet Routing Table: 40826 Prefixes per ASN: 9.97 Origin-only ASes present in the Internet Routing Table: 33106 Origin ASes announcing only one prefix: 15607 Transit ASes present in the Internet Routing Table: 5451 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 64 Max AS path prepend of ASN ( 9902) 56 Prefixes from unregistered ASNs in the Routing Table: 394 Unregistered ASNs in the Routing Table: 128 Number of 32-bit ASNs allocated by the RIRs: 2635 Number of 32-bit ASNs visible in the Routing Table: 2269 Prefixes from 32-bit ASNs in the Routing Table: 5659 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 110 Number of addresses announced to Internet: 2540346576 Equivalent to 151 /8s, 106 /16s and 156 /24s Percentage of available address space announced: 68.5 Percentage of allocated address space announced: 68.6 Percentage of available address space allocated: 99.9 Percentage of address space in use by end-sites: 92.5 Total number of prefixes smaller than registry allocations: 173699 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 99521 Total APNIC prefixes after maximum aggregation: 32245 APNIC Deaggregation factor: 3.09 Prefixes being announced from the APNIC address blocks: 96009 Unique aggregates announced from the APNIC address blocks: 39862 APNIC Region origin ASes present in the Internet Routing Table: 4684 APNIC Prefixes per ASN: 20.50 APNIC Region origin ASes announcing only one prefix: 1238 APNIC Region transit ASes present in the Internet Routing Table: 734 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 190 Number of APNIC addresses announced to Internet: 644227680 Equivalent to 38 /8s, 102 /16s and 34 /24s Percentage of available APNIC address space announced: 81.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 150278 Total ARIN prefixes after maximum aggregation: 76417 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 121331 Unique aggregates announced from the ARIN address blocks: 50436 ARIN Region origin ASes present in the Internet Routing Table: 15053 ARIN Prefixes per ASN: 8.06 ARIN Region origin ASes announcing only one prefix: 5724 ARIN Region transit ASes present in the Internet Routing Table: 1581 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 30 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 807268032 Equivalent to 48 /8s, 29 /16s and 238 /24s Percentage of available ARIN address space announced: 64.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 101788 Total RIPE prefixes after maximum aggregation: 53879 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 93665 Unique aggregates announced from the RIPE address blocks: 58385 RIPE Region origin ASes present in the Internet Routing Table: 16520 RIPE Prefixes per ASN: 5.67 RIPE Region origin ASes announcing only one prefix: 8040 RIPE Region transit ASes present in the Internet Routing Table: 2627 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1528 Number of RIPE addresses announced to Internet: 510941832 Equivalent to 30 /8s, 116 /16s and 90 /24s Percentage of available RIPE address space announced: 82.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 40893 Total LACNIC prefixes after maximum aggregation: 8250 LACNIC Deaggregation factor: 4.96 Prefixes being announced from the LACNIC address blocks: 40763 Unique aggregates announced from the LACNIC address blocks: 20273 LACNIC Region origin ASes present in the Internet Routing Table: 1592 LACNIC Prefixes per ASN: 25.60 LACNIC Region origin ASes announcing only one prefix: 439 LACNIC Region transit ASes present in the Internet Routing Table: 300 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 529 Number of LACNIC addresses announced to Internet: 99745160 Equivalent to 5 /8s, 241 /16s and 253 /24s Percentage of available LACNIC address space announced: 66.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8894 Total AfriNIC prefixes after maximum aggregation: 2137 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6962 Unique aggregates announced from the AfriNIC address blocks: 2224 AfriNIC Region origin ASes present in the Internet Routing Table: 534 AfriNIC Prefixes per ASN: 13.04 AfriNIC Region origin ASes announcing only one prefix: 166 AfriNIC Region transit ASes present in the Internet Routing Table: 120 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 31785728 Equivalent to 1 /8s, 229 /16s and 3 /24s Percentage of available AfriNIC address space announced: 47.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2485 11112 1010 Korea Telecom (KIX) 17974 1822 509 71 PT TELEKOMUNIKASI INDONESIA 7545 1679 301 88 TPG Internet Pty Ltd 4755 1584 386 158 TATA Communications formerly 9829 1261 1069 30 BSNL National Internet Backbo 7552 1169 1062 11 Vietel Corporation 9583 1145 84 490 Sify Limited 4808 1111 2050 319 CNCGROUP IP network: China169 24560 1027 385 167 Bharti Airtel Ltd., Telemedia 9498 954 291 65 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3425 3807 194 bellsouth.net, inc. 7029 3368 986 158 Windstream Communications Inc 18566 2091 382 179 Covad Communications 1785 1906 680 131 PaeTec Communications, Inc. 20115 1639 1566 619 Charter Communications 4323 1599 1044 383 Time Warner Telecom 22773 1580 2910 114 Cox Communications, Inc. 30036 1420 261 768 Mediacom Communications Corp 7018 1249 9774 818 AT&T WorldNet Services 11492 1186 216 364 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1679 544 16 Corbina telecom 2118 1304 97 14 EUnet/RELCOM Autonomous Syste 31148 681 37 9 FreeNet ISP 34984 681 188 173 BILISIM TELEKOM 6830 655 2215 426 UPC Distribution Services 12479 650 668 66 Uni2 Autonomous System 20940 636 206 498 Akamai Technologies European 8551 571 360 80 Bezeq International 3320 531 8441 397 Deutsche Telekom AG 2578 501 33 7 Demos, Moscow, Russia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1832 329 171 TVCABLE BOGOTA 28573 1804 1114 62 NET Servicos de Comunicao S.A 6503 1533 418 65 AVANTEL, S.A. 8151 1486 3000 345 UniNet S.A. de C.V. 7303 1362 829 187 Telecom Argentina Stet-France 26615 903 761 33 Tim Brasil S.A. 27947 685 74 98 Telconet S.A 11172 639 91 73 Servicios Alestra S.A de C.V 22047 582 326 15 VTR PUNTO NET S.A. 3816 572 242 100 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1305 958 13 TEDATA 24863 840 274 35 LINKdotNET AS number 6713 493 649 18 Itissalat Al-MAGHRIB 3741 265 921 223 The Internet Solution 12258 197 28 62 Vodacom Internet Company 33776 195 12 24 Starcomms Nigeria Limited 24835 179 80 8 RAYA Telecom - Egypt 16637 174 666 83 MTN Network Solutions 15706 169 32 6 Sudatel Internet Exchange Aut 29571 157 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3425 3807 194 bellsouth.net, inc. 7029 3368 986 158 Windstream Communications Inc 4766 2485 11112 1010 Korea Telecom (KIX) 18566 2091 382 179 Covad Communications 1785 1906 680 131 PaeTec Communications, Inc. 10620 1832 329 171 TVCABLE BOGOTA 17974 1822 509 71 PT TELEKOMUNIKASI INDONESIA 28573 1804 1114 62 NET Servicos de Comunicao S.A 7545 1679 301 88 TPG Internet Pty Ltd 8402 1679 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3368 3210 Windstream Communications Inc 18566 2091 1912 Covad Communications 1785 1906 1775 PaeTec Communications, Inc. 17974 1822 1751 PT TELEKOMUNIKASI INDONESIA 28573 1804 1742 NET Servicos de Comunicao S.A 8402 1679 1663 Corbina telecom 10620 1832 1661 TVCABLE BOGOTA 7545 1679 1591 TPG Internet Pty Ltd 4766 2485 1475 Korea Telecom (KIX) 6503 1533 1468 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.3.0.0/16 41733 JSC "Z-Telecom" 5.8.184.0/21 29286 Skylogic Italia Autonomous Sy 5.16.0.0/14 41733 JSC "Z-Telecom" 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:235 /13:460 /14:832 /15:1489 /16:12244 /17:6243 /18:10539 /19:20613 /20:29018 /21:30083 /22:40581 /23:38021 /24:213032 /25:1196 /26:1429 /27:784 /28:166 /29:67 /30:17 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3026 3368 Windstream Communications Inc 6389 2143 3425 bellsouth.net, inc. 18566 2040 2091 Covad Communications 10620 1709 1832 TVCABLE BOGOTA 8402 1657 1679 Corbina telecom 30036 1364 1420 Mediacom Communications Corp 6503 1291 1533 AVANTEL, S.A. 11492 1149 1186 Cable One 8452 1105 1305 TEDATA 1785 1072 1906 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:539 2:550 4:14 6:3 8:406 12:1999 13:1 14:611 15:12 16:3 17:5 20:23 23:167 24:1761 27:1273 31:952 32:57 33:2 34:2 36:8 37:421 38:800 40:120 41:3112 42:135 44:3 46:1481 47:3 49:404 50:538 52:13 54:8 55:11 56:3 57:31 58:965 59:520 60:254 61:1277 62:976 63:1990 64:4173 65:2255 66:4486 67:2021 68:1166 69:3189 70:903 71:466 72:1825 74:2602 75:494 76:318 77:941 78:1012 79:487 80:1209 81:902 82:673 83:550 84:482 85:1210 86:412 87:929 88:340 89:1630 90:291 91:4769 92:520 93:1507 94:1510 95:894 96:358 97:315 98:895 99:37 100:7 101:181 103:1030 106:102 107:191 108:268 109:1306 110:746 111:923 112:454 113:600 114:642 115:807 116:929 117:719 118:909 119:1230 120:354 121:692 122:1676 123:1104 124:1364 125:1243 128:562 129:196 130:255 131:626 132:180 133:22 134:242 135:62 136:214 137:177 138:355 139:163 140:492 141:242 142:407 143:392 144:523 145:74 146:495 147:279 148:768 149:306 150:159 151:181 152:464 153:172 154:12 155:399 156:215 157:375 158:179 159:539 160:338 161:262 162:348 163:191 164:580 165:399 166:573 167:468 168:820 169:128 170:859 171:127 172:2 173:1756 174:570 175:437 176:686 177:654 178:1349 180:1192 181:79 182:826 183:289 184:462 185:1 186:2247 187:1056 188:1239 189:1791 190:5513 192:6010 193:5539 194:4658 195:3600 196:1271 197:129 198:3660 199:4543 200:5806 201:1934 202:8518 203:8599 204:4327 205:2498 206:2746 207:2796 208:4057 209:3621 210:2736 211:1478 212:1983 213:1927 214:848 215:104 216:5131 217:1533 218:545 219:318 220:1230 221:558 222:323 223:336 End of report From morrowc.lists at gmail.com Fri Apr 27 14:16:27 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Apr 2012 15:16:27 -0400 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <4F9AC9E4.2070702@brightok.net> References: <20120427135616.GA29251@hiwaay.net> <4F9AAA31.7010702@brightok.net> <20120427142607.GB29251@hiwaay.net> <4F9AAFB3.7070609@brightok.net> <20120427162050.GC29251@hiwaay.net> <4F9AC9E4.2070702@brightok.net> Message-ID: you know what I love? address selection rules, or rather the fact that we have to have them in this new ip protocol :( bugs and code problems and operational headaches and filters and ... :( On Fri, Apr 27, 2012 at 12:31 PM, Jack Bates wrote: > On 4/27/2012 11:20 AM, Chris Adams wrote: >> >> Once upon a time, Jack Bates ?said: >>> >>> fe80::/65 discard >>> fe80:0:0:0:8000::/65 discard >>> >>> More specifics rule out over connected any day. >> >> That would also kill any legitimate link-local traffic though. > > > Perhaps. I'm actually curious on that, as the rules for routing to > link-local are very specialized. It might flag on uRPF for local traffic, > but that can be overcome with a fail filter. Sending out from the RE could > likely ignore the route, as it has to send to specific interfaces. Receiving > on interfaces that don't have uRPF should still work as well. > > It's a theory and would have to be tested. > > Jack > From cabenth at gmail.com Fri Apr 27 14:26:45 2012 From: cabenth at gmail.com (eric clark) Date: Fri, 27 Apr 2012 12:26:45 -0700 Subject: Anyone seeing traffic flow problems in the SanFrancisco / San Jose areas? Message-ID: I was working with a vendor down there and couldn't get files in or out to save our lives. Additionally, he was having trouble locally. I didn't see anything on the pulse site. From baldwinmathew at gmail.com Fri Apr 27 14:28:59 2012 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Fri, 27 Apr 2012 12:28:59 -0700 Subject: Anyone seeing traffic flow problems in the SanFrancisco / San Jose areas? In-Reply-To: References: Message-ID: Yes, we were seeing issues out of SF, too, however those have cleared as of now. -matt On Fri, Apr 27, 2012 at 12:26 PM, eric clark wrote: > I was working with a vendor down there and couldn't get files in or out to > save our lives. Additionally, he was having trouble locally. > > I didn't see anything on the pulse site. > From morrowc.lists at gmail.com Fri Apr 27 15:12:32 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Apr 2012 16:12:32 -0400 Subject: Anyone seeing traffic flow problems in the SanFrancisco / San Jose areas? In-Reply-To: References: Message-ID: outageslist On Fri, Apr 27, 2012 at 3:28 PM, Matt Baldwin wrote: > Yes, we were seeing issues out of SF, too, however those have cleared as of > now. > > -matt > > On Fri, Apr 27, 2012 at 12:26 PM, eric clark wrote: > >> I was working with a vendor down there and couldn't get files in or out to >> save our lives. Additionally, he was having trouble locally. >> >> I didn't see anything on the pulse site. >> From cidr-report at potaroo.net Fri Apr 27 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Apr 2012 22:00:00 GMT Subject: BGP Update Report Message-ID: <201204272200.q3RM00Ca002783@wattle.apnic.net> BGP Update Report Interval: 19-Apr-12 -to- 26-Apr-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 50753 2.8% 39.7 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS24186 41863 2.3% 747.6 -- RAILTEL-AS-IN RailTel Corporation of India Ltd., Internet Service Provider, New Delhi 3 - AS9829 40602 2.3% 41.2 -- BSNL-NIB National Internet Backbone 4 - AS12479 27229 1.5% 225.0 -- UNI2-AS France Telecom Espana SA 5 - AS32528 26218 1.5% 4369.7 -- ABBOTT Abbot Labs 6 - AS8151 21499 1.2% 19.2 -- Uninet S.A. de C.V. 7 - AS7552 21398 1.2% 18.6 -- VIETEL-AS-AP Vietel Corporation 8 - AS13118 20797 1.2% 1890.6 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS19422 19216 1.1% 204.4 -- Telefonica Moviles del Uruguay SA 10 - AS5800 17795 1.0% 72.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS6713 15744 0.9% 34.8 -- IAM-AS 12 - AS2118 15586 0.9% 12.0 -- RELCOM-AS OOO "NPO Relcom" 13 - AS786 15135 0.8% 75.3 -- JANET The JNT Association 14 - AS24560 15117 0.8% 14.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 15 - AS26615 13229 0.7% 14.7 -- Tim Celular S.A. 16 - AS5976 12960 0.7% 107.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - AS20799 12705 0.7% 1155.0 -- DATANET-AS Datanet.co.uk Ltd 18 - AS45899 12487 0.7% 38.0 -- VNPT-AS-VN VNPT Corp 19 - AS44798 11894 0.7% 11894.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 20 - AS1600 11265 0.6% 60.9 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS44798 11894 0.7% 11894.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 2 - AS32528 26218 1.5% 4369.7 -- ABBOTT Abbot Labs 3 - AS13118 20797 1.2% 1890.6 -- ASN-YARTELECOM OJSC Rostelecom 4 - AS11553 1313 0.1% 1313.0 -- MANNATECH-AS MANNATECH 5 - AS20799 12705 0.7% 1155.0 -- DATANET-AS Datanet.co.uk Ltd 6 - AS17408 3300 0.2% 1100.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 7 - AS55665 1081 0.1% 1081.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 8 - AS32541 1041 0.1% 1041.0 -- SAIRB-AS - Schulman Associates Institutional Review Board, Inc. 9 - AS27624 2016 0.1% 1008.0 -- AS-ELCA-CWO - ELCA 10 - AS34043 895 0.1% 895.0 -- RISS Internet Security Systems SRL 11 - AS57767 805 0.0% 805.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network 12 - AS24029 800 0.0% 800.0 -- NIXI-IN-AS NIXI is an IXP in India 13 - AS58074 757 0.0% 757.0 -- MIVIROM-AS MIVIROM COM PROD SRL 14 - AS24186 41863 2.3% 747.6 -- RAILTEL-AS-IN RailTel Corporation of India Ltd., Internet Service Provider, New Delhi 15 - AS36029 737 0.0% 737.0 -- CASAS - CASAS 16 - AS32398 1838 0.1% 612.7 -- REALNET-ASN-1 17 - AS3 588 0.0% 366.0 -- ARKOON Arkoon Network Security SA 18 - AS36980 577 0.0% 577.0 -- JOHNHOLT-ASN 19 - AS54011 559 0.0% 559.0 -- NYDH - New York Downtown Hospital 20 - AS28306 4328 0.2% 541.0 -- TC Net Inform?tica e Telecomunica??es LTDA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 13100 0.7% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 13100 0.7% AS32528 -- ABBOTT Abbot Labs 3 - 91.202.212.0/22 11894 0.6% AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 4 - 46.237.0.0/19 10228 0.5% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 5 - 205.107.121.0/24 9904 0.5% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - 95.106.160.0/19 9461 0.5% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 7 - 62.36.252.0/22 8118 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 62.36.249.0/24 6453 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.241.0/24 6078 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 62.36.210.0/24 5949 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 11 - 194.63.9.0/24 5810 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 12 - 122.161.0.0/16 3722 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 13 - 202.56.215.0/24 3596 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 14 - 182.64.0.0/16 3468 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 15 - 202.153.174.0/24 3285 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 16 - 41.43.147.0/24 2904 0.1% AS8452 -- TE-AS TE-AS 17 - 192.100.162.0/24 2794 0.1% AS8151 -- Uninet S.A. de C.V. 18 - 146.16.176.0/20 2654 0.1% AS6006 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - 200.23.110.0/24 2293 0.1% AS8151 -- Uninet S.A. de C.V. 20 - 200.23.112.0/24 2291 0.1% AS8151 -- Uninet S.A. de C.V. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 27 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Apr 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201204272200.q3RM00Su002777@wattle.apnic.net> This report has been generated at Fri Apr 27 21:12:53 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 20-04-12 409267 239062 21-04-12 409368 239191 22-04-12 409019 239179 23-04-12 409134 239224 24-04-12 409449 239428 25-04-12 409589 239303 26-04-12 409530 239875 27-04-12 411252 239888 AS Summary 40933 Number of ASes in routing system 17094 Number of ASes announcing only one prefix 3425 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 112051488 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 27Apr12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 409873 239469 170404 41.6% All ASes AS6389 3425 197 3228 94.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3409 1780 1629 47.8% WINDSTREAM - Windstream Communications Inc AS22773 1581 123 1458 92.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2485 1030 1455 58.6% KIXS-AS-KR Korea Telecom AS18566 2091 705 1386 66.3% COVAD - Covad Communications Co. AS28573 1806 495 1311 72.6% NET Servicos de Comunicao S.A. AS2118 1304 14 1290 98.9% RELCOM-AS OOO "NPO Relcom" AS4323 1600 385 1215 75.9% TWTC - tw telecom holdings, inc. AS1785 1909 808 1101 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1576 532 1044 66.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS10620 1847 855 992 53.7% Telmex Colombia S.A. AS7552 1169 228 941 80.5% VIETEL-AS-AP Vietel Corporation AS7303 1362 441 921 67.6% Telecom Argentina S.A. AS26615 903 33 870 96.3% Tim Celular S.A. AS8151 1489 666 823 55.3% Uninet S.A. de C.V. AS18101 948 159 789 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1111 351 760 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17974 1822 1094 728 40.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS9394 842 146 696 82.7% CRNET CHINA RAILWAY Internet(CRNET) AS7545 1678 1015 663 39.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1094 458 636 58.1% LEVEL3 Level 3 Communications AS13977 763 127 636 83.4% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS30036 1421 798 623 43.8% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17676 691 75 616 89.1% GIGAINFRA Softbank BB Corp. AS19262 997 401 596 59.8% VZGNI-TRANSIT - Verizon Online LLC AS22561 992 405 587 59.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 1021 444 577 56.5% GBLX Global Crossing Ltd. AS24560 1027 454 573 55.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4780 823 264 559 67.9% SEEDNET Digital United Inc. AS4804 651 96 555 85.3% MPX-AS Microplex PTY LTD Total 43837 14579 29258 66.7% Top 30 total Possible Bogus Routes 5.3.0.0/16 AS41733 ZTELECOM-AS Z-Telecom ltd. 5.16.0.0/14 AS41733 ZTELECOM-AS Z-Telecom ltd. 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From vixie at isc.org Fri Apr 27 17:05:17 2012 From: vixie at isc.org (Paul Vixie) Date: Fri, 27 Apr 2012 22:05:17 +0000 Subject: rpki vs. secure dns? Message-ID: <4F9B181D.30606@isc.org> http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem > "The problem: Border Gateway Protocol (BGP) enables routers to > communicate about the best path to other networks, but routers don't > verify the route 'announcements.' When routing problems erupt, 'it's > very difficult to tell if this is fat fingering on a router or > malicious > ,' > said Joe Gersch, chief operating officer for Secure64, a company that > makes Domain Name System (DNS) server software. In a well-known > incident, Pakistan Telecom made an error with BGP after Pakistan's > government ordered in 2008 that ISPs block YouTube, which ended up > knocking Google's service offline > . > A solution exists, but it's complex, and deployment has been slow. Now > experts have found an easier way." this seems late, compared to the various commitments made to rpki in recent years. is anybody taking it seriously? From cb.list6 at gmail.com Fri Apr 27 17:16:16 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 27 Apr 2012 15:16:16 -0700 Subject: rpki vs. secure dns? In-Reply-To: <4F9B181D.30606@isc.org> References: <4F9B181D.30606@isc.org> Message-ID: On Apr 27, 2012 3:05 PM, "Paul Vixie" wrote: > > http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem > > > "The problem: Border Gateway Protocol (BGP) enables routers to > > communicate about the best path to other networks, but routers don't > > verify the route 'announcements.' When routing problems erupt, 'it's > > very difficult to tell if this is fat fingering on a router or > > malicious > > < http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem >,' > > said Joe Gersch, chief operating officer for Secure64, a company that > > makes Domain Name System (DNS) server software. In a well-known > > incident, Pakistan Telecom made an error with BGP after Pakistan's > > government ordered in 2008 that ISPs block YouTube, which ended up > > knocking Google's service offline > > < http://slashdot.org/story/08/02/25/1322252/pakistan-youtube-block-breaks-the-world >. > > A solution exists, but it's complex, and deployment has been slow. Now > > experts have found an easier way." > > this seems late, compared to the various commitments made to rpki in > recent years. is anybody taking it seriously? > Taking what seriously ? The commitments to rpki you speak off ? Late is a relative term. It does not matter if the cat is white or black, as long as it cathes the rat. CB From ryanczak at gmail.com Fri Apr 27 17:16:38 2012 From: ryanczak at gmail.com (Matt Ryanczak) Date: Fri, 27 Apr 2012 18:16:38 -0400 Subject: rpki vs. secure dns? In-Reply-To: <4F9B181D.30606@isc.org> References: <4F9B181D.30606@isc.org> Message-ID: <4F9B1AC6.1060108@gmail.com> On 04/27/2012 06:05 PM, Paul Vixie wrote: > this seems late, compared to the various commitments made to rpki in > recent years. is anybody taking it seriously? first thing that sprung to mind was this: http://www.cafepress.com.au/nxdomain From jeroen at mompl.net Fri Apr 27 18:50:11 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 27 Apr 2012 16:50:11 -0700 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net> , <4F99FE80.6010007@utc.edu> Message-ID: <4F9B30B3.5090000@mompl.net> O'Reirdan, Michael wrote: > Please look at www.dcwg.org Thanks all for the information. It looks like the practical upshot is that computers that have been infected and not yet fixed may loose the ability to resolve names into IP addresses starting sometime after July 9, which is when the replacement nameservers are supposed to be stopped. That in and of itself is quite a nuisance for the individual as well as the ISP helldesks but it could have been worse. I would certainly not call it "Internet doomsday". Greetings, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, April 27, 2012 21:51:23 UTC Location: Prince Edward Islands region Latitude: -41.1063; Longitude: 43.4278 Depth: 10.00 km From apishdadi at gmail.com Fri Apr 27 19:35:51 2012 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Fri, 27 Apr 2012 19:35:51 -0500 Subject: Operation Ghost Click In-Reply-To: <4F9B30B3.5090000@mompl.net> References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> <4F9B30B3.5090000@mompl.net> Message-ID: <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> If the user is stupid enough to be infected for that long I think it's a good thing they get cut off from the net , should be a policy of all ISPs , If your infected then you lose privilege to get online and thus you can't scan and infect other idiots or become a ddos tool for the script kiddies. I for one say turn em off!!!! Thanks, Ameen Pishdadi On Apr 27, 2012, at 6:50 PM, Jeroen van Aart wrote: > O'Reirdan, Michael wrote: >> Please look at www.dcwg.org > > Thanks all for the information. > > It looks like the practical upshot is that computers that have been infected and not yet fixed may loose the ability to resolve names into IP addresses starting sometime after July 9, which is when the replacement nameservers are supposed to be stopped. > > That in and of itself is quite a nuisance for the individual as well as the ISP helldesks but it could have been worse. I would certainly not call it "Internet doomsday". > > Greetings, > Jeroen > > -- > Earthquake Magnitude: 4.9 > Date: Friday, April 27, 2012 21:51:23 UTC > Location: Prince Edward Islands region > Latitude: -41.1063; Longitude: 43.4278 > Depth: 10.00 km > From ryan.landry at gmail.com Fri Apr 27 20:15:55 2012 From: ryan.landry at gmail.com (ryanL) Date: Fri, 27 Apr 2012 18:15:55 -0700 Subject: Operation Ghost Click In-Reply-To: <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> <4F9B30B3.5090000@mompl.net> <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> Message-ID: On Fri, Apr 27, 2012 at 5:35 PM, Ameen Pishdadi wrote: > If the user is stupid enough to be infected for that long I think it's a good thing they get cut off from the net , should be a policy of all ISPs , If your infected then you lose privilege to get online and thus you can't scan and infect other idiots or become a ddos tool for the script kiddies. I for one say turn em off!!!! > > Thanks, > Ameen Pishdadi you're obviously lucky, and don't have "stupid" grandparents. From apishdadi at gmail.com Fri Apr 27 20:29:07 2012 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Fri, 27 Apr 2012 20:29:07 -0500 Subject: Operation Ghost Click In-Reply-To: References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> <4F9B30B3.5090000@mompl.net> <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> Message-ID: <4321B0BA-6816-4B32-B991-10B3F0FF2EB5@gmail.com> Nope there dead unfortunately but if they were alive I'd clean up there machines maybe give them chrome books something idiot proof Thanks, Ameen Pishdadi On Apr 27, 2012, at 8:15 PM, ryanL wrote: > On Fri, Apr 27, 2012 at 5:35 PM, Ameen Pishdadi wrote: >> If the user is stupid enough to be infected for that long I think it's a good thing they get cut off from the net , should be a policy of all ISPs , If your infected then you lose privilege to get online and thus you can't scan and infect other idiots or become a ddos tool for the script kiddies. I for one say turn em off!!!! >> >> Thanks, >> Ameen Pishdadi > > you're obviously lucky, and don't have "stupid" grandparents. From Valdis.Kletnieks at vt.edu Fri Apr 27 21:17:10 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Apr 2012 22:17:10 -0400 Subject: Operation Ghost Click In-Reply-To: Your message of "Fri, 27 Apr 2012 19:35:51 -0500." <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> <4F9B30B3.5090000@mompl.net> <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> Message-ID: <3530.1335579430@turing-police.cc.vt.edu> On Fri, 27 Apr 2012 19:35:51 -0500, Ameen Pishdadi said: > If the user is stupid enough to be infected for that long And they'd know they were infected, how, exactly? (Think carefully before answering that, and keep in mind that although *you* may be the world's greatest IT specialist, the average Joe Sixpack wants to surf the web and read his e-mail, and does *not* understand (or even *want* to) very much about computer security). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mike-nanog at tiedyenetworks.com Fri Apr 27 21:29:48 2012 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 27 Apr 2012 19:29:48 -0700 Subject: Need spamcop/ironport security contact Message-ID: <4F9B561C.8010007@tiedyenetworks.com> I have a security incident to report and need to make contact with a senior level contact responsible for spamcop/ironport immediately. Thank you. From Valdis.Kletnieks at vt.edu Fri Apr 27 22:41:57 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Apr 2012 23:41:57 -0400 Subject: Need spamcop/ironport security contact In-Reply-To: Your message of "Fri, 27 Apr 2012 19:29:48 -0700." <4F9B561C.8010007@tiedyenetworks.com> References: <4F9B561C.8010007@tiedyenetworks.com> Message-ID: <6836.1335584517@turing-police.cc.vt.edu> On Fri, 27 Apr 2012 19:29:48 -0700, Mike said: > I have a security incident to report and need to make contact with a > senior level contact responsible for spamcop/ironport immediately. And you need a *senior* level contact, why? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From apishdadi at gmail.com Fri Apr 27 23:14:40 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Fri, 27 Apr 2012 23:14:40 -0500 Subject: Operation Ghost Click In-Reply-To: <7292.1335585345@turing-police.cc.vt.edu> References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> <4F9B30B3.5090000@mompl.net> <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> <3530.1335579430@turing-police.cc.vt.edu> <7292.1335585345@turing-police.cc.vt.edu> Message-ID: At some point in like 10 years when all the computer illiterate people are gone there will be no more excuses for not being educated on malware and viruses. While I understand the ISP doesn't want to possibly cut into there profit margins they could easily put in place monitoring tools that can detect network traffic that is malware bound and reach out to the customer by email, phone and if need be by person. How much of tax payer money is spent to pay these FEDERAL (F.B.I.) agents to sit here and baby sit these computer ignorant and illiterate people for 6 months? So for the big ISPs like comcast i should pay out of my tax money because they cannot properly enforce a network policy that would require them to actually give a crap what is coming out of there network? There is always going to be viruses and malware, they will find ways to get them through but for heavens sake why would we if identified leave millions of compromised machines online with an attempt to do a cleanup? YOU as a network operator have a responsiblity to the other 40,000 AUTONOMOUS network to make sure your not polluting our private network infrastructure with garbage coming from your users and network. Clean up your mess. Like we will not tolerate spammers being housed on 'hosting' networks why should tolerate malware and infections coming from ISP's??? How much money is spent cleaning up hacked word press servers and udp.pl scripts... This is much bigger issue then at any cost making sure a user can get on to facebook to upload a picture of there cat sleeping upside down. If we enforced a proper policy and held network activity to certain standards the ISP's would fix the issue of ignorant users themselves by #1 educating there users , #2 implementing network monitoring on there outbound traffic to identify sources of infected and compromised machines, #3 implementing a cleanup policy, #4 letting the end user know they have a responsibility to make sure the machines they access the network from are clean and to do checks and to do there antivirus updates and os updates. Oh yah, and if we got all these 'supporting' DNS servers up why not just direct ALL users of it, who are clearly infected to a temporary page that will enlighten the customer that they are infected and give them instructions on clean up and give them a deadline of when there service will stop......... How hard is that? On Fri, Apr 27, 2012 at 10:55 PM, wrote: > On Fri, 27 Apr 2012 21:39:20 -0500, you said: > > > Is it not detected by the common anti-virus software vendors? If the > > This assumes that the computer hasn't been hit by something *else* that > disables the user's AV software. Remember, multiple infections are > *common*. > > > internet stopped working on my computer i would reach out to someone who > > knew how to fix it, keeping these people online and spreading the malware > > helps how?? > > The point is that the internet *didn't* stop working, so they have no > reason to > reach out yet. > > And no, you can't just blindly cut the users off and make them call the > ISP for > several reasons: > > 1) At that point, the ISP incurs an expense to fix a problem they didn't > cause. > Remember that margins on most consumer-grade Internet accounts are pretty > thin, > and one long support call can wipe out the profit. So explain why the ISP > wants to cut off a user who makes them $10/year profit, and spend $30 or > more > handling the support call, when they aren't in the business of providing > security services to end users? > > 2) If the user has no POTS, cutting them off may have just cut off their > 911 > service. You want to take that risk? > > 3) Many times, there are multiple customer computers behind a NAT. Do you > really want the hassle of an irate user calling in because you just broke > the > dad's VPN to work, because one of their kids has some cruft on their > computer? > (And no, don't try to tell them they should have bought business class > service > or similar crap, that *will* lose you a customer). > > So explain why the ISP wants to cut off the user, when it will cost them > money, and possibly a customer? > From apishdadi at gmail.com Fri Apr 27 23:33:52 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Fri, 27 Apr 2012 23:33:52 -0500 Subject: Operation Ghost Click In-Reply-To: <7292.1335585345@turing-police.cc.vt.edu> References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> <4F9B30B3.5090000@mompl.net> <3796620A-AF09-4C95-BF00-AD8D2B019507@gmail.com> <3530.1335579430@turing-police.cc.vt.edu> <7292.1335585345@turing-police.cc.vt.edu> Message-ID: On Fri, Apr 27, 2012 at 10:55 PM, wrote: > On Fri, 27 Apr 2012 21:39:20 -0500, you said: > > > 3) Many times, there are multiple customer computers behind a NAT. Do you > really want the hassle of an irate user calling in because you just broke > the > dad's VPN to work, because one of their kids has some cruft on their > computer? > (And no, don't try to tell them they should have bought business class > service > or similar crap, that *will* lose you a customer). > > > The malware isn't infecting the end-uses router therefore if there is multiple users behind that NAT'd router as long as there not infected they won't be shut off when those DNS servers go dark. And if daddy is dumb enough to let his 8 year old son use his PC or laptop w/o proper monitoring and gets infected thats his fault. I know I dont let my 10 year old use my work computers , and he knows how to code , but he is still a child and clicks stupid things. Your basically telling me the ISPs should not take any responsibility, well then how can we get pissed off when a host lets a spammer spam for a week straight and is aware and doesn't shut them off, or notices a DDOS attack is stemming from there network, a customer has 5-6 servers he pays for with unmetered gigabit ports and is clearly blasting someone to hell and back with spoofed packets , but because there margins are so thin they shouldn't turn him off and cancel him so they do not have to cut into there 'margins'... In the network world your either on the content side or the eyeball side, and the eyeball networks seem to have double standards when it comes to network abuse. Until this ends and the double standards stop the amount of malware and attacks will never go decrease. I say to your 'it costs the isp money' to do cleanup, that it costs content providers money to do cleanup of constantly being scanned and probed and hacked by what is mostly hacked end-user machines who got owned browsing the internet because they went to a website that had a virus installed by another end-users machine who was compromised the same way, its a vicious circle and as an operator of a content provider im tired of the other half of the internet not taking there share of the responsibility. /End of rant.. From lsc at prgmr.com Sat Apr 28 02:18:41 2012 From: lsc at prgmr.com (Luke S. Crawford) Date: Sat, 28 Apr 2012 03:18:41 -0400 Subject: Squeezing IPs out of ARIN In-Reply-To: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> References: <75305ce04e4a896ddb8f307bee34b7a8@thecpaneladmin.com> Message-ID: <20120428071841.GA28475@luke.xen.prgmr.com> On Tue, Apr 24, 2012 at 01:32:17PM -0400, admin at thecpaneladmin.com wrote: > Anyone have any tips for getting IPs from ARIN? For an end-user > allocation they are requesting that we provide customer names for > existing allocations, which is information that will take a while to > obtain. They are insisting that this is standard process and something > that everyone does when requesting IPs. Has anyone actually had to do > this? I have. clearly, I should have asked, or looked closer, but when I started this mess? it was not at all clear to me that ARIN saw things that went into a home as 'residential' and everything else as 'business' - but from my reading and their reactions to my questions, that's how they see it. If it's in a data center and not in a residence, you need to give them a name (human or business) for every reassigned IP, even if the reassignment is a /32. Probably the majority of my VPSs? personal use, but not residential. I started with changing the privacy policy, and blogged about it, asking for at least 80% of the people to opt-in. Maybe 2% did. I gave it months, then I emailed everyone, asking them to opt-out. I gave them two weeks, maybe 2% did. So yeah; eh, nobody got mad at me for it, and I think some people were impressed that I emailed them when I made such a large change to the privacy policy (that isn't expected?) so I guess it all turned out okay, but yeah. ARIN wants a name of some sort for every /32. (Now, I just did a query against my billing database and returned the business name and only returned the human name if there was no business name.) From owen at delong.com Sat Apr 28 03:09:28 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Apr 2012 01:09:28 -0700 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: References: <20120427135616.GA29251@hiwaay.net> <4F9AAA31.7010702@brightok.net> <20120427142607.GB29251@hiwaay.net> <4F9AAFB3.7070609@brightok.net> <20120427162050.GC29251@hiwaay.net> <4F9AC9E4.2070702@brightok.net> Message-ID: <31C80DA1-43BD-4D12-BC82-B6A6C76FDE2D@delong.com> We kind of needed them in IPv4, though not universally. At least in IPv6, we have them. Owen On Apr 27, 2012, at 12:16 PM, Christopher Morrow wrote: > you know what I love? address selection rules, or rather the fact that > we have to have them in this new ip protocol :( > > bugs and code problems and operational headaches and filters and ... :( > > On Fri, Apr 27, 2012 at 12:31 PM, Jack Bates wrote: >> On 4/27/2012 11:20 AM, Chris Adams wrote: >>> >>> Once upon a time, Jack Bates said: >>>> >>>> fe80::/65 discard >>>> fe80:0:0:0:8000::/65 discard >>>> >>>> More specifics rule out over connected any day. >>> >>> That would also kill any legitimate link-local traffic though. >> >> >> Perhaps. I'm actually curious on that, as the rules for routing to >> link-local are very specialized. It might flag on uRPF for local traffic, >> but that can be overcome with a fail filter. Sending out from the RE could >> likely ignore the route, as it has to send to specific interfaces. Receiving >> on interfaces that don't have uRPF should still work as well. >> >> It's a theory and would have to be tested. >> >> Jack >> From waehlisch at ieee.org Sat Apr 28 03:55:08 2012 From: waehlisch at ieee.org (Matthias Waehlisch) Date: Sat, 28 Apr 2012 10:55:08 +0200 Subject: rpki vs. secure dns? In-Reply-To: <4F9B181D.30606@isc.org> References: <4F9B181D.30606@isc.org> Message-ID: line 408 ff. in the IETF 83 SIDR minutes * http://www.ietf.org/proceedings/83/minutes/minutes-83-sidr.txt Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Fri, 27 Apr 2012, Paul Vixie wrote: > http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem > > > "The problem: Border Gateway Protocol (BGP) enables routers to > > communicate about the best path to other networks, but routers don't > > verify the route 'announcements.' When routing problems erupt, 'it's > > very difficult to tell if this is fat fingering on a router or > > malicious > > ,' > > said Joe Gersch, chief operating officer for Secure64, a company that > > makes Domain Name System (DNS) server software. In a well-known > > incident, Pakistan Telecom made an error with BGP after Pakistan's > > government ordered in 2008 that ISPs block YouTube, which ended up > > knocking Google's service offline > > . > > A solution exists, but it's complex, and deployment has been slow. Now > > experts have found an easier way." > > this seems late, compared to the various commitments made to rpki in > recent years. is anybody taking it seriously? > > From fw at deneb.enyo.de Sat Apr 28 04:56:51 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Apr 2012 11:56:51 +0200 Subject: rpki vs. secure dns? In-Reply-To: <4F9B181D.30606@isc.org> (Paul Vixie's message of "Fri, 27 Apr 2012 22:05:17 +0000") References: <4F9B181D.30606@isc.org> Message-ID: <87ipgk2n8c.fsf@mid.deneb.enyo.de> * Paul Vixie: > this seems late, compared to the various commitments made to rpki in > recent years. is anybody taking it seriously? The idea as such isn't new, this has been floating around for four years or more, including at least one Internet draft, draft-donnerhacke-sidr-bgp-verification-dnssec. I don't know if we can get RPKI to deployment because RIPE and RIPE NCC have rather serious issues with it. On the other hand, there doesn't seem to be anything else which keeps RIRs relevant in the post-scarcity world, so we'll see what happens. From fw at deneb.enyo.de Sat Apr 28 05:01:38 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Apr 2012 12:01:38 +0200 Subject: Operation Ghost Click In-Reply-To: <4F99FE80.6010007@utc.edu> (Jeff Kell's message of "Thu, 26 Apr 2012 22:03:44 -0400") References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> Message-ID: <87ehr82n0d.fsf@mid.deneb.enyo.de> * Jeff Kell: > And what about the millions of users unknowingly infected with > "something else" ?? You have to start somewhere. I received a warning letter, and four or five very organizations had to cooperate in new ways to make this happen. This is certainly a welcome development, and hopefully, this experience can be used for other mitigation efforts. From randy at psg.com Sat Apr 28 05:04:07 2012 From: randy at psg.com (Randy Bush) Date: Sat, 28 Apr 2012 03:04:07 -0700 Subject: rpki vs. secure dns? In-Reply-To: <87ipgk2n8c.fsf@mid.deneb.enyo.de> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> Message-ID: > The idea as such isn't new, this has been floating around for four > years or more, including at least one Internet draft, > draft-donnerhacke-sidr-bgp-verification-dnssec. draft-bates-bgp4-nlri-orig-verif-00.txt was '98 and we dropped it for good reasons randy From saku at ytti.fi Sat Apr 28 05:17:10 2012 From: saku at ytti.fi (Saku Ytti) Date: Sat, 28 Apr 2012 13:17:10 +0300 Subject: rpki vs. secure dns? In-Reply-To: <4F9B181D.30606@isc.org> References: <4F9B181D.30606@isc.org> Message-ID: <20120428101710.GA26852@pob.ytti.fi> On (2012-04-27 22:05 +0000), Paul Vixie wrote: > this seems late, compared to the various commitments made to rpki in > recent years. is anybody taking it seriously? (disclaimer I'm almost completely clueless on RPKI). If two fails don't make win, then I think ROVER is better solution, doesn't need any changes to BGP just little software magic when accepting routes. People might scared to rely on DNS on accepting routes, but is this really an issue? I'd anyhow prefer to run verification in 'relaxed' mode, where routes which fail authorization are logged but accepted if there wasn't pre-existing covering route. Only drop routes if they fail authorization _AND_ there is pre-existing covering route. Maybe after several more years of experience and working out kinks, I could dare to try to run verification in 'strict' more. But 'relaxed' more already would stop the real-life problems we've seen of route-hijackings. I don't care much about unannounced net used for spamming really. Nick Hilliard mentioned in other forum to me bootstrapping problem. DNS would then be inherently part of your NMS, so install DNS in your NMS, and NMS already exists in IGP. So infra for verification should be up, before BGP is up. -- ++ytti From alexb at ripe.net Sat Apr 28 05:34:52 2012 From: alexb at ripe.net (Alex Band) Date: Sat, 28 Apr 2012 12:34:52 +0200 Subject: rpki vs. secure dns? In-Reply-To: <87ipgk2n8c.fsf@mid.deneb.enyo.de> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> Message-ID: On 28 Apr 2012, at 11:56, Florian Weimer wrote: > * Paul Vixie: > >> this seems late, compared to the various commitments made to rpki in >> recent years. is anybody taking it seriously? > > The idea as such isn't new, this has been floating around for four > years or more, including at least one Internet draft, > draft-donnerhacke-sidr-bgp-verification-dnssec. > > I don't know if we can get RPKI to deployment because RIPE and RIPE > NCC have rather serious issues with it. On the other hand, there > doesn't seem to be anything else which keeps RIRs relevant in the > post-scarcity world, so we'll see what happens. Could you elaborate on what those issues are? I can't speak for ROVER, but judging from Gersh's talk at RIPE64 and the discussion afterwards, it looks like it's just an old idea that was brought to the table again, with a few early adopters experimenting. In the linked article Gersh says that RPKI is complex and deployment has been slow. In reality, since the RIRs launched an RPKI production service on 1 Jan 2011, adoption has been incredibly good (for example compared to IPv6 and DNSSEC). More than 1500 ISPs and large organizations world-wide have opted-in to the system and requested a resource certificate using the hosted service, or running an open source package with their own CA. But it's not just that, these ISPs didn't just blindly get certificate and walk away. There are over 800 ROAs in the global system, describing more than 2000 prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 addresses worth of BGP announcements. Data quality is really good. All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better. Global deployment statistics can be found here: http://certification-stats.ripe.net/ From fw at deneb.enyo.de Sat Apr 28 06:35:15 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Apr 2012 13:35:15 +0200 Subject: rpki vs. secure dns? In-Reply-To: (Alex Band's message of "Sat, 28 Apr 2012 12:34:52 +0200") References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> Message-ID: <874ns42ioc.fsf@mid.deneb.enyo.de> * Alex Band: >> I don't know if we can get RPKI to deployment because RIPE and RIPE >> NCC have rather serious issues with it. On the other hand, there >> doesn't seem to be anything else which keeps RIRs relevant in the >> post-scarcity world, so we'll see what happens. > > Could you elaborate on what those issues are? A year ago, RIPE NCC received legal advice that RPKI-based takedowns would not happen under Dutch law because Dutch law lacked any provisions for that. This was used to deflect criticism that RPKI deployment would result in too much concentration of power: The legal analysis turned out to be incomplete and the results incorrect---legal counsel failed to consider public order legislation. The validaty of such an order (issued in the Dnschanger context) is currently being challenged in a Dutch court. >From the comments on these events, I infer that RIPE NCC still does not want to exercise this level of control over routing, and the RIPE community does not want RIPE to have such control. But assuming that the order stands, RPKI will provide RIPE NCC with a tool that nobody wants it to have, and RIPE NCC can be forced to use it. Depending on the seriousness of those concerns, that's the end of RPKI deployment. (However, the most likely outcome of the current court case is that this particular police order will be found invalid on a formality, such as lack of effectiveness, providing little insight on the validity of future orders which are more carefully crafted.) Regarding the post-scarcity future, if most address holders never have to come back to the RIR to request more addresses, the number of address-related RIR/LIR transactions will decrease. Organizations have a tendency to resist decreases in business (even non-profits), and RPKI is an obvious source of future business. From rsk at gsp.org Sat Apr 28 06:44:46 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Apr 2012 07:44:46 -0400 Subject: Operation Ghost Click In-Reply-To: <4F99FE80.6010007@utc.edu> References: <4F99C03A.30506@mompl.net> <4F99FE80.6010007@utc.edu> Message-ID: <20120428114446.GA6461@gsp.org> On Thu, Apr 26, 2012 at 10:03:44PM -0400, Jeff Kell wrote: > And what about the millions of users unknowingly infected with > "something else" ?? s/millions/hundreds of millions/ We passed the 100M zombie/bot mark years ago and nothing has happened in the interim that should/would cause the trend to reverse. (Based on what I've seen, the curve continues to monotonically increase.) Worse, even the most sophisticated measurement techniques we have are guaranteed to miss some unknown/unknowable fraction of the total population, since botmasters are known to keep reserves. And worse yet, we're now seeing infestations of portable devices/phones, systems running MacOS, etc., so while it's been, to this point, a Windows problem to about five to seven 9's, it's not anymore, and it's not going to be. > Does anyone have a plan? No. Well, that's a bit unfair: lots of people have ideas, proposals, and such, but until/unless there's a massive, coordinated, focused effort -- which will cost a LOT of money -- those ideas and proposals can have (at best) temporary, localized effects. I would like to think that the software vendors whose products are involved would step up, but if that was going to happen, it probably would have happened by now. The most likely outcomes are: (1) that the status quo will continue: massive amounts of attention, effort, and money will be focused on mitigating the consequences (e.g., anti-spam, anti-phish, anti-DDoS, anti-malware, anti-anti-anti defenses) and almost none will be focused on addressing the root causes. (2) Those running networks which are infested on a systemic and chronic basis will continue to do so and will not be held accountable (by anyone) for their incompetence. (3) More sophisticated bot-creating software will be developed and thoroughly tested against anti-malware products before being deployed. (4) Botnet command and control mechanisms will become more resilient in the face of attacks. (5) Every now and then, some vendor and/or some government agency will have a press conference and engage in self-congratulatory chest-beating about how they've taken down a 5-million member botnet, while botmasters are busy recruiting all 5 million still-compromised systems into new botnets. (6) Once in a while, some poor unsuspecting person sitting in front of one of these systems will be stuck holding the bag when clueless prosecutors, assisted by thoroughly ignorant judges and stunningly inept "experts", decide to score some election-year points by destroying an innocent person's life: see "Julie Amero" for a canonical example. (7) Data harvested from all these systems will continue to be collated and sold to spammers, phishers, identity thieves, blackmailers, and anyone else with a passing interest in the usable contents of large numbers of systems. (8) Legislators and politicians who cannot even use computers will propose and likely pass bill after bill after bill which not only makes the situation worse, but uses it as an excuse to destroy the few remaining protections that citizens have against wholesale government snooping into their private lives. As a bonus, they'll ensure that much of this information is passed along to any private contractors who've made sufficient campaign contributions, and they in turn will be hacked by the first bored 17-year-old with an attitude that takes note of their existence. Oh. Almost forgot. At each step, the favorite phrases of people who've failed to learn from history, failed to heed warnings, failed to educate themselves, failed to listen to experts and now wish to distance themselves as far as they possibly can from the direct consequences of their own choices and actions will be used: "nobody could have predicted" and "we take this matter seriously" ---rsk From bortzmeyer at nic.fr Sat Apr 28 06:59:39 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 28 Apr 2012 13:59:39 +0200 Subject: rpki vs. secure dns? In-Reply-To: <17627_1335610545_4F9BCCB1_17627_2198_1_m2ehr89nqg.wl%randy@psg.com> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <17627_1335610545_4F9BCCB1_17627_2198_1_m2ehr89nqg.wl%randy@psg.com> Message-ID: <20120428115939.GB30278@sources.org> On Sat, Apr 28, 2012 at 03:04:07AM -0700, Randy Bush wrote a message of 9 lines which said: > draft-bates-bgp4-nlri-orig-verif-00.txt was '98 > > and we dropped it for good reasons Unfortunately, we have RFCs for good ideas but bad ideas never get documented by the IETF (one of the few exceptions is RFC 3197). So, bad ideas keep coming back and back again. Would you explain in a few words why this was a bad idea? I personally find Rover a very interesting idea, and which seems realistic. From cjp at 0x1.net Sat Apr 28 07:11:49 2012 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Sat, 28 Apr 2012 08:11:49 -0400 Subject: Vendor IPv6 RA Guard Support Message-ID: Does there exist a multi-vendor list showing whether a particular switch hardware/software supports or does not support RA Guard? -cjp From excelsio at gmx.com Sat Apr 28 07:30:13 2012 From: excelsio at gmx.com (Michael Muller) Date: Sat, 28 Apr 2012 14:30:13 +0200 Subject: Vendor IPv6 RA Guard Support In-Reply-To: References: Message-ID: <4F9BE2D5.3010804@gmx.com> That would be kind of interesting. I do not know any promoted "RA guard" function that defends against http://thc.org/thc-ipv6/ ,yet. Perhaps the guys from http://tools.ietf.org/wg/savi/ do know more about specific switch vendors. From bortzmeyer at nic.fr Sat Apr 28 07:57:58 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 28 Apr 2012 14:57:58 +0200 Subject: rpki vs. secure dns? In-Reply-To: <17627_1335610611_4F9BCCF3_17627_2201_1_F214ED84-0E9C-4C2F-9B0F-6F5721BE1315@ripe.net> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <17627_1335610611_4F9BCCF3_17627_2201_1_F214ED84-0E9C-4C2F-9B0F-6F5721BE1315@ripe.net> Message-ID: <20120428125758.GC30278@sources.org> On Sat, Apr 28, 2012 at 12:34:52PM +0200, Alex Band wrote a message of 41 lines which said: > In reality, since the RIRs launched an RPKI production service on 1 > Jan 2011, adoption has been incredibly good (for example compared to > IPv6 and DNSSEC). More than 1500 ISPs and large organizations > world-wide have opted-in to the system and requested a resource > certificate using the hosted service, or running an open source > package with their own CA. I have an experience with the deployment of DNSSEC and the problem with DNSSEC was not to have signed zones (many are, now) but to have people *using* these signatures to check the data (i.e. validating in a resolver). RPKI has many ROA (signed objects) but how many operators validate routes on their production routers? Zero? > But it's not just that, these ISPs didn't just blindly get > certificate and walk away. Most of the ROAs are very recent. Again, the experience with DNSSEC shows that starting is easy ("DNSSEC in siw minutes"). It's long term management which is *the* problem. Wait until people start to change the routing data and watch the ROAs becoming less and less correct... > Data quality is really good. It's not what you said: "It is safe to say that overall data quality is pretty bad" (good paper, by the way, thanks) From fernando at gont.com.ar Sat Apr 28 08:03:18 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Sat, 28 Apr 2012 10:03:18 -0300 Subject: Vendor IPv6 RA Guard Support In-Reply-To: References: Message-ID: <4F9BEA96.5040804@gont.com.ar> On 04/28/2012 09:11 AM, Christopher J. Pilkington wrote: > Does there exist a multi-vendor list showing whether a particular > switch hardware/software supports or does not support RA Guard? Last time (a couple of months ago, or so) this was discussed on the ipv6hackers mailing-list (http://lists.si6networks.com/listinfo/ipv6hackers/), comments were that no vendor had addressed this, yet. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From alexb at ripe.net Sat Apr 28 08:04:51 2012 From: alexb at ripe.net (Alex Band) Date: Sat, 28 Apr 2012 15:04:51 +0200 Subject: rpki vs. secure dns? In-Reply-To: <874ns42ioc.fsf@mid.deneb.enyo.de> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> Message-ID: At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote on RPKI at the general meeting. The result was that the RIPE NCC has the green light to continue offering the Resource Certification service, including all BGP Origin Validation related functionality. It's correct that concerns were raised in the area of security, resilience and operator autonomy, as you mention. These concerns are continuously being evaluated and addressed. The response to the update that was given at RIPE 64 two weeks ago indicated that the membership and Community are happy with the approach the RIPE NCC is taking in this regard. Of course I realize that some people will never be convinced, no matter which steps are taken? Looking at the bigger picture though, we shouldn't forget that what RPKI, ROVER and the IRR facilitate is merely the ability make a *statement* about routing (with varying degrees of reliability) and doesn't have a direct impact on BGP routing itself. Ultimately, it is up to the network operator to interpret the data that is entered in the system, allow them to make an informed decision and take action they deem appropriate. Everyone has the ability to apply an override on data they do not trust, or have a specific local policy for. In the toolsets for using the RPKI data set for routing decisions, such as the RIPE NCC RPKI Validator, every possible step is taken is taken to ensure that the operator is in the driver's seat. Have a look here for a public example: http://rpki.netsign.net:8080/ Or install and try it yourself: http://www.ripe.net/certification/tools-and-resources Cheers, Alex On 28 Apr 2012, at 13:35, Florian Weimer wrote: > * Alex Band: > >>> I don't know if we can get RPKI to deployment because RIPE and RIPE >>> NCC have rather serious issues with it. On the other hand, there >>> doesn't seem to be anything else which keeps RIRs relevant in the >>> post-scarcity world, so we'll see what happens. >> >> Could you elaborate on what those issues are? > > A year ago, RIPE NCC received legal advice that RPKI-based takedowns > would not happen under Dutch law because Dutch law lacked any > provisions for that. This was used to deflect criticism that RPKI > deployment would result in too much concentration of power: > > > > The legal analysis turned out to be incomplete and the results > incorrect---legal counsel failed to consider public order legislation. > The validaty of such an order (issued in the Dnschanger context) is > currently being challenged in a Dutch court. > > From the comments on these events, I infer that RIPE NCC still does > not want to exercise this level of control over routing, and the RIPE > community does not want RIPE to have such control. But assuming that > the order stands, RPKI will provide RIPE NCC with a tool that nobody > wants it to have, and RIPE NCC can be forced to use it. Depending on > the seriousness of those concerns, that's the end of RPKI deployment. > > (However, the most likely outcome of the current court case is that > this particular police order will be found invalid on a formality, > such as lack of effectiveness, providing little insight on the > validity of future orders which are more carefully crafted.) > > Regarding the post-scarcity future, if most address holders never have > to come back to the RIR to request more addresses, the number of > address-related RIR/LIR transactions will decrease. Organizations > have a tendency to resist decreases in business (even non-profits), > and RPKI is an obvious source of future business. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From fernando at gont.com.ar Sat Apr 28 08:10:00 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Sat, 28 Apr 2012 10:10:00 -0300 Subject: New IETF I-D: Security Implications of IPv6 on IPv4 networks In-Reply-To: <4F967E6F.10209@gont.com.ar> References: <4F967E6F.10209@gont.com.ar> Message-ID: <4F9BEC28.3090208@gont.com.ar> FYI, I posted a rev of this I-D a couple of days ago, and hence the previous document was automatically removed (thus resulting in a broken link). The latest version of this document is always available at the magic URL: Apologies for the possible inconvenience. Thanks, Fernando On 04/24/2012 07:20 AM, Fernando Gont wrote: > Folks, > > We've published a new IETF I-D entitled "Security Implications of IPv6 > on IPv4 networks". > > The I-D is available at: > > > The Abstract of the I-D is: > ---- cut here ---- > This document discusses the security implications of native IPv6 > support and IPv6 transition/co-existence technologies on "IPv4-only" > networks, and describes possible mitigations for the aforementioned > issues. > ---- cut here ---- > > Any feedback will be very welcome. > > Thanks! > > Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From alexb at ripe.net Sat Apr 28 08:19:39 2012 From: alexb at ripe.net (Alex Band) Date: Sat, 28 Apr 2012 15:19:39 +0200 Subject: rpki vs. secure dns? In-Reply-To: <20120428125758.GC30278@sources.org> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <17627_1335610611_4F9BCCF3_17627_2201_1_F214ED84-0E9C-4C2F-9B0F-6F5721BE1315@ripe.net> <20120428125758.GC30278@sources.org> Message-ID: <4D871DAB-435E-48E8-9B16-C666ECA99E84@ripe.net> On 28 Apr 2012, at 14:57, Stephane Bortzmeyer wrote: > On Sat, Apr 28, 2012 at 12:34:52PM +0200, > Alex Band wrote > a message of 41 lines which said: > >> In reality, since the RIRs launched an RPKI production service on 1 >> Jan 2011, adoption has been incredibly good (for example compared to >> IPv6 and DNSSEC). More than 1500 ISPs and large organizations >> world-wide have opted-in to the system and requested a resource >> certificate using the hosted service, or running an open source >> package with their own CA. > > I have an experience with the deployment of DNSSEC and the problem > with DNSSEC was not to have signed zones (many are, now) but to have > people *using* these signatures to check the data (i.e. validating in > a resolver). > > RPKI has many ROA (signed objects) but how many operators validate > routes on their production routers? Zero? First you need a robust system and reliable data. Native router support is coming along. We could be getting to a stage where people will use the data in production. Time will tell... >> But it's not just that, these ISPs didn't just blindly get >> certificate and walk away. > > Most of the ROAs are very recent. Again, the experience with DNSSEC > shows that starting is easy ("DNSSEC in siw minutes"). It's long term > management which is *the* problem. Wait until people start to change > the routing data and watch the ROAs becoming less and less correct... > >> Data quality is really good. > > It's not what you said: > > "It is safe to say that overall data quality is pretty bad" > > (good paper, by the way, thanks) A lot has changed since I wrote that. :) -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From bortzmeyer at nic.fr Sat Apr 28 08:19:46 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 28 Apr 2012 15:19:46 +0200 Subject: Need spamcop/ironport security contact In-Reply-To: <17627_1335618661_4F9BEC63_17627_2732_1_6836.1335584517@turing-police.cc.vt.edu> References: <4F9B561C.8010007@tiedyenetworks.com> <17627_1335618661_4F9BEC63_17627_2732_1_6836.1335584517@turing-police.cc.vt.edu> Message-ID: <20120428131946.GE30278@sources.org> On Fri, Apr 27, 2012 at 11:41:57PM -0400, Valdis.Kletnieks at vt.edu wrote a message of 33 lines which said: > > I have a security incident to report and need to make contact with > > a senior level contact responsible for spamcop/ironport > > immediately. > > And you need a *senior* level contact, why? He probably meant "someone who has seen an IP address before", not level1-support. From bortzmeyer at nic.fr Sat Apr 28 08:18:55 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 28 Apr 2012 15:18:55 +0200 Subject: rpki vs. secure dns? In-Reply-To: <17627_1335611056_4F9BCEB0_17627_2219_1_20120428101710.GA26852@pob.ytti.fi> References: <4F9B181D.30606@isc.org> <17627_1335611056_4F9BCEB0_17627_2219_1_20120428101710.GA26852@pob.ytti.fi> Message-ID: <20120428131855.GD30278@sources.org> On Sat, Apr 28, 2012 at 01:17:10PM +0300, Saku Ytti wrote a message of 27 lines which said: > I think ROVER is better solution, doesn't need any changes to BGP > just little software magic when accepting routes. I like Rover but RPKI+ROA does not change BGP either (it will be a different story with BGPsec). > People might scared to rely on DNS on accepting routes, but is this > really an issue? RPKI+ROA depends on DNS too, since rsync://rpki.ripe.net/repository will work only if DNS works. Not a problem in practice, since route origins do not change every minute and the validating ROA cache can work even if it can no longer update its data. Same thing with Rover: temporary glitches in the DNS are not a practical problem (the router keeps the old info). > routes which fail authorization are logged but accepted if there > wasn't pre-existing covering route. Only drop routes if they fail > authorization _AND_ there is pre-existing covering route. It is a bit more complicated: more-specific attacks, and so on. But, yes, you're right. As Alex Band says, Rover, RPKI and the IRR make (authenticated) statements about route origins. You then do what you want (what your boss wants? what the FBI wants?) with these statements (route-map, etc). From ops.lists at gmail.com Sat Apr 28 08:35:56 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 28 Apr 2012 19:05:56 +0530 Subject: Need spamcop/ironport security contact In-Reply-To: <20120428131946.GE30278@sources.org> References: <4F9B561C.8010007@tiedyenetworks.com> <17627_1335618661_4F9BEC63_17627_2732_1_6836.1335584517@turing-police.cc.vt.edu> <20120428131946.GE30278@sources.org> Message-ID: On Sat, Apr 28, 2012 at 6:49 PM, Stephane Bortzmeyer wrote: >> And you need a *senior* level contact, why? > > He probably meant "someone who has seen an IP address before", not > level1-support. spamcop being largely volunteer run has people on it that have a few years more spam filtering experience than I do - and I've only been around antispam from like the mid 90s. Good people. -- Suresh Ramasubramanian (ops.lists at gmail.com) From randy at psg.com Sat Apr 28 08:58:00 2012 From: randy at psg.com (Randy Bush) Date: Sat, 28 Apr 2012 06:58:00 -0700 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> Message-ID: [ sorry cameron, trying to keep things down to one message ] > http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem > http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem and don't miss http://www.theregister.co.uk/2012/04/23/ip_hijack_prevention/ free dinner at nanog/van for anyone who can explain how the dnssec approach meets the defcon attack. hint: it is a path attack, not an origin attack, and the dns pidgeon has no hooks to path attack prevention. at ripe, joe gersh asked me for an example of a path attack and i told him of the defcon demo. seems he also did not bother to do his homework. but it makes good pr. someone selling dnssec appliances flew a press release that a few reporters bought without doing their homework. end of net predicted, news at eleven. > Taking what seriously ? The commitments to rpki you speak off ? a thousand LIRs in the ripe region, 500 elsewhere? cisco code shipping on a number of platforms, juniper soon. some of us have actually started validating route origins in the real network using rpki and cisco and juniper (test) code. ---- Saku Ytti wrote: > If two fails don't make win, then I think ROVER is better solution, > doesn't need any changes to BGP just little software magic when > accepting routes. you are right, you have not done your homework. rpki-based origin validation asks no changes to bgp. > People might scared to rely on DNS on accepting routes, but is this > really an issue? yes. rpki can also have that issue as the certs can have urls that use domain names. i believe they could use ip address urls instead. but the gathering operation differs greatly between the rpki and the dnssec based proposal. with the latter, you can't even tell you have the full set. ---- the worry in the ripe region and elsewhere is what i call the 'virginia court attack', also called the 'dutch court attack'. some rights holder claims their movie is being hosted in your datacenter and they get the RIR to jerk the attestation to your ownership of the prefix or your ROA. this problem is inherent in any system which uses the address allocation administrative hierarchy to attest to address space ownership, whether rpki, dns-based, or hollerith cards. i do not like it either. but it is a trade you make for security. and, at ripe ljubljana, i think alex started to discuss some schemes to ameliorate it. more later on this. ---- randy From randy at psg.com Sat Apr 28 09:02:12 2012 From: randy at psg.com (Randy Bush) Date: Sat, 28 Apr 2012 07:02:12 -0700 Subject: rpki vs. secure dns? In-Reply-To: <4F9B1AC6.1060108@gmail.com> References: <4F9B181D.30606@isc.org> <4F9B1AC6.1060108@gmail.com> Message-ID: > first thing that sprung to mind was this: > http://www.cafepress.com.au/nxdomain geoff wore one at ripe64. i was soooooo green with envy that he has graciously sent one to meet me when i get home from travails. see http://archive.psg.com/001213.ietf-dns.pdf for my comments on the subject at an ietf plenary a dozen years ago. randy From askoorb+nanog at gmail.com Sat Apr 28 10:04:35 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Sat, 28 Apr 2012 16:04:35 +0100 Subject: Need spamcop/ironport security contact In-Reply-To: <4F9B561C.8010007@tiedyenetworks.com> References: <4F9B561C.8010007@tiedyenetworks.com> Message-ID: Hello, On Sat, Apr 28, 2012 at 3:29 AM, Mike wrote: > > ? ? ? ?I have a security incident to report and need to make contact with a > senior level contact responsible for spamcop/ironport immediately. > Although I'm pretty sure the OP will have got in touch with someone by now, for reference for the rest of the list, if you need to get in touch with someone senior at SpamCop, service [at] admin.spamcop.net is the address for you. For actual usage issues (about reporting spam or dealing with spam reports, it's deputies [at] spamcop.net. Both these addresses are publicly listed on SpamCop's website so should be OK to release here. +1 to SpamCop being good guys. If anyone hasn't already, go make sure you receive SpamCop reports to the address you want in the format you want (they do ARF if you prefer for example). Go to http://www.spamcop.net/w3m?action=ispsignupform or http://www.spamcop.net/fom-serve/cache/75.html if you have time to learn all about how they work. Alex From fw at deneb.enyo.de Sat Apr 28 10:16:55 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 28 Apr 2012 17:16:55 +0200 Subject: rpki vs. secure dns? In-Reply-To: (Alex Band's message of "Sat, 28 Apr 2012 15:04:51 +0200") References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> Message-ID: <871un7rimw.fsf@mid.deneb.enyo.de> * Alex Band: > At RIPE 63, six months ago, the RIPE NCC membership got a chance to > vote on RPKI at the general meeting. The result was that the RIPE > NCC has the green light to continue offering the Resource > Certification service, including all BGP Origin Validation related > functionality. But this was done outside the Policy Development Process, which is supposed to handle such things. > It's correct that concerns were raised in the area of > security, resilience and operator autonomy, as you mention. These > concerns are continuously being evaluated and addressed. I don't think so. Ultimately, it does not seem to be possible to get this through the PDP. The whole discussion is a bit odd: Even without RPKI, RIPE NCC already has the power to directly influence global routing because it's unreasonable to expect that the majority of their BGP peers employ strict filtering. So they could inject more specifics as they see fit, and thus blackhole pretty arbitrary chunks of address space. However, so can most folks who of those who control routers in the DFZ, and RPKI (or something similar) would change that at least. From nick at foobar.org Sat Apr 28 12:22:15 2012 From: nick at foobar.org (Nick Hilliard) Date: Sat, 28 Apr 2012 18:22:15 +0100 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> Message-ID: <4F9C2747.7010301@foobar.org> On 28/04/2012 14:04, Alex Band wrote: > they do not trust, or have a specific local policy for. In the toolsets > for using the RPKI data set for routing decisions, such as the RIPE NCC > RPKI Validator, every possible step is taken is taken to ensure that the > operator is in the driver's seat. Leaving aside technical matters, this is one of the more contentious political issues with RPKI. RPKI is a tool which can be used to locally influence routing decisions, but allows centralised control of prefix authenticity. If this central point is influenced to invalidate a specific prefix, then that will cause serious reachability problems for that prefix on the Internet. It will be difficult for politicians / legislators / LEAs to look at a technology like this and not see its potential for implementing wide-area Internet blocking. For sure, the LEAs currently looking at it are extremely interested. Nick From regnauld at nsrc.org Sat Apr 28 12:27:51 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 28 Apr 2012 19:27:51 +0200 Subject: rpki vs. secure dns? In-Reply-To: <4F9C2747.7010301@foobar.org> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> Message-ID: <20120428172751.GU36073@macbook.bluepipe.net> Nick Hilliard (nick) writes: > > Leaving aside technical matters, this is one of the more contentious > political issues with RPKI. RPKI is a tool which can be used to locally > influence routing decisions, but allows centralised control of prefix > authenticity. If this central point is influenced to invalidate a specific > prefix, then that will cause serious reachability problems for that prefix > on the Internet. To me that seems like the most obvious problem, but as Alex put it, "Everyone has the ability to apply an override on data they do not trust, or have a specific local policy for." > It will be difficult for politicians / legislators / LEAs to look at a > technology like this and not see its potential for implementing wide-area > Internet blocking. > For sure, the LEAs currently looking at it are extremely interested. Or the ITU ? :) Cheers, Phil From nick at foobar.org Sat Apr 28 12:45:30 2012 From: nick at foobar.org (Nick Hilliard) Date: Sat, 28 Apr 2012 18:45:30 +0100 Subject: rpki vs. secure dns? In-Reply-To: <20120428172751.GU36073@macbook.bluepipe.net> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> Message-ID: <4F9C2CBA.1010602@foobar.org> On 28/04/2012 18:27, Phil Regnauld wrote: > To me that seems like the most obvious problem, but as Alex put it, > "Everyone has the ability to apply an override on data they do not trust, > or have a specific local policy for." So what do you suggest to do with a roa lookup which returns "Invalid"? Nick From alexb at ripe.net Sat Apr 28 13:14:27 2012 From: alexb at ripe.net (Alex Band) Date: Sat, 28 Apr 2012 20:14:27 +0200 Subject: rpki vs. secure dns? In-Reply-To: <4F9C2CBA.1010602@foobar.org> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> Message-ID: <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> On 28 Apr 2012, at 19:45, Nick Hilliard wrote: > On 28/04/2012 18:27, Phil Regnauld wrote: >> To me that seems like the most obvious problem, but as Alex put it, >> "Everyone has the ability to apply an override on data they do not trust, >> or have a specific local policy for." > > So what do you suggest to do with a roa lookup which returns "Invalid"? In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17: https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf -Alex From rubensk at gmail.com Sat Apr 28 14:21:34 2012 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 28 Apr 2012 16:21:34 -0300 Subject: rpki vs. secure dns? In-Reply-To: <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> Message-ID: > In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17: > > https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf The same currently happens with DNSSEC, doing what Comcast calls "negative trust anchors": http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01 Rubens From regnauld at nsrc.org Sat Apr 28 14:28:43 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 28 Apr 2012 21:28:43 +0200 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> Message-ID: <20120428192843.GD44404@macbook.bluepipe.net> Rubens Kuhl (rubensk) writes: > > In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17: > > > > https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf > > The same currently happens with DNSSEC, doing what Comcast calls > "negative trust anchors": > http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01 Yes, NTAs was the comparison that came to my mind as well. Or even in classic DNS, overriding with stubs. You will get bitten by a bogus/ flawed ROA, but you'll have to the chance to mitigate it. Any kind of centralized mechanism like this is subject to these risks, no matter what the distribution mechanism is. From achikhdaho at iweb.com Sun Apr 29 09:30:37 2012 From: achikhdaho at iweb.com (Abdelkader Chikh Daho) Date: Sun, 29 Apr 2012 10:30:37 -0400 Subject: Juniper MX960 with SCB-E vs Cisco ASR9k with RSP400 Message-ID: <4F9D508D.6080509@iweb.com> Hi everyone, I wan to ask for your feedback about these two devices : Juniper MX960 with SCB-E and Cisco AS9k with RSP400. Best regards, -- Abdelkader Chikh Daho Network Architect iWeb Technologies Email : achikhdaho at iweb.com Web : www.iweb.com Tel : 514-286-4242 ext 2309 From alexb at ripe.net Sun Apr 29 10:16:39 2012 From: alexb at ripe.net (Alex Band) Date: Sun, 29 Apr 2012 17:16:39 +0200 Subject: rpki vs. secure dns? In-Reply-To: <20120428192843.GD44404@macbook.bluepipe.net> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> Message-ID: On 28 Apr 2012, at 21:28, Phil Regnauld wrote: > Rubens Kuhl (rubensk) writes: >>> In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17: >>> >>> https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf >> >> The same currently happens with DNSSEC, doing what Comcast calls >> "negative trust anchors": >> http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01 > > Yes, NTAs was the comparison that came to my mind as well. Or even > in classic DNS, overriding with stubs. You will get bitten by a bogus/ > flawed ROA, but you'll have to the chance to mitigate it. Any kind of > centralized mechanism like this is subject to these risks, no matter > what the distribution mechanism is. Now that we have cleared up the fact that any RPKI statement can be overridden, I want to address another tenacious misunderstanding in relation to what Randy said: On 28 Apr 2012, at 15:58, Randy Bush wrote: > the worry in the ripe region and elsewhere is what i call the 'virginia > court attack', also called the 'dutch court attack'. some rights holder > claims their movie is being hosted in your datacenter and they get the > RIR to jerk the attestation to your ownership of the prefix or your ROA. If a Dutch court would order the RIPE NCC to remove a certificate or ROA from the system, the effect would be that there no longer is an RPKI statement about a BGP route announcement. The result is that the announcement will have the RPKI status *UNKNOWN*. It will be like the organization never used RPKI to make the statement in the first place. Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID route announcement; the result is RPKI UNKNOWN. The only way a court order could make a route announcement get the RPKI status *INVALID* would be to: 1: Remove the original, legitimate ROA 2: Tamper with the Registry, inject a false ROA authorizing another AS to make the announcement look like a hijack All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override. -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From jrex at CS.Princeton.EDU Sun Apr 29 10:28:58 2012 From: jrex at CS.Princeton.EDU (Jennifer Rexford) Date: Sun, 29 Apr 2012 11:28:58 -0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> Message-ID: >> the worry in the ripe region and elsewhere is what i call the 'virginia >> court attack', also called the 'dutch court attack'. some rights holder >> claims their movie is being hosted in your datacenter and they get the >> RIR to jerk the attestation to your ownership of the prefix or your ROA. > > If a Dutch court would order the RIPE NCC to remove a certificate or ROA from the system, the effect would be that there no longer is an RPKI statement about a BGP route announcement. The result is that the announcement will have the RPKI status *UNKNOWN*. It will be like the organization never used RPKI to make the statement in the first place. > > Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID route announcement; the result is RPKI UNKNOWN. > > The only way a court order could make a route announcement get the RPKI status *INVALID* would be to: > 1: Remove the original, legitimate ROA > 2: Tamper with the Registry, inject a false ROA authorizing another AS to make the announcement look like a hijack How does this interact with the presence of certificates for supernets, though? That is, suppose an ISP creates a legitimate ROA for 12.0.0.0/8, after ensuring that all of its customers have legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose one of these customers has its legitimate ROA revoked by a court order. Would the legitimate announcement of that subnet (originated by the customer's ASN) still result in UNKNOWN status, or would it look like a sub-prefix hijack because the announcement has a different ASN than the matching 12.0.0.0/8 prefix? -- Jen From Valdis.Kletnieks at vt.edu Sun Apr 29 10:31:17 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 29 Apr 2012 11:31:17 -0400 Subject: Juniper MX960 with SCB-E vs Cisco ASR9k with RSP400 In-Reply-To: Your message of "Sun, 29 Apr 2012 10:30:37 -0400." <4F9D508D.6080509@iweb.com> References: <4F9D508D.6080509@iweb.com> Message-ID: <84964.1335713477@turing-police.cc.vt.edu> On Sun, 29 Apr 2012 10:30:37 -0400, Abdelkader Chikh Daho said: > I wan to ask for your feedback about these two devices : Juniper MX960 > with SCB-E and Cisco AS9k with RSP400. They both work well in some situation, and totally fail in others. It would help if you gave more detail what problem you're trying to solve. Also, are you sure that *those two* devices are the only suitable ones for your application, or do you want answers of "You may want to look at XYZ's model 915 as well"? http://www.catb.org/~esr/faqs/smart-questions.html is probably the most helpful answer I can give to your original query. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From brandon at rd.bbc.co.uk Sun Apr 29 11:21:23 2012 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 29 Apr 2012 17:21:23 +0100 (BST) Subject: rpki vs. secure dns? Message-ID: <201204291621.RAA02589@sunf10.rd.bbc.co.uk> > Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID > route announcement; the result is RPKI UNKNOWN. Which is fine until UNKNOWNs are no longer permitted, a logical next step. It may not apply globally, initially perhaps just a US anti terrorist measure requiring all networks in the USA do it. > The only way a court order could make a route announcement get the > RPKI status *INVALID* would be to: > 1: Remove the original, legitimate ROA > 2: Tamper with the Registry, inject a false ROA authorizing another > AS to make the announcement look like a hijack Domains already get FBI hijacked so this seems plausible too. > All in all, for an RPKI-specific court order to be effective in > taking a network offline, the RIR would have to tamper with the > registry, inject false data and try to make sure it's not detected so > nobody applies a local override. Doesn't need to be undetected, more likely it'll be quite overt and have a big don't mess FBI entry in the RIR similar to www.megaupload.com brandon From bortzmeyer at nic.fr Sun Apr 29 11:37:59 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 29 Apr 2012 18:37:59 +0200 Subject: rpki vs. secure dns? In-Reply-To: <17627_1335716979_4F9D6C71_17627_8157_1_F53AFDE0-6034-45F5-9250-A289F72F5657@cs.princeton.edu> References: <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> <17627_1335716979_4F9D6C71_17627_8157_1_F53AFDE0-6034-45F5-9250-A289F72F5657@cs.princeton.edu> Message-ID: <20120429163759.GA2702@sources.org> On Sun, Apr 29, 2012 at 11:28:58AM -0400, Jennifer Rexford wrote a message of 37 lines which said: > How does this interact with the presence of certificates for > supernets, though? That is, suppose an ISP creates a legitimate ROA > for 12.0.0.0/8, after ensuring that all of its customers have > legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose > one of these customers has its legitimate ROA revoked by a court > order. Would the legitimate announcement of that subnet (originated > by the customer's ASN) still result in UNKNOWN status, or would it > look like a sub-prefix hijack because the announcement has a > different ASN than the matching 12.0.0.0/8 prefix? The second (and therefore Alex Band's example is not good). But it depends on the value of the MaxLength attribute in the 12.0.0.0/8 ROA (section 3.3 of RFC 6482). If, in the future, RIRs or operators create ROAs for all the blocks they manage, revocation of a ROA will be deadly. From waehlisch at ieee.org Sun Apr 29 14:40:17 2012 From: waehlisch at ieee.org (Matthias Waehlisch) Date: Sun, 29 Apr 2012 21:40:17 +0200 Subject: rpki vs. secure dns? In-Reply-To: <20120429163759.GA2702@sources.org> References: <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> <17627_1335716979_4F9D6C71_17627_8157_1_F53AFDE0-6034-45F5-9250-A289F72F5657@cs.princeton.edu> <20120429163759.GA2702@sources.org> Message-ID: On Sun, 29 Apr 2012, Stephane Bortzmeyer wrote: > > How does this interact with the presence of certificates for > > supernets, though? That is, suppose an ISP creates a legitimate ROA > > for 12.0.0.0/8, after ensuring that all of its customers have > > legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose > > one of these customers has its legitimate ROA revoked by a court > > order. Would the legitimate announcement of that subnet (originated > > by the customer's ASN) still result in UNKNOWN status, or would it > > look like a sub-prefix hijack because the announcement has a > > different ASN than the matching 12.0.0.0/8 prefix? > > The second (and therefore Alex Band's example is not good). But it > depends on the value of the MaxLength attribute in the 12.0.0.0/8 ROA > (section 3.3 of RFC 6482). > unclear as the scenario doesn't depend on the maxLength (wrt the current specs). If there are valid covering ROAs in the RPKI and none of them match in the origin AS (customer ROA removed), the route prefix is invalid. The scenario is similar to the case in which the ISP starts to create a ROA for a superblock before the customer adds its route prefix into the RPKI ... this happened with AT&T during testing, for example, https://labs.ripe.net/Members/waehlisch/one-day-in-the-life-of-rpki Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From drc at virtualized.org Sun Apr 29 15:03:11 2012 From: drc at virtualized.org (David Conrad) Date: Sun, 29 Apr 2012 13:03:11 -0700 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> Message-ID: Alex, On Apr 29, 2012, at 8:16 AM, Alex Band wrote: > All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override. I suspect the court order would simply say something like 'RIPE-NCC must, upon pain of contempt of court, take sufficient steps to invalidate the allocations made to customer X' and leave it up to you all to figure out how to do it. I doubt they'd care all that much about implementation details. Are you saying it is not possible for RIPE-NCC staff to do this? I also doubt the court would care too much about 'local override' as the "Tyranny of Defaults" would be sufficient for their needs (and they could probably sanction the folks in the Netherlands who they discovered did the override). As Randy points out, this is not unique to SIDR-defined RPKI. It is applicable to any top-down hierarchical authorization mechanism. Security has (non-monetary) costs. Regards, -drc From nick at foobar.org Sun Apr 29 15:08:20 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 29 Apr 2012 21:08:20 +0100 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> Message-ID: <4F9D9FB4.4040703@foobar.org> On 29/04/2012 16:16, Alex Band wrote: > All in all, for an RPKI-specific court order to be effective in taking a > network offline, the RIR would have to tamper with the registry, inject > false data and try to make sure it's not detected so nobody applies a > local override. You mean, like an FBI domain seizure on the basis of a US court order? Realistically, it doesn't matter a whole lot if the occasional network here or there applies a local override. If their upstream transit provider isn't carrying the prefix (on the basis of similar simultaneous court orders), it's game over for that prefix. Nick From alexb at ripe.net Sun Apr 29 15:38:39 2012 From: alexb at ripe.net (Alex Band) Date: Sun, 29 Apr 2012 22:38:39 +0200 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> Message-ID: On 29 Apr 2012, at 22:03, David Conrad wrote: > Alex, > > On Apr 29, 2012, at 8:16 AM, Alex Band wrote: >> All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override. > > I suspect the court order would simply say something like 'RIPE-NCC must, upon pain of contempt of court, take sufficient steps to invalidate the allocations made to customer X' and leave it up to you all to figure out how to do it. I doubt they'd care all that much about implementation details. Are you saying it is not possible for RIPE-NCC staff to do this? I also doubt the court would care too much about 'local override' as the "Tyranny of Defaults" would be sufficient for their needs (and they could probably sanction the folks in the Netherlands who they discovered did the override). > > As Randy points out, this is not unique to SIDR-defined RPKI. It is applicable to any top-down hierarchical authorization mechanism. Security has (non-monetary) costs. Thanks David, I know that a court order doesn't have to specific. I just want to make people aware that in the case of RPKI, things are not as clear cut as "Revoked ROA = Offline network". It depends on many factors and I just want to offer a little perspective of what's involved. -Alex (P.S. I'm going on holiday for a week without internet access, so I won't be able to follow up on this thread for a while) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From nick at foobar.org Sun Apr 29 15:50:41 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 29 Apr 2012 21:50:41 +0100 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> Message-ID: <4F9DA9A1.9000301@foobar.org> On 28/04/2012 14:04, Alex Band wrote: > At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote > on RPKI at the general meeting. The result was that the RIPE NCC has the > green light to continue offering the Resource Certification service, > including all BGP Origin Validation related functionality. It's correct > that concerns were raised in the area of security, resilience and > operator autonomy, as you mention. These concerns are continuously being > evaluated and addressed. The response to the update that was given at > RIPE 64 two weeks ago indicated that the membership and Community are > happy with the approach the RIPE NCC is taking in this regard. Of course > I realize that some people will never be convinced, no matter which > steps are taken? Alex, I have to take exception with your statement that people in the RIPE region are generally happy about RPKI and the RIPE NCC RPKI project. They aren't. On the basis of some initial interest in the RIPE community several years ago, the RIPE NCC embarked on a certification + rpki project. By way of clarification for other readers of this mailing list, the RIPE NCC is a Dutch company constituted to carry out the policy requirements of the RIPE community. The way this is supposed to work is that the RIPE community puts forward policy proposals, and the RIPE NCC carries these policies out. Some time after the certification project was started in the NCC, a policy proposal (2008-08) was floated in the RIPE community in order to turn this into official RIPE policy, so that it could be formally carried out by the RIPE NCC. Mid last year, after extensive and heated discussion on the address policy working group mailing list, that policy proposal was withdrawn from the RIPE policy development process because it was clear that a large number of people in the RIPE community were deeply uneasy about a variety of implications. It is true that some of these concerns have been addressed to some extent by the NCC, but the core issues of concern are fundamental to RPKI. Later that year, several potential proposals were put forward by the RIPE NCC board at the Nov 2011 general meeting concerning the future of the RIPE NCC certification project. The RIPE NCC members - who are a fee-paying subset of the RIPE community - voted by 52% to 48% to keep funding the project. By any objective measure, this is an alarmingly slim majority. In short: - a substantial number of people, both within the RIPE community and within the RIPE NCC membership have serious concerns about the long-term legal consequences of this project which have not (in their opinion) been addressed adequately. - the RIPE NCC is now funding a project for which there is no consensus policy supported by the RIPE community, and is doing this on the basis of a hair's breath majority vote amongst its membership. Nick From randy at psg.com Sun Apr 29 16:39:06 2012 From: randy at psg.com (Randy Bush) Date: Sun, 29 Apr 2012 17:39:06 -0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> Message-ID: > As Randy points out, this is not unique to SIDR-defined RPKI. It is > applicable to any top-down hierarchical authorization mechanism. > Security has (non-monetary) costs. as this derives from address space ownership's dependence on the current hierarchic administrative allocation model, to fix it merely change the administrative model or our trust model that depends on that hierarchy. randy From alexb at ripe.net Mon Apr 30 02:18:12 2012 From: alexb at ripe.net (Alex Band) Date: Mon, 30 Apr 2012 09:18:12 +0200 Subject: rpki vs. secure dns? In-Reply-To: <4F9DA9A1.9000301@foobar.org> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9DA9A1.9000301@foobar.org> Message-ID: <6A18C3C0-DEC1-42F0-B3A4-782F3239453C@ripe.net> On 29 Apr 2012, at 22:50, Nick Hilliard wrote: > On 28/04/2012 14:04, Alex Band wrote: >> At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote >> on RPKI at the general meeting. The result was that the RIPE NCC has the >> green light to continue offering the Resource Certification service, >> including all BGP Origin Validation related functionality. It's correct >> that concerns were raised in the area of security, resilience and >> operator autonomy, as you mention. These concerns are continuously being >> evaluated and addressed. The response to the update that was given at >> RIPE 64 two weeks ago indicated that the membership and Community are >> happy with the approach the RIPE NCC is taking in this regard. Of course >> I realize that some people will never be convinced, no matter which >> steps are taken? > > Alex, I have to take exception with your statement that people in the RIPE > region are generally happy about RPKI and the RIPE NCC RPKI project. They > aren't. That's not what I said. :) > - a substantial number of people, both within the RIPE community and > within the RIPE NCC membership have serious concerns about the long-term > legal consequences of this project which have not (in their opinion) been > addressed adequately. I already linked to my RIPE64 presentation from two weeks ago before, but here it is again: https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf Slide 2-4: we heard you. This is what I said: >> The response to the update that was given at >> RIPE 64 two weeks ago indicated that the membership and Community are >> happy with the approach the RIPE NCC is taking in this regard. This is where I suspect you may be: >> I realize that some people will never be convinced, no matter which >> steps are taken? So all in all you quoted me well. :) -Alex Now getting in my car for some internet-free holidays in the sun. See you all in a week! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From rens at autempspourmoi.be Mon Apr 30 04:42:27 2012 From: rens at autempspourmoi.be (Rens) Date: Mon, 30 Apr 2012 11:42:27 +0200 Subject: VPN over satellite Message-ID: <000e01cd26b5$8e132d90$aa3988b0$@be> Dear, Could anybody recommend any hardware that can build a VPN that works well over satellite connections? (TCP enhancements) I want to setup a L3 VPN between 2 satellite connections Even additionally if that hardware would also support WAN bonding even better because I also have a scenario to connect 2 times 2 satellites to have more capacity for my L3 VPN Regards, Rens From jason.tredup at gmail.com Mon Apr 30 06:29:51 2012 From: jason.tredup at gmail.com (Gmail) Date: Mon, 30 Apr 2012 07:29:51 -0400 Subject: VPN over satellite In-Reply-To: <000e01cd26b5$8e132d90$aa3988b0$@be> References: <000e01cd26b5$8e132d90$aa3988b0$@be> Message-ID: Why not use a standard Cisco router or Asa for the routing and VPN and put a riverbed steelhead on both ends to do Tcp optimization and compression. On Apr 30, 2012, at 5:42 AM, "Rens" wrote: > Dear, > > > > Could anybody recommend any hardware that can build a VPN that works well > over satellite connections? (TCP enhancements) > > I want to setup a L3 VPN between 2 satellite connections > > > > Even additionally if that hardware would also support WAN bonding even > better because I also have a scenario to connect 2 times 2 satellites to > have more capacity for my L3 VPN > > > > Regards, > > > > Rens > > > > > From rens at autempspourmoi.be Mon Apr 30 07:06:03 2012 From: rens at autempspourmoi.be (Rens) Date: Mon, 30 Apr 2012 14:06:03 +0200 Subject: VPN over satellite In-Reply-To: References: <000e01cd26b5$8e132d90$aa3988b0$@be> Message-ID: <003e01cd26c9$9d8fc760$d8af5620$@be> IPSec does not run well over satellite since the TCP headers are also encrypted -----Original Message----- From: Gmail [mailto:jason.tredup at gmail.com] Sent: maandag 30 april 2012 13:30 To: Rens Cc: Subject: Re: VPN over satellite Why not use a standard Cisco router or Asa for the routing and VPN and put a riverbed steelhead on both ends to do Tcp optimization and compression. On Apr 30, 2012, at 5:42 AM, "Rens" wrote: > Dear, > > > > Could anybody recommend any hardware that can build a VPN that works well > over satellite connections? (TCP enhancements) > > I want to setup a L3 VPN between 2 satellite connections > > > > Even additionally if that hardware would also support WAN bonding even > better because I also have a scenario to connect 2 times 2 satellites to > have more capacity for my L3 VPN > > > > Regards, > > > > Rens > > > > > From denys at visp.net.lb Mon Apr 30 07:33:05 2012 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 30 Apr 2012 15:33:05 +0300 Subject: VPN over satellite In-Reply-To: <003e01cd26c9$9d8fc760$d8af5620$@be> References: <000e01cd26b5$8e132d90$aa3988b0$@be> <003e01cd26c9$9d8fc760$d8af5620$@be> Message-ID: <031d254af567e0c3379def9e4548d111@visp.net.lb> I did developed my own accelerator in 2006(globax) and have customers till now, but only for one-way ISP's in CIS region, and partially Europe (Germany). Sure worked with satellite internet all that years. But since i am not interested to advertise it here(working only for ISPs), i will mention possible alternatives: There was few solutions, most of them was from Tellinet and Mentat. Tellinet are for Newtec now, and Mentat are for Packeteer(and Packeteer for Bluecoat). Last time i seen optimization option in Packetshaper from Bluecoat. Probably worth to visit Newtec, as i see your domain are .be, and their HQ in Belgium. Riverbed, i heard about them, but never tried. Most of TDMA VSAT modems also has embedded accelerators. Please let me know if you want to know anything else. On 2012-04-30 15:06, Rens wrote: > IPSec does not run well over satellite since the TCP headers are also > encrypted > > -----Original Message----- > From: Gmail [mailto:jason.tredup at gmail.com] > Sent: maandag 30 april 2012 13:30 > To: Rens > Cc: > Subject: Re: VPN over satellite > > Why not use a standard Cisco router or Asa for the routing and VPN > and put a > riverbed steelhead on both ends to do Tcp optimization and > compression. > > On Apr 30, 2012, at 5:42 AM, "Rens" wrote: > >> Dear, >> >> >> >> Could anybody recommend any hardware that can build a VPN that works >> well >> over satellite connections? (TCP enhancements) >> >> I want to setup a L3 VPN between 2 satellite connections >> >> >> >> Even additionally if that hardware would also support WAN bonding >> even >> better because I also have a scenario to connect 2 times 2 >> satellites to >> have more capacity for my L3 VPN >> >> >> >> Regards, >> >> >> >> Rens >> >> >> >> >> --- Network engineer Denys Fedoryshchenko Dora Highway - Center Cebaco - 2nd Floor Beirut, Lebanon Tel: +961 1 247373 E-Mail: denys at visp.net.lb From russw at riw.us Mon Apr 30 08:41:51 2012 From: russw at riw.us (Russ White) Date: Mon, 30 Apr 2012 09:41:51 -0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> Message-ID: <4F9E969F.4040308@riw.us> > free dinner at nanog/van for anyone who can explain how the dnssec > approach meets the defcon attack. hint: it is a path attack, not an > origin attack, and the dns pidgeon has no hooks to path attack > prevention. at ripe, joe gersh asked me for an example of a path attack > and i told him of the defcon demo. seems he also did not bother to do > his homework. but it makes good pr. .... > you are right, you have not done your homework. rpki-based origin > validation asks no changes to bgp. Free dinner to anyone who can explain how the RPKI piece of the SIDR work resolves path attacks. You're comparing apples to oranges here. Neither a DNS based solution nor the RPKI will resolve path attacks, so neither apply to the type of attack you're talking about. There are solutions for this sort of attack. Everything from completely loose, community based solutions to totally control freak horrible solutions, like BGP-SEC (and which doesn't really solve the problem anyway). > yes. rpki can also have that issue as the certs can have urls that use > domain names. i believe they could use ip address urls instead. but > the gathering operation differs greatly between the rpki and the dnssec > based proposal. with the latter, you can't even tell you have the full > set. The problem at hand is relying on routing to build the routing system. How does using an IP address rather than a DNS based hostname change the need for routing to work before routing can work? Reality check: I don't know that this is all that important, in the end. So long as you can use an IGP locally with a default route to reach a copy of the database, whether it be based on DNS, an RPKI, or anything else, then you can bootstrap your EGP routing. If everything goes down at the same time, then you would just start rebuilding from the places where the root servers live, no matter what system's root servers we're talking about. So I think this is a bit of a red herring at the EGP level. > i do not like it either. but it is a trade you make for security. and, > at ripe ljubljana, i think alex started to discuss some schemes to > ameliorate it. more later on this. The problem is worse than your initial estimate. A day's worth of downtime can cost you your business in total, not just some lost revenue. No matter whether or not you agree with the article's premise, at least some provider folks are starting to ask some hard questions --which is a good thing! Let's not shut the conversation down by making broad proclamations about how the problem has been solved, "move along, nothing to see here," etc. There is something to see here, so slow down and take a look. Rubbernecking, in this case, is encouraged. Russ -- <>< Scripture Alone, Grace Alone, Faith Alone http://thinkinginchrist.com/ From bortzmeyer at nic.fr Mon Apr 30 08:53:46 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 30 Apr 2012 15:53:46 +0200 Subject: rpki vs. secure dns? In-Reply-To: <4F9E969F.4040308@riw.us> References: <4F9B181D.30606@isc.org> <4F9E969F.4040308@riw.us> Message-ID: <20120430135346.GA7454@nic.fr> On Mon, Apr 30, 2012 at 09:41:51AM -0400, Russ White wrote a message of 60 lines which said: > Neither a DNS based solution nor the RPKI will resolve path attacks, I want to be sure of the terminology: what is deployed presently is the bundle RPKI+ROA. As their name say, ROA can only be used against origin attacks. But RPKI can be used for other things than RPKI+ROA, including BGP-sec (against path-based attacks), no? From randy at psg.com Mon Apr 30 09:05:21 2012 From: randy at psg.com (Randy Bush) Date: Mon, 30 Apr 2012 10:05:21 -0400 Subject: rpki vs. secure dns? In-Reply-To: <20120430135346.GA7454@nic.fr> References: <4F9B181D.30606@isc.org> <4F9E969F.4040308@riw.us> <20120430135346.GA7454@nic.fr> Message-ID: > I want to be sure of the terminology: what is deployed presently is > the bundle RPKI+ROA. As their name say, ROA can only be used against > origin attacks. But RPKI can be used for other things than RPKI+ROA, > including BGP-sec (against path-based attacks), no? wfm From russw at riw.us Mon Apr 30 09:05:40 2012 From: russw at riw.us (Russ White) Date: Mon, 30 Apr 2012 10:05:40 -0400 Subject: rpki vs. secure dns? In-Reply-To: <20120430135346.GA7454@nic.fr> References: <4F9B181D.30606@isc.org> <4F9E969F.4040308@riw.us> <20120430135346.GA7454@nic.fr> Message-ID: <4F9E9C34.2050902@riw.us> >> Neither a DNS based solution nor the RPKI will resolve path attacks, > > I want to be sure of the terminology: what is deployed presently is > the bundle RPKI+ROA. As their name say, ROA can only be used against > origin attacks. But RPKI can be used for other things than RPKI+ROA, > including BGP-sec (against path-based attacks), no? The RPKI can provide the keying infrastructure on which a mechanism to "protect the path," (controversial terminology in and of itself) could be based. Is that the right basis for path validation? I don't know that we should assume this. But key distribution is the easy part of the problem here. The hard part is determining what we're trying to protect and what the tradeoffs are in trying to defend against those attacks. BGP-SEC assumes we care about verifying the path a "routing object" takes through the network, we don't much care about replay attacks, policy is off the table (except one policy specific folks care about), and operators are willing to replace their hardware specifically to resolve this problem. Is this the right set of presuppositions to make? The provider community, IMHO, hasn't really participated too much in this entire discussion, so we don't really know the answers to this question. Russ From brandon at rd.bbc.co.uk Mon Apr 30 09:33:48 2012 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 30 Apr 2012 15:33:48 +0100 (BST) Subject: rpki vs. secure dns? Message-ID: <201204301433.PAA03427@sunf10.rd.bbc.co.uk> > Reality check: I don't know that this is all that important, in the end. > So long as you can use an IGP locally with a default route to reach a > copy of the database, whether it be based on DNS, an RPKI, or anything > else, then you can bootstrap your EGP routing. If everything goes down > at the same time, then you would just start rebuilding from the places > where the root servers live, no matter what system's root servers we're > talking about. or you wait for the Elders of the Internet to visit with blessings http://www.youtube.com/watch?v=iDbyYGrswtg brandon From regnauld at nsrc.org Mon Apr 30 09:43:55 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 30 Apr 2012 16:43:55 +0200 Subject: rpki vs. secure dns? In-Reply-To: <201204301433.PAA03427@sunf10.rd.bbc.co.uk> References: <201204301433.PAA03427@sunf10.rd.bbc.co.uk> Message-ID: <20120430144355.GP52497@macbook.bluepipe.net> Brandon Butterworth (brandon) writes: > > or you wait for the Elders of the Internet to visit with blessings > http://www.youtube.com/watch?v=iDbyYGrswtg Didn't randy just chime in ? From danny at tcb.net Mon Apr 30 09:53:05 2012 From: danny at tcb.net (Danny McPherson) Date: Mon, 30 Apr 2012 10:53:05 -0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> Message-ID: On Apr 28, 2012, at 6:34 AM, Alex Band wrote: > All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better. We should be more careful with statements such as this, they're conflating important things that add to the confusion in this area. None of these implementations support "RPKI" today. What they support is a new protocol for onboarding routing policy data (some call this a [VRP], essentially prefix,origin bindings) into soft state in a router. -danny [VRP] https://ripe64.ripe.net/presentations/74-120417.sidr-origin.pdf From dburk at burkov.aha.ru Mon Apr 30 10:16:10 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Mon, 30 Apr 2012 19:16:10 +0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> Message-ID: <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru> Danny, just one more comment. So named vendor's support can be the worst case when there are no practical ways to deploy and it is absolutely not clear - should we follow this hierarchical model - I think it is the key point as we pushed ourselves by inertia to this way of thinking. Imho - it is way to nowhere in such form We need more flexible, distributed architecture behind - no matter - which interests will be lobbied as we have got already. On Apr 30, 2012, at 6:53 PM, Danny McPherson wrote: > > On Apr 28, 2012, at 6:34 AM, Alex Band wrote: > >> All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better. > > We should be more careful with statements such as this, they're conflating important things that add to the confusion in this area. > > None of these implementations support "RPKI" today. What they support is a new protocol for onboarding routing policy data (some call this a [VRP], essentially prefix,origin bindings) into soft state in a router. > > -danny > > [VRP] https://ripe64.ripe.net/presentations/74-120417.sidr-origin.pdf > From randy at psg.com Mon Apr 30 10:46:06 2012 From: randy at psg.com (Randy Bush) Date: Mon, 30 Apr 2012 11:46:06 -0400 Subject: rpki vs. secure dns? In-Reply-To: <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru> References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru> Message-ID: > We need more flexible, distributed architecture behind - no matter - > which interests will be lobbied as we have got already. as i agree that there is a problem, i *very* eagerly await your proposal randy From jared at puck.nether.net Mon Apr 30 10:51:10 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 30 Apr 2012 11:51:10 -0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru> Message-ID: Personally I find the BitTorrent approach interesting. Jared Mauch On Apr 30, 2012, at 11:46 AM, Randy Bush wrote: >> We need more flexible, distributed architecture behind - no matter - >> which interests will be lobbied as we have got already. > > as i agree that there is a problem, i *very* eagerly await your proposal > > randy From dburk at burkov.aha.ru Mon Apr 30 10:55:26 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Mon, 30 Apr 2012 19:55:26 +0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru> Message-ID: <588825E3-EE10-4A69-87A8-6A72AC383063@burkov.aha.ru> Randy - you know that I'm enough stupid- means straightforward - may be the way is not only technical (recomendations design) - but also to combine with some policy changes as splitting allocations and assignments (may be changing who is responsible for what?) Or we follow the traditional way(means hierarchy) or we are capable to introduce one more level for flexebility - we should be honest that all techinical design just follows some political or quasi-political decisions. But I think it can be changed. Dima On Apr 30, 2012, at 7:46 PM, Randy Bush wrote: >> We need more flexible, distributed architecture behind - no matter - >> which interests will be lobbied as we have got already. > > as i agree that there is a problem, i *very* eagerly await your proposal > > randy From Eric.Morin at corp.xplornet.com Mon Apr 30 13:06:15 2012 From: Eric.Morin at corp.xplornet.com (Eric Morin) Date: Mon, 30 Apr 2012 15:06:15 -0300 Subject: Colo recommendations for 2001 6th (Westin BLDG) Seattle Message-ID: Hi I am looking for a few RUs / ? rack (~20Amps of VAC) in a carrier neutral location with 24x365 smart hands service at 2001 6th Ave in Seattle. Any recommendations? Thanks in advance Eric RR Morin Internetwork Designer IP Network Engineering & Carrier Relations XplorNet Communications Inc AS22995 506.324.4533 | eric.morin at corp.xplornet.com NOTE: My email address has changed! 864 Anderson Dr | Saint John, New Brunswick | Canada E2M 4G3 This e-mail (including any attachments) is for the sole use of the intended recipient and may contain confidential information protected by duties of confidentiality or privilege. If you are not the intended recipient of this e-mail, please immediately notify us by return e-mail or by telephone, delete this e-mail and destroy any copies. Thank you. ________________________________________________________________________________ Ce message est destin? uniquement ? la personne pr?vue et peut contenir des renseignements confidentiels et/ou privil?gi?s au titre d?une obligation de confidentialit?. Si vous n'?tes pas le destinataire vis?, veuillez nous en informer sans d?lai par courriel ou t?l?phone et d?truire ce message ainsi que toute pi?ce jointe, sans en garder de copie. Merci. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 25450 bytes Desc: image001.jpg URL: From streiner at cluebyfour.org Mon Apr 30 13:36:34 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 30 Apr 2012 14:36:34 -0400 (EDT) Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: <20120427142607.GB29251@hiwaay.net> References: <20120427135616.GA29251@hiwaay.net> <4F9AAA31.7010702@brightok.net> <20120427142607.GB29251@hiwaay.net> Message-ID: On Fri, 27 Apr 2012, Chris Adams wrote: > I don't think that will work, because there's an automatic direct route > for fe80::/64 to all interfaces with family inet6 configured. The only > way I see around it is to apply a firewall filter to all IPv6 interfaces > that blocks anything with a source in fe80::/64 and destination _not_ in > fe80::/64. I've verified this between two M7is in my lab, running Junos 10.3. I tried to verify similar behavior between a 6509 running 12.2(33)SXJ2 and my target M7i, but either the Cisco box doesn't appear to allow the traffic, or the command parser in that version of IOS is smart enough not to allow a ping sourced from a link-local address, but destined to a non-link-local address. jms From randy.johnson at Avalara.com Mon Apr 30 13:38:13 2012 From: randy.johnson at Avalara.com (Randy Johnson) Date: Mon, 30 Apr 2012 18:38:13 +0000 Subject: Colo recommendations for 2001 6th (Westin BLDG) Seattle In-Reply-To: References: Message-ID: <3734B6220034504CA4A5E23B0E34B4550870C1FF@av-corp-esx01.SanJuan.Avalara.com> Does it absolutely need to be at the Westin ? If 'within downtown Seattle' is acceptable, you might try 'DFCOLO.COM' as they are over at 3101 Western Ave. -----Original Message----- From: Eric Morin [mailto:Eric.Morin at corp.xplornet.com] Sent: Monday, April 30, 2012 11:06 AM To: nanog at nanog.org Subject: Colo recommendations for 2001 6th (Westin BLDG) Seattle Hi I am looking for a few RUs / ? rack (~20Amps of VAC) in a carrier neutral location with 24x365 smart hands service at 2001 6th Ave in Seattle. Any recommendations? Thanks in advance Eric RR Morin Internetwork Designer IP Network Engineering & Carrier Relations XplorNet Communications Inc AS22995 506.324.4533 | eric.morin at corp.xplornet.com NOTE: My email address has changed! 864 Anderson Dr | Saint John, New Brunswick | Canada E2M 4G3 This e-mail (including any attachments) is for the sole use of the intended recipient and may contain confidential information protected by duties of confidentiality or privilege. If you are not the intended recipient of this e-mail, please immediately notify us by return e-mail or by telephone, delete this e-mail and destroy any copies. Thank you. ________________________________________________________________________________ Ce message est destin? uniquement ? la personne pr?vue et peut contenir des renseignements confidentiels et/ou privil?gi?s au titre d'une obligation de confidentialit?. Si vous n'?tes pas le destinataire vis?, veuillez nous en informer sans d?lai par courriel ou t?l?phone et d?truire ce message ainsi que toute pi?ce jointe, sans en garder de copie. Merci. This communication, including attachments, is confidential and may contain proprietary information intended only for the proposed recipient. Please notify the sender and delete this message if you believe that you have received this message in error or if you are not the proposed recipient. Unauthorized disclosure, copying, or distribution of the information is strictly prohibited. Please also be aware Avalara does not provide client-specific tax management advice. Recipients seeking advice on specific tax matters should conduct their own due diligence and seek advice from a qualified tax practitioner before relying on any information contained herein. From fw at deneb.enyo.de Mon Apr 30 16:04:16 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 30 Apr 2012 23:04:16 +0200 Subject: rpki vs. secure dns? In-Reply-To: (Alex Band's message of "Sun, 29 Apr 2012 17:16:39 +0200") References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <874ns42ioc.fsf@mid.deneb.enyo.de> <4F9C2747.7010301@foobar.org> <20120428172751.GU36073@macbook.bluepipe.net> <4F9C2CBA.1010602@foobar.org> <99047008-B5DE-48DA-AD21-700C3CB7B8C5@ripe.net> <20120428192843.GD44404@macbook.bluepipe.net> Message-ID: <87bom9aq3z.fsf@mid.deneb.enyo.de> * Alex Band: > All in all, for an RPKI-specific court order to be effective in > taking a network offline, the RIR would have to tamper with the > registry, inject false data and try to make sure it's not detected > so nobody applies a local override. Please keep in mind that this is what's happening with DNS: registries are not only forced by the courts to remove delegations, but to delegate names to specific parties. On the other hand, it's not entirely clear whether this is such a bad thing. From nikm at cyberflunk.com Mon Apr 30 16:41:19 2012 From: nikm at cyberflunk.com (Nikos Mouat) Date: Mon, 30 Apr 2012 14:41:19 -0700 (PDT) Subject: Colo recommendations for 2001 6th (Westin BLDG) Seattle In-Reply-To: References: Message-ID: Hi Eric - The SIX has a list of co-lo vendors on our website: http://www.seattleix.net/join.htm#colo-circuit Good luck. Nikos Mouat On Mon, 30 Apr 2012, Eric Morin wrote: > Hi > > I am looking for a few RUs / ? rack (~20Amps of VAC) in a carrier neutral location with 24x365 smart hands service at 2001 6th Ave in Seattle. > > > > Any recommendations? > > > > Thanks in advance > > Eric RR Morin > > Internetwork Designer > > IP Network Engineering & Carrier Relations > > XplorNet Communications Inc > > AS22995 > > > > 506.324.4533 | eric.morin at corp.xplornet.com NOTE: My email address has changed! > > > > 864 Anderson Dr | Saint John, New Brunswick | Canada E2M 4G3 > > > > > > > > > > > > > > This e-mail (including any attachments) is for the sole use of the intended recipient and > may contain confidential information protected by duties of confidentiality or privilege. If you are not the intended recipient of this e-mail, please immediately notify us by return e-mail or by telephone, delete this e-mail and destroy any copies. Thank you. > > ________________________________________________________________________________ > > Ce message est destin? uniquement ? la personne pr?vue et peut contenir des renseignements confidentiels et/ou privil?gi?s au titre d?une obligation de confidentialit?. Si vous n'?tes pas le destinataire vis?, veuillez nous en informer sans d?lai par courriel ou t?l?phone et d?truire ce message ainsi que toute pi?ce jointe, sans en garder de copie. Merci. > > > From bedard.phil at gmail.com Mon Apr 30 16:41:29 2012 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 30 Apr 2012 17:41:29 -0400 Subject: JUNOS forwards IPv6 link-local packets In-Reply-To: Message-ID: On 4/30/12 2:36 PM, "Justin M. Streiner" wrote: >On Fri, 27 Apr 2012, Chris Adams wrote: > >> I don't think that will work, because there's an automatic direct route >> for fe80::/64 to all interfaces with family inet6 configured. The only >> way I see around it is to apply a firewall filter to all IPv6 interfaces >> that blocks anything with a source in fe80::/64 and destination _not_ in >> fe80::/64. > >I've verified this between two M7is in my lab, running Junos 10.3. I >tried to verify similar behavior between a 6509 running 12.2(33)SXJ2 and >my target M7i, but either the Cisco box doesn't appear to allow the >traffic, or the command parser in that version of IOS is smart enough >not to allow a ping sourced from a link-local address, but destined to a >non-link-local address. > >Jms When I tried this on IOS-XR I first tried a local ping and it did not allow a ping sourced from a link-local address to ping any global address except for one assigned to the same interface. However that didn't stop it from forwarding frames coming into an interface from another device. Phil From morrowc.lists at gmail.com Mon Apr 30 21:54:50 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 30 Apr 2012 22:54:50 -0400 Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <87ipgk2n8c.fsf@mid.deneb.enyo.de> <93E56914-2833-491B-9035-E852E0A1C4BA@burkov.aha.ru> Message-ID: On Mon, Apr 30, 2012 at 11:51 AM, Jared Mauch wrote: > Personally I find the BitTorrent approach interesting. this conflates the 2 (at least!) topics here: 1) distribution of repository data 2) heirarchy of authority for the data which is in the repository -chris > On Apr 30, 2012, at 11:46 AM, Randy Bush wrote: > >>> We need more flexible, distributed architecture behind - no matter - >>> which interests will be lobbied as we have got already. >> >> as i agree that there is a problem, i *very* eagerly await your proposal >> >> randy > From paul4004 at gmail.com Mon Apr 30 21:58:55 2012 From: paul4004 at gmail.com (PC) Date: Mon, 30 Apr 2012 20:58:55 -0600 Subject: VPN over satellite In-Reply-To: <000e01cd26b5$8e132d90$aa3988b0$@be> References: <000e01cd26b5$8e132d90$aa3988b0$@be> Message-ID: Most satellite modems offer built in TCP acceleration options heavily optimized for VSAT use and an encryption option (proprietary to their hardware only) which is probably your best bet. You can then use traditional encryption to your satellite provider (or take Ethernet handoff at the satellite earth station with co-located equipment, if appropriate). Otherwise, if this is not adequate you can use any traditional acceleration solution at the end sites, just check with the vendor for how optimized they are for your latency scenario. For various reasons, you're best not bonding. Just obtain a bigger space segment. It's literally scalable to at least ~35 megabit with ease by buying the appropriate sized pipe. Otherwise if you must bond I suggest you consider traditional ip routing mechanisms to do so on a per-flow basis. On Mon, Apr 30, 2012 at 3:42 AM, Rens wrote: > Dear, > > > > Could anybody recommend any hardware that can build a VPN that works well > over satellite connections? (TCP enhancements) > > I want to setup a L3 VPN between 2 satellite connections > > > > Even additionally if that hardware would also support WAN bonding even > better because I also have a scenario to connect 2 times 2 satellites to > have more capacity for my L3 VPN > > > > Regards, > > > > Rens > > > > > > From eyeronic.design at gmail.com Mon Apr 30 23:01:12 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 30 Apr 2012 21:01:12 -0700 Subject: VPN over satellite In-Reply-To: References: <000e01cd26b5$8e132d90$aa3988b0$@be> Message-ID: "You can then use traditional encryption to your satellite provider (or take Ethernet handoff at the satellite earth station with co-located equipment, if appropriate)." True...except for most audit/regulatory purposes, having the traffic unencrypted in any part of the chain is unacceptable. "Just obtain a bigger space segment. It's literally scalable to at least ~35 megabit with ease by buying the appropriate sized pipe." True, but you have to make sure you have the right modem. The majority of modems in VSAT stacks can go up to ~10mbps. You usually have to shell out quite a bit more money to get a modem capable of handling larger bandwidths. "Otherwise, if this is not adequate you can use any traditional acceleration solution at the end sites, just check with the vendor for how optimized they are for your latency scenario." Exactly. Figuring out *what* specifically you want to accelerate is vital. Virtually any accelerator on the market can handle FTP, HTTP and other simple protocols. It takes a lot of know-how to properly accelerate some of the more complex ones. On Mon, Apr 30, 2012 at 7:58 PM, PC wrote: > Most satellite modems offer built in TCP acceleration options heavily > optimized for VSAT use and an encryption option (proprietary to their > hardware only) which is probably your best bet. ?You can then use > traditional encryption to your satellite provider (or take Ethernet handoff > at the satellite earth station with co-located equipment, if appropriate). > > Otherwise, if this is not adequate you can use any traditional acceleration > solution at the end sites, just check with the vendor for how optimized > they are for your latency scenario. > > For various reasons, you're best not bonding. ?Just obtain a bigger space > segment. ?It's literally scalable to at least ~35 megabit with ease by > buying the appropriate sized pipe. ?Otherwise if you must bond I suggest > you consider traditional ip routing mechanisms to do so on a per-flow basis. > > > > On Mon, Apr 30, 2012 at 3:42 AM, Rens wrote: > >> Dear, >> >> >> >> Could anybody recommend any hardware that can build a VPN that works well >> over satellite connections? (TCP enhancements) >> >> I want to setup a L3 VPN between 2 satellite connections >> >> >> >> Even additionally if that hardware would also support WAN bonding even >> better because I also have a scenario to connect 2 times 2 satellites to >> have more capacity for my L3 VPN >> >> >> >> Regards, >> >> >> >> Rens >> >> >> >> >> >> -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From malayter at gmail.com Fri Apr 20 15:11:40 2012 From: malayter at gmail.com (Ryan Malayter) Date: Fri, 20 Apr 2012 20:11:40 -0000 Subject: SunGard contact in Boston datacenter? Message-ID: <11369929.863.1334952694502.JavaMail.geo-discussion-forums@ynlp3> Anybody from SunGard lurking? We're observing major packet loss on an AT&T link to SunGard router 74.205.255.246 in Boston. We have a SaaS vendor behind that router, and the application is all but unusable. The SaaS vendor's support staff aren't able to address the issue with SunGard (or don't know how). Thanks for any help, -- Ryan Malayter