only WV FIBER now peering with Atrivo / Intercage
http://cidr-report.org/cgi-bin/as-report?as=AS27595v=4view=2.0#AS27595 Gadi.
Re: an effect of ignoring BCP38
do that many networks really allow spoofing? i used to think so, based on hearsay, but rob beverly's http://spoofer.csail.mit.edu/summary.php suggests things are a lot better than they used to be, arbor's last survey echos same. are rob's numbers inconsistent with numbers anyone else believes to be true? i think you unfairly characterize UW's work, but i also think you make questionable inferences regarding the extent of spoofing, which seems more relevant to nanog. k On Fri, Sep 05, 2008 at 05:22:27AM +, [EMAIL PROTECTED] wrote: seems that some folks in the RE community, with institutional support from Cisco, Google, and the US NSF, are exploiting our inability to take even rudimentary steps toward providing a level of integrity in routing by teaching students that spoofing IP space is ok. This whole thing works at all because so few people use/deploy/maintain BCP-38 compliance. This was an eye-opener for me. http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf --bill
Re: only WV FIBER now peering with Atrivo / Intercage
Or is it? On Sat, 6 Sep 2008, Gadi Evron wrote: http://cidr-report.org/cgi-bin/as-report?as=AS27595v=4view=2.0#AS27595 Gadi.
Re: Cisco uRPF failures
On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett [EMAIL PROTECTED] wrote: That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and What do you mean by 'non routable?' What was the src/dst makeup of the test traffic? We also discovered problems related to uRPF and load balanced links, but those were difficult to reproduce in the lab and we couldn't affect their peering, so we had to disable uRPF and ignore so I don't have much details. What version of code? Also, port-channel/lag or ECMP? quickly, but that turns out not to be the case. To this day I've never I've never seen the issues you speak of, so it could be code/platform/config specific. Also, what sup were you testing? found a network operator using uRPF on Cisco gear. (note: network operator. it's probably fine for several-hundred-meg enterprise sites) Forgive me, but what does bits/sec have to do with anything? -Tk
Re: only WV FIBER now peering with Atrivo / Intercage
On Sat, Sep 6, 2008 at 11:31 AM, Gadi Evron [EMAIL PROTECTED] wrote: Or is it? Looks to not be, so I call BS on your subject line.. however, I do see: * 64.28.176.0/20 71.13.116.101 100 0 20115 19151 26769 27595 i * 204.11.128.105100 0 33125 174 3549 27595 i * 67.210.0.0/2171.13.116.101 100 0 20115 19151 26769 27595 i * 204.11.128.105100 0 33125 174 3549 27595 i * 67.210.8.0/2271.13.116.101 100 0 20115 19151 26769 27595 i 20115 sees 27595 through wv (which peers with bandcon), so it would seem wv shut the edge edge (renesys data also agrees). It's interesting the gx edge is still active. -Tk
Re: only WV FIBER now peering with Atrivo / Intercage
Gadi, A quick look at route-views will confirm that Atrivo is multi-homed. And WV Fiber is a transit provider to them, not a peer. As NANOG community members in good standing, I'm sure WV, nLayer, etc would take the appropriate action if you were to contact their respective abuse departments, *privately*, with evidence of active abuse on Atrivo's part. Drive Slow, Paul Wall On Sat, Sep 6, 2008 at 9:47 AM, Gadi Evron [EMAIL PROTECTED] wrote: http://cidr-report.org/cgi-bin/as-report?as=AS27595v=4view=2.0#AS27595 Gadi.
Re: Cisco uRPF failures
On 9/6/08, Anton Kapela [EMAIL PROTECTED] wrote: On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett [EMAIL PROTECTED] wrote: found a network operator using uRPF on Cisco gear. (note: network operator. it's probably fine for several-hundred-meg enterprise sites) Forgive me, but what does bits/sec have to do with anything? it's possible that on some platforms the uRPF check happens on the main processor, or on a linecard processor. So, bps rates (proxied for by pps rates) matter greatly, on those platforms. -Chris
Re: only WV FIBER now peering with Atrivo / Intercage
On Sat, 6 Sep 2008, Anton Kapela wrote: On Sat, Sep 6, 2008 at 11:31 AM, Gadi Evron [EMAIL PROTECTED] wrote: Or is it? Looks to not be, so I call BS on your subject line.. Thanks Anton! I appreciae you looking into it. however, I do see: * 64.28.176.0/20 71.13.116.101 100 0 20115 19151 26769 27595 i * 204.11.128.105100 0 33125 174 3549 27595 i * 67.210.0.0/2171.13.116.101 100 0 20115 19151 26769 27595 i * 204.11.128.105100 0 33125 174 3549 27595 i * 67.210.8.0/2271.13.116.101 100 0 20115 19151 26769 27595 i 20115 sees 27595 through wv (which peers with bandcon), so it would seem wv shut the edge edge (renesys data also agrees). It's interesting the gx edge is still active. -Tk
BGP Clueful from Windstream/Alltel?
Is there anyone hanging around here who happens to either be or can get me in touch with a BGP-clueful person at Windstream/Alltel (AS7029)??? Unicast would be great, I hate to tie up the list with this, but the standard prescribed methods haven't worked in 72 hours now... Thanks in advance! Scott Morris [EMAIL PROTECTED]
Re: only WV FIBER now peering with Atrivo / Intercage
On Sep 6, 2008, at 1:27 PM, Paul Wall wrote: A quick look at route-views will confirm that Atrivo is multi-homed. And WV Fiber is a transit provider to them, not a peer. As NANOG community members in good standing, I'm sure WV, nLayer, etc would take the appropriate action if you were to contact their respective abuse departments, *privately*, with evidence of active abuse on Atrivo's part. Minor correction to your at least implied statement above: nLayer has no direct connectivity to Atrivo, peering or transit. Personally, I'm fine with anyone providing Atrivo transit being shamed in public, but I understand if others do not want such traffic on the list. Anton's post that GX is still providing them transit is a bit curious, since I was under the impression GX had severed all ties with Atrivo. But the table does not lie, a path of 174 3549 27595 is clearly transit. GX, care to comment? -- TTFN, patrick
RE: SMTP rate-limits [Was: Re: ingress SMTP]
Can anyone comment authoritatively on the percentage of spam that's from a leaky faucet compared to fire hose? The stuff I see in my customer base are all fire hoses at the rate of 2.5, sometimes 5 message connection attempts per second. (I bet an academic could study the rate of spam emissions from a certain IP to identify their upstream bandwidth). Frank -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 9:46 AM To: Paul Ferguson Cc: nanog@nanog.org Subject: Re: SMTP rate-limits [Was: Re: ingress SMTP] snip I thought that these bot nets were so massive that it is pretty easy for them to fly under the radar for quotas, rate limiting, etc. Not that all bot nets are created equal, and there aren't local hot spots for whatever reason, but putting on the brakes in a way that users wouldn't feel pain is simply not going to make any appreciable difference in the overall mal-rate. No? Mike
Re: only WV FIBER now peering with Atrivo / Intercage
On Sat, Sep 6, 2008 at 8:30 PM, Anton Kapela [EMAIL PROTECTED] wrote: On Sat, Sep 6, 2008 at 6:33 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: Anton's post that GX is still providing them transit is a bit curious, since I was under the impression GX had severed all ties with Atrivo. But the table does not lie, a path of 174 3549 27595 is clearly transit. GX, care to comment? After poking for a bit, it's unclear what, if anything, GX is or isn't doing here. I tossed a static /24 towards the upstream sending the AS path with GX in it, and traced towards a host in the that /24 - the traceroute output disagrees with the as path, oddly enough. bgp routes, again: r 58.65.238.0/24 71.13.116.101 100 0 20115 19151 27595 i r 204.11.128.105 100 0 33125 174 3549 27595 i actual path is cogent, (3), wv, intercage, not cogent, gx, intercage: Tracing the route to 58-65-238-1.myrdns.com (58.65.238.1) 1 204.11.128.105 [AS 33125] 0 msec 0 msec 0 msec 2 gi2-15.ccr02.ord03.atlas.cogentco.com (38.104.102.29) [AS 174] 4 msec 4 msec 8 msec 3 te-9-1.car4.Chicago1.Level3.net (4.68.127.129) [AS 3356] 4 msec 8 msec 4 msec 4 ae-32-56.ebr2.Chicago1.Level3.net (4.68.101.190) [AS 3356] 8 msec 20 msec 16 msec 5 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) [AS 3356] 8 msec 4 msec 8 msec 6 ae-2.ebr2.Washington1.Level3.net (4.69.132.70) [AS 3356] 40 msec 36 msec 36 msec 7 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS 3356] 36 msec ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) [AS 3356] 40 msec ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) [AS 3356] 40 msec 8 ae-14-69.car4.Washington1.Level3.net (4.68.17.6) [AS 3356] 28 msec ae-24-79.car4.Washington1.Level3.net (4.68.17.70) [AS 3356] 32 msec ae-34-89.car4.Washington1.Level3.net (4.68.17.134) [AS 3356] 32 msec 9 CWIE-LLC.car4.Washington1.Level3.net (4.79.170.146) [AS 3356] 32 msec 32 msec 28 msec 10 * * * 11 atl-ten3-1-ash-ten3-1.wvfiber.net (66.216.1.157) [AS 19151] [MPLS: Label 120 Exp 0] 216 msec 208 msec 188 msec 12 nsh-ten4-1-atl-ten3-2.wvfiber.net (64.127.130.58) [AS 19151] [MPLS: Label 73 Exp 0] 32 msec 32 msec 32 msec 13 la-ten1-1-nsh-ten4-2.wvfiber.net (66.186.197.109) [AS 19151] [MPLS: Label 113 Exp 0] 80 msec 80 msec 80 msec 14 sjc-ten1-1-la-ten1-2.wvfiber.net (66.186.197.106) [AS 19151] 80 msec 84 msec 80 msec 15 58-65-238-1.myrdns.com (58.65.238.1) 84 msec 132 msec 104 msec question I have for the list is...who's faking the funk? second that... from ripe bgplay view, gx is never seen as an adjacency to 27595, just wv and bandcon, with liteup being brought up later on in the 2 day interval http://www.ris.ripe.net/cgi-bin/bgplay.cgi?prefix=58.65.238.0/24start=2008-09-05+01:15end=2008-09-07+01:15 -Tk -christian
