02.10.2013 Views

FTOS Configuration Guide for the C-Series - Force10 Networks

FTOS Configuration Guide for the C-Series - Force10 Networks

FTOS Configuration Guide for the C-Series - Force10 Networks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

RPM Failover<br />

When a system with two RPMs boots or reboots, <strong>the</strong> system brings up <strong>the</strong> primary RPM first. By default<br />

<strong>the</strong> RPM in slot 0 becomes <strong>the</strong> primary RPM. To change this, use <strong>the</strong> command redundancy primary.<br />

<strong>FTOS</strong> copies all data from RPM0 to RPM1. Once <strong>the</strong> system is stable only changes on <strong>the</strong> primary RPM<br />

are copied to <strong>the</strong> secondary RPM. You can per<strong>for</strong>m a one-time synchronization of data by issuing <strong>the</strong><br />

command redundancy synchronize.<br />

Given <strong>the</strong> default conditons, when a failover occurs, RPM 1 becomes <strong>the</strong> primary. RPM 0 reboots and<br />

becomes <strong>the</strong> standby with its switch fabric available <strong>for</strong> routing.<br />

By default, when a secondary RPM with a logical SFM is inserted or removed, <strong>the</strong> system must add or<br />

remove <strong>the</strong> backplane links to <strong>the</strong> switch fabric trunk. Any time such links are changed, traffic is disrupted.<br />

Use <strong>the</strong> command redundancy sfm standby to avoid any traffic disruption when <strong>the</strong> secondary RPM is<br />

inserted. When this command is executed, <strong>the</strong> logical SFM on <strong>the</strong> standby RPM is immediately taken<br />

offline, and <strong>the</strong> SFM state set as standby. Use <strong>the</strong> command show sfm all to see SFM status in<strong>for</strong>mation.<br />

Hitless Feature Definition<br />

Hitless is a protocol-based system behavior that makes an RPM failover on <strong>the</strong> local system transparent to<br />

remote systems. Hitless behavior is defined in <strong>the</strong> context of an RPM failover only and does not include<br />

line card, SFM, and power module failures. Causes of an RPM failover include software exception, <strong>for</strong>ced<br />

failover via <strong>the</strong> CLI, and manual removal of <strong>the</strong> primary RPM.<br />

For hitless protocols, <strong>the</strong> system synchronizes protocol in<strong>for</strong>mation on <strong>the</strong> standby and primary RPMs<br />

such that, <strong>the</strong> event of an RPM failover, <strong>the</strong>re is no need to notify remote systems of a local state change.<br />

Hitless protocols are compatible with o<strong>the</strong>r hitless and graceful restart protocols. For example, if hitless<br />

OSPF is configured over hitless LACP LAGs, both features work seamlessly to deliver a hitless<br />

OSPF-LACP result. However, if hitless behavior involves multiple protocols, all must be hitless in order to<br />

receive a hitless end result. For example, if OSPF is hitless but BFD is not, OSPF operates hitlessly and<br />

BFD flaps upon an RPM failover.<br />

<strong>FTOS</strong> <strong>Configuration</strong> <strong>Guide</strong>, version 7.7.1.0 383

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!