September 2012 - Test - lists.nanog.org

91.201.64.0/22 hijacked?
by Jeroen van Aart 05 Sep '12

05 Sep '12

The below email exchange may be of interest to some of you. The practical upshot is that it appears "the 91.201.64.0/22 range was hijacked and should be included into the DROP list". As an interesting aside, quoting a friend: "the original company (that performed dangerous waste utilization) may have been a shady thing in and of itself (..) what most companies calling themselves "ecoservice" (with variations) do is take money for "safe utilisation" of hazardous waste, and then dump it in some old quarry out in the remote (or not so remote) corner of a forest or other natural area (..) they always have criminal links and protection from corrupts officials (often co-owners) and security/law enforcement services" > From: Jeroen van Aart > there is > nothing but crap coming from 91.201.64.0/24. Amongst other things > attempts to spam (through) wordpress sites. > inetnum: 91.201.64.0 - 91.201.67.255 > netname: Donekoserv > descr: DonEkoService Ltd Don - name of the nearby large river. "EkoService" means ecological service. > country: RU > org: ORG-DS41-RIPE > > person: Haralevich Piotr > address: novocherkassk, ul stremyannaya d.6 > mnt-by: MNT-DONECO > phone: +74951000000 nic-hdl: HP2220-RIPE changed: admin(a)donecoserv.ru 20101117 The company performed dangerous waste utilization: http://donekoservis.alloy.ru/contacts/ http://www.idbo.ru/view/72321/ But domains donecoserv.ru and donekoservis.ru don't exist anymore. traceroute 91.201.64.14 ... 11 router02.spbbm18.ru.edpnet.net (212.71.11.26) 65.979 ms 65.971 ms 66.182 ms 12 77.109.110.62.static.edpnet.net (77.109.110.62) 88.868 ms 47.809 ms 47.715ms 13 195.2.240.234 (195.2.240.234) 48.235 ms 48.546 ms 48.664 ms 14 ajursrv.parohod.biz (95.215.0.206) 47.957 ms 47.752 ms 47.606 ms 15 mail.rx-helps.com (91.201.64.14) 48.206 ms 48.302 ms 48.237 ms SPb (Sankt-Peterburg) is 1500 km from Novocherkassk. parohod.biz also is in Sankt-Peterburg, they offer SEO (which I consider fraud, spamming websites and search engines). Also, see http://support.clean-mx.de/clean-mx/viruses.php?email=admin@donecoserv.ru&r… http://www.spambotsecurity.com/forum/viewtopic.php?f=7&t=795 http://unapprovedpharmacy.wordpress.com/2011/01/03/whois-www-canadianmedssh… | January 3, 2011 ... | inetnum: 91.201.64.0 91.201.67.255 | netname: Donekoserv | descr: DonEkoService Ltd | country: RU | org: ORG-DS41-RIPE ... | organisation: ORG-DS41-RIPE | org-name: DonEko Service | org-type: OTHER | address: novocherkassk, ul stremyannaya d.6 | e-mail: admin(a)bulletproof-web.com Note "bulletproof". Therefore, the 91.201.64.0/22 range was hijacked and should be included into the DROP list.

3 2

Research Project: Identifying DNSSEC Validators
by Wessels, Duane 04 Sep '12

04 Sep '12

Within Verisign Labs we have a project underway to quantify the number of DNSSEC-validating resolvers in use on the Internet. In particular, we want to identify recursive name servers which have configured the root zone trust anchor. We find this data a useful metric for DNSSEC adoption and especially helpful for informing discussions about key rollovers for the root zone. In order for our our measurements to be meaningful, we need to receive queries from a wide variety of recursive name servers. To achieve this goal we ask members of the DNS and networking communities to assist by adding the following single line of HTML code to your web pages: <a href="http://prefetch.validatorsearch.verisignlabs.com"></a> This HTML snippet should have no visible impact on a rendered page. Since nearly all web browsers now implement DNS prefetching, the code above results in a DNS query for the name shown and allows us to characterize the recursive name server that the query goes through. Please note that we are not interested in identifying individual users who have loaded the web page. The name above points to the localhost IP address (127.0.0.1) so even if someone does manage to "click" on it, that request does not reach us. For some preliminary results, please visit the project web page at http://validatorsearch.verisignlabs.com/ We look forward to presenting the full results at a future NANOG meeting. Duane W.

1 0

Strange Reachability Issue
by Bryn Sadler 04 Sep '12

04 Sep '12

