KATARA Entry-Level Stackable Switch

Download Report

Transcript KATARA Entry-Level Stackable Switch

BROCADE ACCREDITED CAMPUS NETWORKING SPECIALIST STUDY NOTES

HyperEdge: “Virtual IP”

Simplified Management of Entire Campus Access Layer

IP: 10.1.1.110

VIP: 10.1.1.10

Floor 3

IP: 10.1.1.200

Floor 2

IP: 10.1.1.210

 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

Floor 1

HyperEdge

Mix and Match Low Cost and Premium Switches

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

Stacking

Feature Flex-link ports Number of units in a stack POD Licensing ICX 6450 Four 10G available.

Default stacking ports are 1 and 3 Up to 8 units ICX 6430 Four 1G ports Default stacking ports are 1 and 3 Up to 4 units Required to use ports 2 and 4 in 10G mode for stacking Not required © 2012 Brocade Communications Systems, Inc. 4

MCT L2 Features – MAC management

• 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

• • • • • • • 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

• 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 7 © 2012 Brocade Communications Systems, Inc.

Typical Deployment In Core Network

• 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 8 © 2012 Brocade Communications Systems, Inc.

Supportsave

•

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.