January 2013 - Test - lists.nanog.org

Issues with level3?
by Network Operations 15 Jan '13

15 Jan '13

Anyone seeing any issues with level3? We can connect to every other IP in our Class C. When tracerouting to individual IP's, (x.x.x.50/51/52/53) we get a drop at ge-4-16.car2.Washington1.Level3.net [4.59.146.53] for 50, but 51 is fine, drop for 52, 53 is fine. Thanks.

12 15

Re: Issues with level3?
by Scott Weeks 15 Jan '13

15 Jan '13

------- original message ---------- > I still call a /24 a class c too.. :/ lol ----------------------------------- I'm having trouble rectifying the top part of your email: -------- bhm(a)ufl.edu wrote: -------- More efficient that way - "class c" uses fewer syllables than "slash twenty four" :-) ------------------------------------- with the bottom part of your email: ---------------------------------------------- Senior Network Engineer - University of Florida CNS/Network Services -------------------------------------------------

1 0

State of the RING 2012
by Job Snijders 15 Jan '13

15 Jan '13

Hi, Here is the yearly update regarding the NLNOG RING project, this year's update includes some links to tools that might be of interest to the broader community. More information about the RING can be found here: https://ring.nlnog.net/ Kind regards, Job ============================================================ State of the NLNOG RING 2012 A yearly newsletter about the best debugging project ever Edition 2, 28 Dec 2012 ============================================================ Contents ============================================================ 1. Introduction: growth 2. New services 4. Into the future! 5. Testimonials & conference exposure 6. Closing notes ============================================================ 1. Introduction: growth ============================================================ Today, 28th of december 2012, the RING turns 2 years old! The project's origins can be traced back to the following line on IRC (translated): [28 Dec 2010/10:26 CET - #NLNOG] "hey, maybe we should create a #nlnog test platform" And now here we are, 2 years later: 188 machines provided by 165 organisations in 39 countries. Compared to 2011 we have more than doubled in size! From our usage statistics we gather that 65% of organisations actively makes use of the RING through SSH. Other statistics gathered from our code repositories: - 1111 commits were made (doubled since last year!) - Most code commits happened, again, on Tuesdays - Lines of code: 20267 insertions(+), 5774 deletions(-) We could not have sustained this level of growth without the continuing support of our infrastructure sponsors and the 2012 fundraiser contributors: XS4ALL, Amazon Web Services, Leaseweb, Atrato IP Networks, Gossamer Threads, BIT, PCextreme, SoftLayer, Snijders IT, Solido Hosting, Duocast, A2B Internet, Nedzone, Tetaneutral, LCHost, Previder, Triple IT and eBay Classifieds Group. A full overview of all supporters can be found here: https://ring.nlnog.net/patrons/ ============================================================ 2. New services ============================================================ AMP (Active Measurement Project): --------------------------------- One of the biggest changes this year was moving from a distributed master/slave smokeping setup to something much better: AMP. The AMP software performs measurements from every RING node to every other RING node, and reports the results to central collectors which in turn feed a web interface. AMP as a tool offers us insight in end-to-end MTU, jitter, latency, packetloss and historic traceroutes both for IPv4 and IPv6 between all RING nodes. URL: http://amp.ring.nlnog.net/ BGP Looking glass: ------------------ Due to popular request we set up a BGP looking glass, which currently receives full IPv4 and IPv6 tables from 35+ participants. The LG uses the BIRD BGP daemon with a web interface written by one of the RING participants! We currently are exploring if we can use the collected data for a monitoring and alerting system to help participants gain insight in prefix visibility and, for instance hijack events. Stay tuned! URL: http://lg.ring.nlnog.net/ IRR/RPLS services: ------------------ Although the IRR system and RPSL have been around for a long time, there still is a lot of room for improvement in terms of performance, ease of use and standardised methods and tools. We believe that the RING community can make a difference in the popularity of proper filtering. One of the first things we offer (in beta) is a web service to expand RPSL object such as AS-SET, AUTNUM and RS-SETs and expose the data in JSON. URL: http://irr.ring.nlnog.net/ ============================================================ 3. Into the future! ============================================================ In 2013 we will continue to automate as many aspects of the RING as possible. But more importantly, the RING has to become the best swiss army knife a network engineer can imagine so we will focus on usability, more advanced tools and security. We are making a lot of progress towards publication of all kinds of RING related information in an easy accessible database, we imagine this will accelerate the development of a new generation of tools! We also started talks with other debugging projects such as RIPE Atlas to explore if cooperation and exchange of information can further such projects. As the RING is a community effort, we can only become more valuable to our members by help from the community. We need you for new creative ideas, high quality code, and of course more RING nodes. If you can help out in our efforts, don't hesitate to contact us! ============================================================ 4. Testimonials & Exposure ============================================================ Two debugging cases have been documented, where the RING proved to be of vital importance when debugging an issue at hand. Route leak: ----------- A root-cause analysis based on historic data collected by the RING. URL: https://ring.nlnog.net/news/root-cause-analysis-using-amp/ The IPv4 address that ended with .255: -------------------------------------- How the variety in RING nodes helped locate an ancient, dysfunctional ACL. URL: https://ring.nlnog.net/news/ring-success-the-ipv4-255-problem/ Conference exposure: -------------------- Various RING participants have spoken at Internet oriented conferences around the world. The following meetings made a presentation slot available to the RING: eduPERT, LINX79, MENOG11, NANOG56 and RIPE65. All of these presentations have helped the RING grow, as in the days after such a presentation we saw a spike in RING participant applications. If you want to present about the RING at a meeting in your region or local operator community, please contact us. We have great slides available for this purpose! ============================================================ 5. Closing notes ============================================================ We conclude this newsletter by saying to you, the participants, THANK YOU! Without the continued support from lots of participants the RING would not be where it is today. We are proud to be playing a small role in making the Internet an easier thing to debug and research. Again, thank you! Kind regards, Job Snijders Martin Pels Peter van Dijk Edwin Hermans ringthing

2 1

(Long) rant about some LIRs in RIPE region, most likely linked to RFG's earlier email
by Vasile Capdefier 15 Jan '13

15 Jan '13

Disclaimer: this is just my POV, I didn't investigate (too) much/deep. All the information bellow is public, easy to find and Google Translate seems to work most of the times. From what I know, Jump.RO's business model is to *sell* IP space from their ALLOCATED PA ranges received from RIPE. Not *sub-allocate*, not *assign* or similar terms. They don't ask too many questions. They give you IPs faster than other LIRs. They market this as being professional. All of the Jump.RO's sub-allocations (that I've seen in whois) have *ASSIGNED PA* status, which according to ripe-553 [1] is to be used when the range is assigned to an end user for services provided by the issuing LIR. This is probably not the case because except the (new) annual fee for the registration service there are no other services provided by that LIR to the end user. Most of Jump.RO's "end users" are in fact small ISPs that can't afford the RIPE membership fees and bypass the rules of not using PI space for customers by deaggregating Jump's IP space. I don't know about the 12k number, but they have a large client base in the country and neighboring countries. I also think that Jump is aware of their IPs being in use by spammers as they advertise on their website that new and unused IP blocks cost about 2 times more than "used" ones. They also note that the previously "used" PA space is checked with "MxToolBox" in 120 anti-spam lists [2]. Even though Jump.RO's business model isn't exactly in the spirit of the RIPE region rules or following best practices (no prefix aggregation, but their excuse is that they are not the only ones doing it), I don't think that they are willing to risk their LIR status by defending known spam operations, so reporting well documented cases of false information provided during registration first to RIPE and then to them would probably get them to withdraw the PA from that customer. The ranges found by you clearly suggest that fake information has been used. Only "under construction" sites, nobody ever heard of those companies, all using same ISPs. With all this said about ro.registry (Jump.RO's LIR id) i'd like to add the following. There are entire LIRs with very large IP allocations and suspicious activities. I'll just list here a few: (RIPE allocation list publicly available here [3]) The first candidate that pops up is ro.visnet (VisNetwork Media SRL). According to their web page [4] they are a pretty large ISP with over 300 experienced employees and over 30 vehicles used for interventions and installations. They provide no CIF (Romanian for Fiscal Identification Code) or other identifying information, but the company is valid and has CIF 25083281. According to the Romanian Trade Register [5], the company named VisNetwork Media SRL with Fiscal Identification Code 25083281 is registered since February 2009, has no employees (where did those 300 professionals go?) and has registered for the 2011 fiscal year expenses of roughly about 3000 EUR (this value is around the value of the RIPE maintenance fees) and an amazing income of 100 EUR. Also, they are not registerd with ANCOM [6] (Romanian National Agency for Management and Regulation in Communications), so they are not a real ISP. They have received from RIPE the following IP space: 20090624 188.170.0.0/16 ALLOCATED PA 20100713 46.49.128.0/17 ALLOCATED PA 20110404 31.173.0.0/16 ALLOCATED PA 20110707 146.0.128.0/17 ALLOCATED PA 20110707 146.0.32.0/19 ALLOCATED PA 20111012 128.234.0.0/16 ALLOCATED PA 20120113 37.56.0.0/16 ALLOCATED PA 20120405 37.224.0.0/16 ALLOCATED PA 20120730 5.163.0.0/16 ALLOCATED PA 20121113 185.9.244.0/22 ALLOCATED PA 20110331 2a03:4100::/29 With this much IP space I would think they must have at least a few LARGE cities covered, but nobody ever heard of them or their professional employees. Also, because apparently their IPs were not enough and their employees seem that they couldn't handle hosting their main website, their website is hosted on IP ranges from another LIR. visnet.ro has address 77.36.59.10 inetnum: 77.36.59.0 - 77.36.59.255 netname: ROSITE-EQUIPMENTS The second obvious candidate for our small investigation is, as you might have guessed, ro.rosite (RoSite Equipment SRL). Information about their deaggregation habits can be found here [7]. According to the Trade Register, ROSITE EQUIPMENT SRL has CIF 17352052 and is a registered company since march 2005. They are registered as an ISP at ANCOM, but with a different company name (ROSITE NET SRL). Their second company, the one registered as an ISP, ROSITE NET SRL has CIF 13669105 and is a registered company since january 2001. The larger company, not the ISP, received from RIPE a large number of IP addresses: 20090706 188.119.128.0/18 ALLOCATED PA 20090813 188.74.128.0/18 ALLOCATED PA 20091223 188.74.192.0/18 ALLOCATED PA 20100325 62.216.64.0/19 ALLOCATED PA 20100628 178.157.64.0/18 ALLOCATED PA 20110712 146.158.128.0/17 ALLOCATED PA 20110712 146.66.208.0/20 ALLOCATED PA 20120105 37.35.128.0/17 ALLOCATED PA 20120105 37.35.32.0/19 ALLOCATED PA 20120724 5.157.128.0/17 ALLOCATED PA 20101217 2a03:8800::/32 On the third place in our list we have ro.swift (now Media Trend Sistem SRL, formerly using the company Swift Marketing SRL). Swift Marketing SRL (nice name, huh?) was deleted from the Trade Registry in may 2011. During 2010 they had 0 employees. The new company, Media Trend Sistem SRL (CIF 26301830) is registered since december 2009 and was known under another name (not publicly available) until changing it's name to the current one in december 2010. They are also not registered as an ISP with ANCOM and had 0 employees in 2011. This didn't seem to stop them from receiving the following IP ranges from RIPE: 20070730 78.95.0.0/16 ALLOCATED PA 20080319 93.168.0.0/15 ALLOCATED PA 20090303 95.218.0.0/15 ALLOCATED PA 20110518 2a00:aa80::/32 Another interesting Romanian LIR is ro.ssnet (SISTEM SOFT NETWORK SRL). The company is registered with the Trade Register with CIF 24496484 since september 2008, had in 2011 only 1 employee and is not a registered ISP with ANCOM. They became LIR just a few months before the final /8 was reached in RIPE region. They only got from RIPE this /15: 20120719 5.154.0.0/15 ALLOCATED PA They also seem to like deaggregating very much [8], now originating 369 prefixes. Now with all this in sight I suppose the ro.registry issue of about an /14 block seems a rather small issue. [1] https://www.ripe.net/ripe/docs/ripe-553 [2] http://www.ip.ro/ip.html [3] ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt [4] http://www.visnet.ro/despre/ [5] http://www.mfinante.ro/agenticod.html [6] http://www.ancom.org.ro/furnizoricomunicatii-electronice_133 [7] http://bgp.he.net/AS49687#_prefixes [8] http://bgp.he.net/AS56465#_prefixes

1 0

NANOG 57 netops security track
by John Kristoff 15 Jan '13

15 Jan '13

Friends, colleagues, fellow operators, The network security track, formerly known as the ISP security BoF, returns at NANOG 57. One option we're considering is taking a few moments for veterans and newcomers to get up and doing a 2 minute or less security contact personal introduction, akin to the peering personals that have been in done in the peering sessions for years. If you're planning on attending and are willing to stand up and introduce yourself to the group, please contact me offline. In addition, we may have room for one or two more brief discussion topics or lightning talks. If anyone, especially newcomers, have something they'd really like to present, conduct a demonstration of or coordinate a brief discussion about, I'd be grateful for your follow ups. Here is an incomplete list of ideas to help stir your thoughts: * Botnet take downs * BGPSEC and RPKI update or trial deplolyments * DDoS case study * Control plane best practices and templates * DNS RPZ overview and/or experience * Embedded device problems and protections * Government regulatory and compliance issues * Malware analysis * Mobile issues * MPLS and VLAN security issues * Route leak/hijack monitoring and mitigation * VM and cloud security challenges * <insert your new cool tool or idea here> Note, this track is not streamed nor recorded. John

1 0

Re: De-funding the ITU
by John Levine 15 Jan '13

15 Jan '13

>>> Please consider signing this petition: >>> >>> http://DeFundTheITU.org Please learn a little more about the ITU before doing so. There is more to the ITU than the dysfunctional ITU-T, and the political fallout from the US being seen as a big rich bully taking its wallet and going home is likely not worth the trivial amount of money involved. -- Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly

14 26

Postini Exiting ISP Business?
by Paul Stewart 14 Jan '13

14 Jan '13

Hey there. We have been using Postini for a number of years as our anti-spam/anti-virus protection for customer email accounts. Mid last year we received a notice from Google that "In 2013, we plan to transition your Postini services to Google Apps for Business." As part of this notice we were also told "You don't need to make any changes to your Postini service or sign up for a Google Apps account. Your Postini service will continue as usual until your migration begins. We will be in touch at least 60 days before your renewal date." In mid November, Google sent us a letter that stated that we had until the end of 2013 to basically get off their service or to contact their preferred partner (Tech Excel) and migrate to Google Apps with them. Recently we have now been told in email by someone at Postini that we "must transition ASAP" and that we really only had til the end of 2012. Geesh, talk about confusing.. Not a great way to treat a long term customer! Anyone else getting the complete "run around" by Postini? We are fine with leaving them, especially now. Having said that, I'm interested in hearing about competitive solutions either in appliances or in cloud based - this is *not* an invitation for sales people to call me please. Thanks, Paul

7 6

Brocade XMR/MLX VLAN bit counters (Cacti graphs for brocade VLANS) (95% billing).
by James Wininger 14 Jan '13

14 Jan '13

All, We are running into an issue with Brocade where we are finding it difficult to to graph VLAN interfaces for bits (in/out) across a tagged (trunk) interface. On Cisco this is not an issue. So what we end up with in Cacti is a blank (no data) graph. I have been all over these devices with snmpwalk etc (typical tool set). Has anyone found a "fix" or work around for this? Or perhaps I should be asking a different question….Is there a better tool/mindset for 95% billing since this is what we are doing with this info. -- Jim Wininger "Don't find fault, find a remedy." - Henry Ford

6 5

Re: ripe/ncc likes cookies
by Scott Weeks 13 Jan '13

13 Jan '13

--- scott(a)doc.net.au wrote: From: Scott Howard <scott(a)doc.net.au> That seems to be a perfectly acceptable use of cookies for me, and is something that could not reliably be done any other way. -------------------------------- How many cookies does nanog.org require for you to allow to look at their site? Seems to me it operates very well without them. Job well done NANOG! :-) scott

2 1

RE: ripe/ncc likes cookies
by Scott Weeks 13 Jan '13

13 Jan '13

---------------------------- Many browsers can be configured into three states (1) accept anything (2) reject third-party cookies (3) reject all cookies. --------------------------- Or "ask me every time". Sites should not require cookies just to look around. I get it if there's a transaction to be made, but just to look? :-( Especially a site like RIPE! scott ps. the www.cookielaw.org site uses the GOOG's Urchin cookies as well as one of their own. No one asked my permission.

2 1