Peering vs SFI (was Re: Cogent/Level 3 depeering)

Richard Irving wrote: Maybe not, the depeering L3 is involved in is sort of like blackmail, we can all thank the indicted ex-CEO of WorldCom, Bernie Ebbers, for the modern peering "There can only be one" rule set. Because you were there at the time Ebbers was going around? Do you have

Re: Peering vs SFI (was Re: Cogent/Level 3 depeering)

Richard Irving wrote: Richard Irving wrote: Maybe not, the depeering L3 is involved in is sort of like blackmail, we can all thank the indicted ex-CEO of WorldCom, Bernie Ebbers, for the modern peering "There can only be one" rule set. Because you were there at the time Ebbers was go

Re: Peering vs SFI (was Re: Cogent/Level 3 depeering)

Richard Irving wrote: vijay gill wrote: "There can only be *one* !" - WorldCom chant, Circa 1995. WorldCom didn't know what IP SFI was in 95. Perhaps you mean UUNET/MFS? Or, perhaps I mean Alternet, eh ? Perhaps this is a rolex on my wrist, but they seemed to ha

Re: Scalability issues in the Internet routing system

Andre Oppermann wrote: I guess it's time to have a look at the actual scalability issues we face in the Internet routing system. Maybe the area of action becomes a bit more clear with such an assessment. In the current Internet routing system we face two distinctive scalability issues: 1.

Re: Scalability issues in the Internet routing system

Andre Oppermann wrote: vijay gill wrote: Moore's law for CPUs is kaput. Really, Moore's Law is more of an observation, than a law. We need to stop fixating on Moore's law for the love of god. It doesn't exist in a vacuum, Components don't get on the curve f

Re: cogent+ Level(3) are ok now

