On 26-May-13, at 8:13 AM, JP Velders <[email protected]> wrote: > However, a dual-homed FEX does _not_ allow for LAGs downstream (to > dual home a server in active/active mode), at least on the 1st gen > FEXes we have, and that stupidity (together with all the STP > limitations) has steered me away from N2/5K for real datacenters.
enhanced vpc is supported as of 5.1(3)n1(1) on n5k. this allows for multihomed fex as well as a vpc down to the actual host. its supported across all n2k platforms. http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/layer2/513_n1_1/b_Cisco_n5k_layer2_config_gd_rel_513_N1_1_chapter_01010.html > Do make sure to look at any vPC setup with an almost pessimistic view > to work out all the failure scenarios and design accordingly. as long as you plan for the major cases of vpc-link failure (peer-link, peer-keepalive, and keepalive followed by peer-link) and understand the traffic impact (if any), you're in good shape. from there -- as long as you understand the limitations of the topology and ensure your code supports it (things like single-homed fex with single-homed or "network fault tolerant" teams with 'vpc orphan-port suspend') you're golden. > Also remember that in a dual-homed FEX setup you need to duplicate > everything on both N5K's, and inconsistencies can be impacting. config-synch is your friend here. it provides a knob to duplicate certain configs (namely vpc related bits) across n5k chassis to reduce the number of touchpoints for the access-layer configuration. its pretty handy at times, though its worth playing with in the lab to understand how the pieces fit together, how to troubleshoot it, and how to remove/add config snippets in case something goes pear shaped. while i've seen may people use it, i'm still used to having to duplicate configs across chassis and thats how i've stuck with it. i don't do much in terms of "operations" though. in terms of the inconsistencies, each n2k access-port config is given a "vpc number" (when you dual-home the n2k). as such, its possible to grep the normal vpc inconsistency commands to find an issue. q. -- quinn snyder [email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
