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
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
I'll show you 50% of the Fortune 100 where I can SSH directly to a switch or router with no jump server in the dat path. I know of one organization where from a desktop I can SSH to over 75,000 network devices unfettered...
dg
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
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
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 Mirror
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
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
I'll show you 50% of the Fortune 100 where I can SSH directly to a switch or router with no jump server in the dat path. I know of one organization where from a desktop I can SSH to over 75,000 network devices unfettered... dg
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
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
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