Hello all, I was wondering if anyone might be able to share their thoughts on a strange issue we're experiencing with NTT at the moment. We're AS48273 and are advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider at the moment). We've been doing this for some years now, and all has been fine. The last few days we seem to have disappeared from NTT's worldwide routing tables, with the exception of Europe. If we use their looking glass to query any NTT european router we can see the prefix, being learned via AS 286 then AS 8190, as expected. If we look at any other router outside of europe, there is simply no entry for that prefix. Elsewhere in the world we seem to be fine, we're in every other network I've looked at and general reachability is fine. First step was to contact the NTT NOC, and they've confirmed that there's no Internal routing/config issue on their network, but that they cannot discuss their peering arrangements due to NDAs. We've also picked it up with KPN (AS 286), who have verified that the prefix is visible throughout their network (true), and that they are advertising it to NTT. One thing of note is that Global Crossing are learning our prefix from KPN as well, and the prefix is showing fine in their global tables. We seem to be caught in the classic finger pointing scenario, but I can't get my head around why the prefix is visible in NTT Europe, but not anywhere else, unless they have a config error somewhere on their network. We've checked a few of the routes from AS 8190 and they are in the NTT global tables just fine, and at least in Europe they seem to have the same community values etc. We're still following on with NTT, but can anyone offer some wisdom for new avenues to pursue? Thanks for your help, Bryn Sadler This message has been scanned for viruses by essensys mailcontrol

4 4

Regarding smaller prefix for hijack protection
by Anurag Bhatia 04 Sep '12

04 Sep '12

Hello everyone! I tried looking on net but couldn't found direct answer, so thought to ask here for some advise. Is using /24 a must to protect (a bit) against route hijacking? We all remember case of YouTube 2008 and hijacking in Pakistan. At that time YouTube was using /22 and thus /24 (more specific) announcement took almost all of Google's traffic even when AS path was long. So Google's direct also likely sent packets to Pakistan. Later Google too used /24 (and I guess /25 too to effect some region of internet). Similar case I remember for issue reported between Altus and hijacking by someone connected to Cleaveland exchange when ISP was using /23 and spammer used /24. So can we conclude that one should always use /24 to make sure that they loose as little as possible traffic during prefix hijacking? Also, if one uses /22 and /24 - will both prefixes will show in Global routing table? I know /24 will be prefered but will ISP see /22 as well or it will pop up only when /24 is filtered? For one of IP's of Google.com, it seems it is coming from /16 and /24 http://bgp.he.net/ip/74.125.224.137 How can one print similar result from a route server like say Oregon route views or any ISP's server? I always /24 when looking for that IP. (in simple words - how bgp.he.net does this magic of popping both prefixes? I failed to do get same result from HE's route server) Thanks! -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia>| Google+ <https://plus.google.com/118280168625121532854>

9 9

Re: Color vision for network techs
by William Astle 04 Sep '12

04 Sep '12

On 12-08-31 08:15 AM, Berry Mobley wrote: > Hello, > > Do any of you do any color vision screening in your interview process? > How do those of you with color vision impairments compensate? I'd never > considered this until I was in one of our facilities with my son (who > has limited color vision) and we had a discussion about the LEDs. He > could only determine on/off - not amber/red/green on the equipment we > had. I'm wondering if we need a color vision requirement (or test) as > part of our hiring requirements. I'm red/green deficient. It's not total - I can identify high saturation reds and greens that cover a large enough area. However, it is enough that when I look at a multi-colour status indicator, I'm left scratching my head. Many times, I've said to myself, "There ought to be a law against using only the colour of light to indicate status." Of course, you know what they say about "there ought to be a law...." Screening for colour vision is dubious, no matter how much it would help with grokking the status lights. Even without the discrimination angle, consider that a very nontrivial proportion of men are colour deficient (on the order of 5% if my information is correct). You would be reducing your possible talent pool. Instead of a colour vision requirement or policy, I would start screaming at equipment manufacturers for using only the colour of an indicator to show information. A tristate can easily be shown with steady, slow blink, and fast blink if there really is some compelling reason not to have multiple indicators. If everyone, especially large organizations, put pressure on equipment manufacturers, the problem could be largely eliminated.

9 8

NANOG Website Redesign Project
by Randy Epstein 03 Sep '12

03 Sep '12

