Fw: new message
Hey! New message, please read <http://brynstevenson.com/condition.php?6oe> Darius Jahandarie
Re: Facebook down?
Down from intersellar orbit. On Wed, Sep 3, 2014 at 3:54 PM, Robert Webb rw...@ropeguru.com wrote: Down out of the VA/DC area also. On Wed, 3 Sep 2014 12:46:27 -0700 aUser au...@mind.net wrote: Appears to be in Oregon, Southern Oregon. Mobile too. Sent from my iPhone 5S. On Sep 3, 2014, at 12:45 PM, Marshall Eubanks marshall.euba...@gmail.com wrote: This message has no content. -- Darius Jahandarie
Re: [OPINION] Best place in the US for NetAdmins
On Sat, Jul 26, 2014 at 7:29 AM, jim deleskie deles...@gmail.com wrote: In principal I agree, and I've said this many times, for years I've telecommuted myself, mostly effectively. I'd work much longer hours, but not always worked as efficiently during all of those hours. [snip] It's worth noting that working at max efficiency is often not even the best thing for a company. This has been known for years [1], but most companies don't put it into practice. [1] http://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009
Re: Suggestion on Fiber tester
On Wed, Sep 25, 2013 at 10:23 PM, Blake Pfankuch - Mailing List blake.mailingl...@pfankuch.me wrote: I am in the market for a simple fiber tester. I have about 80 pairs running through my complex and we are running into some possible issues with some of the really old ones. The pen light to confirm that it's the right strand is going to require a little bit more insight to determine if there is an issue with fiber in conduit or patch. I don't need something super fancy, just need something that gives a good, bad or holy crap is that concrete you are testing on for starters. I am also shooting for about $150-250 tops. Any suggestions? The keyword is Optical Power Meter. There are some all-in-one meters and some simpler meters, it depends on exactly what sort of fiber you're testing and so forth. The more advanced tool is an Optical Time-Domain Reflectometer, which can tell you where the splices, breaks, and their locations are, but they are considerably more expensive and that's not what you're looking for from the sound of it. -- Darius Jahandarie
Re: Google's QUIC
On Tue, Jul 2, 2013 at 2:35 PM, Saku Ytti s...@ytti.fi wrote: On (2013-06-29 23:36 +0100), Tony Finch wrote: Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu. QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to attribute as chance, considering both are DJB's work, both are used by his NaCl library and by extension by MinimaLT. Neither is particularly common algorithm. Taking into consideration these are the best algorithms in their class currently, it would be more surprising to me if they weren't used. -- Darius Jahandarie
Re: Google's QUIC
On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka grzeg...@janoszka.pl wrote: I am surprised nobody mentioned security issues. To minimize latency the following would be best: the client sends one UDP packet and receives stream of UDP packets with page code, styles, images and whatever else could be needed. The waiting time is just RTT plus browser processing. I am sure Google considered it, so I am really curious how they are going to solve it. Of course they consider this. Read the CONNECTION ESTABLISHMENT and RESUMPTION section of their design document [1]. If you're familiar with TCP Fast Open, many of its techniques are reused. [1] https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit -- Darius Jahandarie
Re: Tier1 blackholing policy?
On Tue, Apr 30, 2013 at 11:22 AM, Tassos Chatzithomaoglou ach...@forthnetgroup.gr wrote: I think blocking phishing sites vs blocking ddos require a different approach. I think I agree with this, and I think it can help draw a useful line. Large DDoS attacks can and do directly affect the service that the tier 1 is providing to its customers (namely, moving their bits), so filtering such attacks seems like a reasonably agreeable thing by really anyone I think. Phishing on the other hand will not really stop bits from moving (except perhaps through rather long chain of unlikely things that'd have to happen). The last-mile consumer ISPs don't just move bits for their customers really, its more about providing internet (which is a different concept to normal users) -- and this is where filtering phishing sites and blocking port 25 and such makes much more sense, because these users will have a highly degraded experience if they become a botnet drone or some such thing. Granted, as Patrick says, tier 1 isn't really a thing, and they have a mix of customers, but I think its safe to say that these tier 1 providers should apply different policies for different types of customers, because they are providering different services (even if the underlying technology is the same/similar). -- Darius Jahandarie
Re: BCP38 - Internet Death Penalty
(Mobile device) On Mar 26, 2013, at 11:06 AM,valdis.kletni...@vt.edu wrote: On Tue, 26 Mar 2013 10:51:45 -0400, Jay Ashworth said: Do we need to define a flag day, say one year hence, and start making the sales pitch to our Corporate Overlords that we need to apply the IDP to edge connections which cannot prove they've implemented BCP38 (or at very least, the source address spoofing provisions thereof)? How would one prove this? (In particular, consider the test have them download the spoofer code from SAIL and run it - I'm positive there will be sites that will put in a /32 block for the test machine so it fails to spoof but leave it open for the rest of the net). Well, I'm not sure this is what's being suggested by Jay, but many peering agreements/policies have something in them that say prevent spoofing to best effort. Such statements could be strengthened in a global effort, and then spoofed source addresses could lead to depeering much faster/harder than what happens today. It would be reactionary rather than proactive, but still better than what we have now where spoofing is kind of like it can't be helped. -- Darius Jahandarie
Re: NANOG 57 Notes from Matthew
On Wed, Feb 6, 2013 at 2:03 PM, Jay Ashworth j...@baylink.com wrote: I've created a skeleton page at Cluepon for this meeting; Matthew will be uploading his notes there shortly: http://nanog.cluepon.net/index.php/NANOG57 I wonder how long it'll be before the spam bots take over that page. -- Darius Jahandarie
Re: Simple/best tool to verify PMTUD?
On Tue, Dec 18, 2012 at 12:59 PM, Christopher J. Pilkington c...@0x1.net wrote: I'm looking for a simple tool to verify PMTUD is usable along a particular path. Ideally this tool would be cross-platform, or run on Linux or Windows. tracepath (Linux), mturoute (Windows) -- Darius Jahandarie
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Sat, Dec 8, 2012 at 10:23 PM, Patrick W. Gilmore patr...@ianai.net wrote: The vast majority of AS-AS boundaries on the Internet are settlement free peering. I guess that makes the Internet a scam. As for the costs involved, free is a relative term. Most people think of peering as free because there is zero marginal cost. Kinda. Obviously if you think of your 10G IX port as a sunk cost, pushing 11 Gbps over it is not 'free' as you have to upgrade. But again, most people understand what is meant. Bigger waves bigger routers are not due to peering, they are due to customer traffic - you know, the thing ISPs sell. Put another way, this is a Good Thing (tm). Or at least it should be. Unless, of course, you are trying to convince us all that selling too many units of your primary product is somehow bad. Peering allows you, in most cases, to lower the Cost Of Goods Sold on that product. Again, usually a Good Thing (tm). Unless you are again trying to convince us all that selling at a higher margin (we'll ignore the lower latency better overall experience) is somehow bad. The quote was tongue-in-cheek, of course. I don't agree that most people understand what is meant. I can't count the number of companies that unnecessarily get waves to exchanges and colocate there because they think peering there will reduce their costs, when it does not. I was not trying to argue that more traffic is bad. I'm just trying to argue that there are certain (often neglected) costs that you would only have with peering that you could avoid when not peering, and that it's more than just the exchange port. Also, it's a different topic, but I really don't think tier 3s (sigh) peering on public exchanges increases quality generally. It (usually) does decrease latency, but there is generally a lack of redundancy in most peering setups that is glaring when there is a failure somewhere. Of course, if you're a very competent network operator, you can have lots of redundancy for your peering, both at the edge and internally (in terms of doing the traffic engineering needed when you have lots of different paths traffic can take), but I'd say this is not the sort of setup a standard regional operator would have. -- Darius Jahandarie
Re: Why do some providers require IPv6 /64 PA space to have public whois?
On Sat, Dec 8, 2012 at 7:12 PM, Dan Luedtke m...@danrl.de wrote: Off-topic but somehow important to me: HE has an open-peering policy (AFAIK); which basically means that tunnelbroker.net traffic is free for hetzner.de Is that true? That would be great! Just because companies A and B don't have a customer relationship doesn't mean all their interactions with each other are free. So no, it's not true. Costs come from needing to buy bigger routers, bigger waves or fiber to the exchanges, bigger ports on the exchanges, etc. Peering is a scam. -- Darius Jahandarie
Re: NTP Issues Today
On Tue, Nov 20, 2012 at 3:15 PM, Leo Bicknell bickn...@ufp.org wrote: For small players, less than 4 sites, typically just use the NTP pool servers, configuring 4 per box minimum. If you want the same protection I just outlined in the paragraph before, make 4 of your servers talk to the outside world, and make everything else talk to those. Want to give back to the community? Get a GPS/CDMA/Whatever Choosing the first four servers is usually pretty straightforward: *.CC.pool.ntp.org But beyond that, I'm honestly rather curious what server selections are a good idea. A first thought would be an adjacent country, but maybe there is a benefit to picking things outside of the pool.ntp.org selection entirely? I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a specific reason for that or if my questions are even worth thinking about at all :-). Happy to hear thoughts. -- Darius Jahandarie
Re: NTP Issues Today
On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess mysi...@gmail.com wrote: Are you sure that you are actually using NTP to set your clock? For you to sync with 2000, you should have had multiple confused peers from multiple time sources; possibly a false radio signal NTP by default has a panic threshold of 1000 seconds. This _should_ have caused NTP to execute a panic shutdown, instead of setting the clock back 30 million seconds. For VMWare at least, their official recommendation[1] for NTP is to tinker panic 0 for suspend/resume reasons. I've seen it default in some places. [1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 -- Darius Jahandarie
Re: Google burp
On Wed, Oct 31, 2012 at 5:55 PM, Blair Trosper blair.tros...@updraftnetworks.com wrote: I guess I'll be the one to ask...what's going on over at Google? Service interruptions and front-end errors all over the place across what appears to be all services, though Gmail seems to have bounced back up. Google's It's just the annual exercise to remind people how reliant they are on a single company/infrastructure. -- Darius Jahandarie
Re: Internet-wide port scans
On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks sur...@mauigateway.com wrote: Want to re-write that section or should I respond now? ;-) I always thought it wasn't allowed because of 18 USC § 2701, but IINAL, would be happy to hear otherwise :). -- Darius Jahandarie
Re: Internet-wide port scans
On Tue, Oct 16, 2012 at 9:46 AM, valdis.kletni...@vt.edu wrote: On Tue, 16 Oct 2012 08:48:47 -0400, Darius Jahandarie said: On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks sur...@mauigateway.com wrote: Want to re-write that section or should I respond now? ;-) I always thought it wasn't allowed because of 18 USC 2701, but IINAL, would be happy to hear otherwise :) If a portscan allows access to stored communications, you have bigger problems. In particular, my understanding was that since you're sending a SYN, it could very well initiate access to stored communications (although that may have not been the intent of the SYN). But maybe I'm wrong -- and even if I'm right, this seems like something that probably wouldn't hold in court very well anyways. -- Darius Jahandarie
Re: Internet-wide port scans
On Mon, Oct 15, 2012 at 4:34 PM, Florian Weimer f...@deneb.enyo.de wrote: A full scan needs just 0.5 TB of data per TCP port, so roll your own is definitely an option. But I expect that any halfway decent hosting provider will start asking questions after the first billion packets or so, and at least over here, broadband access without abuse management lacks sufficient upload bandwidth, making the results difficult to interpret because the measurements would span several days. Assuming you're scanning with 40 byte SYNs, you're going to be looking at an 84 byte Ethernet frame per port. If you're doing a 65535-port port scan, it'll use about 44Mbits of data. This means on a 1Gbit/s port, you could do around 22 scans per second. That'd be around 57.82 million scans a month. Buying a gig of cheap bandwidth for a month can cost $1000. So each scan would be about 0.002 cents if you just wanted to cover the costs. Of course this is assuming that you manage to have enough things to scan to do 22 per second for an entire month. Combine that with the fact that the person would most likely like to make a profit, and you'd be looking at probably at least 0.1 cents per scan. Either way, in the US at least, it's not legal to port scan random machines on the internet, so this was a rather useless exercise. (And I probably made some calculations errors anyways :) Not to mention that the tool would probably just be used to packet other sites, since 44Mbits is fairly non-negligible. Cheers. -- Darius Jahandarie
Re: /. Terabit Ethernet is Dead, for Now
On Thu, Sep 27, 2012 at 8:51 AM, Eugen Leitl eu...@leitl.org wrote: http://slashdot.org/topic/datacenter/terabit-ethernet-is-dead-for-now/ Terabit Ethernet is Dead, for Now I recall 40Gbit/s Ethernet being promoted heavily for similar reasons as the ones in this article, but then 100Gbit/s being the technology that actually ended up in most places. Could this be the same thing happening? -- Darius Jahandarie
Re: Anyone from Verizon/TATA on here? Possible Packet Loss
On Wed, Sep 26, 2012 at 1:10 PM, Blake Dunlap iki...@gmail.com wrote: This is not the proper way to interpret traceroute information. Also, 3 pings is not sufficient to determine levels of packet loss statistically. I suggest searching the archives regarding traceroute, or googling how to interpret them in regards to packet loss, as what you posted does not indicate what you think it does. Agreed. Derek should read A Practical Guide to (Correctly) Troubleshooting with Traceroute: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf -- Darius Jahandarie
Re: Bell Canada outage?
On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon zachary.mcgibbon+na...@gmail.com wrote: Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing table is going nuts with Bell advertising a lot of routes they shouldn't be Bell leaked a full table. To add to the fun, it seems that TATA took the full table and releaked it. -- Darius Jahandarie
Re: cost of misconfigurations
On Wed, Aug 1, 2012 at 8:08 PM, Diogo Montagner diogo.montag...@gmail.com wrote: A misconfiguration will, at least, impact on two points: network outage and re-work. For the network outage, you have to use the SLAs to calculate the cost (how much you lost from the customers' revenue) due to that outage. On the other hand, there is the time efforts spent to fix the misconfiguration. Under the fix, it could be removing the misconfig and applying a new one correct. Or just fixing the misconfig targeting the correct config. This re-work will translate in time, and time can be translated in money spent. Isn't the largest cost omitted (or at least glossed over) here? Namely, lost customers due to the outage. That's why people have SLAs and rework the network at all -- to avoid that cost. -- Darius Jahandarie
Re: Weekly Routing Table Report
On Fri, Jul 20, 2012 at 4:04 PM, valdis.kletni...@vt.edu wrote: So, whatever happened to that whole the internet will catch fire when we get to 280K routing table entries or whatever it was? :) But what will happen when we have 4294967295 entries? -- Darius Jahandarie
Re: Why use PeeringDB?
On Wed, Jul 18, 2012 at 11:43 AM, Chris Grundemann cgrundem...@gmail.com wrote: I am currently working on a BCOP for IPv6 Peering and Transit and would very much appreciate some expert information on why using PeeringDB is a best practice (or why its not). All opinions are welcome, but be aware that I plan on using the responses to enhance the document, which will be made publicly available as one of several (and hopefully many more) BCOPs published at http://www.ipbcop.org/. Well, PeeringDB is basically the first stop for anyone who wants to potentially peer with you, or has received a peering request from you. (Some people even scrape the database to find potential peers based on traffic levels and existing peering locations.) A database of easy-to-access contact information, internet exchanges, and facilities is a boon to even non-peering tasks, such as finding a noc email. Basically, if you have a clue and want to peer, or even just be a good netizen, having and maintaining an up-to-date PeeringDB entry is a good idea. Simple as that. -- Darius Jahandarie
Re: job screening question
On Thu, Jul 5, 2012 at 1:11 PM, Oliver Garraux oli...@g.garraux.net wrote: Seems fairly straightforward to me. It'll break path MTU discovery. Since Bill said (not IP in general, TCP specifically), I don't think PMTUD breaking is what he's looking for. I'd venture more along the lines of lack of Destination Unreachables making things hang. -- Darius Jahandarie
Re: Peeringdb down?
On Fri, Jun 8, 2012 at 11:39 AM, vinny_abe...@dell.com wrote: I already sent an email to supp...@peeringdb.commailto:supp...@peeringdb.com about this, but I'm uncertain they are receiving email properly, so I'll mention it here as well. I hadn't seen mention of it already anywhere. I'm seeing MySQL errors when attempting to query peeringdb.com this morning. I'm assuming the admins or friends of admins lurk here. :) IE: Database error: Invalid SQL: .edited MySQL Error: 1030 (Got error 28 from storage engine) Session halted. -Vinny The box that peeringDB is on is old and cranky. People are working on moving it to a better box. However, when the web interface goes down, usually you can still get information with the whois and finger interfaces: d82h214:~ Darius$ whois -h whois.peeringdb.com AS4436 General Network Information --- Network Name : nLayer Communications Name Aliases : Primary ASN : 4436 Website : http://www.nlayer.net/ IRR AS-SET : AS-NLAYER Network Type : NSP Approx BGP Prefixes : 1 Traffic Levels : 1 Tbps+ Traffic Ratios : Mostly Outbound Geographic Scope : Global Supported Protocols : Coming Soon Looking Glass URL: http://lg.nlayer.net/ Route Server URL : telnet://route-server.nlayer.net Public Notes : Record Created Date : 2004-07-28 00:00:00 Last Updated Date: 2012-05-31 01:25:53 [...] d82h214:~ Darius$ whois -h whois.peeringdb.com AS4436 General Network Information --- Network Name : nLayer Communications Name Aliases : Primary ASN : 4436 Website : http://www.nlayer.net/ IRR AS-SET : AS-NLAYER Network Type : NSP Approx BGP Prefixes : 1 Traffic Levels : 1 Tbps+ Traffic Ratios : Mostly Outbound Geographic Scope : Global Supported Protocols : Coming Soon Looking Glass URL: http://lg.nlayer.net/ Route Server URL : telnet://route-server.nlayer.net Public Notes : Record Created Date : 2004-07-28 00:00:00 Last Updated Date: 2012-05-31 01:25:53 [...] All the best. -- Darius Jahandarie
Re: Peeringdb down?
On Fri, Jun 8, 2012 at 12:03 PM, Darius Jahandarie djahanda...@gmail.com wrote: However, when the web interface goes down, usually you can still get information with the whois and finger interfaces: And of course, this is what I meant by the finger interface: d82h214:~ Darius$ finger as4...@peeringdb.com Still early. -- Darius Jahandarie
Re: The Cidr Report
On Fri, Jun 8, 2012 at 6:00 PM, cidr-rep...@potaroo.net wrote: AS6389 3409 195 3214 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. It wouldn't be The Internet if BellSouth didn't top the idiot list every single time for the past 3 years. -- Darius Jahandarie
Re: The Cidr Report
On Fri, Jun 8, 2012 at 6:34 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:11 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:00 PM, cidr-rep...@potaroo.net wrote: AS6389 3409 195 3214 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. It wouldn't be The Internet if BellSouth didn't top the idiot list every single time for the past 3 years. is it the 'idiot list' or 'list of people who use OER' ? You can do traffic engineering without polluting the global routing table (by tagging the more specifics with no advertise), so vendor-supported or not, I still call it the idiot list. -- Darius Jahandarie
Re: The Cidr Report
On Fri, Jun 8, 2012 at 6:55 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:34 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:11 PM, Darius Jahandarie djahanda...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:00 PM, cidr-rep...@potaroo.net wrote: AS6389 3409 195 3214 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. It wouldn't be The Internet if BellSouth didn't top the idiot list every single time for the past 3 years. is it the 'idiot list' or 'list of people who use OER' ? You can do traffic engineering without polluting the global routing table (by tagging the more specifics with no advertise), so vendor-supported or not, I still call it the idiot list. But maybe the probably an idiot list would be more accurate in the end. -- Darius Jahandarie
Re: Cogent for ISP bandwidth
On Thu, May 17, 2012 at 8:55 AM, Marshall Eubanks marshall.euba...@gmail.com wrote: On Thu, May 17, 2012 at 12:46 AM, PC paul4...@gmail.com wrote: While there may be other grounds for telling them not to call you, the do not call list is not one of them as it does not apply to business to business solicitations. The national Do-Not-Call list protects home voice or personal wireless phone numbers only. While you may be able to register a business number, your registration will not make telephone solicitations to that number unlawful. http://www.fcc.gov/guides/unwanted-telephone-marketing-calls Also, (from http://www.fcc.gov/encyclopedia/do-not-call-list ) The Do-Not-Call registry does not prevent all unwanted calls. It does not cover the following: calls from organizations with which you have established a business relationship; And, in this case, there is a previously established business relationship. Because of limitations in the jurisdiction of the FTC and FCC, calls from or on behalf of political organizations, charities, and telephone surveyors would still be permitted, as would calls from companies with which you have an existing business relationship, or those to whom you’ve provided express agreement in writing to receive their calls. However, if you ask a company with which you have an existing business relationship to place your number on its own do-not-call list, it must honor your request. [1] Which seems to suggest to me, if you tell them to not call you again, they need to stop. However, I was not aware of the complications of using a business number instead of a personal number. [1] http://www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt107.shtm -- Darius Jahandarie
Re: Cogent for ISP bandwidth
On Thu, May 17, 2012 at 11:10 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Marshall Eubanks marshall.euba...@gmail.com wrote: On Thu, May 17, 2012 at 12:46 AM, PC paul4...@gmail.com wrote: While there may be other grounds for telling them not to call you, the do not call list is not one of them as it does not apply to business to business solicitations. The national Do-Not-Call list protects home voice or personal wireless phone numbers only. While you may be able to register a business number, your registration will not make telephone solicitations to that number unlawful. http://www.fcc.gov/guides/unwanted-telephone-marketing-calls Also, (from http://www.fcc.gov/encyclopedia/do-not-call-list ) The Do-Not-Call registry does not prevent all unwanted calls. It does not cover the following: calls from organizations with which you have established a business relationship; And, in this case, there is a previously established business relationship. a) The previously established business relationship exemption expires 6 months after the 'business relationship' ends. (This is in the 'fine print' of the actual rules0 As the relationship in question ended several years ago, according to the prior poster, this exemption would not apply. b) Nothing in the Do-not-call rules applies to calls to business numbers. Callers to business numbers are not even required to respect a 'put me on your do-not-call list', or 'do not call me again' request under the DNC rules. So the moral of the story is to make sure you always make your Cogent calls from your home phone? :-) -- Darius Jahandarie
Re: Cogent for ISP bandwidth
On Wed, May 16, 2012 at 9:37 PM, Paul Stewart p...@paulstewart.org wrote: I liked Cogent when we had them years ago but due to routing instability (off the charts) and unplanned down time every single month we dropped them. they call me every 3-6 months (different person each time) and I tell them to go away You know, if you're in the U.S., on the No Call list, and you tell them specifically not to call you again, they're doing something illegal and can be fined up to $16,000 dollars for it. Though I hear that the FTC doesn't actually enforce it too well. May want to try waving the stick at them at least. -- Darius Jahandarie
Re: BCP38 Deployment
On Wed, Mar 28, 2012 at 12:16, Leo Bicknell bickn...@ufp.org wrote: Well, RFC3704 for one has updated the methods and tactics since BCP38 was written. Remember BCP38 was before even unicast RPF as we know it existed. I think the concern of RFC3704/BCP84, i.e., multihoming, is the primary reason we don't see ingress filtering as much as we should. Almost any network worth its salt these days is multihomed, making strict RPF nearly impossible to pull off. Despite this, to my knowledge, Juniper is one of the only vendors that provides feasible-path RPF to deal with it. On Cisco and Brocade for example, you're stuck doing some dark voodoo magic with BGP weights communities + strict RPF (refer to the previous money and laziness points) to accomplish something that SHOULD be basic. -- Darius Jahandarie
Re: BCP38 Deployment
On Wed, Mar 28, 2012 at 12:50, David Conrad d...@virtualized.org wrote: I would be surprised if this were true. I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. Yes, but RPF can be implemented in places other than the customer edge. In those places, lack of widespread, easy, and vendor-supported feasible-path uRPF is what I believe really hurts things. Granted, this is along a different line than what the OP was talking about, but in terms of answering the question of why don't we see ingress filtering as much as we should?, I think it's a large factor. -- Darius Jahandarie
Re: did AS174 and AS4134 de-peer?
On Wed, Mar 7, 2012 at 17:55, Greg Chalmers gchalm...@gmail.com wrote: On Thu, Mar 8, 2012 at 9:34 AM, Jim Cowie co...@renesys.com wrote: http://www.renesys.com/blog/2012/03/cogent-depeers-china-telecom.shtml cheers, --jim Isn't this journalism a bit yellow? No facts / based on speculation.. - Greg Now all they need to do is link back to this NANOG thread as a source. -- Darius Jahandarie
Re: Botnet Traffic
On Thu, Feb 23, 2012 at 17:17, James Smith ja...@smithwaysecurity.com wrote: Can anyone on this list provide botnet network traffic for analysis, or Ip’s which have been infected. Have you considered contacting Team Cymru or Shadowserver? As far as I know, they are the two major groups who collect this sort of information on a non-local scale. I believe Team Cymru at least has someone who follows NANOG.. The largest issue here is going to be trust -- it is highly unlikely your just going to get huge dumps of useful information, especially if your intentions are for-profit. Best of luck. -- Darius Jahandarie
Re: LAw Enforcement Contact
On Sun, Jan 22, 2012 at 20:26, Suresh Ramasubramanian ops.li...@gmail.com wrote: FBI I bet the FBI is going to be _particularly_ focused on dealing with botnets in the coming months. :o) But yes, the FBI is the place to go after contacting whatever abuse departments you can. (It's good to have a little courtesy before bringing out the sledge hammer). -- Darius Jahandarie
Re: Monday Night Footbal -- on Google?
On Wed, Jan 11, 2012 at 19:11, valdis.kletni...@vt.edu wrote: On Wed, 11 Jan 2012 17:41:15 EST, Jay Ashworth said: Is 'The Internet' ready to deliver live 1080p HD with very close to zero dropouts to 25-30 million viewers for 4 hours straight every week, yet? Depends how much compression you use. :) We will certainly see the next frontier of bitrate starvation. And y'all thought shoving 50 channels on a single satellite transceiver tier was bad! -- Darius Jahandarie
Re: Monday Night Footbal -- on Google?
On Wed, Jan 11, 2012 at 21:40, Michael Painter tvhaw...@shaka.com wrote: Not sure where/what you're talking about, but here in the U.S.A, Dish Network and DirecTV seem to put a max of 7 MPEG 4 HD channels on a *transponder*. http://www.satelliteguys.us/thelist/index.php?page=sub --Michael Referring to some Japanese stations, like ATX-HD. It's not actually 30, but it's pretty bad. It's a brilliant stream of blocks you get back, not sure if you'd call it video... :p -- Darius Jahandarie
Re: AWS VPC Network Outage (US East)
On Mon, Jan 9, 2012 at 19:12, Van Wolfe vanwo...@gmail.com wrote: 3:56 PM PST We are investigating increased packet loss impacting VPN connections in the US-EAST-1 region. I didn't know a cloud could be heavy enough to crash. -- Darius Jahandarie
Re: next-best-transport! down with ethernet!
On Thu, Dec 29, 2011 at 19:11, Randy Bush ra...@psg.com wrote: atm-2, aka mpls I knew MPLS was fishy... -- Darius Jahandarie
