Forgot your password?
typodupeerror

Comment Re:Why do we still trust the manufacturer? (Score 1) 168

I wouldn't say 'there is no comparison' between Cisco business and infrastructure devices and what people load a variant of Linux on - unless you mean that what most people run Linux on has far more horsepower, memory, and capability. The bulk of the Cisco routers, by volume, are branch boxes - these have relatively low performing CPUs and largely do packet forwarding in the CPU because there is no need for HW acceleration when you are running up to 1Gbps nowadays. Lately, since the advent of IOS-XE and NX-OS/SANOS they are also largely running Linux as the base OS layer as opposed to the straight monolithic IOS code. If you were to take an Asus board, slap a few NICs onto it, you could make a reasonably credible router (Vyatta anyone?). If you were a third year Computer Engineering/EE Student you should be able to redesign the PCB stripping off the components you don't need to at least VE the thing down and surface mount the NICs - poof, you just made a base-model ISR... dg

Comment Re:Where's the highly persistent part? (Score 1) 168

The lack of signature signed images and image verification for OS images, firmware/ROMMON, and such is fairly well known at this point. The fact it was well understood when I worked at Cisco from 1998-2009 and no one did anything about it is an altogether different issue. There are quite a few other fun exploits that can be run against newer switches and routers too - network automation and virtualization have created a ton of new opportunities. dg

Comment Re:Of course (Score 1) 337

Somehow in editing/HTML-izing my table got messed up, corrected version below:

Old Model: User pays Comcast who pays T1 ISP who is paid by Netflix who pays for Content
Distributed Old Model: User pays Comcast who is paid by CDN who is paid by Netflix who pays for Content
Direct Peering Model: User pays Comcast who is paid by Netflix who pays for Content


dg

Comment Re:Of course (Score 1) 337

I am not sure I completely 'get' your argument here on the Comcast piece.

Traditionally Comcast would get paid by end users for access, and Comcast would buy service from a Tier-1 ISP. Netflix would get paid by end users for their content and they would also buy service from a Tier-1 ISP. Netflix could also distribute their service by pushing their content to a CDN who also paid for their access to either Comcast, TWC, Verizon, etc (you don't think Akamai and Limelight get their access for free do you)

Old Model: User >>>$$>>> Comcast >>>$$>>> T1 ISP >>$$>>> Content
Distributed Old Model User >>>$$>>> Comcast >>$$>>> Content
Direct Peering Model User >>>$$>>> Comcast >>$$>>> Content

I fail to see why you are so upset that Comcast and Netflix have eliminated the middle-man here. Netflix drove enough bandwidth to find CDNs very expensive and to find that the performance through their T1 ISPs was not only cost prohibitive but also had challenges with service quality. Comcast had enough users and a large enough backhaul network on their own to be able to offer a direct peering model into local markets for less than Netflix was paying their CDN provider + T1 ISP before as a percentage of number of users served via Comcast. Comcast won't need anywhere near as much connectivity from their CDN customers that supported Netflix (and were paid by Netflix) so that revenue stream actually goes away. (why is no one upset about poor CDN players in this!)

On the flip side to the first point made by NoKaOi above Cisco has always been a strong advocate against Net Neutrality - primarily because it drives requirements for more intelligent devices in the network that can do exactly what you are saying - prioritize certain traffic types ahead of others. Whether that is the hypothetical and altruistic sounding examples Cisco used or the more pragmatic 'Bob pays more than Bill, give Bob better service' (which does sort of seem to be the way the world works in most other areas - I know if I buy the 55Mb burst service I sure would like to get a better service level than the guy down the street not buying it...) or the more nefarious examples that everyone likes to also throw out: Our cable company owns a media company that produces TV programming - so we are going to de-prioritize competing programs so that their service level makes them darn near unusable versus keeping our own TV programming at such a high bit rate that its service level is great and it becomes the preferred show you watch - not because the content is better but because the performance/viewing experience is.

From everything I have read here this last one is the one that has everyone worried and 'up in arms' about Net Neutrality. Its also, as a fairly experienced network engineer, very very very difficult, borderline impossible, to accomplish. If you've ever looked at the configurations on those big, fast, routers in the core of networks like Comcast, AT&T, Verizon, etc, or the PE boxes at the edge of the carrier networks you will find that no device can and no network engineer wants to administer or ever implement and a policy that tries to identify a specific piece of content and de-prioritizes it. Simply put the TCAM based forwarding architectures in the large routers do not have the depth of inspection in them to identify a specific piece of streaming content and increase its priority over another.

Compounding the absolute impracticality of the argument is that most content shops use CDNs. So if I was a cable MSO I would probably have a nice tertiary income stream by selling some of my network resources to a CDN provider: this gets me a little bit of $, and means I don't have to go through a cost center Tier-1 ISP link to get those, usually rather large data streams, to my customers so everyone kinda wins. But if I then wanted to identify specific media traffic or a specific program coming from a competing site - lets say as a Cable MSO I found that 'Hannity and Colmes' was a show that we hated, was getting watched too much in our market, and we wanted people to watch our version of right-leaning news - I would have to do the following:

1) Identify the streaming media traffic sourced from Fox that was the specific 'Hannity and Colmes' show being streamed

