Uhhhh... dotcom, anyone? Plenty of twenty-something "executives" hyping ridiculous/unsustainable business models. Clearly the people giving out the money (VC's, et al) were generally somewhat older, but a healthy portion of the abject failures that typified the period can be laid at the feet of the (then) under-30 crowd. Incidentally, how old do you think those energy traders at Enron were? Naive or not, they certainly played their role. Stupidity, incompetence and corruption are well-represented at all age levels.
So... Income distribution in the US is such that 35% of net worth resides with the top 1% of the population and ~86% resides with the top 20%. How would the other 80% of the country, which holds the remaining 14% of total wealth / net income (http://sociology.ucsc.edu/whorulesamerica/power/wealth.html) even theoretically be -able- to contribute an equivalent amount?
I work hard and make decent money - likely many times what a teacher, fireman or construction worker earns. Likewise, the amount I pay in taxes is also several times the average gross income in this country. I'm reaping a somewhat higher reward from an economy that is underpinned by infrastructure that's paid for by my taxes and supported/protected/defended by individuals that are also paid from my taxes. Without roads, telecom, cops / law enforcement, firemen, teachers and, yes, the occasional bureaucrat to help keep it all together then my company is going to have a hell of a time selling its wares and, thus, will likely have proportionately less need for my services.
The notion of "poor" is a pretty variable term. Lots and lots of folks live in that bottom 14% - especially including the civil servants I mentioned above and lots of folks who are loudest to condemn the so-called "socialist" nature of our government. This, of course, is notwithstanding of the fact that lots of these folks couldn't accurately describe the distinctions between socialism, communism and fascism - at least judging by the way such terms are lightly thrown around.
Then die. You paid - at best - a tiny share of the cost of the roads and bridges you likely use every day, the medicines that keep you and your family alive. I'm personally a big fan of antibiotics when I have an infection. What paid for the development of mass production of Penicillin? Oh, right... the military, which is paid for by who, again?
Yeah - those damned government workers... just flaunting their lazy, socialist lifestyles and living off of the hard work and industry of others. I've always felt that cops and firemen were just drains on society. Hell, government subsidies of modern hospitals in rural areas (...where many of the supposedly self-sufficient people live and work) are just a drain on your independently earned dollar. Same idea for schools - screw people in rural areas! They shouldn't have modern, competitive schools! Don't even get me started about all the hard-earned cash that's wasted in taxes and regulations to compel telecom and electric utilities to provide service to sparsely populated areas.
While we're at it - what about all of those contractors that are building things for government agencies? Clearly all pork. Shut 'em down! Why bother with helicopters for the Coast Guard? If someone's ship capsizes then it was clearly their fault! And if they can't swim to shore when 10 miles out? Screw 'em.
Oh - and your job? Hopefully whatever goods or services you're involved with selling/producing/distributing/etc aren't ever procured by people who work for those contractors building those helicopters, tanks, ships, planes, etc - 'cause then your livelihood is, at least partially, tied to precisely the same tax-mooching lazy bastards you're sick of supporting.
Take a look at how much money is spent of AFDC or Medicaid. It's a lot of money. Now compare that to the cost of the defense department budget, Social Security, Medicare or the cost of infrastructure. Guess what? It's a *LOT* more money.
Face it, all of the self-sufficient hard work you're putting out there to make money from the open market is utterly and completely reliant on lots of shared services and, yes, regulations that are administered by local, state and federal government. Short of folks living in tribes in the furthest corners of the Earth, *everyone* is reliant on some amount of so-called welfare.
Buy the right hardware and run M0n0wall or pfsense. If you can audit the code of your firewall it's the only way to be sure there are no backdoors in it.
I have had a M0n0Wall running for well over 6 years with no problems. Granted it's for a very small company with only a few thousand users.... but there are some out there doing the work for fortune 500 companies.
So what's the right hardware if I'm a service provider with thousands of routers and lots and lots of OC192's and OC768's floating around? Do you deploy a firewall (PC based or otherwise) in-line in a framed SONET link between carriers? How many 10GE flows can I switch at line rate on an interrupt driven platform? There's a reason beyond corporate greed that big, fast, reliable high-end network devices cost a lot of money.
Anyhow - even in smaller commercial networks the final demarcation between networks is rarely a firewall. I've yet to see any sort of firewall in-line for BGP sessions between an enterprise and an SP, for example. If there's a back door in an infrastructure device (and I'm not especially suggesting that Huawei in particular has one) it can be far more subtle and far more difficult to mitigate than trying to block the latest flavor of windows malware.
Here's an example - if some weird mixture of BGP community values on an arbitrary route caused a given router to begin to execute an arbitrary bit of code there's just about nothing that -any- firewall is going to do, especially if the goal is some kind of DoS attack. Until someone manually steps in from the network side with a device from another vendor, this malicious information could happily propagate through thousands upon thousands of networks across the planet. If the underlying network device is compromised, the utility and effectiveness of -any- firewall decreases rapidly. The knowledge that your firewall's code is open, audited and pristine is utterly irrelevant if that firewall has been bypassed.
Neither does a FC ISL. Any time we're using multiple links in parallel there needs to be a mechanism to deterministically map sessions or hosts to a particular element of the channel. Failing this, we end up with out-of-sequence packets, weird loss conditions, etc... Per-packet load balancing in LAN's (or FC, for that matter) died out a *long* time ago for this reason.
1.) Not everything runs over IP. If I have non-IP protocols occupying the same media as IP, I need a non-IP mechanism to make sure they don't step on each other.
2.) TCP is not designed to provide low latency lossless delivery. It can be made to work pretty well with various hacks and tweaks, but it's ultimately harder to make traffic like storage work well on it (witness difficulties with iSCSI).
3.) I agree partially with your point - Ethernet is the least common denominator. Economies of scale dictate that I can get a lot more bandwidth than FC for a lot less money. If this is true and I need to run Ethernet (of whatever flavor) to my servers anyhow, why not bolt on some enhancements to allow a single fabric to be deployed. Draw an analogy to VOIP encapsulating a different type of traffic on a common network or, if you remember back a ways, SNA being tunneled/encapsulated. It's all about convergence on fewer, more functional networks running over a common media.
FDDI has absolutely nothing to do with this. FDDI relied on expensive media, expensive termination and a ring topology (whether run physically or collapsed in a concentrator). It was great from the point of view of being able to provide media reliability on longer links but provides absolutely none of the guaranteed delivery, service lane or traffic control mechanisms being discussed.
Ether-channel may provide additional bandwith on each pipe that's being used to connect two switches, but it doesn't solve the issue of each session deciding only once which of the multiple pipes to use.
The issue you're describing is a function of how efficiently the hash algorithms on the Ethernet switches are operating. On modern switches src/dst port, src/dst hw address and src/dst L3 address are all figured into the mix. This is why high-volume, enterprise IP backup systems build multiple parallel flows to maximize use of the network.
Also - on the FC front, ISL's don't operate all that differently than etherchannel. There needs to be a hard mapping between a given flow / host and a particular link. Slicing up the traffic to alternate frames between multiple elements of any kind of channel is a recipe for out-of-order delivery, sequencing problems, etc, etc.
They're generally called pause frames and they've not been universally implemented across the products of various switch and NIC vendors, let alone OS drivers.
The technique discussed (PFC) is actually an extension of this mechanism. Whereas the current model drops *all* traffic in the case of a buffer congestion event, PFC allows for certain types of traffic (e.g. best effort) to be paused/queued to insure bandwidth is available for other types of traffic (lossless services - like FCoE).
Overall, the intent is to provide the same sorts of delivery guarantees currently available on Fibre Channel via buffer credits to a converged Ethernet network.
Not every site on our network requires 1G+ but most require the other features I mentioned (MPLS, QoS, etc, etc). Once again, though, the nature of my network isn't all that out of the ordinary for my industry. I could say the same about a number of other sectors. You're absolutely right that there are thousands and thousands of small networks for every big one but also bear in mind that when looking at the wider networking industry that big organizations also buy thousands and thousands of network devices.
The airline and retail industries (as referenced in your post) aren't known for substantial bandwidth requirements to all sites. To take your specific airline case - the reason even your major hubs don't need much bandwidth is that the apps being supported are almost completely terminal based. The same applies to the hospitality sector and really any industry where lots and lots of locations have a relatively small number of users entering data into similar host-based apps. The funny thing is, though, that until recently the only way that these sorts of mainframe apps could be supported was either via thousands and thousands of square feet of aging IBM FEP's landing tons of tiny circuits linking them to terminal controllers or - in the last 10 years or so - via some kind of scheme to transport SNA traffic over an IP backbone. This usually implied DLSw+ and its associated support for SDLC, translational bridging, etc, etc. Things have obviously changed and gotten better as IBM started putting credible IP stacks and Ethernet interfaces into mainframes and PC's with IP and tn3270 clients replaced dumb terminals but these sorts of features (..including airline specific features in IOS) are what sold millions upon millions of almost comically slow and obsolete 2500 and 2600 routers despite being outclassed on most levels by cheap PC's with T1 cards and a BSD or Linux with gated/zebra/quagga/whatever.
Once again, however, my point was that - despite the 4-6 Gbps cited earlier and numerous OSS performance endorsements on this thread - raw throughput alone offers a generally poor view of the capabilities or utility of a given router or switch platform. To draw the almost inevitable automotive analogy, if I'm presented with a heavy load to move across town I know that I'll need something with plenty of horsepower and torque to do so. Race cars have lots of horsepower and torque. Race cars make lousy moving vans. Similarly, the potential of an OSS routing platform to sustain gigabits of throughput (as referenced in your earlier post) isn't all that interesting as an abstract fact.
The features that allow me to build a network of thousands of sites while maintaining rock solid stability, sane and predictable ongoing operating expenses and the ability to rapidly and easily adjust to changing requirements are those that make that network useful. These are the things that Cisco and Juniper do well - at the low end and the high end and these are the reasons why a completely free (as in beer) routing platform can be a heck of a lot more expensive than its multi million dollar commercial equivalent. I'd argue that this logic holds true even for many smaller networks. We didn't look to the competent (and fast) BSD routers of 10 years ago to provide channel attached mainframe connectivity and fancy SNA features over a WAN and we don't generally look at the OSS routers of today to provide fancy QoS, MPLS, complex routing policy tools and a host of other items that go well beyond pushing IP from one interface to another.
A small percentage? Take a look at medium to large ISP's and larger enterprises. MPLS, QoS, high bandwidth and requirements for high density of 1G, 10G and SONET interfaces pretty much define many (most) of these sorts of networks.
As for assumptions and theories - I run one of these networks in the financial services sector, including 2000+ network devices spread across several hundred sites and I've been involved with literally dozens of environments of similar and larger scale over the past ten years or so in the enterprise, carrier and public sectors. Within our network we use MPLS extensively and rely on complex QoS mechanisms. We push more bandwidth than many carriers. Downtime represents astronomical costs.
If your measure of the success or utility of a routing platform is strictly how many packets it can move from one interface to another then you're not talking about real environments where people solve actual problems for actual money. The history of networking is littered with the corpses of companies with devices that were faster but lacked in stability, flexibility, manageability and vendor support.
4-6 Gbps is plenty of traffic. I'll take folks at their word that these numbers are accurate (..though I've got serious doubts) but honestly the issue of a dozen or so boxes passing that kind of traffic in a vanilla IP environment positively pale in comparison to managing several thousand boxes spread across the planet.
OSS PC hardware routers are a niche. Smart folks can build very useful routers in relatively small environments on standard commodity hardware. When faced with much larger environment with critical requirements for reliability and the very real issues of support, feature sets, staffing, management and ongoing operations costs lots of smart folks have also tended to realize that the several million dollar delta between an OSS solution and that of a major vendor is cheap in comparison.
I think we see some version of this article every few months - yet another revelation of an open source package that can turn PC's into routers. This isn't news. There have been various shapes and forms of routers on *NIX platforms for many, many years. Some of these platforms served (and still serve) as reference implementations of certain routing protocols.
The common responses on here seem to revolve around the inability of PC hardware to handle high bandwidth. To an extent this is necessarily true. A general purpose PC is going to rely on its CPU to handle each packet traversing the box. Processors are fast and cheap and becoming faster and cheaper as time passes. Most commercial router vendors realized quite a while ago that any architecture whose perforance is based on a single, centrl CPU inherently represents an eventual bottleneck and thus a serious challenge to scalability. As such, most commercial routers have moved to a model where forwarding is pushed as far as possible from a control plane that is as discrete as possible.
In other words, if we push the actual heavy lifting of forwarding out to distributed components (e.g. the interfaces themselves) then we're no longer left in a situation where our BGP process is vying for cycles and memory access with packets in transit. When properly implemented this means that I can be moving huge amounts of traffic through my router without interrupting network control traffic, management of the box, etc, etc.. It also means that by distributing packet switching they can hit massive performance levels with a comparitively modest CPU.
At the high end with Cisco and Juniper you're paying for the development of some exotic ASIC's and some even more exotic interface hardware. You're also paying for the capability to support high density - PC platforms aren't going to support tens of 10G or hundreds of 1G interfaces any time soon. The capacity for redundant CPU's, stateful failover, etc is also worth remembering.
At every level of Cisco and Juniper hardware you're paying for the ongoing development and maintenance of a highly complex codebase full of features that just aren't practical (or, in some situations, possible) for the OSS community to implement well. Implicit in this is a huge system test and regression faculty.
I've used and deployed open source routers up to OC3 bandwidth. They worked and, for the most part, worked well when faced with relatively simple networking tasks - multihoming enterprises to the Internet, basic WAN routing, etc. My observation has been that these platfoms start to fall apart when faced with requirements for complex routing policies, fancy QoS, MPLS, etc.
There's a definite place in the world for PC-based open source routing platforms - particularly at the edge of larger networks or in the midst of small and medium sized ones but I don't think Cisco and Juniper need to worry about being rendered completely obsolete any more than Oracle needs to worry about being driven completely out of business by MySQL or PG.
There has been an unbelievable amount of hype around this change. I guess I'm not sure why so many people seem to have some sort of religious attachment to the CPU. The vast majority of folks (even many developers) never interact in any meaningful way with the CPU itself (e.g. assembly) that would really differ in moving from PPC to Intel. There will be emulation for a while and this will be less than optimal but for the most part this shouldn't have much effect on most users and from a functional point of view will barely be a blip on the radar in 2-3 years.
It's not about competition between states with different levels of legislated morality. It's about the idea that the tyanny of the majority is still tyranny. We have a federal constitution that goes to some length to speak to this point.
I know it's kind of a boogeyman but imagine another situation where the federal government stepped in to directly contravene the wishes of the states: Arkansas, 1957. The supreme court decides that the notion of segregated public facilities (schools) isn't consistent with the constitution. The federal government sends troops down to escort some black kids into school despite an overwhelming objection by the majority (white) population. Arkansas was (and is) a part of a larger union - a union governed by laws and made up of a lot of people with a lot of differing views. Ultimately you either choose the *country* whose laws you feel best fit your personal beliefs or stay where you are and try to change things while accepting the fact that the ideals of the larger union don't necessarily completely jibe with your own but that there are folks out there who disagree with you who will fight for your ability to try to change it.
Here's the other thing about your competition argument - why not have the Mormons set up their own ISP with its own blocking and censorship measures. If folks feel like they need more protection for their kids they can use that ISP. Why does the state need to get involved here? If there's really such a desire for this kind of thing among religious conservatives wouldn't this suggest that the free market - not the state - is the right answer?
1-900 isn't about content, it's about billing. It's a financial decision that consumers of telephone services can make to prevent themselves from assuming liability for inappropriate calls. It doesn't matter if it's phone sex or Billy Graham - if I don't want to pay for it, I don't have to. Clicking on a porn site doesn't cause my ISP to bill me differently.
While we're at it, the constitution does *NOT* guarantee you the right to say whatever you want whenever you want. It prohibits the state from passing legislation preventing you from doing so (within a wide set of boundaries) but it unequivocally doesn't compel the fine folks who operate slashdot to display your postings if they don't want to any more than the New York Times is compelled to run any piece of paper you send them.
I guess the way I see it is that the ACLU seems to err on the side of individual liberty while opponents of the ACLU seem to often err on the side of the rights of local legislative bodies to obstruct said individual liberty. I'm not crazy about defending Nazis marching in Skokie but - like many - I'm glad it was defended. I'm also glad that there's some kind of organized body to challenge the overwhelming ability of the majority to marginalize and often destroy the minority.
The thing that has struck me as odd about the demonization of liberals vs conservatives and the ACLU is the frequent extent to which conservatives with libertarian tendencies seem to espouse a frequently common agenda while decrying the excesses of the left.
What I also find frankly hypocritical is the recent tendency of social conservatives to bemoan the tyanny of a big (elected) federal government (including its judiciary) over the rights of localities while ardently and passionately supporting the tyranny of localities over the rights of individuals. It's amazing how quickly folks who imagine(d) being previously persecuted for their beliefs springing forth as persecutors themselves.
"The U.S. government is being very stupid about doing IPv6, and it's going to put us at a disadvantage," Lightman said. "If studies like this aren't acted on... then instead of having a quarter of all the world's ISPs clustered here, around Reston, you'll have a quarter of the world's ISPs clustered around Tokyo or Beijing. I don't know if that's what the U.S. government really wants."
This is just silly on the face of it. ISP's exist and physically cluster based on fairly straightforward economics - where are the customers and where can they get capacity cheapest. The choice of protocols is a direct function of customer demand and is not some kind of product or mindshare that would arbitrarily find itself overseas. If the US continues to move towards hundreds of millions of consumers online there will continue to be lots of ISP's - both serving customers directly and connecting to other ISP's serving customers directly.
From a more technological point of view as networks are upgraded in the normal course of things we're seeing devices which would either not support- or inadequately support- IPv6 disappearing, to be replaced by boxes which will do a better job with IPv4 and - surprise surprise - tend to also support IPv6. Look at the routing offerings from Cisco and Juniper - IPv6 is widely available.
When and if ISP's want to roll IPv6 in a big way (which, incidentally, is going to be driven by customer demand - not some fear of shady Asian ISP's taking over) they can do so with software changes.
The downside of IPng, IPv6, ISO CLNS/CLNP, ATM, etc.. has been that standards bodies often set out with (sometimes wonderful) solutions in search of problems. They seem to often ignore the fact that the strictures imposed by the present state of things is one of the chief factors to be considered. Life and technology very rarely afford us the opportunity of a completely fresh start. We should plan accordingly.
Juniper sells boxes that do NAT. They also sell boxes that route IPv6. People buy their equipment regardless.
I don't think Juniper is pushing an anti-IPv6 agenda here - who do you think is providing a lot of the IPv6 routing infrastructure in DoD and Asia? They've got entire groups that do nothing but deal with IPv6. IPv4 vs. IPv6 in the Juniper world doesn't make that huge of a difference. They sell the same hardware either way.
So does this mean they should be judging the qualification of scientists up for technical jobs based not on their published works, education or experience but rather by who they voted for last time through? The precedent set here isn't a good one. Perhaps we can move to the point where only Bush *contributors* are tapped for this kind of thing. Kinda neat being able to buy one's way into regulatory positions, eh?
Traditionally speaking these kinds of relatively low-level technical spots -have- been filled without a whole lot of view toward political affiliation. Clinton appointed plenty of Republicans to positions like this. Bush Sr. appointed plenty of Democrats, and so on. This isn't a function of poison, it's a function of pettiness.
I don't think it matters what side of the spectrum you call home. This isn't good for America.
SOX deals with accountability within US corporations. It doesn't speak to the operations of companies outside the US. Attempts by particular countries to legislate the Internet have historically been ineffectual at best. This would be no exception.
It actually isn't about the amount of fiber that matters any more. To an ever increasing degree these strands are being lit with DWDM equipment. The few OC192's these folks are transmitting is a small portion of what's possible. Even without going into particularly exotic or ridiculously expensive equipment it's possible to push 80Gbps+ (e.g. 10 gigabytes per second - or a bit more than 16x the throughput mentioned in the article) out of a pair of strands. Upgrade to the bigger units (or wait a few months for the technology to improve) and this number goes way up.
The net outcome here is that DWDM has made trans-Atlantic bandwidth surprisingly cheap. Assuming you're well connected to the right carrier hotels an OC3 or OC12 (..carried on a lambda on someone's DWDM equipment) between NYC and Amsterdam can often be had for substantially less than the same circuit between two arbitrary points within the US. With the kind of facilities available to major labs (..with major government backing in many cases) access to huge amounts of relatively cheap bandwidth is not the barrier it used to be.
OK... they lit up the equivalent of two OC48's worth of bandwidth. That's half of an OC192 or a 10G Ethernet. There have been long haul OC192's for a number of years now. If I hook up a hardware-based traffic generator and run at 100% over an OC192 for a few weeks will I get a slashdot article, too?
I couldn't agree more, although I wonder if irony wouldn't cover it even more. Perhaps they should take a closer look at TunaCenter if they're really curious to see bloat epitomized - then again the comparison might be confusing to them: after all, Linux is actually useful to anybody.
Yes - there's lots coded in software on any router out there. My point is that there is very specialized dedicated hardware that's being driven by this software and that this hardware has necessary limitations that stem from the need to balance the extra ASIC engineering, associated support hardware (memory, bus capacity, etc) and (in some cases) architectural changes required vs. the commercial benefit of said fancy feature. Implementing these features in software is (relatively) cheap. Implementing the hardware that can by driven by this software is not.
Also - Cisco and Juniper's QoS is a lot more involved than placing packets into three queues. Depending on hardware platform you've got multiple queueing schemes (fifo, weighted round-robin, fair, weighted fair) which, in turn, can make use of multiple congestion avoidance/control mechanisms (RED/WRED, policing, shaping, etc) that can be driven by a number of mechanisms (L2-based from FR/ATM, queue-based, etc). Reservation of bandwidth can be accomplished on a static or dynamic basis based on multiple criteria. Admission control, traffic engineering and various fault tolerance mechanisms are also available. A lot of these features vary by specific hardware platform (especially true within Cisco) but I don't think the feature disparity is as great as you seem to make out.
That said - I'd love it if Cisco opened up their forwarding code to some sort of external API. The present architecture of IOS couldn't even faintly support this kind of model but IOS-XR potentially could some day (essentially all of the vendors under discussion are moving in the direction of more modular code). The present JunOS might be a bit better - in theory one could reverse-engineer the protocol that passes between the routing engine and the packet forwarding engine (it runs on ethernet and can be viewed from JunOS with the included tcpdump, after all) or - more properly - leverage their publicly documented API's but I sort of doubt that they're going to swing open the doors to low-level ASIC interfaces any time soon.
Incidentally there's zero question that the JunOS routing engine runs on standard, commodity Intel hardware and that the OS is absolutely FreeBSD. As I mentioned above, the basic architecture is a BSD box dealing with control-plane functions and a dedicated ASIC complex dealing with actual data-plane forwarding.
There is a lot of misconception about layer-4 (and up) switching. Yes - Cisco has had switching paths that track state for a number of years (Netflow switching was incorporated somewhere in 97 or 98 in the 11.1 train for just this reason) and this has been incorporated into hardware but the problems with the scalability of this approach are well documented. On very busy high-speed links you literally end up having to store hundreds of millions (or even billions) of state entries to maintain track of layer-4 (or, heaven forbid, layer-7) sessions. It rapidly becomes impractical to store this information for more than a few minutes. This isn't a problem that scales as a function of Moore's law. Real-time (and I mean true real-time - orders of nanoseconds) lookup of this kind of information for forwarding is a function of memory speed and general I/O - neither of which has grown on par with CPU speed. This is one of those areas where pure software implementations start to fall apart. This is why protocol and router designers tend to hold that scalability and state tracking are diametrically opposed problems.
Cisco's stated approach to dealing with the problem of layer-7 switching lies more in their firewall (PIX) and load balancer (CSM/CSS) products. Juniper's approach is going to follow via their acquisition of Netscreen and its hardware-based firewall products. Their customers (including us) want things this way because it's the only realistic way to scale. Tracking and managing state (QoS, ACL functions, etc) is a problem that has been consistently shown to be best solved in a distributed fashion.
There seems to be an automatic desire on Slashdot to compare the features of Linux/BSD boxes to anythging under discussion (in this case high-end routers). There's no question that FOSS implementations have the flexibility to implement lots of cool new features at a rapid rate. Then again, these FOSS implementations aren't saddled with requirements to run at hundreds of millions of packets per second on custom ASIC's, or, indeed, to run in real-time production-critical systems.
Juniper, Cisco and similar are *hardware* companies. They spend billions of dollars fabricating ASIC's and distributed processing mechanisms to forward packets at rates our general-purpose PC's (even the clustered ones) can't even theoretically approach. NetBSD boxes push many gigabits in Internet2 speed records. Now consider how much beside that NetBSD box that the rest of the network has to handle. A system whose only job is sending tons of data to a single destination is a lot different than a box that has to switch flows from millions of boxes while also potentially handling the big flows from said box.
Don't lose track of the fact that these boxes are designed to meet a very specific set of needs in the core of the network. The market isn't demanding fancy layer-7 filtering capabilities in boxes terminating a dozen OC-192's and, as such, there aren't a lot of dollars being put into ASIC's to silently proxy peer-to-peer file sharing applications to run correctly with NAT at hundreds of millions of packet per second (or insert other nifty Linux feature). There's a domain where software based routing makes a ton of sense - and that domain is the edge of larger networks or even the middle of very small ones. In cases where things like density, consistent line-rate forwarding, hardware designed/certified for real-time operation and such are required, hardware-based platforms are the only way to go.
I guess my point here is that comparing the rapid rate of innovation in- and availability of- aftermarket parts for sports cars to that of 50-ton dump trucks doesn't make a whole lot of sense. Both have wheels, tires, internal combustion engines and horns but the similarities don't run a whole lot deeper.
Slashdot Mirror
Uhhhh... dotcom, anyone? Plenty of twenty-something "executives" hyping ridiculous/unsustainable business models. Clearly the people giving out the money (VC's, et al) were generally somewhat older, but a healthy portion of the abject failures that typified the period can be laid at the feet of the (then) under-30 crowd. Incidentally, how old do you think those energy traders at Enron were? Naive or not, they certainly played their role. Stupidity, incompetence and corruption are well-represented at all age levels.
So... Income distribution in the US is such that 35% of net worth resides with the top 1% of the population and ~86% resides with the top 20%. How would the other 80% of the country, which holds the remaining 14% of total wealth / net income (http://sociology.ucsc.edu/whorulesamerica/power/wealth.html) even theoretically be -able- to contribute an equivalent amount?
I work hard and make decent money - likely many times what a teacher, fireman or construction worker earns. Likewise, the amount I pay in taxes is also several times the average gross income in this country. I'm reaping a somewhat higher reward from an economy that is underpinned by infrastructure that's paid for by my taxes and supported/protected/defended by individuals that are also paid from my taxes. Without roads, telecom, cops / law enforcement, firemen, teachers and, yes, the occasional bureaucrat to help keep it all together then my company is going to have a hell of a time selling its wares and, thus, will likely have proportionately less need for my services.
The notion of "poor" is a pretty variable term. Lots and lots of folks live in that bottom 14% - especially including the civil servants I mentioned above and lots of folks who are loudest to condemn the so-called "socialist" nature of our government. This, of course, is notwithstanding of the fact that lots of these folks couldn't accurately describe the distinctions between socialism, communism and fascism - at least judging by the way such terms are lightly thrown around.
Then die. You paid - at best - a tiny share of the cost of the roads and bridges you likely use every day, the medicines that keep you and your family alive. I'm personally a big fan of antibiotics when I have an infection. What paid for the development of mass production of Penicillin? Oh, right... the military, which is paid for by who, again?
Yeah - those damned government workers... just flaunting their lazy, socialist lifestyles and living off of the hard work and industry of others. I've always felt that cops and firemen were just drains on society. Hell, government subsidies of modern hospitals in rural areas (...where many of the supposedly self-sufficient people live and work) are just a drain on your independently earned dollar. Same idea for schools - screw people in rural areas! They shouldn't have modern, competitive schools! Don't even get me started about all the hard-earned cash that's wasted in taxes and regulations to compel telecom and electric utilities to provide service to sparsely populated areas.
While we're at it - what about all of those contractors that are building things for government agencies? Clearly all pork. Shut 'em down! Why bother with helicopters for the Coast Guard? If someone's ship capsizes then it was clearly their fault! And if they can't swim to shore when 10 miles out? Screw 'em.
Oh - and your job? Hopefully whatever goods or services you're involved with selling/producing/distributing/etc aren't ever procured by people who work for those contractors building those helicopters, tanks, ships, planes, etc - 'cause then your livelihood is, at least partially, tied to precisely the same tax-mooching lazy bastards you're sick of supporting.
Take a look at how much money is spent of AFDC or Medicaid. It's a lot of money. Now compare that to the cost of the defense department budget, Social Security, Medicare or the cost of infrastructure. Guess what? It's a *LOT* more money.
Face it, all of the self-sufficient hard work you're putting out there to make money from the open market is utterly and completely reliant on lots of shared services and, yes, regulations that are administered by local, state and federal government. Short of folks living in tribes in the furthest corners of the Earth, *everyone* is reliant on some amount of so-called welfare.
Buy the right hardware and run M0n0wall or pfsense. If you can audit the code of your firewall it's the only way to be sure there are no backdoors in it.
I have had a M0n0Wall running for well over 6 years with no problems. Granted it's for a very small company with only a few thousand users.... but there are some out there doing the work for fortune 500 companies.
So what's the right hardware if I'm a service provider with thousands of routers and lots and lots of OC192's and OC768's floating around? Do you deploy a firewall (PC based or otherwise) in-line in a framed SONET link between carriers? How many 10GE flows can I switch at line rate on an interrupt driven platform? There's a reason beyond corporate greed that big, fast, reliable high-end network devices cost a lot of money.
Anyhow - even in smaller commercial networks the final demarcation between networks is rarely a firewall. I've yet to see any sort of firewall in-line for BGP sessions between an enterprise and an SP, for example. If there's a back door in an infrastructure device (and I'm not especially suggesting that Huawei in particular has one) it can be far more subtle and far more difficult to mitigate than trying to block the latest flavor of windows malware.
Here's an example - if some weird mixture of BGP community values on an arbitrary route caused a given router to begin to execute an arbitrary bit of code there's just about nothing that -any- firewall is going to do, especially if the goal is some kind of DoS attack. Until someone manually steps in from the network side with a device from another vendor, this malicious information could happily propagate through thousands upon thousands of networks across the planet. If the underlying network device is compromised, the utility and effectiveness of -any- firewall decreases rapidly. The knowledge that your firewall's code is open, audited and pristine is utterly irrelevant if that firewall has been bypassed.
Neither does a FC ISL. Any time we're using multiple links in parallel there needs to be a mechanism to deterministically map sessions or hosts to a particular element of the channel. Failing this, we end up with out-of-sequence packets, weird loss conditions, etc... Per-packet load balancing in LAN's (or FC, for that matter) died out a *long* time ago for this reason.
1.) Not everything runs over IP. If I have non-IP protocols occupying the same media as IP, I need a non-IP mechanism to make sure they don't step on each other.
2.) TCP is not designed to provide low latency lossless delivery. It can be made to work pretty well with various hacks and tweaks, but it's ultimately harder to make traffic like storage work well on it (witness difficulties with iSCSI).
3.) I agree partially with your point - Ethernet is the least common denominator. Economies of scale dictate that I can get a lot more bandwidth than FC for a lot less money. If this is true and I need to run Ethernet (of whatever flavor) to my servers anyhow, why not bolt on some enhancements to allow a single fabric to be deployed. Draw an analogy to VOIP encapsulating a different type of traffic on a common network or, if you remember back a ways, SNA being tunneled/encapsulated. It's all about convergence on fewer, more functional networks running over a common media.
FDDI has absolutely nothing to do with this. FDDI relied on expensive media, expensive termination and a ring topology (whether run physically or collapsed in a concentrator). It was great from the point of view of being able to provide media reliability on longer links but provides absolutely none of the guaranteed delivery, service lane or traffic control mechanisms being discussed.
Ether-channel may provide additional bandwith on each pipe that's being used to connect two switches, but it doesn't solve the issue of each session deciding only once which of the multiple pipes to use.
The issue you're describing is a function of how efficiently the hash algorithms on the Ethernet switches are operating. On modern switches src/dst port, src/dst hw address and src/dst L3 address are all figured into the mix. This is why high-volume, enterprise IP backup systems build multiple parallel flows to maximize use of the network.
Also - on the FC front, ISL's don't operate all that differently than etherchannel. There needs to be a hard mapping between a given flow / host and a particular link. Slicing up the traffic to alternate frames between multiple elements of any kind of channel is a recipe for out-of-order delivery, sequencing problems, etc, etc.
They're generally called pause frames and they've not been universally implemented across the products of various switch and NIC vendors, let alone OS drivers.
The technique discussed (PFC) is actually an extension of this mechanism. Whereas the current model drops *all* traffic in the case of a buffer congestion event, PFC allows for certain types of traffic (e.g. best effort) to be paused/queued to insure bandwidth is available for other types of traffic (lossless services - like FCoE).
Overall, the intent is to provide the same sorts of delivery guarantees currently available on Fibre Channel via buffer credits to a converged Ethernet network.
The airline and retail industries (as referenced in your post) aren't known for substantial bandwidth requirements to all sites. To take your specific airline case - the reason even your major hubs don't need much bandwidth is that the apps being supported are almost completely terminal based. The same applies to the hospitality sector and really any industry where lots and lots of locations have a relatively small number of users entering data into similar host-based apps. The funny thing is, though, that until recently the only way that these sorts of mainframe apps could be supported was either via thousands and thousands of square feet of aging IBM FEP's landing tons of tiny circuits linking them to terminal controllers or - in the last 10 years or so - via some kind of scheme to transport SNA traffic over an IP backbone. This usually implied DLSw+ and its associated support for SDLC, translational bridging, etc, etc. Things have obviously changed and gotten better as IBM started putting credible IP stacks and Ethernet interfaces into mainframes and PC's with IP and tn3270 clients replaced dumb terminals but these sorts of features (..including airline specific features in IOS) are what sold millions upon millions of almost comically slow and obsolete 2500 and 2600 routers despite being outclassed on most levels by cheap PC's with T1 cards and a BSD or Linux with gated/zebra/quagga/whatever.
Once again, however, my point was that - despite the 4-6 Gbps cited earlier and numerous OSS performance endorsements on this thread - raw throughput alone offers a generally poor view of the capabilities or utility of a given router or switch platform. To draw the almost inevitable automotive analogy, if I'm presented with a heavy load to move across town I know that I'll need something with plenty of horsepower and torque to do so. Race cars have lots of horsepower and torque. Race cars make lousy moving vans. Similarly, the potential of an OSS routing platform to sustain gigabits of throughput (as referenced in your earlier post) isn't all that interesting as an abstract fact.
The features that allow me to build a network of thousands of sites while maintaining rock solid stability, sane and predictable ongoing operating expenses and the ability to rapidly and easily adjust to changing requirements are those that make that network useful. These are the things that Cisco and Juniper do well - at the low end and the high end and these are the reasons why a completely free (as in beer) routing platform can be a heck of a lot more expensive than its multi million dollar commercial equivalent. I'd argue that this logic holds true even for many smaller networks. We didn't look to the competent (and fast) BSD routers of 10 years ago to provide channel attached mainframe connectivity and fancy SNA features over a WAN and we don't generally look at the OSS routers of today to provide fancy QoS, MPLS, complex routing policy tools and a host of other items that go well beyond pushing IP from one interface to another.
As for assumptions and theories - I run one of these networks in the financial services sector, including 2000+ network devices spread across several hundred sites and I've been involved with literally dozens of environments of similar and larger scale over the past ten years or so in the enterprise, carrier and public sectors. Within our network we use MPLS extensively and rely on complex QoS mechanisms. We push more bandwidth than many carriers. Downtime represents astronomical costs.
If your measure of the success or utility of a routing platform is strictly how many packets it can move from one interface to another then you're not talking about real environments where people solve actual problems for actual money. The history of networking is littered with the corpses of companies with devices that were faster but lacked in stability, flexibility, manageability and vendor support.
4-6 Gbps is plenty of traffic. I'll take folks at their word that these numbers are accurate (..though I've got serious doubts) but honestly the issue of a dozen or so boxes passing that kind of traffic in a vanilla IP environment positively pale in comparison to managing several thousand boxes spread across the planet.
OSS PC hardware routers are a niche. Smart folks can build very useful routers in relatively small environments on standard commodity hardware. When faced with much larger environment with critical requirements for reliability and the very real issues of support, feature sets, staffing, management and ongoing operations costs lots of smart folks have also tended to realize that the several million dollar delta between an OSS solution and that of a major vendor is cheap in comparison.
The common responses on here seem to revolve around the inability of PC hardware to handle high bandwidth. To an extent this is necessarily true. A general purpose PC is going to rely on its CPU to handle each packet traversing the box. Processors are fast and cheap and becoming faster and cheaper as time passes. Most commercial router vendors realized quite a while ago that any architecture whose perforance is based on a single, centrl CPU inherently represents an eventual bottleneck and thus a serious challenge to scalability. As such, most commercial routers have moved to a model where forwarding is pushed as far as possible from a control plane that is as discrete as possible.
In other words, if we push the actual heavy lifting of forwarding out to distributed components (e.g. the interfaces themselves) then we're no longer left in a situation where our BGP process is vying for cycles and memory access with packets in transit. When properly implemented this means that I can be moving huge amounts of traffic through my router without interrupting network control traffic, management of the box, etc, etc.. It also means that by distributing packet switching they can hit massive performance levels with a comparitively modest CPU.
At the high end with Cisco and Juniper you're paying for the development of some exotic ASIC's and some even more exotic interface hardware. You're also paying for the capability to support high density - PC platforms aren't going to support tens of 10G or hundreds of 1G interfaces any time soon. The capacity for redundant CPU's, stateful failover, etc is also worth remembering.
At every level of Cisco and Juniper hardware you're paying for the ongoing development and maintenance of a highly complex codebase full of features that just aren't practical (or, in some situations, possible) for the OSS community to implement well. Implicit in this is a huge system test and regression faculty.
I've used and deployed open source routers up to OC3 bandwidth. They worked and, for the most part, worked well when faced with relatively simple networking tasks - multihoming enterprises to the Internet, basic WAN routing, etc. My observation has been that these platfoms start to fall apart when faced with requirements for complex routing policies, fancy QoS, MPLS, etc.
There's a definite place in the world for PC-based open source routing platforms - particularly at the edge of larger networks or in the midst of small and medium sized ones but I don't think Cisco and Juniper need to worry about being rendered completely obsolete any more than Oracle needs to worry about being driven completely out of business by MySQL or PG.
There has been an unbelievable amount of hype around this change. I guess I'm not sure why so many people seem to have some sort of religious attachment to the CPU. The vast majority of folks (even many developers) never interact in any meaningful way with the CPU itself (e.g. assembly) that would really differ in moving from PPC to Intel. There will be emulation for a while and this will be less than optimal but for the most part this shouldn't have much effect on most users and from a functional point of view will barely be a blip on the radar in 2-3 years.
I know it's kind of a boogeyman but imagine another situation where the federal government stepped in to directly contravene the wishes of the states: Arkansas, 1957. The supreme court decides that the notion of segregated public facilities (schools) isn't consistent with the constitution. The federal government sends troops down to escort some black kids into school despite an overwhelming objection by the majority (white) population. Arkansas was (and is) a part of a larger union - a union governed by laws and made up of a lot of people with a lot of differing views. Ultimately you either choose the *country* whose laws you feel best fit your personal beliefs or stay where you are and try to change things while accepting the fact that the ideals of the larger union don't necessarily completely jibe with your own but that there are folks out there who disagree with you who will fight for your ability to try to change it.
Here's the other thing about your competition argument - why not have the Mormons set up their own ISP with its own blocking and censorship measures. If folks feel like they need more protection for their kids they can use that ISP. Why does the state need to get involved here? If there's really such a desire for this kind of thing among religious conservatives wouldn't this suggest that the free market - not the state - is the right answer?
While we're at it, the constitution does *NOT* guarantee you the right to say whatever you want whenever you want. It prohibits the state from passing legislation preventing you from doing so (within a wide set of boundaries) but it unequivocally doesn't compel the fine folks who operate slashdot to display your postings if they don't want to any more than the New York Times is compelled to run any piece of paper you send them.
The thing that has struck me as odd about the demonization of liberals vs conservatives and the ACLU is the frequent extent to which conservatives with libertarian tendencies seem to espouse a frequently common agenda while decrying the excesses of the left.
What I also find frankly hypocritical is the recent tendency of social conservatives to bemoan the tyanny of a big (elected) federal government (including its judiciary) over the rights of localities while ardently and passionately supporting the tyranny of localities over the rights of individuals. It's amazing how quickly folks who imagine(d) being previously persecuted for their beliefs springing forth as persecutors themselves.
This is just silly on the face of it. ISP's exist and physically cluster based on fairly straightforward economics - where are the customers and where can they get capacity cheapest. The choice of protocols is a direct function of customer demand and is not some kind of product or mindshare that would arbitrarily find itself overseas. If the US continues to move towards hundreds of millions of consumers online there will continue to be lots of ISP's - both serving customers directly and connecting to other ISP's serving customers directly.
From a more technological point of view as networks are upgraded in the normal course of things we're seeing devices which would either not support- or inadequately support- IPv6 disappearing, to be replaced by boxes which will do a better job with IPv4 and - surprise surprise - tend to also support IPv6. Look at the routing offerings from Cisco and Juniper - IPv6 is widely available.
When and if ISP's want to roll IPv6 in a big way (which, incidentally, is going to be driven by customer demand - not some fear of shady Asian ISP's taking over) they can do so with software changes.
The downside of IPng, IPv6, ISO CLNS/CLNP, ATM, etc.. has been that standards bodies often set out with (sometimes wonderful) solutions in search of problems. They seem to often ignore the fact that the strictures imposed by the present state of things is one of the chief factors to be considered. Life and technology very rarely afford us the opportunity of a completely fresh start. We should plan accordingly.
I don't think Juniper is pushing an anti-IPv6 agenda here - who do you think is providing a lot of the IPv6 routing infrastructure in DoD and Asia? They've got entire groups that do nothing but deal with IPv6. IPv4 vs. IPv6 in the Juniper world doesn't make that huge of a difference. They sell the same hardware either way.
Traditionally speaking these kinds of relatively low-level technical spots -have- been filled without a whole lot of view toward political affiliation. Clinton appointed plenty of Republicans to positions like this. Bush Sr. appointed plenty of Democrats, and so on. This isn't a function of poison, it's a function of pettiness.
I don't think it matters what side of the spectrum you call home. This isn't good for America.
SOX deals with accountability within US corporations. It doesn't speak to the operations of companies outside the US. Attempts by particular countries to legislate the Internet have historically been ineffectual at best. This would be no exception.
The net outcome here is that DWDM has made trans-Atlantic bandwidth surprisingly cheap. Assuming you're well connected to the right carrier hotels an OC3 or OC12 (..carried on a lambda on someone's DWDM equipment) between NYC and Amsterdam can often be had for substantially less than the same circuit between two arbitrary points within the US. With the kind of facilities available to major labs (..with major government backing in many cases) access to huge amounts of relatively cheap bandwidth is not the barrier it used to be.
OK... they lit up the equivalent of two OC48's worth of bandwidth. That's half of an OC192 or a 10G Ethernet. There have been long haul OC192's for a number of years now. If I hook up a hardware-based traffic generator and run at 100% over an OC192 for a few weeks will I get a slashdot article, too?
I couldn't agree more, although I wonder if irony wouldn't cover it even more. Perhaps they should take a closer look at TunaCenter if they're really curious to see bloat epitomized - then again the comparison might be confusing to them: after all, Linux is actually useful to anybody.
Also - Cisco and Juniper's QoS is a lot more involved than placing packets into three queues. Depending on hardware platform you've got multiple queueing schemes (fifo, weighted round-robin, fair, weighted fair) which, in turn, can make use of multiple congestion avoidance/control mechanisms (RED/WRED, policing, shaping, etc) that can be driven by a number of mechanisms (L2-based from FR/ATM, queue-based, etc). Reservation of bandwidth can be accomplished on a static or dynamic basis based on multiple criteria. Admission control, traffic engineering and various fault tolerance mechanisms are also available. A lot of these features vary by specific hardware platform (especially true within Cisco) but I don't think the feature disparity is as great as you seem to make out.
That said - I'd love it if Cisco opened up their forwarding code to some sort of external API. The present architecture of IOS couldn't even faintly support this kind of model but IOS-XR potentially could some day (essentially all of the vendors under discussion are moving in the direction of more modular code). The present JunOS might be a bit better - in theory one could reverse-engineer the protocol that passes between the routing engine and the packet forwarding engine (it runs on ethernet and can be viewed from JunOS with the included tcpdump, after all) or - more properly - leverage their publicly documented API's but I sort of doubt that they're going to swing open the doors to low-level ASIC interfaces any time soon.
Incidentally there's zero question that the JunOS routing engine runs on standard, commodity Intel hardware and that the OS is absolutely FreeBSD. As I mentioned above, the basic architecture is a BSD box dealing with control-plane functions and a dedicated ASIC complex dealing with actual data-plane forwarding.
There is a lot of misconception about layer-4 (and up) switching. Yes - Cisco has had switching paths that track state for a number of years (Netflow switching was incorporated somewhere in 97 or 98 in the 11.1 train for just this reason) and this has been incorporated into hardware but the problems with the scalability of this approach are well documented. On very busy high-speed links you literally end up having to store hundreds of millions (or even billions) of state entries to maintain track of layer-4 (or, heaven forbid, layer-7) sessions. It rapidly becomes impractical to store this information for more than a few minutes. This isn't a problem that scales as a function of Moore's law. Real-time (and I mean true real-time - orders of nanoseconds) lookup of this kind of information for forwarding is a function of memory speed and general I/O - neither of which has grown on par with CPU speed. This is one of those areas where pure software implementations start to fall apart. This is why protocol and router designers tend to hold that scalability and state tracking are diametrically opposed problems.
Cisco's stated approach to dealing with the problem of layer-7 switching lies more in their firewall (PIX) and load balancer (CSM/CSS) products. Juniper's approach is going to follow via their acquisition of Netscreen and its hardware-based firewall products. Their customers (including us) want things this way because it's the only realistic way to scale. Tracking and managing state (QoS, ACL functions, etc) is a problem that has been consistently shown to be best solved in a distributed fashion.
The comparison
Juniper, Cisco and similar are *hardware* companies. They spend billions of dollars fabricating ASIC's and distributed processing mechanisms to forward packets at rates our general-purpose PC's (even the clustered ones) can't even theoretically approach. NetBSD boxes push many gigabits in Internet2 speed records. Now consider how much beside that NetBSD box that the rest of the network has to handle. A system whose only job is sending tons of data to a single destination is a lot different than a box that has to switch flows from millions of boxes while also potentially handling the big flows from said box.
Don't lose track of the fact that these boxes are designed to meet a very specific set of needs in the core of the network. The market isn't demanding fancy layer-7 filtering capabilities in boxes terminating a dozen OC-192's and, as such, there aren't a lot of dollars being put into ASIC's to silently proxy peer-to-peer file sharing applications to run correctly with NAT at hundreds of millions of packet per second (or insert other nifty Linux feature). There's a domain where software based routing makes a ton of sense - and that domain is the edge of larger networks or even the middle of very small ones. In cases where things like density, consistent line-rate forwarding, hardware designed/certified for real-time operation and such are required, hardware-based platforms are the only way to go.
I guess my point here is that comparing the rapid rate of innovation in- and availability of- aftermarket parts for sports cars to that of 50-ton dump trucks doesn't make a whole lot of sense. Both have wheels, tires, internal combustion engines and horns but the similarities don't run a whole lot deeper.