Comments for BRAD HEDLUND http://bradhedlund.com Studies in Data Center Networking, Virtualization, Computing Wed, 16 May 2012 06:59:43 +0000 hourly 1 http://wordpress.org/?v=3.3.2 Comment on Cisco UCS criticism and FUD: Answered by Nico http://bradhedlund.com/2010/12/31/cisco-ucs-criticism-and-fud-answered/comment-page-1/#comment-9278 Nico Wed, 16 May 2012 06:59:43 +0000 http://bradhedlund.com/?p=2529#comment-9278 some of this is out of date. Palo is not only already released but vendors intel, emulex, qlogic and cisco all have a version of DCE/FCoE cards. Cisco does follow the standards if you have a chance take a look at http://www.t11.org/fcoe Cisco assisted in co-authoring many of the 10 gig ethernet standards. as a matter of fact, Cisco came out with it before everyone else. Brocade bought McData and Foundry to maintain its competitive edge. Juniper followed in suit not long after Brocade did. Much of this is easily found on the internet among many of the news sources on technology. theStork, yahoo, MSNBC etc... definately not telling you anything you don't already know. some of this is out of date. Palo is not only already released but vendors intel, emulex, qlogic and cisco all have a version of DCE/FCoE cards. Cisco does follow the standards if you have a chance take a look at http://www.t11.org/fcoe Cisco assisted in co-authoring many of the 10 gig ethernet standards. as a matter of fact, Cisco came out with it before everyone else. Brocade bought McData and Foundry to maintain its competitive edge. Juniper followed in suit not long after Brocade did. Much of this is easily found on the internet among many of the news sources on technology. theStork, yahoo, MSNBC etc… definately not telling you anything you don’t already know.

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Brad Hedlund http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9277 Brad Hedlund Sat, 12 May 2012 01:03:28 +0000 http://bradhedlund.com/?p=3771#comment-9277 Mark, If you have a chip that has N front panel ports, and N fabric ports -- you can pin Front1 to Fabric1. In the fabric chips you can apply similar logic. No hashing collisions, and no predictions required. Mark,
If you have a chip that has N front panel ports, and N fabric ports — you can pin Front1 to Fabric1. In the fabric chips you can apply similar logic. No hashing collisions, and no predictions required.

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Mark Berly (@markberly) http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9276 Mark Berly (@markberly) Sat, 12 May 2012 00:16:22 +0000 http://bradhedlund.com/?p=3771#comment-9276 Unless you have a predictive hash then there will be situations where you have multiple flows hashing to a link which exceeds its capacity. Once you get into this condition then you can change the hash and redistribute the flows, this is after you are dropping packets and no guarantee that the traffic patterns will not change exposing the issue again. WIthout the ability to predict the flows ahead of time you will see drops due to this, no different than we see on port-channels. Unless you have a predictive hash then there will be situations where you have multiple flows hashing to a link which exceeds its capacity. Once you get into this condition then you can change the hash and redistribute the flows, this is after you are dropping packets and no guarantee that the traffic patterns will not change exposing the issue again. WIthout the ability to predict the flows ahead of time you will see drops due to this, no different than we see on port-channels.

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Brad Hedlund http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9275 Brad Hedlund Fri, 11 May 2012 21:30:59 +0000 http://bradhedlund.com/?p=3771#comment-9275 Mark, Modern chips in fixed switches today mitigate HOLB. These chips also provide multiple hashing options. Where you have a fixed switch using a multi-chip architecture, the switch designer just needs to implement the appropriate hashing technique for inter-chip flows. Mark,
Modern chips in fixed switches today mitigate HOLB. These chips also provide multiple hashing options. Where you have a fixed switch using a multi-chip architecture, the switch designer just needs to implement the appropriate hashing technique for inter-chip flows.

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Mark Berly (@markberly) http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9273 Mark Berly (@markberly) Fri, 11 May 2012 17:24:48 +0000 http://bradhedlund.com/?p=3771#comment-9273 While we are discussing differences between fixed and modular we need to look at the fabric architecture and how it handles traffic flows. In general multi-chip Clos based designs can run into trouble when we see multiple flows hashing to the same internal link, while this can be mitigated it is an issue. A VoQ fabric design, which most modular switches have today, helps ensure fairness and mitigates HOLB issues. As stated earlier there are many important factors that need to be considered when designing a network, power and space being two, but there are many others.... While we are discussing differences between fixed and modular we need to look at the fabric architecture and how it handles traffic flows. In general multi-chip Clos based designs can run into trouble when we see multiple flows hashing to the same internal link, while this can be mitigated it is an issue. A VoQ fabric design, which most modular switches have today, helps ensure fairness and mitigates HOLB issues. As stated earlier there are many important factors that need to be considered when designing a network, power and space being two, but there are many others….

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Mark Berly (@markberly) http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9272 Mark Berly (@markberly) Fri, 11 May 2012 17:18:38 +0000 http://bradhedlund.com/?p=3771#comment-9272 When TRILL is supported in a non-proprietary way by the majority of vendors then I will consider it ;-) When TRILL is supported in a non-proprietary way by the majority of vendors then I will consider it ;-)

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Derek Dolan http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9271 Derek Dolan Fri, 11 May 2012 17:13:28 +0000 http://bradhedlund.com/?p=3771#comment-9271 Can we please forget about TRILL? :) It's just spanning tree for bigger, faster networks. Not remotely a fundamental change that fixes a real issue... just a band-aid, IMO. I much prefer the idea of killing those sort of protocols altogether in favor of something more intelligent in the SDN arena (per your post on dodging open protocols). Can we please forget about TRILL? :) It’s just spanning tree for bigger, faster networks. Not remotely a fundamental change that fixes a real issue… just a band-aid, IMO.

