1 / 40

CIS 187 Multilayer Switched Networks CCNP version 7 Rick Graziani Spring 2016

Learn about high availability components, network resiliency, and optimal redundancy for industry-standard switched networks. Explore the benefits and verification methods of StackWise and VSS technologies. Discover how to provide alternate paths and avoid over-redundancy for a more efficient and stable network infrastructure. Delve into logical switching architectures and virtualization solutions to enhance performance and reliability in multi-layer switched networks.

ceads
Download Presentation

CIS 187 Multilayer Switched Networks CCNP version 7 Rick Graziani Spring 2016

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CIS 187 Multilayer Switched NetworksCCNP version 7Rick GrazianiSpring 2016 Ch. 9 High Availability

  2. Chapter 9 High Availability • The Need for Logical Switching Architectures 394 • What Is StackWise? 395 • StackWise Benefits 396 • Verifying StackWise 396 • What Is VSS? 397 • VSS Benefits 398 • Verifying VSS 399 • Redundant Switch Supervisors 401 • Supervisor Redundancy Modes 402 • Stateful Switchover 403 • Nonstop Forwarding 404

  3. The Need for Logical Switching Architectures • The Need for Logical Switching Architectures 394 • What Is StackWise? 395 • StackWise Benefits 396 • Verifying StackWise 396 • What Is VSS? 397 • VSS Benefits 398 • Verifying VSS 399 • Redundant Switch Supervisors 401 • Supervisor Redundancy Modes 402 • Stateful Switchover 403 • Nonstop Forwarding 404

  4. High Availability Components • Network resiliency • Built with device and link redundancy. • System-level resiliency • Redundant components (power supplies, fans, supervisor engines) • Duplicate devices available to replace failed components. • Network monitoring • Can provide instant notification of network failure.

  5. Network Resiliency • Built with device and link redundancy. • Employs fast convergence. • Relies on monitoring with NTP, SNMP, Syslog, and IP SLA.

  6. Network Resiliency: Failover Times • The overall failover time is the combination of convergence at Layer 2, Layer 3, and Layer 4 components.

  7. Network Resiliency: Failover Times • Network components have different recovery times: • Tuned routing protocols failover in less than 1 second. • RSTP converges in about 1 second. • EtherChannel can failover in approximately 1 second. • HSRP timers are 3 seconds for hello and 10 seconds for hold time. • TCP/IP stacks in Windows Server and clients have up to a 9-second tolerance.

  8. Network Resiliency: Optimal Redundancy • Optimal redundancy is important for high availability. • Avoid: • Too much redundancy! • Single point of failure. • If applicable, use: • Cisco Nonstop Forwarding (NSF) • Stateful Switchover (SSO).

  9. Network Resiliency: Provide Alternate Paths • Use redundant distribution-to-core links in case a core switch fails. • Configure Distribution switches to support summarization of routing information to the core.

  10. Network Resiliency: Too Much Redundancy • Where should the root switch be placed? • With this design, it is not easy to determine where the root switch is located. • What links should be in a blocking state? • It is hard to determine how many ports will be in a blocking state. • What are the implications of STP and RSTP convergence? • The network convergence is definitely not deterministic. • When something goes wrong, how do you find the source of the problem? • The design is much harder to troubleshoot.

  11. Need for Logical Switching Architectures Consider a topology where two (could be more) access layer switches and each one has redundant connections to distribution layer switches. Hosts connected to ASW1 can only communicate with hosts in the same VLAN connected to ASW2 via one of the distribution switches. To satisfy the redundancy requirements, every access switch needs its own uplink to the distribution switches, but one of the uplinks will be blocked by STP to prevent a loop, thus cutting the bandwidth in half. • To overcome some of these limitations, Cisco proposes the following virtualization solutions. • StackWise: Focused on the access layer module • VSS: Focused on the aggregation layer module The Layer 2 switches are commonly mounted in the same rack in a wiring closet! Topology introduces overhead in terms of management, resiliency, and performance. Every switch demands its own configuration and management, even though you can clearly identify only two different roles: access and distribution. Configuring the PVSTP will unequally utilize both uplinks, but with additional management overhead.

  12. StackWise Access Switches • Cisco StackWise technology gives us a way to collectively utilize the capabilities of a stack of switches. • Configuration and routing information is shared by every switch in the stack, creating a single switching unit. • Switches can be added to and deleted from a working stack without affecting the performance

  13. StackWise Access Switches • The switches are united into a single logical unit, using special stack interconnect cables that create a bidirectional closed-loop path. • This bidirectional path acts as a switch fabric for all the connected switches. • The stack is managed as a single unit by a master switch, which is elected from one of the stack member switches. • Up to nine separate switches can be joined. Each stack of switches has a single IP address and is managed as a single object.

  14. Verifying StackWise S1# show switch Switch/Stack Mac Address: 0013.6075.7280 Switch# Role Mac Address Priority H/W Version Current State *1 Master 0013.6075.7280 1 0 Ready 2 Member 0013.60e1.1800 1 0 Ready S1# S1# show switch stack-ports Switch # Port 1 Port 2 --------- ------ ------ 1 Ok Ok 2 Ok Ok • Use the show switch command to verify the switch stack. Each stack switch uses two ports to connect to other stack switches to form a bidirectional ring.

  15. https://www.youtube.com/watch?v=KCLPwqXlUCo Fast Forward to 2:54

  16. What Is VSS? • The Need for Logical Switching Architectures 394 • What Is StackWise? 395 • StackWise Benefits 396 • Verifying StackWise 396 • What Is VSS? 397 • VSS Benefits 398 • Verifying VSS 399 • Redundant Switch Supervisors 401 • Supervisor Redundancy Modes 402 • Stateful Switchover 403 • Nonstop Forwarding 404

  17. Virtual Switching System (VSS) • VSS is a network system virtualization technology that combines a pair of Catalyst 4500 or 6500 series switches into one virtual switch. • Increases the operational efficiency, boosting nonstop communications, and scaling the system bandwidth capacity. • VSS simplifies network configuration and operation by reducing the number of Layer 3 routing neighbors and by providing a loop-free Layer 2 topology.

  18. VSS • VSS is made up of two Catalyst switches and a virtual switch link (VSL) between them. • VSL can use up to eight 10 Gigabit Ethernet connections bundled into an EtherChannel. • VSL carries the control plane communication and regular data traffic between the two VSS members.

  19. Verifying VSS • To verify the status of VSS configuration, use the following show switch virtual commands with various parameters: • show switch virtual • show switch virtual link • show switch virtual role • show switch virtual link port-channel

  20. https://www.youtube.com/watch?v=RVwnXMVeKNs

  21. Redundant Switch Supervisors • The Need for Logical Switching Architectures 394 • What Is StackWise? 395 • StackWise Benefits 396 • Verifying StackWise 396 • What Is VSS? 397 • VSS Benefits 398 • Verifying VSS 399 • Redundant Switch Supervisors 401 • Supervisor Redundancy Modes 402 • Stateful Switchover 403 • Nonstop Forwarding 404

  22. Single Point of Failure? • An edge device represents a single point of failure. • How are Catalyst 4500 and 6500 built to overcome this problem? • Using redundant: • Power supplies • Cooling Fans • Supervisor Engines

  23. The “Sup” • The Supervisor Engine is the most important component in Catalyst switches. • If it fails, the switch fails to forward traffic. • Therefore providing Sup redundancy is the most critical form of high availability. • The Catalyst 4500, 6500, and 6800 families of switches support three main types of sup engines: • Supervisor 2 • Supervisor 32 • Supervisor 720 • Two supervisor modules can be installed in a single chassis thereby removing a single point of failure. • The first supervisor module to successfully boot becomes the active supervisor for the chassis. • The other supervisor remains in a standby role, waiting for the active supervisor to fail. • When the active module fails, the standby module can proceed to initialize any remaining functions and take over the active role.

  24. Catalyst 6800 Series Supervisor Engine

  25. Redundancy Features on Catalyst 4500/6500 • Redundant supervisor modules can be configured in several modes. • Note: • RPR and RPR+ are no longer the recommended option and SSO (with NSF) provides better convergence time.

  26. Route Processor Redundancy (RPR) • RPR enables a quick switchover between an active and standby Route Switch Processor (RSP) if the active RSP experiences a fatal error. • First form of high availability feature in Cisco IOS Software starting with Cisco IOS Software Release 12.1(13)E. • When configured, the standby RSP loads a Cisco IOS image on bootup and initializes itself in standby mode. • In the event of a fatal error on the active RSP, the system switches to the standby RSP, which reinitializes itself as the active RSP, reloads all of the line cards, and restarts the system. • Any of the following events triggers an active to standby switchover: • A manual switchover from the CLI. • Removal of the active Supervisor Engine. • Route Processor (RP) or Switch Processor (SP) crash on the active Supervisor Engine.

  27. RPR+ • The RPR+ feature is an enhancement of the RPR feature. • RPR+ keeps the virtual IPs (VIPs) from being reset and reloaded when a switchover occurs between the active and standby RSPs. • Because VIPs are not reset and microcode is not reloaded on the VIPs, and the time needed to parse the configuration is eliminated, switchover time is reduced to 30 seconds.

  28. RPR+ Additional Benefits • Reduced switchover time: • Depending on the configuration, the switchover time is 30 to 60 seconds. • No reloading of installed modules: • Both startup and running configuration stay continually synchronized between the active to the redundant Supervisor Engines. • Synchronization of Online Insertion and Removal (OIR) events between the active and standby: • Modules in the online state remain online and modules in the down state remain in the down state after a switchover.

  29. Configuring and Verifying RPR+ Redundancy • Use the redundancy command to start configuring redundancy modes. • Use the mode rpr-plus command under redundancy configuration submode to configure RPR+: S1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)# redundancy Switch(config-red)# mode rpr-plus Switch(config-red)# end Switch# show redundancy states my state = 13 –ACTIVE peer state = 1 -DISABLED Mode = Simplex Unit = Primary Unit ID = 1 Redundancy Mode (Operational) = Route Processor Redundancy Plus Redundancy Mode (Configured) = Route Processor Redundancy Plus Split Mode = Disabled Manual Swact = Disabled Reason: Simplex mode Communications = Down Reason: Simplex mode <output omitted>

  30. Stateful Switchover (SSO) • Provides minimal Layer 2 traffic disruption during Supervisor switchover. • SSO establishes one of the supervisor engines as active while the other supervisor engine is designated as standby. • SSO then synchronizes information between them. • Standby Supervisor in SSO mode keeps in sync with active Supervisor for all changes in hardware and software states for features supported via SSO. • SSO switchover preserves FIB and adjacency entries and can forward Layer 3 traffic after a switchover. • Configuration information and data structures are synchronized from the active to the redundant supervisor engine at startup and whenever changes to the active supervisor engine configuration occur.

  31. Protocols and Features Supported by SSO • 802.3x (Flow Control) • 802.3ad (LACP) and PAgP • 802.1X (Authentication) and Port security • 802.3af (Inline power) • VTP • Dynamic ARP Inspection/DHCP snooping/IP source guard • IGMP snooping (versions 1 and 2) • DTP (802.1Q and ISL) • MST/PVST+/Rapid-PVST • PortFast / UplinkFast / BackboneFast /BPDU Guard and filtering • Voice VLAN • Unicast MAC filtering • ACL (VLAN ACLs, Port ACLs, Router ACLs) • QOS (DBL) • Multicast storm control/broadcast storm control

  32. Configuring and Verifying SSO • Enter the redundancy command to enter redundancy modes. • Use the mode sso configuration mode command to configure RPR+. S1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. S1(config)# redundancy S1(config-red)# mode sso Changing to sso mode will reset the standby. Do you want to continue? [confirm] S1(config-red)# end S1# show redundancy states my state = 13 –ACTIVE peer state = 8 -STANDBY HOT Mode = Duplex Unit = Primary Unit ID = 2 Redundancy Mode (Operational) = Stateful Switchover Redundancy Mode (Configured) = Stateful Switchover Split Mode = Disabled Manual Swact = Enabled Communications = Up <output omitted>

  33. NSF (Non-Stop Forwarding) with SSO • SSO with NSF minimizes the time that the L3 network is unavailable following Supervisor switchover. • It continues to forward IP packets using CEF entries built from the old active Supervisor providing zero or near zero packet loss. • Prevents route flapping. • Supports BGP, EIGRP, OSPF, and IS-IS. • Routing protocol neighbor relationships are maintained during Supervisor failover. • Cisco NSF provides: • Improved network availability: NSF continues forwarding network traffic and application state information so that user traffic is not interrupted after a supervisor switchover. • Overall network stability: Network stability is improved by maintaining routing protocol neighbor relationships during supervisor failover.

  34. Configuring and Verifying NSF with SSO • NSF is an additional configuration option for configuring SSO. • Use the nsf command to configure NSF for OSPF, EIGRP, and IS-IS. • Use the bgp graceful-restart command to configure BGP for NSF support. Switch# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)# router ospf 200 Switch(config-router)# nsf Switch(config-router)# exit Switch(config)# router bgp 100 Switch(config-router)# bgpgraceful-restart Switch(config-router)# end Switch#

  35. Configuring and Verifying NSF with SSO • Verify NSF in OSPF. Switch# show ip ospf Routing Process “ospf 200” with ID 192.168.20.1 and Domain ID 0.0.0.1 Supports only single TOS(TOS0) routes Supports opaque LSA SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs Number of external LSA 0. Checksum Sum 0x0 Number of opaque AS LSA 0. Checksum Sum 0x0 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa External flood list length 0 Non-Stop Forwarding enabled, last NSF restart 00:02:36 ago (took 34 secs) Area BACKBONE(0) Number of interfaces in this area is 1 (0 loopback) Area has no authentication SPF algorithm executed 3 times Switch#

  36. Configuring and Verifying NSF with SSO • Verify NSF in OSPF. Switch# show ip bgp neighbors 192.168.200.1 BGP neighbor is 192.168.200.1, remote AS 200, external link BGP version 4, remote router ID 192.168.200.1 BGP state = Established, up for 00:01:23 Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh:advertised and received(new) Address family IPv4 Unicast:advertised and received Address family IPv4 Multicast:advertised and received Graceful Restart Capability:advertised and received Remote Restart timer is 120 seconds Address families preserved by peer: IPv4 Unicast, IPv4 Multicast Received 1539 messages, 0 notifications, 0 in queue Sent 100 messages, 0 notifications, 0 in queue Default minimum time between advertisement runs is 30 seconds

  37. CIS 187 Multilayer Switched NetworksCCNP version 7Rick GrazianiSpring 2016 Ch. 9 High Availability

More Related