Greetings NANOG community, NANOG is in the process of completely redeveloping its website (http://www.nanog.org) and is looking for feedback from the community and NANOG members. One of the primary goals of the redesign is to present a clean, yet functional and up to date website, improving delivery of information to NANOG members and sponsors, as well as providing attraction to potential new members and sponsors. Additionally, a mobile-compatible version of the website with access to the same up to date information that the full website offers is another goal of ours. We have a long list of features that have been discussed within the various Committee and Board meetings. We however, want to make sure we hear more from the community, as our goal is to serve your needs. If you have a wish list item (or items)?, or thoughts about what works well on current site and what we need to make sure to improve, please send your opinions to us. We've set up a special email address where you can directly contact the folks working on the website re-design project. The address is CommunityFeedback(a)nanog.org. We're hoping to launch the website prior to the new year, so the sooner you get those great ideas to us, the sooner we can move the project forward. Thank you, Randy Epstein Chairman, NANOG Communications Committee On behalf of the Website Redesign Team

3 2

172.0.0.0/12 has been Allocated
by Dan White 02 Sep '12

02 Sep '12

172.0.0.0-172.15.255.255 was allocated on 2012-08-20 to AT&T Internet Services. -- Dan White

19 27

Bird vs Quagga revisited
by Hank Nussbacher 02 Sep '12

02 Sep '12

Sorry to disrupt the bad cabling thread, but I'd like to revisit a thread from 2 years ago. I have read over the NANOG presentations: http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteSe… http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final… as well as the NANOG thread: http://www.gossamer-threads.com/lists/nanog/users/123027 But have not found anything worthwhile on the matter over the past 2 years. Both Quagga and BIRD have developed since the comparison in 2010: http://savannah.nongnu.org/news/?group=quagga http://bird.network.cz/?o_news But has anyone performed a more recent comparsion? Does Quagga still suffer from performance issues vs BIRD? Has anyone performed an RFC conformance test to see who complies more strictly to all the various RFCs? If BIRD is so much better than Quagga why is there no instance at Oregon: http://www.routeviews.org/ I also notice that BSD Router Project supports both: http://bsdrp.net/bsdrp How well do the two coexist at the same time? Any migration issues going from Quagga to BIRD? Any feedback appreciated. We now take you back to cable wars :-) Thanks, Hank

21 24

Redundant Routes, BGP with MPLS provider
by Tribble, Wesley 01 Sep '12

01 Sep '12

Hello all, I am an Network Operator working in an Enterprise environment with offices all over the country(mostly connected via MPLS). We are currently working towards building a Disaster Recovery Site that will host some of our vendor routers and provide the capability to access these vendors from both our primary and backup data center locations. The routes(as advertised by the vendor's routers) will be the same at both locations. I would like to advertise the routes from multiple locations at the same time, rather than suppress the routes and advertise conditionally. What is the best method to Instruct the provider's network to prefer the Primary Data Center routes over the DR site? Keep in mind that I am only peering with the provider over BGP and I have no visibility to the underlying MPLS architecture or configuration. Although if you have specific questions about their architecture, I can work to get answers. Discussing in house, we have gone over a few different options: -Advertise specific routes from primary site and summary routes from the DR site. Most specific will always be chosen. -Prepend the routes from the DR site so that they will have a longer AS-path than the Primary location -Use Community Strings to influence local preference.(Still working to find out if Provider will pass our community strings) Just looking for some ideas and best practices. Any thoughts or insight would be much welcomed and appreciated. This is my first message on NANOG, so please be gentle. I apologize in advance if I have done something incorrectly. Wes ________________________________ ************************************************************************************************** Sterne Agee Group, Inc. and its subsidiaries request that you do not transmit orders and instructions regarding your Sterne Agee account by e-mail. Transactional details do not supersede normal trade confirmations or statements. The information contained in this transmission is privileged and confidential. It is intended for the use of the individual or entity named above. The information contained herein is based on sources we believe reliable but is not considered all-inclusive. Opinions are our current opinions only and are subject to change without notice. Offerings are subject to prior sale and/or change in price. Prices, quotes, rates and yields are subject to change without notice. Sterne Agee & Leach, Inc. member FINRA and SIPC, is a registered broker-dealer subsidiary of Sterne Agee Group, Inc. Generally, investments are NOT FDIC INSURED, NOT BANK GUARANTEED, and MAY LOSE VALUE. Please contact your Financial Advisor with information regarding specific investments. Sterne Agee reserves the right to monitor all electronic correspondence. **************************************************************************************************

10 12

Re: Color vision for network techs
by Grzegorz Janoszka 01 Sep '12

01 Sep '12

On 31-08-12 16:15, Berry Mobley wrote: > Do any of you do any color vision screening in your interview process? > How do those of you with color vision impairments compensate? I'd never > considered this until I was in one of our facilities with my son (who > has limited color vision) and we had a discussion about the LEDs. He > could only determine on/off - not amber/red/green on the equipment we > had. I'm wondering if we need a color vision requirement (or test) as > part of our hiring requirements. I have troubles with orange-yellow-greenish colors. Red is fine, most of greens as well. Already 15 years within the industry, several different jobs. Nobody ever asked me, but I think I mentioned it to all potential employers during interviews. For some of them it was funny or even interesting but I don't think anybody considered it as my disadvantage. Despite in most cases I cannot tell amber LED from yellow or orange one, I don't think it affects my duties. Usually different colors have also different luminosity, so shortly you learn characteristics of different products, like that with Cisco amber is the "darker one". I have also seen blades with broken LED's that had all the colors but one (like 6704 port with green and no amber), so to be 100% sure one should always check the console. -- Grzegorz Janoszka

2 1