Re: Tahiti's OPT ASN?
On Fri, Feb 19, 2010 at 12:15 AM, Scott Weeks sur...@mauigateway.com wrote: Anyone got the ASN of Office des Postes et Télécommunications in French Polynesia? I'm having a heck of a time looking for it in APNIC. I'm not sure whether the OPT from French Polynesia has its own ASN as it owns the operator named Mana. Maybe you should have a look to AS 9471: MANA-PF-AP MANA S.A. Regards, -- sarah
AS33259 leaking
Hi, Does anyone know a contact for AS33259? It seems the AS33259 is leaking a bunch of prefixes in error, and this caused reachability problems. - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
multicast beacon group seeing extremely high traffic
Any multicast networks seeing a large amount of traffic for the beacon group 233.4.200.18? Starting approximately 0730 GMT, we started receiving more than 12 Mbps for that group which normally is far less. Group: 233.4.200.18, (?) Source: 64.251.63.189 (mcast.cen.ct.gov) Rate: 1095 pps/606 kbps(1sec), 567 kbps(last 30 secs), 631 kbps(life avg) Source: 128.105.40.15 (mbone-test.cs.wisc.edu) Rate: 1020 pps/553 kbps(1sec), 405 kbps(last 40 secs), 450 kbps(life avg) Source: 128.109.1.249 (ws-beacon.ncren.net) Rate: 846 pps/364 kbps(1sec), 349 kbps(last 40 secs), 384 kbps(life avg) Source: 128.109.3.228 (wil-beacon.ncren.net) Rate: 786 pps/339 kbps(1sec), 203 kbps(last 40 secs), 241 kbps(life avg) Source: 128.109.16.117 (gb-beacon.ncren.net) Rate: 758 pps/326 kbps(1sec), 306 kbps(last 40 secs), 328 kbps(life avg) Source: 128.109.58.21 (ecu-beacon.ncren.net) Rate: 509 pps/221 kbps(1sec), 297 kbps(last 40 secs), 331 kbps(life avg) Source: 128.135.122.108 (g217display.bsd.uchicago.edu) Rate: 840 pps/495 kbps(1sec), 376 kbps(last 40 secs), 442 kbps(life avg) Source: 128.182.160.60 (arsenal.psc.edu) Rate: 1084 pps/595 kbps(1sec), 280 kbps(last 40 secs), 366 kbps(life avg) Source: 129.78.221.17 (crayon.ucc.usyd.edu.au) Rate: 9 pps/4 kbps(1sec), 4 kbps(last 40 secs), 5 kbps(life avg) Source: 129.96.120.11 (?) Rate: 9 pps/4 kbps(1sec), 3 kbps(last 40 secs), 4 kbps(life avg) Source: 129.127.96.120 (beacon.sapac.edu.au) Rate: 10 pps/5 kbps(1sec), 5 kbps(last 40 secs), 5 kbps(life avg) Source: 130.102.78.179 (vv2.vislab.uq.edu.au) Rate: 10 pps/5 kbps(1sec), 6 kbps(last 40 secs), 6 kbps(life avg) Source: 130.207.166.66 (pulsar.noc.gatech.edu) Rate: 843 pps/364 kbps(1sec), 346 kbps(last 40 secs), 360 kbps(life avg) Source: 130.220.64.249 (dawn.ml.unisa.edu.au) Rate: 8 pps/4 kbps(1sec), 4 kbps(last 50 secs), 5 kbps(life avg) Source: 134.129.95.122 (netmenderx.cc.ndsu.NoDak.edu) Rate: 1094 pps/608 kbps(1sec), 314 kbps(last 50 secs), 342 kbps(life avg) Source: 138.23.2.53 (kaon.ucr.edu) Rate: 20 pps/13 kbps(1sec), 10 kbps(last 50 secs), 10 kbps(life avg) Source: 139.86.2.226 (?) Rate: 11 pps/7 kbps(1sec), 5 kbps(last 50 secs), 6 kbps(life avg) Source: 141.142.2.55 (jhereg.ncsa.uiuc.edu) Rate: 999 pps/670 kbps(1sec), 360 kbps(last 50 secs), 400 kbps(life avg) Source: 144.174.29.10 (accessgrid.sc.fsu.edu) Rate: 1158 pps/730 kbps(1sec), 531 kbps(last 50 secs), 553 kbps(life avg) Source: 144.174.29.11 (ag1.sc.fsu.edu) Rate: 878 pps/637 kbps(1sec), 487 kbps(last 50 secs), 532 kbps(life avg) Source: 144.174.29.12 (ag2.sc.fsu.edu) Rate: 232 pps/102 kbps(1sec), 411 kbps(last 50 secs), 428 kbps(life avg) Source: 152.2.255.225 (beacon.net.unc.edu) Rate: 853 pps/619 kbps(1sec), 413 kbps(last 50 secs), 459 kbps(life avg) Source: 155.98.194.254 (ebc.mc-beacon.utah.edu) Rate: 1074 pps/658 kbps(1sec), 447 kbps(last 50 secs), 447 kbps(life avg) Source: 155.101.3.100 (multicast.chpc.utah.edu) Rate: 476 pps/333 kbps(1sec), 339 kbps(last 50 secs), 388 kbps(life avg) Source: 161.45.190.10 (ns-beacon.mtsu.edu) Rate: 947 pps/534 kbps(1sec), 474 kbps(last 50 secs), 439 kbps(life avg) Source: 192.17.24.169 (faranth.ci.uiuc.edu) Rate: 939 pps/591 kbps(1sec), 426 kbps(last 50 secs), 442 kbps(life avg) Source: 192.43.244.8 (npad.ucar.edu) Rate: 1157 pps/716 kbps(1sec), 574 kbps(last 50 secs), 612 kbps(life avg) Source: 192.65.130.134 (black.ivec.org) Rate: 11 pps/7 kbps(1sec), 7 kbps(last 0 secs), 5 kbps(life avg) Source: 192.88.114.244 (nic.3rox.net) Rate: 962 pps/548 kbps(1sec), 548 kbps(last 0 secs), 453 kbps(life avg) Source: 205.127.87.150 (zoot.uen.net) Rate: 1100 pps/611 kbps(1sec), 611 kbps(last 0 secs), 512 kbps(life avg) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Re: AS33259 leaking
Date: Fri, 19 Feb 2010 20:05:10 +0900 (JST) Matsuzaki Yoshinobu m...@iij.ad.jp wrote It seems the AS33259 is leaking a bunch of prefixes in error, and this caused reachability problems. at the route-views.oregon-ix.net, it looks like '701 33259 25843 3356 ...' as follows. | * 12.147.32.0/21 157.130.10.233 0 701 33259 25843 3356 7132 14858 i | * 17.86.0.0/16 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 714 714 714 714 714 i | * 17.86.132.0/22 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 i | * 20.134.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.134.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.143.112.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.128.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.144.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17916 i | * 20.143.208.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17647 i | * 41.92.128.0/22 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.136.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.139.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.140.0/22 157.130.10.233 0 701 33259 25843 335 snip - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
VZ/UU/701 Accepting AS33259 leaking
This appears to be ongoing. I'm seeing more updates here: http://puck.nether.net/bgp/leakinfo.cgi Some people at 701 are getting email alerts from my monitoring system. I'll ask them about this shortly. - jared On Feb 19, 2010, at 7:06 AM, Matsuzaki Yoshinobu wrote: Date: Fri, 19 Feb 2010 20:05:10 +0900 (JST) Matsuzaki Yoshinobu m...@iij.ad.jp wrote It seems the AS33259 is leaking a bunch of prefixes in error, and this caused reachability problems. at the route-views.oregon-ix.net, it looks like '701 33259 25843 3356 ...' as follows. | * 12.147.32.0/21 157.130.10.233 0 701 33259 25843 3356 7132 14858 i | * 17.86.0.0/16 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 714 714 714 714 714 i | * 17.86.132.0/22 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 i | * 20.134.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.134.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.143.112.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.128.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.144.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17916 i | * 20.143.208.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17647 i | * 41.92.128.0/22 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.136.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.139.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.140.0/22 157.130.10.233 0 701 33259 25843 335 snip - Matsuzaki Yoshinobu m...@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
Re: Spamhaus...
On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: And I want to know how they figured out we had a Barracuda. It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior. As to Spamhaus policy re appliances in general, their terms are on their web site and while you or I or anyone else may not agree with or like their terms, it *is* their service to offer on the terms that they wish. And given that the Zen DNSBL is far-and-away the highest quality DNSBL available, it's probably worth paying for if one finds oneself in a situation where its use is indicated. An easy way around this is not to use an appliance: it's a straightforward exercise for any competent postmaster to build anti-spam defenses that vastly outperform [1] any appliance in an afternoon. Finally, this discussion should really be on spam-l, not nanog. ---Rsk [1] Where performance is measure in terms of acquisition cost, maintenance cost, FP, FN, bandwidth, memory, CPU, resistance to attack, scalability, etc.
Re: AS33259 leaking
| * 12.147.32.0/21 157.130.10.233 0 701 33259 25843 3356 7132 14858 i | * 17.86.0.0/16 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 714 714 714 714 714 i | * 17.86.132.0/22 157.130.10.233 0 701 33259 25843 3356 4637 1221 714 i | * 20.134.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.134.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.48.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.139.144.0/20 157.130.10.233 0 701 33259 25843 3356 3549 17916 i | * 20.143.112.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.128.0/20 157.130.10.233 0 701 33259 25843 3356 4637 17916 i | * 20.143.144.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17916 i | * 20.143.208.0/20 157.130.10.233 0 701 33259 25843 3356 4637 1221 17647 i | * 41.92.128.0/22 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.136.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.139.0/24 157.130.10.233 0 701 33259 25843 3356 5511 15964 37034 i | * 41.92.140.0/22 157.130.10.233 0 701 33259 25843 335 level(3) must be paying 25843 a good bit of money for transit to uunet :) we would not mind if they were not also doing it for iij's prefixes :( randy
Re: Spamhaus...
Rich Kulawiec wrote: On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: And I want to know how they figured out we had a Barracuda. It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior. Is there some very specific poor behavior you're referring to? Finally, this discussion should really be on spam-l, not nanog. Actually considering the original message was addressed to the 'large DNS server operators' this is probably more appropriate. Whether the non-followups in this thread should be there instead is a different issue. Michelle
New botnet launch?
All, We noticed at around midnight for a brief period of time and around 6AM EST for an extended period that several hosted customer servers (4 completely different customers) launched quite a campaign doing 100Mbps during these times (on 100Mbps ports). The thing I find 'suspicious' is that all of the machines connected Interfaces said they were sending out 200Mbps (on 100Mbps links) and that they all had the same exact traffic profile (MRTG, etc). 5 minute input rate 213353000 bits/sec, 18516 packets/sec 5 minute output rate 583000 bits/sec, 855 packets/sec Anyone else see this or am I just very lucky? thanks, -Drew
Re: New botnet launch?
On Fri, 19 Feb 2010, Drew Weaver wrote: All, We noticed at around midnight for a brief period of time and around 6AM EST for an extended period that several hosted customer servers (4 completely different customers) launched quite a campaign doing 100Mbps during these times (on 100Mbps ports). The thing I find 'suspicious' is that all of the machines connected Interfaces said they were sending out 200Mbps (on 100Mbps links) and that they all had the same exact traffic profile (MRTG, etc). 5 minute input rate 213353000 bits/sec, 18516 packets/sec 5 minute output rate 583000 bits/sec, 855 packets/sec If these 100Mbps ports are 100BaseT ethernet, and your switch(es) reported them receiving 213353000 bits/sec, I'd be more suspicious of cisco counter bugs than a new botnet. 100BaseT can't do that. Cisco has a long history of writing code that can't count properly. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: New botnet launch?
Sorry, the point was that MRTG and other metrics also showed that they were doing 100Mbps, and I am well aware of counter bugs in Cisco's IOS but it has never been that out of whack (on several different switches) before, also the fact that all of these hosts are Windows 2003 and had the exact same SNMP metrics is kind of suspicious to me, but maybe I'm wrong. -Original Message- From: Jon Lewis [mailto:jle...@lewis.org] Sent: Friday, February 19, 2010 10:28 AM To: Drew Weaver Cc: 'nanog@nanog.org' Subject: Re: New botnet launch? On Fri, 19 Feb 2010, Drew Weaver wrote: All, We noticed at around midnight for a brief period of time and around 6AM EST for an extended period that several hosted customer servers (4 completely different customers) launched quite a campaign doing 100Mbps during these times (on 100Mbps ports). The thing I find 'suspicious' is that all of the machines connected Interfaces said they were sending out 200Mbps (on 100Mbps links) and that they all had the same exact traffic profile (MRTG, etc). 5 minute input rate 213353000 bits/sec, 18516 packets/sec 5 minute output rate 583000 bits/sec, 855 packets/sec If these 100Mbps ports are 100BaseT ethernet, and your switch(es) reported them receiving 213353000 bits/sec, I'd be more suspicious of cisco counter bugs than a new botnet. 100BaseT can't do that. Cisco has a long history of writing code that can't count properly. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Spamhaus and Barracuda Networks BRBL
Dean Drako dr...@barracuda.com writes: ^ When they were providing a free service we promoted them strongly, Translation: We made money using it and it didn't cost us anything. but when they started charging the customers that really used it, we had to part ways. Translation: Our customers complained about being asked to pay for something that we should have paid for, but it's cheaper to let our customers hang in the wind than to pay up. Sorry, I could let this pass without comment. -- Bob Poortinga K9SQL Bloomington, Indiana US
RE: MLFR Differential Delay Problems
The differential delay is most likely caused by the T1's in the MFR bundle riding physically diverse paths across the TDM network. The carrier would need to validate their CLR/DLR to see what paths/DS3's the individual T1's follow to verify they are on the same circuit. Unfortunately there are those that try and sell MFR as redundancy and have the T1's ride diverse paths that can sometimes be pretty huge in difference of loop distance etc.., when they should really just be selling MFR for the bandwidth. - Jim P. -Original Message- From: R. Benjamin Kessler [mailto:r...@mnsginc.com] Sent: Thursday, February 18, 2010 10:55 PM To: nanog@nanog.org Subject: MLFR Differential Delay Problems Hello NANOGers - I'm working on a project to migrate a customer from one Tier 1 provider to another at 50+ locations (all domestic US sites). Most of these connections are 4xT1 multi-link bundles. The old router configuration was MLPPP which was rock-solid for 3 years (save for the typical last-mile circuit issues, fiber-cuts, etc.). The new carrier uses FRF.16 multi-link Frame Relay vs. MLPPP. We've completed the migration on 10+ sites and all of them are now reporting errors like the following: Feb 17 21:01:39 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 91.7 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 115.9 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 79.0 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 79.1 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 90.0 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 100.0 ms over yellow differential delay 75 ms The customer routers are all Juniper J6350; I believe the Carrier's routers are all Cisco GSRs. Advanced JTAC says that our configurations are solid and that there are no known bugs that would exhibit behavior like this. The carrier is insisting on performing physical-level tests of the circuits (even though they're running error free) before they'll engage higher-level engineers so I'm currently in a holding pattern awaiting those results. My Google-foo is failing me and I'm not able to find any documents that help explain what may be causing this and how to troubleshoot and find an eventual solution. I would really appreciate any tips or suggestions from anyone on the list that may have seen issues like this in the past. Thanks, Ben
Re: Spamhaus...
On Feb 18, 2010, at 2:25 PM, Nick Hilliard wrote: On 18/02/2010 10:40, Michelle Sullivan wrote: They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a Use Spamhaus RBL in our software. I sympathise. It's very frustrating when you try to deal with these anti-spam outfits in a reasonable way and you're met with almost completely arbitrary b/s. What's arbitrary about free for non-commerical use, everyone else pays? When you include it in a commercial product, yes, you should have to pay for it. If you're making money by reselling or providing access to the Spamhaus lists, you should have to pay for it. There's a lot of work that goes into it (I'm sure Michelle would agree) and they have very specific criteria under which they will allow free use and under which they will not. If you don't like it, make your own lists. If you *really* don't like it, make your own lists, and provide a free public infrastructure to support billions of requests a day. -- Marc
Re: Recommendations for router with routed copper gig-e ports?
On Feb 16, 2010, at 9:24 AM, Joe Abley wrote: On 2010-02-14, at 12:41, Lorell Hathcock wrote: My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. Force10 S25N/S50N. http://www.force10networks.com/products/s50n.asp If you look for used models, make sure they're not so old that they can't run FTOS. You don't want SFTOS, which is what the older switches run. They work nicely in a stack, when you find you need to grow. Joe I had absolutely horrible experiences with SFTOS. The upgrade to FTOS was not pleasant. Once they were running on FTOS, they weren't horrible, but, I will never buy another one. Owen
Re: Spamhaus...
Michelle Sullivan matt...@sorbs.net writes: Rich Kulawiec wrote: On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: And I want to know how they figured out we had a Barracuda. It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior. Is there some very specific poor behavior you're referring to? I don't know what Rich referred to, but Barracudas used to be easy to spot by backscatter levels: http://www.dontbouncespam.org/#barracuda Bjørn
40G/100G options at this time
Hi. Are there solutions already available implementing 40GBASE-LR4, 100GBASE-LR4 and 100GBASE-ER4 draft standards ? By solutions it means both switches with CFP-MSA/QSFP/CXP ports and the modules. Rubens
Re: Spamhaus...
Bjørn Mork wrote: Michelle Sullivan matt...@sorbs.net writes: Rich Kulawiec wrote: On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: And I want to know how they figured out we had a Barracuda. It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior. Is there some very specific poor behavior you're referring to? I don't know what Rich referred to, but Barracudas used to be easy to spot by backscatter levels: http://www.dontbouncespam.org/#barracuda Yes that was what Rich was referring to, however, that I suspect is not what Spamhaus are doing. Regards, Michelle
troll (was: Spamhaus...)
[ subject: changed and refs headers removed ] So you should think that its ok for blacklists to charge money for things they got for free? why not? apnic, arin, ripe, ... do! giggle randy
Re: Spamhaus...
On Fri, Feb 19, 2010 at 07:18:38PM +0100, Bj??rn Mork wrote: I don't know what Rich referred to, but Barracudas used to be easy to spot by backscatter levels: http://www.dontbouncespam.org/#barracuda They're *still* easy to spot by backscatter levels, probably because (a) a lot of people still have that switch set to on (b) some people still switch it to on (c) Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not. Reject good, bounce baaad. [1] Now whether there are *other* ways to spot them: I don't know. But there are some very sharp people at Spamhaus, and it would not surprise me if they knew. ---Rsk [1] Unless you are bouncing to an authenticated/internal user.
Air Force Blacklist
Hello all, We have a customer that appears to have a portion of their ARIN- assigned IP space blocked from accessing specific US Air Force resources. We've tried opening tickets with various groups and are not getting anywhere after several months of dancing. I was wondering if: 1) Anyone has experience getting themselves OFF an Air Force blocked list and is willing to share tips. 2) If there are any Air Force contacts that can confirm or deny that a specific IP is indeed blocked or if we're chasing the wrong problem. Off-list replies (obviously) welcome. -- Brad Fleming
Re: BIRD vs Quagga
On 13 Feb 2010, at 01:01, Nathan Ward wrote: On 13/02/2010, at 11:51 AM, Steve Bertrand wrote: fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. OpenBGPd would be great for a public route server at an IX. Nathan has made a good point. Deploying them in an IX environment, with features like per-peer RIBs, very complex filtering, and the numbers of peers you might expect on a route-server environment, is a very different beast to (and more complicated than) deploying them in a network edge/forwarding role. In a forwarding role, the underlying OS's features and the robustness of the daemon under load matters in different ways. So what's best ? I have used all three in a forwarding role and found BIRD on Debian a pretty solid combination. I found OpenBGPd on OpenBSD a pain to use - it converged really slowly and bgpctl seemed to lock up for a while after startup in an environment with *many* peers, and the behaviour with ospf3 used to change quite a lot. Quagga on Linux or FreeBSD seemed to work ok, and the interface will be quite familiar to Cisco users. Using all three as an injector for Anycast or similar leads to quite similar outcomes. However you might find ExaBGP more lightweight in this role - see http://bgp.exa.org.uk/ - do check it out. This has an interface which will feel extremely comfortable to Juniper users. You should still go to the IX Route-Servers panel to learn more about the software in question :-) And its really very good research being presented - but I am biased here. Best wishes Andy -- // www.netsumo.com // Professional network engineering consultancy // //uk ddi: +44(0)20 7993 1702// us ddi: (415) 520 3589//
Re: Blocking private AS
Thomas Magill wrote: I am thinking about implementing a filter to block all traffic with private AS numbers in the path. I see quite a few in my table though so I am concerned I might block some legitimate traffic. In some cases, these are just prefixes with the private appended to the end but a few have the private as a transit. Is this a good idea or would I likely be blocking too much legitimate traffic? The filter I am using currently shows the following: I filter private asn's and have not had any reachability problems related to that. I suspect most of the routes you see with a private ASN in the path are covered by a less specific route without any private ASN in the path. Someone used a private ASN with their customer and forgot to filter it to their upstreams/peers. - Kevin
Intel 10Gb on VMware (AMD) ESX 4.0 intermittent problem
Has anyone experience problems using Intel 10 Gb NIC on VMware (AMD) ESX 4.0? Some VM's are experiencing intermittent network drop issues even though the actual VM is online. The VM are unable to ping out or respond to ping and sometime unable to ping VM-to-Vm on the same physical server. The problem is only on some VM's on the same ESX host. We move the vms to another ESX 4.0 with same Intel 10 GB card, the problem is resolve, but return days later with same VM at new location. The Intel 10 GB has VMDQ features was not sure if that is part of the problem. Thanks in advance --Louis
BGP Update Report
BGP Update Report Interval: 11-Feb-10 -to- 18-Feb-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS18170 89373 7.0%4062.4 -- CHANGWON-AS-KR Changwon National University 2 - AS31055 19699 1.5%4924.8 -- CONSULTIX-AS Consultix GmbH 3 - AS773814391 1.1% 30.2 -- Telecomunicacoes da Bahia S.A. 4 - AS330013892 1.1% 66.5 -- BT-INFONET-EUROPE BT-Infonet-Europe 5 - AS14420 12476 1.0% 32.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 6 - AS45408 11584 0.9%5792.0 -- 7 - AS958310657 0.8% 10.4 -- SIFY-AS-IN Sify Limited 8 - AS19318 10518 0.8% 457.3 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 9 - AS9498 8632 0.7% 12.9 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS9829 8616 0.7% 10.3 -- BSNL-NIB National Internet Backbone 11 - AS358058417 0.7% 14.7 -- UTG-AS United Telecom AS 12 - AS165698258 0.7%4129.0 -- ASN-CITY-OF-CALGARY - City of Calgary 13 - AS288788004 0.6% 667.0 -- SIGNET-AS Signet B.V. 14 - AS113117284 0.6% 78.3 -- Sinectis S.A. 15 - AS9430 7249 0.6% 233.8 -- STPI-NOIDA Software Technology Parks of India,Block-IV 16 - AS260257053 0.6%3526.5 -- COC - City of Calgary 17 - AS8452 7009 0.6% 6.8 -- TEDATA TEDATA 18 - AS5800 6663 0.5% 26.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS245606289 0.5% 7.4 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 20 - AS8551 6110 0.5% 15.4 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS45408 11584 0.9%5792.0 -- 2 - AS31055 19699 1.5%4924.8 -- CONSULTIX-AS Consultix GmbH 3 - AS165698258 0.7%4129.0 -- ASN-CITY-OF-CALGARY - City of Calgary 4 - AS18170 89373 7.0%4062.4 -- CHANGWON-AS-KR Changwon National University 5 - AS260257053 0.6%3526.5 -- COC - City of Calgary 6 - AS270975113 0.4%1022.6 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 7 - AS28052 839 0.1% 839.0 -- Arte Radiotelevisivo Argentino 8 - AS272451504 0.1% 752.0 -- HEIDRICK-CHICAGO - HEIDRICK 9 - AS288788004 0.6% 667.0 -- SIGNET-AS Signet B.V. 10 - AS19318 10518 0.8% 457.3 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 11 - AS168125615 0.4% 401.1 -- SPACENET-ENT - Spacenet, Inc. 12 - AS181671506 0.1% 376.5 -- HCLCOMNET-AS-IN HCL Comnet Systems Services Ltd 13 - AS45960 333 0.0% 333.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 14 - AS146701322 0.1% 330.5 -- SOLAR-VPS - Solar VPS 15 - AS20524 757 0.1% 252.3 -- MVH Bit Conection Soft Computers S.R.L. 16 - AS50469 251 0.0% 251.0 -- HESSENKOM-DE HessenKom GmbH Co KG 17 - AS244711756 0.1% 250.9 -- GLOBAL-UST-AS-IN USsoftware P Ltd. 18 - AS9430 7249 0.6% 233.8 -- STPI-NOIDA Software Technology Parks of India,Block-IV 19 - AS8668 1566 0.1% 223.7 -- TELONE-AS TelOne Zimbabwe P/L 20 - AS27027 425 0.0% 212.5 -- ANBELL ASN-ANBELL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 19689 1.4% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/248257 0.6% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 208.98.231.0/247052 0.5% AS26025 -- COC - City of Calgary 4 - 114.70.96.0/24 5792 0.4% AS45408 -- 5 - 114.70.97.0/24 5792 0.4% AS45408 -- 6 - 193.177.160.0/23 5672 0.4% AS28878 -- SIGNET-AS Signet B.V. 7 - 118.39.130.0/245294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 8 - 118.39.128.0/245294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 9 - 203.246.0.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 10 - 59.22.142.0/24 5294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 11 - 203.246.23.0/245294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 12 - 118.39.129.0/245294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 13 - 118.39.131.0/245294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 14 - 118.39.132.0/245294 0.4% AS18170 -- CHANGWON-AS-KR Changwon National University 15 - 62.193.80.0/24 5279 0.4% AS5536 -- Internet-Egypt 16 - 203.246.0.0/19 5224 0.4% AS18170 -- CHANGWON-AS-KR Changwon
The Cidr Report
This report has been generated at Fri Feb 19 21:11:27 2010 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 PrefixesCIDR Agg
12-02-10313721 194084
13-02-10313877 194074
14-02-10313836 194173
15-02-10313863 193766
16-02-10314099 193990
17-02-10314228 193395
18-02-10314052 193123
19-02-10314156 193226
AS Summary
33625 Number of ASes in routing system
14320 Number of ASes announcing only one prefix
4380 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
93114880 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').
--- 19Feb10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 314385 193240 12114538.5% All ASes
AS6389 4115 320 379592.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4380 1835 254558.1% TWTC - tw telecom holdings,
inc.
AS4766 1860 490 137073.7% KIXS-AS-KR Korea Telecom
AS1785 1848 679 116963.3% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1279 214 106583.3% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS22773 1119 74 104593.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS18566 1059 33 102696.9% COVAD - Covad Communications
Co.
AS17488 1289 341 94873.5% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS8151 1582 677 90557.2% Uninet S.A. de C.V.
AS18101 1092 205 88781.2% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS10620 1000 167 83383.3% TV Cable S.A.
AS19262 1065 245 82077.0% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6478 1117 443 67460.3% ATT-INTERNET3 - ATT WorldNet
Services
AS8452 1002 363 63963.8% TEDATA TEDATA
AS4808 850 237 61372.1% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4804 678 72 60689.4% MPX-AS Microplex PTY LTD
AS7303 681 108 57384.1% Telecom Argentina S.A.
AS4134 1018 460 55854.8% CHINANET-BACKBONE
No.31,Jin-rong Street
AS7018 1567 1013 55435.4% ATT-INTERNET4 - ATT WorldNet
Services
AS24560 847 298 54964.8% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3356 1202 664 53844.8% LEVEL3 Level 3 Communications
AS17908 767 229 53870.1% TCISL Tata Communications
AS35805 578 40 53893.1% UTG-AS United Telecom AS
AS4780 631 142 48977.5% SEEDNET Digital United Inc.
AS17676 563 82 48185.4% GIGAINFRA Softbank BB Corp.
AS9443 559 80 47985.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS7545 971 495 47649.0% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS28573 881 407 47453.8% NET Servicos de Comunicao S.A.
AS9299 672 211 46168.6% IPG-AS-AP Philippine Long
Distance Telephone Company
AS22047 529 77 45285.4% VTR BANDA ANCHA S.A.
Total 36801107012610070.9% Top 30 total
Possible Bogus Routes
2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project
2.1.0.0/21 AS12654
Re: Spamhaus...
on Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: Spamhaus does some good work, but being used as a pawn in some conflict between vendors doesn't feel nice. And I want to know how they figured out we had a Barracuda. If it's connected to the 'Net and listening on port 25, it's rather obvious in the SMTP banner. As far as I know, only Barracudas use the parenthized 32-char hex in their banners. 220 ham.globalstar.com ESMTP (025830353ddfaf0a57c33778b8725ad9) HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: Regular Expression for IPv6 addresses
On 2010-02-04 at 17:50 -0500, Richard E. Brown wrote: My company, Dartware, have derived a regex for testing whether an IPv6 address is correct. I've posted it in my blog: http://intermapper.ning.com/profiles/blogs/a-regular-expression-for-ipv6 This has links to the regular expression, a (Perl) program that tests various correct and malformed addresses, and a Ruby implementation of the same. There's a full grammar in RFC 3986 (URI Generic Syntax) already, which can be translated straight. It too handles the embedded IPv4 addresses. While your code is written in a more condensed manner, those who want to be able to cross-check against the RFC might want to take a look at this one, which emits a PCRE regexp: http://people.spodhuis.org/phil.pennock/software/emit_ipv6_regexp-0.304 http://people.spodhuis.org/phil.pennock/software/emit_ipv6_regexp-0.304.asc (Version numbers for repository, not for that one script :) ). FWIW, the ability to grab a shell variable which contains an RE for IPv6 addresses, which can be used in: pcregrep $ipv6_regex log_file has proven very useful, especially when debugging newly-added IPv6 support for an app. This is also the most coherent justification I've come up with so far for using a regexp instead of a dedicated parser, other than because I could. Regards, -Phil
Re: Spamhaus...
On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec r...@gsp.org wrote: Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not. Reject good, bounce baaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash. If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an undeliverable mail notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path). Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Spamhaus...
On 2/19/2010 7:20 PM, William Herrin wrote: On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec r...@gsp.org wrote: Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not. Reject good, bounce baaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash. If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an undeliverable mail notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path). Does the RFC say what to do if the reverse-path has been damaged and now points to somebody who had nothing what ever to do with the email? Do your SNMP clients respond truthfully to EXPN requests? How about source-routed traffic? ICMP requests? Recursive DNS requests? If not, why not? I don't run any sites anymore, but when I did, unsolicited traffic (traffic not in response to traffic from somebody on my network) was blocked when detected, and remained blocked until somebody inside our boundary complained, and on second occurrence until my management directed me to remove the block. in response to our traffic was a situational matter determined by reasonable people on a case by case basis as required. -- Government big enough to supply everything you need is big enough to take everything you have. Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Spamhaus...
Reject good, bounce baaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash. no, rich is talking operation pragmatics. more and more these years, rfcs are where the rubber meets the sky. but if you really like backscatter, i think i can find a few megabytes a day for you. no problem. randy
Cyber Shockwave on CNN
US carried out Cyber Shockwave - an exercise by non-government actors who have close relations to the government past. The results will be aired on CNN this weekend. Intelligence suggests the scenario was not standard and that a crash in the smart phone network was used as a concept of how US National Security *could* be compromised in 2011. CNN had exclusive television access to the national security cyber “war game” scenario. The simulated attack took place on Tuesday and was host by members of The Bipartisan Policy Center and will debut on Saturday, Feb. 20 and Sunday, Feb. 21 at 8pm, 11pm and 2am ET on CNN. I hope the Nanog community can tune in or watch later on catch up services and give feedback on your thoughts. Kind regards, Andrew
Re: Cyber Shockwave on CNN
the details were in the press days ago. 83.2% scare, negligible lessons we can actually put in practice without becoming (more of) a police state. randy
Re: Spamhaus...
On Fri, Feb 19, 2010 at 9:02 PM, Randy Bush ra...@psg.com wrote: Reject good, bounce baaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash. no, rich is talking operation pragmatics. more and more these years, rfcs are where the rubber meets the sky. but if you really like backscatter, i think i can find a few megabytes a day for you. no problem. Randy, Feel free to bounce as much spam forged with my return address as you like, so long as you first follow at least the bounce suppression criteria I do: No bounce if the message claimed to be from a mailing list. No bounce if the spam scored higher than 8 in spamassassin No bounce if the server which you received the spam from doesn't match my domain's published SPF records evaluated as if ~all and ?all are -all I figure I can handle the additional -zero- messages... And I can manage it without mysteriously dropping false-positives off into the ether. I agree backscatter is a nasty problem but as solutions go, reject good, bounce baaad sucks. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Spamhaus...
On Fri, Feb 19, 2010 at 8:35 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/19/2010 7:20 PM, William Herrin wrote: If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an undeliverable mail notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path). Does the RFC say what to do if the reverse-path has been damaged and now points to somebody who had nothing what ever to do with the email? Hi Larry, Re-reading the paragraph I quoted and you repeated, I'm going to say that the answer is yes. SMTP had been around for a long time when 2821 was written, as had spam. I doubt leaving the must in section 3.7 was an oversight. Even if it was, I didn't suggest rote adherence to the RFC. I said, reasonably compatible with RFC 2821's section 3.7. Dropping all bounce messages on the floor -- the exact opposite of 3.7 -- is not reasonably compatible. Do your SNMP clients respond truthfully to EXPN requests? I assume you mean SMTP servers here rather than SNMP clients. 2821 rightly leaves EXPN as a should instead of a must. And yes, they respond truthfully -- with an prohibited operation error. I don't run any sites anymore, but when I did, unsolicited traffic (traffic not in response to traffic from somebody on my network) was blocked when detected, and remained blocked until somebody inside our boundary complained, and on second occurrence until my management directed me to remove the block. I can't resist the set up: Maybe that's why you don't run any sites anymore. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Spamhaus...
On Fri, Feb 19, 2010 at 5:20 PM, William Herrin b...@herrin.us wrote: On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec r...@gsp.org wrote: Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not. Reject good, bounce baaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash. In the case of Barracuda's long history of Backscatter the solution is simple, and is implemented by most other mail vendors - it's called Don't accept incoming mail to an invalid recipient. Barracudas used to have no way of doing address validation for incoming mail, so they would accept it and then bounce it when the next hop (eg, the Exchange server) rejected the recipient address. They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it... Scott.
Re: Spamhaus...
On Fri, Feb 19, 2010 at 9:28 PM, Scott Howard sc...@doc.net.au wrote: They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it... ... can NOW integrate... even. Scott.
