me=8.052 ms 64 bytes from 10.10.10.2: icmp_seq=2 ttl=254 time=8.078 ms 64 bytes from 10.10.10.2: icmp_seq=3 ttl=254 time=8.168 ms 64 bytes from 10.10.10.2: icmp_seq=4 ttl=254 time=8.178 ms Chapter 18: Cisco Nexus The downside is that it makes the command prompt pretty ugly, but that's the price we pay for being lazy typists. To change it back to the normal state, use the routing- context vrf default command: NX-5K-1%management# routing-context vrf default NX-5K-1# VRFs can be very useful for accomplishing things like multitenancy in data centers. The ability to have 10 customers on the same switch, all with the same 10.10.10.0/24 ad- dress space, is a pretty nice benefit. Virtual Device Contexts The Nexus 7000s are capable of being split into multiple logical switches. If you're at all like me, you no doubt got very excited at the possibilities of running a pile of virtual switches within a single chassis. Naturally, I assumed that VDCs would be like firewall contexts in the ASA and FWSMs, where you can have up to 50 contexts. Naturally, I was wrong. Only the 7000 series of Nexus switches supports VDCs at this time and, as of this writing, these powerful switches only support four VDCs. I thought that was an almost pointless number of contexts, SO I asked some people in the know at Cisco why the seemingly silly limitation. The reply I got was that they wanted to make sure each context could have the full power and capabilities of a Nexus switch. The argument was that if they allowed 50 contexts-each supporting BGP, OSPF, EIGRP, tens of thousands of routes, and all the myriad possibilities a Nexus switch could include- the performance within the contexts would suffer. My argument would be to allow more contexts, provided certain features were disabled-just like on the ASAs. Perhaps this option will be available in the future, but as of this writing, we're stuck with a maximum of four contexts. For our lab, I've taken two Nexus 7000s, built two VDCs within each, and intercon- nected them in a variety of ways. The t