I much prefer the idea of killing those sort of protocols altogether in favor of something more intelligent in the SDN arena (per your post on dodging open protocols).

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Pablo Carlier http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9270 Pablo Carlier Fri, 11 May 2012 16:41:57 +0000 http://bradhedlund.com/?p=3771#comment-9270 One could argue that ISSU reduces the impact of downtime of one large box. One could also argue that in supporting these kind of redundancy mechanisms you slow feature adoption and development speed, and that you require more complex and expensive hardware with each extra bit of internal redundancy you throw into the mix. What if, for your aggregation layer (where port density matters big time), you moved from two behemoth highly redundant (99,9% uptime) switches with 480 ports each, to a "spine" of ten simple switches of 48 ports each, with limited redundancy (98% uptime). The likelihood of losing half of your bandwidth is far greater with the behemoths than with the simple spines. You just need the right protocols to design that setup. The bigger challenges, IMHO, in moving to that scenario for massive scale, are two: - Management overhead: managing 5x as many switches is not so funny :) - Expandability: fixed switches force to modify the topology to grow, modular switches allow to insert more cards leaving the network diagram untouched. I see modern protocols making this a non-issue, but for the moment, building a old Ethernet three-box distribution layer is a pain in the butt. Just my 2c here. Keep it up, Brad, you are well missed around here at Cisco. ;) One could argue that ISSU reduces the impact of downtime of one large box. One could also argue that in supporting these kind of redundancy mechanisms you slow feature adoption and development speed, and that you require more complex and expensive hardware with each extra bit of internal redundancy you throw into the mix.

What if, for your aggregation layer (where port density matters big time), you moved from two behemoth highly redundant (99,9% uptime) switches with 480 ports each, to a “spine” of ten simple switches of 48 ports each, with limited redundancy (98% uptime). The likelihood of losing half of your bandwidth is far greater with the behemoths than with the simple spines. You just need the right protocols to design that setup.

The bigger challenges, IMHO, in moving to that scenario for massive scale, are two:

- Management overhead: managing 5x as many switches is not so funny :)
- Expandability: fixed switches force to modify the topology to grow, modular switches allow to insert more cards leaving the network diagram untouched. I see modern protocols making this a non-issue, but for the moment, building a old Ethernet three-box distribution layer is a pain in the butt.

Just my 2c here. Keep it up, Brad, you are well missed around here at Cisco. ;)

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by A network that Doesn’t Suck for cloud and Big Data: Interop 2012 session teaser http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9269 A network that Doesn’t Suck for cloud and Big Data: Interop 2012 session teaser Fri, 11 May 2012 12:19:54 +0000 http://bradhedlund.com/?p=3771#comment-9269 [...] time to re-think which platforms provide the best overall efficiency.  It’s a fact that fixed switches continue to outpace chassis switches in line-rate density and power efficiency.  Space and power, two precious and finite [...] [...] time to re-think which platforms provide the best overall efficiency.  It’s a fact that fixed switches continue to outpace chassis switches in line-rate density and power efficiency.  Space and power, two precious and finite [...]

]]> Comment on Comparing efficiencies of Fixed vs Chassis switches by Brad Hedlund http://bradhedlund.com/2012/05/10/comparing-efficiencies-of-fixed-vs-chassis-switches/comment-page-1/#comment-9268 Brad Hedlund Fri, 11 May 2012 12:14:33 +0000 http://bradhedlund.com/?p=3771#comment-9268 Don't forget about TRILL -- which will provide good old physical Layer 2 between racks in a scale-out fabric of fixed switches. Don’t forget about TRILL — which will provide good old physical Layer 2 between racks in a scale-out fabric of fixed switches.

]]>