We started out looking at new Juniper switches after this article on the Register Juniper rolls out multi-product attack on Cisco
Somehow we got into discussion of Data Centre switches and then we started deep diving into Data Centre Ethernet and the Death of Spanning Tree. On the way we took a detour through why Catalyst C6500 aren’t so great but are a universal workhorse, and some of the limitations of the Nexus 7000 platform and spend some time musing on the vagaries of IOS and its differences on different hardware platforms.
We took a quick look at the IOS Naming Conventions on IOS in Version 15.0 after Ivan Pepelnjak posted some information. IOS Release Numbering at IOS Hints.
EtherealMind on Network Fabric:TRILL for Server and Network People. Welcome RBridges
Subscribe in iTunes
You can subscribe in iTunes by clicking on the logo here.
Media Player and MP3 Download
I am working on a RSS Feed for the MP3 version, hopefully this week.
You can download an MP3 Version FROM HERE.
You can subscribe to the Podcast RSS feed (M4A version)
I thought the issue with FCoE multi-hop has to do with the congestion control standard being delayed. QCN is the algorithm that seems to be in favor with the IEEE 802.1Qau committee at the moment to resolve this. I don’t believe the switches need to talk FCIP between themselves, but they do all need to support the DCB standards, including DCBX.
TRILL is TRansparant Interconnction of Lots of Links. While it does provide for redundancy, Redundant isn’t part of the title….
Regarding knowing all the hosts, in TRILL, only the RBridges that have end-hosts in a VLAN need to add those hosts into it’s forwarding tables. Transit RBridges only see the outer TRILL header MAC’s and never see the end-host MAC address. 39:30 in or so?
Per Section 2.5 of the TRILL protocol standard that’s been submitted to the IETF as a proposed standard: “RBridges enforce delivery of a native frame originating in a particular VLAN only to other links in the same VLAN”.
At the moment they are currently waiting for the Layer 2 IS-IS standard to be completed. They recently broke apart that group so the TRILL standard could move forward.
I believe it’s likely that TRILL products will be shipping by the end of the year btw, with the only issues being software (L2 IS-IS & VLAN mapping). And I’m not sure I want VLAN mapping yet. To easy to mistakenly join two networks you don’t want connected with a FW.
Thanks for the podcast.
BTW, if you want to scale a TRILL network, you need to look at using a Clos architecture. That’s why not having transit RBridges not learn end MAC addresses is important to scale. You still can’t reasonably put huge numbers of hosts in each VLAN because of the impact of all the broadcast traffic on end hosts.
You mentioned DC’s with 10-20K MAC addresses and routers that can handle “hundreds of thousands”. It’s not really that optimistic. This is the coming DC scale issue – If you want to consolidate layers and virtualize your environments onto a couple L3 routers at the edge you’re toast at any real scale with Cisco and most if not all other vendors.
Look to TRILL plus a mechanism like Etherproxy/Portland/VL2/Seattle to really solve that problem. Leaning towards VL2 myself…
Jeez…
Last sentence in second post should end with “without a firewall”.
The second sentence in my third post should read “Thatís why having transit RBridges not learn end MAC addresses is important to scale.”