September 2012 - Test - lists.nanog.org

Level 3 BGP Advertisements
by Nick Olsen 05 Sep '12

05 Sep '12

Greetings all. In practice, We've always advertised our space all the way down to /24's but also the aggregate block (the /20 or the /21). Just so there was still reachability to our network in the event that someone made the foolish mistake of filtering lets say prefixes smaller /23... Anyways, I've always thought that was standard practice. And its never been a problem. Until we brought up peering with level 3.. I noticed that while the /24's made it out to the world. The larger counterparts (2 /21's and a /20) did not. So, I start sniffing around. Find that I do indeed see the prefixes in Level 3's looking glass but they aren't handing it off to peers. So, Naturally, I land on this being some kind of prefix filtering issue and open a ticket with Level 3. They tell me this is standard practice. And If I want to see the /20 or /21's make it out to the rest of the world, I need to stop sending the /24's. Does this sound normal? Is what I'm doing (Advertising the aggregate prefix) a good rule of thumb? Any other thoughts? Nick Olsen Network Operations (855) FLSPEED x106

19 21

Blocking MX query
by Ibrahim 05 Sep '12

05 Sep '12

Hi All, I've read old archive about blocking SMTP port (TCP port 25). In my current situation we are mobile operator and use NAT for our subscribers and we have few spammers, a bit difficult to track it because mostly our subscribers are prepaid services. If we block TCP port 25, there might be "good" subscribers will not be able to send email. We are thinking to block MX queries on our DNS server, so only spammer that use their own SMTP server will got affected. All DNS queries from our subscribers already redirected to our DNS cache servers. But seem Bind don't have feature to block MX query. Any best practice to block MX query? Regards Ibrahim

15 36

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 03 Sep '12

03 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