This is harder than it sounds: Many streaming media systems use a well known tCP port for the session control but then use a relatively random UDP port for the live streaming or a separate TCP session for the actual content delivery in an on-demand model. Also no-where in the packet headers is the actual program identified unless its in the URL of the initial request which is not in subsequent packets and may also only be in the control channel.

2) Parse all the traffic going to and from my CDN partner to try an dal so identify 'Hannity and Colmes' - since they use redirected HTTP requests, customer coded URLs, and custom coded DNS - this is about impossible.

3) Now if I wanted I suppose I could put a customer 'gateway' in front of every customer or group of them that terminated their SSL packets, somehow spoofing the end site and tracking every URL in a full proxy mode and then running a deep packet inspection engine to look for all URL combinations that look lie they could be 'Hannity and Colmes' while also employing a team of people to monitor Fox's site for any URL or name changes and then keep this policy updated at every CO/Headend on every gateway.

While #3 is probably the most realistic way to actually solve this you also have to accept that a device that does this level of inspection, de-cryption/re-encryption, and has the traffic management capabilities costs well over $100k for a 10Gb performance. It also violates about every principle and tenet of cryptography and would be flagged by your browser in about 1/10th of a second as a man-in-the-middle since it wouldn't have the key for fox.com. But even assuming in fantasy-land where that didn't matter and was possible you are not looking at an aggregate costs of millions of dollars of CAPEX, a team of network engineers, and a team of content monitoring folks simply to make a show 'Hannity and Colmes' suck more than it already does... let's be frank... it doesn't need a Cable MSO's help to suck any more - its doing fine on its own! (it also happens to be economically unfeasible)

dg

Comment Some Facilities Thoughts (Score 1) 422

Rooms: I like having three rooms or closets depending on the size: 1) Room 1: For outside plant telco termination, vendor/provider CPE devices, etc. This should have a separate locking system and that you can use to let them have access to THEIR equipment without necessarily giving themselves access to YOUR equipment. 2) Room 2/Telco: For your telco equipment and cable termination. Here you bring back in all of your cabling from around the plant and I would fastidiously follow every bit of advice given on using larger conduit and labeling every conduit and preferably every cable. One thing to think about is location of the room though: if it is central copper may be OK. If it is on a building corner you may want to plan for 12-strand OM4 MMF and a 12-strand SMF fiber pull to each conduit. Why? 40Gb and 100Gb isn't spec'd on Cat6/6A/7 yet - and requires anywhere from 4-10 pairs of MMF/SMF for the SR10/SR4 specs. Plus, while Copper gets aged and obsoleted every 5-10 years SMF has been a perennial long-lifecycle choice and the actual fiber and termination costs are around the same. 3) Room 3/Server Room: Here I like a contained hot-aisle with exhaust out the building and dedicated HVAC, dual power circuits, separate PDUs, UPS systems, etc. I would plan on 30kW per cabinet of servers as a power requirement and then make sure you can dissipate that heat, ingest that power, move enough airflow, etc. dg

Slashdot Top Deals

You may call me by my name, Wirth, or by my value, Worth. - Nicklaus Wirth

Working...