Resiliency Nexus switches can be upgraded with no impact to packet flow under the proper conditions. Processes are run in separate protected-memory space. The control plane is separate from the data plane. All of these features and many others make the switch more resistant to failure. I've seen Nexus 7000s that were running at 100 percent CPU with no impact to the packet flowing through them. This is pos- sible because routing tables are processed by the CPU, which then translates them to forwarding tables that are downloaded to hardware. Unless the forwarding ta- bles change, the CPU is not involved in packet forwarding. Integration of L3 routing, L2 switching, and SAN switching Though the topic is not covered in this book, Nexus was designed from the ground up to incorporate storage networking including, but not limited to, FCoE. Support for multiprocessor and multithreaded CPUs Using multi-processor architectures allows you to take advantage of significantly increased processing power. Virtual Routing and Forwarding VRFs are separate and distinct routing processes within the same router. In a nutshell, a router can have multiple routing tables, each with its own set of routes and protocols. This is not a Nexus-specific feature. IOS version 15 supports VRFs as well. IOS version 15? I thought we were on 12.x. What happened to versions 13 and 14? Apparently, 13 is unlucky, as is 14 in some cultures, SO Cisco jumped from 12 to 15. We now return you to our regularly scheduled Nexus chapter. The Nexus 5000 comes with two VRFs by default: the default VRF and the management VRF. Here we assign a default route to the management VRF on a 5000. Notice that an IP address assigned to the management interface will reside in the management VRFs as well: vrf context management ip route 0.0.0.0/0 10.1.1.1 Nexus Design Features Be careful with VRFs, especially on the 5000s. The 5000s do not, as of this writing, really support routing to begin with (the recently released 5500s will, with an additional daughter card). Their curr