Pete Templin wrote: John Curran wrote: Cold-potato only addresses the long-haul; there's still cost on the receiving network even if its handed off at the closest interconnect to the final destination(s). And there's still revenue, as the traffic is going to customers (we all filter our p

Re: the iab simplifies internet architecture!

Randy Bush wrote: but it will be a classic. if you can get and edit it, send it to boing boing or /. Pearls before swine. that's what a number of i* members have publicly stated is their opinion of talking to us operators. i saved in my mementos the following quote from an ipv6 architect an

Re: Anycast 101

On Fri, Dec 17, 2004 at 02:31:06PM -0500, Hannigan, Martin wrote: > > > > Link outages are higher than router failures when you > subtract "human error" RFO's. > > > Overall, "fat fingers" account for the larger percentage > of all outages. > See my preso at the eugene nanog /vijay

Re: public accessible snmp devices?

Petri Helenius wrote: And lately, for reasons undetermined so far there has been instances of both vendor C and J where counters suddenly go to zero either temporarily (like 1,2,3,4,0,6,7,8,0,10,etc.) or reset altogether without any reason. Pete I am unclear as to what Vendors "C" and "J" are.

Please verify RFC1918 filters

We here at AOL have noticed that there are still some people filtering 172.0.0.0/8, which is causing AOL subscribers to get blocked from some sites. As a matter of general IP route filtering hygene I thought it worth mentioning (again) to see if we can get this tamped down (or, better still, stam

Re: Please verify RFC1918 filters

On Tue, Mar 22, 2005 at 03:13:07PM -0800, Randy Bush wrote: > y'all might give us something pingable in that space so we can > do a primitive and incomplete test in a simple fashion. > > randy > try 172.128.1.1 /vijay

Re: MD5 for TCP/BGP Sessions

Stephen J. Wilcox wrote: without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in This is why you either have

Re: MD5 for TCP/BGP Sessions

Christopher L. Morrow wrote: provided your gear supports it an acl (this is one reason layered acls would be nice on routers) per peer with: permit /30 eq 179 /30 permit /30 /30 eq 179 deny all-network-gear-ip-space (some folks call it backbone ip space, Paul Quinn at cisco says: "Infrastructure ip

soBGP deployment

If you are an operator, would you deploy soBGP or something like it? If not, why not. http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac236/about_cisco_ipj_archive_article09186a00801c5a9b.html /vijay

Re: [NON-OPERATIONAL] Re: NANOG Evolution

Hannigan, Martin wrote: It shouldn't be complicated. I think "members" are looking for Operator experience. I don't think it's too hard to make that easily discernable as long as it's fair. Members aren't looking for Operator experience (sic). Members are looking for talks that do not suck

Re: OSPF -vs- ISIS

Dan Evans wrote: All, Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Those on this list who are currently running IS-IS, do you find better scalability and stability running IS-IS than

Re: Scaled Back Cybersecuruty

Avi Freedman <[EMAIL PROTECTED]> writes: > Perhaps the Feds (and maybe states) could use their purchasing power > to effect change. Short of that, or regulation, the I don't see how > the serious issues we have with the 'net will get resolved. > > I suppose that the "problem" is likely that peo

Re: Scaled Back Cybersecuruty

Avi Freedman <[EMAIL PROTECTED]> writes: > Many networks of sizable import have no capex budget, though - or > sometimes very little if no engineering resources. They all pay > attention to sales - and especially to RFIs and RFQs from the Feds, > though. I suspect this will be a self correctin

Re: Scaled Back Cybersecuruty

Avi Freedman <[EMAIL PROTECTED]> writes: > - Routers must be configured by end of 2003 so that all packets > to the control plane must be logically separated from user > packets (or demonstrate the ability to take 200mb of attack > traffic to the router CPU without having an effect) Thi

Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?

"Al Rowland" <[EMAIL PROTECTED]> writes: > mention the effect everyone on AOL going to broadband and downloading > Disney clips all the time would have on their settlement plans with > backbone providers. Of course, because you are definitely being kept in the loop regarding the AOL settlement p

Re: mSQL Attack/Peering/OBGP/Optical exchange

David Diaz <[EMAIL PROTECTED]> writes: > With the rapid onset of an attack such as the one sat morning. Models > I have show that not only would the spare capacity been utilized > quickly but that in a tiered (colored) customer system. That the lower > service level customers (lead colored, silve

Re: mSQL Attack/Peering/OBGP/Optical exchange

David Diaz <[EMAIL PROTECTED]> writes: > was to "pay" for what you used when you used it. The biggest > technical factor was "how the heck do you bill it." Actually I'd think the biggest technical factor would be the trained monkey that would sit at the switch and do OIR of line cards on the ro

Re: mSQL Attack/Peering/OBGP/Optical exchange

Stephen Stuart <[EMAIL PROTECTED]> writes: > Optical switch technology, and the control systems that cause the > technology to implement the business rules of an exchange point, have > a ways to go before they're ready for prime-time. We don't know anything we could do with 50ms provisioning wit

Re: concern over public peering points [WAS: Peering point speed publicly available?]

On Mon, Jul 05, 2004 at 10:55:42AM -0700, joe mcguckin wrote: > > $5000 for an ethernet switch port? It makes me long for the days of throwing > ethernet cables over the ceiling to informally peer with other networks in a Throwing ethernet cables over the ceiling does not scale. /vijay

Re: concern over public peering points [WAS: Peering point speed publicly available?]

On Tue, Jul 06, 2004 at 01:43:14AM +, Paul Vixie wrote: > > [EMAIL PROTECTED] (vijay gill) writes: > > Throwing ethernet cables over the ceiling does not scale. > > i think it's important to distinguish between "things aol and uunet don't > think are good

Re: concern over public peering points [WAS: Peering point speed publicly available?]

--On Tuesday, July 06, 2004 08:46 -0400 Leo Bicknell <[EMAIL PROTECTED]> wrote: Everyone running their cable wherever they want with no controls, and abandoning it all in place makes a huge mess, and is one way to think about it. [snipped] I believe the problem Vijay is referencing isn't "throw

Re: 2511 line break

On Mon, Jul 26, 2004 at 04:32:53PM -0400, [EMAIL PROTECTED] wrote: > I don't know how you run your lab nets, but if I have something on a lab net, > it still gets secured the same way as a world-visible machine would. > > 1) That protects it if ever I add a gateway machine that talks to the world

Re: Summary with further Question: Domain Name System protection

On Tue, Aug 17, 2004 at 03:57:17AM +, [EMAIL PROTECTED] wrote: > > 5. 'bogon'in BIND configuration could be used to > > filter requests from RFC1918 address; > > this should be pushed to > the router. don't waste CPU cycles > on the Nameserver. Hosts tend to be a faster

Re: OT- need a new GSM provider

On Fri, Sep 03, 2004 at 10:47:43AM +1200, Randy Bush wrote: > strongly recommended. or, as here in fiji, one can get a phone > unlocked for a few bucks (couple of guys on a bench in a street > stall). Triband phones mostly operate on 900/1800/1900 frequencies. There is a major US deployment of

Re: OT- need a new GSM provider

On Thu, Sep 02, 2004 at 06:23:31PM -0700, Fred Baker wrote: > > At 06:04 PM 09/02/04 -0700, Joe Rhett wrote: > >> Also note due to fraud mitigation, most phones only allow you to call > >> within the country you are in or back to the home country, all the while > >> charging you an exhorbitant pr

Re: OT- need a new GSM provider

On Thu, Sep 02, 2004 at 07:48:00PM -0700, Joe Rhett wrote: > vijay gill wrote: > > Sorry, again YMMV but I had no trouble with this in either Taiwan or > Singapore, when I was responsible for support in those countries, Japan and > Korea combined. I never saw a problem calling

Re: Spammers Skirt IP Authentication Attempts

On Wed, Sep 08, 2004 at 11:54:32AM +0100, Paul Jakma wrote: > > Except that, SPF records are as easy to setup for a spammer, as for > you and I. If the above is a spammer, then SPF for foobar.com will > list randomgibberish.comcast.net as an authorised sender. > > SPF will absolutely not have

Re: Spammers Skirt IP Authentication Attempts

On Wed, Sep 08, 2004 at 12:14:54PM +0100, Paul Jakma wrote: > On Wed, 8 Sep 2004, vijay gill wrote: > > >But if instead of foobar.com, it is vix.com or citibank.com, then > >their SPF records will not point at randomgibberish.comcast.net as > >an authorized sender. Tha

Re: Important IPv6 Policy Issue -- Your Input Requested

On Wed, Nov 10, 2004 at 02:17:41AM -0500, Jerry Eyers wrote: > > Ok, let me throw some cold reality water on this discussion... ... > in the UK, the largest 'chemist' in the UK, built the largest > website in the world (2.4 million cc transactions/month with over 460 > servers) and coordinated

Re: Outbound Route Optimization

On Wed, Jan 21, 2004 at 09:05:46PM +, Paul Vixie wrote: > > > My questions are these: > > > > "Is sub-optimal routing caused by BGP so pervasive it needs to be > > addressed?" > > that depends on your isp, and whether their routing policies (openness > or closedness of peering,

Re: Outbound Route Optimization

On Mon, Jan 26, 2004 at 08:47:54AM -0700, Wayne E. Bouchard wrote: > > Although in principle I agree with what you say here, I will point out > that the number and frequency of "significant" network outages > (excluding things like the recent power failure in LAX) has become > rare as compared to

Re: Unbelievable Spam.

On Tue, Feb 03, 2004 at 10:31:00AM +, [EMAIL PROTECTED] wrote: > > inject large volumes of email into the system? The existing > non-hierarchical email exchange network is not scalable. > I hope that everyone on this list can understand what the > email exchange overlay network is and recogni

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)

On Thu, Feb 26, 2004 at 11:48:17AM +, [EMAIL PROTECTED] wrote: > Similarly, the Internet has always had N+1 or better vendor resiliency > so IOS can have problems while the non-IOS vendor (or vendors) keep on > running. In fact, I would argue that N+1 vendor resiliency is a good > thing fo

Re: Converged Networks Threat (Was: Level3 Outage)

On Thu, Feb 26, 2004 at 02:48:55PM +, [EMAIL PROTECTED] wrote: > > >> This is possible today. Build your own routers using > >> the right microkernel, OSKIT and the Click Modular Router > >> software and you can have this. When we restrict ourselves > >> only to router packages from major ven

Re: Converged Networks Threat (Was: Level3 Outage)

On Thu, Feb 26, 2004 at 10:05:03AM -0800, David Barak wrote: > > --- vijay gill <[EMAIL PROTECTED]> wrote: > > How would you know this? Historically, the cutting > > edge technology > > has always gone into the large cores first because > > they are the &

Re: Converged Networks Threat (Was: Level3 Outage)

On Thu, Feb 26, 2004 at 09:32:07PM +0200, Petri Helenius wrote: > along. It might still exist. CEF was developed to address the issue of > route cache insertion and purging. The unneccessarily painful 60 second > interval new destination stall was widely documented before CEF got > widespread

Re: Converged Networks Threat (Was: Level3 Outage)

On Thu, Feb 26, 2004 at 11:28:09AM +, [EMAIL PROTECTED] wrote: > > > Wouldn't it be great > >if routers had the equivalent of 'User mode Linux' each process > >handling a service, isolated and protected from each other. The > >physical router would be nothing more than a generic kernel ha

Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)

On Sun, Mar 07, 2004 at 08:35:54PM +, Christopher L. Morrow wrote: > > > Here is a sticky point... There are reasons to allow 10.x.x.x sources to > transit a network. Mostly the reasons come back to 'broken' configurations > or 'broken' hardware. The reasons still equate to customer calls an

Re: Publish or (gulp) Perish

On Tue, Mar 23, 2004 at 03:01:56PM -0500, Daniel Golding wrote: [ various journals ] > Any thoughts? Have NANOG powerpoint presentations made these sorts of > journals obsolete? :) Powerpoints have a hard time matching the depth of a refereed journal submission, because with the powerpoint,

Re: BGP TTL check in 12.3(7)T

On Thu, Apr 08, 2004 at 11:30:38AM +0200, Hank Nussbacher wrote: > > > > From Dave Meyer's NANOG 27 presentation: > http://www.nanog.org/mtg-0302/hack.html > > Not bad - Feb 2003 till April 2004

Re: Backbone IP network Economics - peering and transit

On Tue, Apr 20, 2004 at 05:15:48AM +, Paul Vixie wrote: > > > > Peering? Who needs peering if transit can be > > > had for $20 per megabit per second? > > anyone whose applications are too important to risk dependency on OPNs > (other people's networks). OPNs also carry some of the consum

Re: TCP RST attack (the cause of all that MD5-o-rama)

On Tue, Apr 20, 2004 at 02:11:02PM -0700, Dan Hollis wrote: > > On Tue, 20 Apr 2004, Crist Clark wrote: > > But it has limited effectiveness for multi-hop sessions. There is the > > appeal of a solution that does not depend of the physical layout of the > > BGP peers. > > Does MD5 open the door

Re: TCP RST attack (the cause of all that MD5-o-rama)

On Tue, Apr 20, 2004 at 02:42:07PM -0700, Rodney Joffe wrote: > > > vijay gill wrote: > > > > > > Yes it does. About 5 mbit of md5 should peg a juniper at 100% according > > to my friend alex. I have not verified this in the lab. I suggest > > you try

Re: TCP RST attack (the cause of all that MD5-o-rama)

On Tue, Apr 20, 2004 at 09:45:01PM +, vijay gill wrote: > infrastructure today - a large amount of PPS at the _router_ (with or > without md5 or tcpsecure) will blow it out of the water. A 10mbits/s > of packets at the juniper without md5 will also destroy it. To be clear, I was j

Re: 2006.06.05 NANOG-NOTES Peering BOF notes

Matthew Petach wrote: Thank you Matt, these notes are almost like being there. Excellent work. Also Ted Seely at the peering bof? Shocked there wasn't a riot. They're getting into the peering fray, and only a year old. This is gigs and gigs, has potential to dwarf current peering traffic. Cu

Re: rack power question

On Sun, Mar 23, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote: > > Given that power and HVAC are such key issues in building > big datacenters, and that fiber to the office is now a reality > virtually everywhere, one wonders why someone doesn't start > building out distributed data centers. Essentia

Re: cooling door

On Sat, Mar 29, 2008 at 3:04 PM, Frank Coluccio <[EMAIL PROTECTED]> wrote: > > Michael Dillon is spot on when he states the following (quotation below), > although he could have gone another step in suggesting how the distance > insensitivity of fiber could be further leveraged: Dillon is not on

Re: cooling door

On Mon, Mar 31, 2008 at 8:24 AM, <[EMAIL PROTECTED]> wrote: > > > Here is a little hint - most distributed applications in > > traditional jobsets, tend to work best when they are close > > together. Unless you can map those jobsets onto truly > > partitioned algorithms that work on local copy, th

Re: cooling door

On Wed, Apr 2, 2008 at 3:06 AM, <[EMAIL PROTECTED]> wrote: > > > > I doubt we'll ever see the day when running gigabit across > > town becomes cost effective when compared to running gigabit > > to the other end of your server room/cage/whatever. > > You show me the ISP with the majority of their

Re: Boeing's Connexion announcement

Owen DeLong wrote: This may be a nit, but, you will _NEVER_ see AC power at any, let alone all of the seats. Seat power that works with the iGo system is DC and is not conventional 110 AC. Is this your final answer? I've used AC power in lufthansa business class. Makes the 8 or 9 hour trip

Re: Curious question on hop identity...

Joseph Jackson wrote: I'm pretty new to the networking world. While I don't run a huge and complex network in a service provider market. We're just an enterprise network. I have read a lot of useful info about networking from the nanog list. But I do have to say that when I speak to the design