BROCADE ACCREDITED CAMPUS NETWORKING SPECIALIST STUDY NOTES March 2012 © 2012 Brocade Communications Systems, Inc. 1

 Dramatically lowers administrative costs and time  Extends and automates single IP management domain from access to core  Reduces human error and improves availability  Automatic discovery and deployment HyperEdge: “Virtual IP” Simplified Management of Entire Campus Access Layer Floor 1 Floor 3 IP: Floor 2 IP: IP: VIP: © 2012 Brocade Communications Systems, Inc 2

HyperEdge Mix and Match Low Cost and Premium Switches L2 Basic L3 Advanced L3 GRE IPv6 VRF Future services  Excellent investment protection— no fork-lift upgrades  Extends stacking to heterogeneous members  Benefits: investment protection, flexibility, simplicity 3 © 2012 Brocade Communications Systems, Inc

Stacking FeatureICX 6450ICX 6430 Flex-link portsFour 10G available. Default stacking ports are 1 and 3 Four 1G ports Default stacking ports are 1 and 3 Number of units in a stack Up to 8 unitsUp to 4 units POD LicensingRequired to use ports 2 and 4 in 10G mode for stacking Not required © 2012 Brocade Communications Systems, Inc. 4

MCT L2 Features – MAC management © 2012 Brocade Communications Systems, Inc. 5 MAC learned on the cluster VLAN needs to be sync’d to the peer MAC learned on CCEP port Peer’s local CCEP is UP, peer would program to its local CCEP Peer’s local CCEP is down, peer would program to ICL. MAC learned on CEP port, peer would program to its ICL port. MDUP: Mac Database Update Protocol is the control plane protocol to sync MAC entries. MAC aging: Only the local MAC entries are aged on a node. The remote MAC entries will be aged based on explicit MDUP messages only.

MCT L2 Features – MAC management © 2012 Brocade Communications Systems, Inc. 6 Cluster Local MAC (CL): MACs that are learned on CEP ports locally. MACs are synchronized to the cluster peer and are subject to aging. Cluster Remote MAC (CR): MACs that are learned via MDUP message from the peer (CL on the peer) The MACs are always programmed on the ICL port and do not age. Cluster Client Local MAC (CCL): MACs that are learned on CCEP ports locally. The MACs are synchronized to the cluster peer and are subject to aging. Cluster Client Remote MAC (CCR): MACs that are learned via MDUP message from the peer (CCL on the peer) The MACs are always programmed on the corresponding CCEP port and do not age. Cluster Multi-Destination Local MAC (CML): static MAC  static N MAC Static MAC entry configured on MCT VLAN locally. Any static MAC configured on MCT VLAN will have ICL added by default so it will automatically become Multi-destination MAC entry. The port list of a CML entry has ICL port, all the client ports from the client list in the local and remote (if exists) configuration and all locally configured CEP ports. Cluster Multi-Destination Remote MAC (CMR): Static MAC entry configured on MCT VLAN at peer side and there is no local configuration for this MAC entry. The port list of a CMR entry has ICL port, all the client ports from the client list in the remote configuration. Once there is local configuration for the same entry, the CMR would be converted to CML.

Typical Deployment At Edge Network © 2012 Brocade Communications Systems, Inc. 7 VRRP/VRRP-E on MCT cluster devices Virtual IP as the default gateway on the hosts Configure same routes on MCT cluster devices as dynamic routing is not supported on the VEs of Cluster VLAN Use VRRP-E2 SPF to get routing load- balancing on VRRP nodes MCT management IP only for MCT management. Routing (static/dynamic/policy-based) not allowed Can’t use this IP as tunnel source IP features not required for MCT management not supported like UC/MC routing, ip follow, proxy-arp, redirect, VRRP and VRRP-E IPv6 not supported on VEs of session & cluster VLANs

Typical Deployment In Core Network © 2012 Brocade Communications Systems, Inc. 8 Cascaded MCT deployment Each MCT cluster device acts as MCT client for other cluster VRRP/VRRP-E can have multiple backups Dynamic routing not supported over VEs of cluster VLAN. Static/policy based routes for reachability

Supportsave © 2012 Brocade Communications Systems, Inc. 9 supportsave feature Collects detailed debug information from standalone and stack The log files are TFTP’d to an external server Details collected through show tech also part of the supportsave logs At a given time only one supportsave can be executed supportsave show shows the supportsave status. This needs to be invoked from another telnet window. In a stacking environment supportsave run from the master node will collect logs from all the nodes of the stack.