Understanding equal-cost multipathing in Brocade’s VCS Fabric is a bit tricky, not because it would be a complex topic, but because it’s a bit counter-intuitive (while still being perfectly logical once you understand it). Michael Schipp tried to explain how it works, Joel Knight went even deeper, and I’ll try to draw a parallel with the routed networks because most of us understand them better than the brave new fabric worlds.
A while ago I was writing about the behavior of Microsoft’s Network Load Balancing, the problems it’s causing and how Microsoft tried to hack around them using multicast MAC addresses as the hardware address of sender in ARP replies (which is illegal). A few days ago one of my readers asked me whether I know which RFC prohibits the use of multicast MAC address in ARP replies.
A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address.
Problem solved – now I know the real reason we have to configure static ARP entries on Cisco routers and switches.
This topic has been on my to-write list for over a year and its working title was phrased as a question, but all the horror stories you’ve shared with me over the last year or so (some of them published in my blog) have persuaded me that there’s no question – it’s a fact.
If you think I’m rephrasing the same topic ad nauseam, you’re right, but every month or so I get an external trigger that pushes me back to the same discussion, this time an interesting comment thread on Massimo Re Ferre’s blog.
We knew Brocade has OpenFlow support in its devices for at least a year; now it’s official: OpenFlow is supported on its MLX-series routers. But wait, there’s more: that’s just the first step in Brocade’s long-term SDN strategy, according to their press release. Let’s take a deeper look at that strategy.
A while ago I wrote about uselessness of stateless NAT64 and got in nice discussion with Tore Anderson who wanted to use stateless NAT64 in reverse direction (stateless NAT46) to build an IPv6-only data center. Some background information first (to define the context of his thinking before we jump into the technical details):
Some of you have noticed that I’d changed the commenting system on my blog recently. Here’s the full story (with a question for you at the very end).
I was totally fed up with Blogger comments years ago and decided to look for an alternative. JS-Kit was a perfect solution and it even allowed me to import Blogger comments and synchronize new entries with Blogger (so I could turn it off at any time and retain my comments).
With IPv6 support added in Cisco IOS Release 12.2(2)T, the ip http server command simultaneously enables and disables both IP and IPv6 access to the HTTP server. However, an access list configured with the ip http access-class command will only be applied to IPv4 traffic. IPv6 traffic filtering is not supported.
Wait ... WHAT? I cannot control who can access the HTTP(S) server running in Cisco IOS over IPv6 (apart from kludges like ingress ACLs on all interfaces or CoPP), and this stupidity has been left unfixed for nine(9) years?. Are we really in 2012, less than a month away from World IPv6 Launch or have I been transported to 1990’s?
Google unveiled some details of its new internal network at Open Networking Summit in April and predictably the industry press and OpenFlow pundits exploded with the “this is the end of the networking as we know it” glee. Unfortunately I haven’t seen a single serious technical analysis of what it is they’re actually doing and how different their new network is from what we have today.
Brad Hedlund did an excellent analysis of fixed versus chassis-based switches in his Interop presentation and concluded that fixed switches offer higher port density and lower per-port power consumption than chassis-based ones. That’s true when comparing individual products, but let’s ask a different question: how much does it take to implement a 384-port non-blocking fabric (equivalent to Arista’s 7508 switch) with fixed switches?
I usually use the “Nicira is Skype of virtual networking” analogy when describing the differences between Nicira’s NVP and traditional VLAN-based implementations. Cade Metz liked it so much he used it in his What Is a Virtual Network? It’s Not What You Think It Is article, so I guess a blog post is long overdue.
Stephen Hauser sent me an interesting question after the Data Center fabric webinar I did with Abner Germanow from Juniper:
A common theme in your talks is that L2 does not scale. Do you mean that Transparent (Learning) Bridging does not scale due to its flooding? Or is there something else that does not scale?
As is oft the case, I’m not precise enough in my statements, so let’s fix that first:
Just prior to Networking Field Day, the merry band of geeks sat down with Chip Copper, Brocade’s Solutioneer (a job title almost as good as Packet Herder) to discuss the intricate details of VCS Fabric. The videos are well worth watching – the technical details are interesting, but above all, Chip is a fantastic storyteller.
NHRP-based interface state control is a fantastic feature that you can use for faster convergence of very large DMVPN networks (as explained in the DMVPN Designs webinar, you can also use it to solve some interesting backup scenarios). We tested it in a network with over 1000 spokes (using ASR1K as the hub router) using very short registration timeouts, and the CPU utilization of the NHRP process rarely exceeded a few percents.
Every data center network has a mixture of bridging (layer-2 or MAC-based forwarding, aka switching) and routing (layer-3 or IP-based forwarding); the exact mix, the size of L2 domains, and the position of L2/L3 boundary depend heavily on the workload ... and I would really like to understand what works for you in your data center, so please leave as much feedback as you can in the comments.