Hi gg,

Without the two features you referenced, a failover from the master CSS to the backup would only occur if the master CSS fails.  These two features enhance the redundancy by triggering a failover if the master CSS cannot reach one or more of it uplink devices (such as a gateway), or if one or more of its physical ports loses its link status.

For the multiple redundant uplinks, you simply configure a service of "type redundancy-up".  You can configure one of these special services for up to 512 critical devices, though most customers would only use one or two.  This is a special type of service is that you would not add this service to a content rule.  Example below shows how to trigger a failover if the Master CSS cannot ping either GATEWAY_01 or GATEWAY_02.:

service GATEWAY_01

  type redundancy-up
  ip address 10.15.0.1
  active

service GATEWAY_02

  type redundancy-up
  ip address 10.16.0.1
  active

The second feature you referred to is the CSS redundancy-phy command.  You would enable this command under any of the physical ports that you want to monitor on the CSS.  If any of the ports configured with this feature lose their link, then it will trigger a failover. In the example below, if either interface 2/1 or 2/2 loses link, it will trigger a failover to the backup CSS.

interface 2/1
  redundancy-phy
  bridge vlan 15 

interface 2/2
  redundancy-phy
  bridge vlan 16 

I hope this helps you understand the features more clearly.  For more details, please refer back to the documentation.

Thank you,

Sean