Configuring PRP

This document provides details about configuring Parallel Redundancy Protocol (PRP) on the Cisco Industrial Ethernet 4000 Series, Cisco Industrial Ethernet 4010 Series, and Cisco Industrial Ethernet 5000 Series switches.


Note

PRP is supported on multiple IE platforms, and PRP feature support may vary by platform. For details, refer to Feature History. Be sure to use the configuration guide for your IE platform.

Information About PRP

Parallel Redundancy Protocol (PRP) is defined in the International Standard IEC 62439-3. PRP is designed to provide hitless redundancy (zero recovery time after failures) in Ethernet networks.

To recover from network failures, redundancy can be provided by network elements connected in mesh or ring topologies using protocols like RSTP, REP, or MRP, where a network failure causes some reconfiguration in the network to allow traffic to flow again (typically by opening a blocked port). These schemes for redundancy can take between a few milliseconds to a few seconds for the network to recover and traffic to flow again.

PRP uses a different scheme, where the end nodes implement redundancy (instead of network elements) by connecting two network interfaces to two independent, disjointed, parallel networks (LAN-A and LAN-B). Each of these Dually Attached Nodes (DANs) then have redundant paths to all other DANs in the network.

The DAN sends two packets simultaneously through its two network interfaces to the destination node. A redundancy control trailer (RCT), which includes a sequence number, is added to each frame to help the destination node distinguish between duplicate packets. When the destination DAN receives the first packet successfully, it removes the RCT and consumes the packet. If the second packet arrives successfully, it is discarded. If a failure occurs in one of the paths, traffic continues to flow over the other path uninterrupted, and zero recovery time is required.

Non-redundant endpoints in the network that attach only to either LAN-A or LAN-B are known as Singly Attached Nodes (SANs).

A Redundancy Box (RedBox) is used when an end node that does not have two network ports and does not implement PRP needs to implement redundancy. Such an end node can connect to a RedBox, which provides connectivity to the two different networks on behalf of the device. Because a node behind a RedBox appears for other nodes like a DAN, it is called a Virtual DAN (VDAN). The RedBox itself is a DAN and acts as a proxy on behalf of its VDANs.

Figure 1. PRP Redundant Network

Role of the Switch

The IE 4000, IE 4010, and IE 5000 switches implement RedBox functionality using Gigabit Ethernet port connections to each of the two LANs.

PRP Channels

PRP channel or channel group is a logical interface that aggregates two Gigabit Ethernet interfaces (access, trunk, or routed) into a single link. In the channel group, the lower numbered Gigabit Ethernet member port is the primary port and connects to LAN_A. The higher numbered port is the secondary port and connects to LAN_B. The PRP channel remains up as long as at least one of these member ports remains up and sends traffic. When both member ports are down, the channel is down. The total number of supported PRP channel groups is 2 per switch, and the interfaces that can be utilized for each group on each switch series are fixed.

On the IE 4000:

  • PRP channel group 1 always uses Gi1/1 for LAN_A and Gi1/2 for LAN_B

  • PRP channel group 2 always uses Gi1/3 for LAN_A and Gi1/4 for LAN_B

On the IE 4010:

  • PRP channel group 1 always uses Gi1/25 for LAN_A and Gi1/26 for LAN_B

  • PRP channel group 2 always uses Gi1/27 for LAN_A and Gi1/28 for LAN_B

On the IE 5000:

  • PRP channel group 1 always uses Gi1/17 for LAN_A and Gi1/18 for LAN_B

  • PRP channel group 2 always uses Gi1/19 for LAN_A and Gi1/20 for LAN_B

Mixed Traffic and Supervisory Frames

Traffic egressing the RedBox PRP channel group can be mixed, that is, destined to either SANs (connected only on either LAN-A or LAN-B) or DANs. To avoid duplication of packets for SANs, the switch learns source MAC addresses from received Supervision frames for DAN entries and source MAC addresses from non-PRP (regular traffic) frames for SAN entries and maintains these addresses in the node table. When forwarding packets out the PRP channel to SAN MAC addresses, the switch looks up the entry and determines which LAN to send to rather than duplicating the packet.

A RedBox with VDANs needs to send supervisory frames on behalf of those VDANs. For traffic coming in on all other ports and going out PRP channel ports, the switch learns source MAC addresses, adds them to the VDAN table, and starts sending Supervisory frames for these addresses. Learned VDAN entries are subject to aging.

You can add static entries to the node and VDAN tables as described in Adding Static Entries to the Node and VDAN Tables. You can also display the node and VDAN tables and clear entries. See Verifying Configuration and Clearing All Node Table and VDAN Table Dynamic Entries.

PTP over PRP

Precision Time Protocol (PTP) can operate over Parallel Redundancy Protocol (PRP) on IE 4000, IE 4010, and IE 5000 switches. PRP provides high availability through redundancy for PTP. For a description of PTP, see Precision Time Protocol Software Configuration Guide for IE 4000, IE 4010, and IE 5000 Switches.

The PRP method of achieving redundancy by parallel transmission over two independent paths (see Information About PRP) does not work for PTP as it does for other traffic. The delay experienced by a frame is not the same in the two LANs, and some frames are modified in the transparent clocks (TCs) while transiting through the LAN. A Dually Attached Node (DAN) does not receive the same PTP message from both ports even when the source is the same. Specifically:

  • Sync/Follow_Up messages are modified by TCs to adjust the correction field.

  • Boundary Clocks (BCs) present in the LAN are not PRP-aware and would generate their own Announce and Sync frames with no Redundancy Control Trailer (RCT) appended.

  • Follow_Up frames are generated by every 2-step clock and carry no RCT.

  • TCs are not PRP-aware and not obliged to forward the RCT, which is a message part that comes after the payload.

Previously, PTP traffic was allowed only on LAN-A to avoid the issues with PTP and parallel transmission described above. However, if LAN-A went down, PTP synchronization was lost. To enable PTP to leverage the benefit of redundancy offered by the underlying PRP infrastructure, PTP packets over PRP networks are handled differently than other types of traffic. The implementation of the PTP over PRP feature is based on the PTP over PRP operation detailed in IEC 62439-3:2016, Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR). This approach overcomes the problems mentioned above by not appending an RCT to PTP packets and bypassing the PRP duplicate/discard logic for PTP packets.

PTP over PRP Packet Flow

The following figure illustrates the operation of PTP over PRP.

Figure 2. PTP over PRP Packet Flow

In the figure, VDAN 1 is the grandmaster clock (GM). Dually attached devices receive PTP synchronization information over both their PRP ports. The LAN-A port and LAN-B port use a different virtual clock that is synchronized to the GM. However, only one of the ports (referred to as SLAVE) is used to synchronize the local clock (VDAN 2 in the figure). While the LAN-A port is the SLAVE, the LAN-A port’s virtual clock is used to synchronize VDAN-2. The other PRP port, LAN-B, is referred to as PASSIVE_SLAVE. The LAN-B port’s virtual clock is still synchronized to the same GM, but is not used to synchronize VDAN 2.

If LAN-A goes down, the LAN-B port takes over as the SLAVE and is used to continue synchronizing the local clock on RedBox 2. VDAN 2 attached to RedBox 2 continues to receive PTP synchronization from RedBox 2 as before. Similarly, all DANs, VDANs and Redboxes shown in the figure continue to remain synchronized. Note that for SANs, redundancy is not available, and in this example, SAN 1 will lose synchronization if LAN-A goes down.

Due to the change, VDAN 2 may experience an instantaneous shift in its clock due to the offset between the LAN-A port’s virtual clock and the LAN-B port’s virtual clock. The magnitude of the shift should only be a few microseconds at the most, because both clocks are synchronized to the same GM. The shift also occurs when the LAN-A port comes back as SLAVE and the LAN-B port becomes PASSIVE_SLAVE.

Supported Location of GM

The GM can be located in a PTP over PRP topology as one of the following:

  • A Redbox connected to both LAN A and LAN B (for example, RedBox 1 in the diagram above).

  • A VDAN (for example, VDAN 1 in the diagram above).

  • A DAN (for example, the DAN in the diagram above).

The GM cannot be a SAN attached to LAN-A or LAN-B, because only the devices in LAN-A or LAN-B will be synchronized to the GM.

Configuration

PTP over PRP does not require configuration beyond how you would normally configure PTP and PRP separately, and there is no user interface added for this feature. The difference is that prior to the PTP over PRP feature, PTP worked over LAN_A only; now it works over both LANs. Before implementing PTP over PRP, refer to Guidelines and Limitations.

The high-level workflow to implement PTP over PRP in your network is as follows:

  1. Refer to PRP RedBox Types to determine the location of the PRP RedBox. Refer to Precision Time Protocol Software Configuration Guide for IE 4000, IE 4010, and IE 5000 Switches to determine PTP mode and profile.

  2. Configure PTP as described in Precision Time Protocol Software Configuration Guide for IE 4000, IE 4010, and IE 5000 Switches, following the procedure for the PTP profile determined in step 1 above.

  3. Configure PRP as described in Creating a PRP Channel and Group.

Supported PTP Profiles and Clock Modes

The following table summarizes PTP over PRP support for the various PTP profiles and clock modes. In unsupported PTP profile/clock mode combinations, PTP traffic flows over LAN-A only. LAN-A is the lower numbered interface. See PRP Channels for PRP interface numbers.

PTP Profile

Clock Mode

Supported?

PRP RedBox type as per IEC 62439-3
Delay Request-Response Default PTP profile BC Yes PRP RedBox as doubly attached BC (DABC) with E2E
E2E TC No PRP RedBox as doubly attached TC (DATC) with E2E
Power Profile BC Yes PRP RedBox as doubly attached BC (DABC) with P2P
P2P TC Yes PRP RedBox as doubly attached TC (DATC) with P2P
802.1AS Profile N/A No N/A

PRP RedBox Types

The switch plays the role of a RedBox in PRP networks. This section describes the types of PRP RedBoxes supported for PTP over PRP as defined in IEC 62439-3.

PRP RedBox as a Doubly Attached BC (DABC) with E2E

In the configuration shown below, two RedBoxes (for example, M and S) are configured as Boundary Clocks (BCs) that use the End-to-End delay measurement mechanism and IEEE1588v2 Default Profile. The Best Master Clock Algorithm (BMCA) on RedBox M determines port A and port B to be MASTER. The PTP protocol running on Redbox M treats both ports A and B individually as MASTER ports and sends out Sync and Follow_Up messages individually on both the ports.

Figure 3. PRP Redbox as DABC with E2E

On Redbox S, the regular BMCA operation determines port A to be a SLAVE and port B to be PASSIVE. However, with the knowledge that ports A and B are part of the same PRP channel, port B is forced into PASSIVE_SLAVE state. Port A and Port B on Redbox S operate as follows:

  • Port A works as a regular SLAVE port. It uses the end-to-end delay measurement mechanism to calculate delay and offset from the MASTER. Using the calculated delay and offset, it synchronizes the local clock.

  • Port B is in PASSIVE_SLAVE state. It uses the end-to-end delay measurement mechanism to calculate delay and offset from the MASTER.

    It is passive in the sense that it maintains the calculated delay and offset, but does not perform any operation on the local clock. Having the delay and offset information readily available equips it to seamlessly change its role to SLAVE if there is loss of connectivity to the MASTER on port A.

PRP RedBox as Doubly Attached BC (DABC) with P2P

The following figure shows an example where Redbox M and Redbox S are configured to run in Power Profile as Boundary Clocks that use Peer-to-Peer (P2P) delay measurement mechanism. In this example, the GM is the ordinary clock attached through LAN C. All the clocks are configured to run Peer-to-Peer Delay measurement and the peer delay is regularly calculated and maintained on every link shown in the figure.

The BMCA on Redbox M determines ports A and B to be MASTER. The PTP protocol running on Redbox M treats both ports A and B individually as MASTER ports and sends out Sync and Follow_Up messages individually on both the ports.

Figure 4. PRP Redbox as DABC with P2P

On Redbox S, the regular BMCA operation determines port A to be SLAVE and port B to be PASSIVE. However, with the knowledge that ports A and B are part of the same PRP channel, port B is forced into PASSIVE_SLAVE state. Port A and Port B on Redbox S operate as follows:

  • Port A works as a regular SLAVE port. It uses the Sync and Follow_Up messages along with their correction field to calculate the delay and offset from Master and synchronize the local clock. (Unlike an E2E BC, it does not need to generate Delay_Req messages because all the link delays and residence times along the PTP path are accumulated in the correction field of the Follow_Up messages).

  • Port B is in PASSIVE_SLAVE state. Like port A, it maintains the delay and offset from master, but does not perform any operation on the local clock. Having all the synchronization information available enables it to seamlessly take over as the new SLAVE in case port A loses communication with the GM.

PRP RedBox as Doubly Attached TC (DATC) with P2P

The following figure shows an example where Redbox M and Redbox S are configured to run in Power Profile mode as Transparent Clocks. In this example, the GM is the ordinary clock attached through LAN C. All the clocks are configured to run Peer-to-Peer Delay measurement and the peer delay is regularly calculated and maintained on every link shown in the figure.

Redbox M and Redbox S run BMCA even though it is not mandatory for a P2P TC to run BMCA. On Redbox M, the BMCA determines ports A and B to be MASTER. Redbox M forwards all Sync and Follow_Up messages received on port C out of ports A and B.

Figure 5. PRP Redbox as DATC with P2P

On Redbox S, port A is determined to be SLAVE and port B to be PASSIVE_SLAVE as described earlier. Port A and Port B on Redbox S operate as follows:

  • Port A works as a regular SLAVE port. It uses the Sync and Follow_Up messages along with their correction field to calculate the delay and offset from Master and synchronize the local clock. (Unlike an E2E BC, it does not need to generate Delay_Req messages since all the link delays and residence times along the PTP path are accumulated in the correction field of the Follow_Up messages).

  • Like port A, port B maintains the delay and offset from master, but does not perform any operation on the local clock. Having all the synchronization information available enables it to seamlessly take over as the new SLAVE in case port A loses communication with the GM.

LAN-A and LAN-B Failure Detection and Handling

Failures in LAN-A and LAN-B are detected and handled in the same way for all Redbox types described in PRP RedBox Types.

Using the example shown in PRP Redbox as DATC with P2P with the GM as a SAN in LAN C, a failure in LAN-A or LAN-B pertaining to PTP can occur due to the following reasons:

  • A device within the LAN goes down.

  • A link within the LAN goes down resulting in loss of connectivity.

  • PTP messages are dropped within the LAN.

These events result in PTP Announce Receipt Timeout on Redbox S, which triggers the BMCA calculation. Refer to section 7.7.3.1 of the IEEE 1588v2 standard for details on Announce Receipt Timeout.

The BMCA, once invoked, changes the state of the PASSIVE_SLAVE port to SLAVE and SLAVE to PASSIVE_SLAVE or PASSIVE or FAULTY. The state changes are done atomically to avoid transient cases where there are two SLAVE ports or two PASSIVE_SLAVE ports.

Redbox S now synchronizes to the GM over the new SLAVE port. The change to synchronization should be quick and seamless, unless the delays experienced by PTP packets on the two LANs are very different or if there are some non-PTP devices in the LANs.

The SAN Slave in LAN D also sees this shift in the timing from Redbox S and needs to converge to the new clock. This is similar to a GM change event for this clock, but as mentioned earlier, the change is usually seamless.

Prerequisites

All releases and FPGA support basic PRP for IE 4000, IE 4010 and IE 5000 switches.

However, node table support and automatic learning of source MAC addresses in the VDAN table require the following releases and FPGA versions:

  • IE 4000 switches must have Release 15.2(5)E or greater, and the FPGA version must be 0.37 or greater.

  • IE 5000 switches must have Release 15.2(5)E or greater, and the FPGA version must be 2.79 or greater.

  • IE 4010 switches must have Release 15.2(6)E or greater, and the FPGA version must be 1.1.16 or greater.


Note
To check the FPGA version, use the show version command. For example: 

IE4000#sh ver | incl FPGA
Backplane FPGA version : 0.37
IE4000#

Guidelines and Limitations

  • PRP traffic load cannot exceed 90% bandwidth of the Gigabit Ethernet interface channels.

  • Because PRP DANs and RedBoxes add a 6-byte PRP trailer to the packet, PRP packets can be dropped by some switches with a maximum transmission unit (MTU) size of 1500. To ensure that all packets can flow through the PRP network, increase the MTU size for switches within the PRP LAN-A and LAN-B network to 1506 as follows:

    • system mtu 1506

    • system mtu jumbo 1506

  • A PRP channel must have two active ports configured within a channel to remain active and maintain redundancy.

  • Both interfaces within a channel group must have the same configuration.

  • For Layer 3, you must configure the IP address on the PRP channel interface.

  • Load-balancing is not supported.

  • LLDP and CDP must be disabled on interfaces where PRP is enabled.

  • UDLD must be disabled on interfaces where PRP is enabled, especially if the interfaces have media-type sfp.

  • The spanning-tree bpdufilter enable command is required on the prp-channel interface. Spanning-tree BPDU filter drops all ingress/egress BPDU traffic. This command is required to create independent spanning-tree domains (zones) in the network.

  • The spanning-tree portfast edge trunk command is optional on the prp-channel interface but highly-recommended. It improves the spanning-tree converge time in PRP LAN-A and LAN-B.

  • The show interface g1/1 or show interface g1/2 command should not be used to read PRP statistics if these interfaces are PRP channel members because the counter information can be misleading. Use the show interface prp-channel [1 | 2 ] command instead.

  • The Protocol status displays incorrectly for the Layer type = L3 section when you enter the show prp channel detail command. Refer to the Ports in the group section of the output for the correct Protocol status (CSCur88178). IE 5000 output is shown in the following example: 

    
show prp channel detail
 
PRP-channel listing: 
--------------------
PRP-channel: PR1
------------
Layer type = L3
 Ports: 2       Maxports = 2
 Port state = prp-channel is Inuse
 Protocol = Disabled
 
Ports in the group:
  1) Port: Gi1/17
   Logical slot/port = 1/17 Port state = Inuse
   Protocol = Enabled
  2) Port: Gi1/18
   Logical slot/port = 1/19 Port state = Inuse
   Protocol = Enabled

  • On IE 4000 and IE 5000, PRP does not allow member ports in a PRP channel to be shut down. For example, issuing a shut on gi1/17 or gi1/18 when it is part of a PRP channel is not allowed.

    If you attempt to execute shut on a PRP member interface, the following message is displayed: 

    
switch(config)#int gi 1/3
switch(config-if)#shut
%Interface GigabitEthernet1/3 is configured in PRP-channel group, shutdown not permitted!

    Note

    On IE 4010, although the capability exists for PRP to allow member ports to be shut down, we do not recommend this option since it is not supported.

  • When an individual PRP interface goes down, show interface status continues to show a status of UP for the link. This is because the port status is controlled by the PRP module. Use the show prp channel command to confirm the status of the links, which will indicate if a link is down (CSCva06447). 

    
show prp channel 2 detail
PRP-channel: PR2
------------
Layer type = L2
Ports: 2 Maxports = 2
Port state = prp-channel is Inuse
Protocol = Enabled
Ports in the group:
1) Port: Gi1/3
Logical slot/port = 1/3 Port state = Inuse
Protocol = Enabled
2) Port: Gi1/4
Logical slot/port = 1/4 Port state = Not-Inuse (link down)
Protocol = Enabled

Node and VDAN Tables

  • The switch supports up to 512 (SAN+DANP) entries in the node table.

  • The maximum static Node/VDAN count is 16.

  • Hash collisions can limit the number of MAC addresses. If the node table is out of resources for learning a MAC address from a node, the switch will default to treating that node as a DAN.

  • After reload (before any MAC address is learned), the switch will temporarily treat the unlearned node as a DAN and duplicate the egress packets until an ingress packet or supervision frame is received from the node to populate an entry into the node table.

  • The switch supports up to 512 VDAN entries in the VDAN table. If the VDAN table is full, the switch cannot send Supervisory frames for new VDANS.

PTP over PRP

  • You must configure PRP and PTP separately. PTP over PRP works automatically without any additional configuration.

    No PTP configuration is available under interface prp-channel . The PRP channel member interfaces need to be individually configured for PTP. However, in most cases, you do not need to perform any PTP configuration on the interfaces because PTP is enabled by default on all physical Ethernet interfaces.


    Note

    You can use the show ptp port command to verify PTP over PRP configuration. In the command output, the LAN_B port may be displayed as “PASSIVE_SLAVE”.

  • PTP over PRP can coexist with Device Level Ring (DLR). In this scenario, the PRP RedBox is also part of a DLR network.

  • No configuration compatibility is enforced on the PRP channel member interfaces with respect to PTP.

    You can have different PTP configurations on PRP member interfaces. However, we recommend that you have identical PTP configurations on the interfaces that are part of the same PRP channel to allow for seamless transitions between PASSIVE_SLAVE and SLAVE states.

  • We recommend that the grandmaster (GM) clock be dually attached to both PRP LANs (as RedBox, VDAN, or DAN). If a GM is singly attached to one of the PRP LANs, only the devices in that LAN will be synchronized to the GM.

  • PTP over PRP supports only the Redbox types described in PRP RedBox Types. The following Redbox types described in IEC 62439-3, Section A are not supported:

    • PRP RedBoxes as three-port BCs (TWBC) - Section A.4.5.2

    • PRP RedBox as DATC with E2E - Section A.4.5.4.1

    • PRP RedBox as a stateless TC (SLTC) - Section A.4.5.5

  • To prevent any switch within PRP LAN-A/B from becoming a Grand Master, when PTP over PRP is configured for the system, other switches in PRP LAN-A and LAN-B should not be configured for PTP boundary mode. PTP transparent mode on PRP LAN-A/B switches is recommended in a time-sensitive environment.

  • IE switch platforms do not support PTP profile conversion. For example, if RedBox S in PRP Redbox as DABC with P2P were an IE switch, it would not support Delay_Req/Delay_Resp message exchange with LAN D shown in the figure. It would only support Peer-to-Peer delay measurement mechanism using PDelay messages.

  • PTP VLAN behavior remains unchanged by the PTP over PRP feature.

  • The IE 2000U continues to support PTP traffic over LAN_A only. The IE 2000U will interoperate with the platforms that support PTP over PRP (IE 4000, IE 4010, and IE 5000) with a potential loss of redundancy. With IE 2000U as a RedBox, there are two important scenarios to consider with respect to interoperability:

    • The grandmaster clock is the IE 2000U itself or a VDAN behind the IE 2000U—In this case, PTP synchronization in the network only occurs on LAN_A even in presence of other devices capable of supporting PTP over both LANs. This is because the IE 2000U will only send out PTP packets on LAN_A. PTP continues to operate in the network as long as there is no failure in LAN_A.

    • The grandmaster clock is a device capable of supporting PTP over both LANs—In this case, all devices in the network except IE 2000U (and VDANs behind it) are able to leverage the redundancy offered by PRP. However, the IE 2000U drops all incoming packets on LAN_B. As a result, the IE 2000U and the VDANs behind it cannot avail of the PRP redundancy with respect to PTP synchronization.

Default Settings

LED Display mode PRP is disabled.

Creating a PRP Channel and Group

To create and enable a PRP channel and group on the switch, follow these steps:

Before you begin

  • Review the specific interfaces supported per switch type, described in PRP Channels.

  • Review the Prerequisites and Guidelines and Limitations.

  • Ensure that the member interfaces of a PRP channel are not participating in any redundancy protocols such as FlexLinks, EtherChannel, REP, and so on before creating a PRP channel.

The following example is based on the IE 4000. Adjust the interface utilized based on the earlier information.

SUMMARY STEPS

  1. Enter global configuration mode:
  2. Assign two Gigabit Ethernet interfaces to the PRP channel group:
  3. (Optional) For Layer 2 traffic, enter switchport . (Default):
  4. (Optional) Set a non-trunking, non-tagged single VLAN Layer 2 (access) interface:
  5. (Optional) Create a VLAN for the Gi1/1-2 interfaces:
  6. (Optional) Disable Precision Time Protocol (PTP) on the switch:
  7. Disable loop detection for the redundancy channel:
  8. Disable UDLD for the redundancy channel:
  9. Enter sub-interface mode and create a PRP channel group:
  10. Bring up the PRP channel:
  11. Specify the PRP interface and enter interface mode:
  12. Configure bpdufilter on the prp-channel interface:
  13. (Optional) Configure LAN-A/B ports to quickly get to FORWARD mode:

DETAILED STEPS

Step 1

Enter global configuration mode:

configure terminal

Step 2

Assign two Gigabit Ethernet interfaces to the PRP channel group:

interface range {GigabitEthernet1/1-2 | GigabitEthernet1/3-4 }

Use the no interface prp-channel 1 |2 command to disable PRP on the defined interfaces and shut down the interfaces.

Note 

You must apply the Gi 1/1 interface before the Gi1/2 interface. So, we recommend using the interface range command. Similarly, you must apply the Gi1/3 interface before the Gi1/4 interface.

Step 3

(Optional) For Layer 2 traffic, enter switchport . (Default):

switchport

Note 

For Layer 3 traffic, enter no switchport .

Step 4

(Optional) Set a non-trunking, non-tagged single VLAN Layer 2 (access) interface:

switchport mode access

Step 5

(Optional) Create a VLAN for the Gi1/1-2 interfaces:

switchport access vlan <value>

Note 

Only required for Layer 2 traffic.
Step 6

(Optional) Disable Precision Time Protocol (PTP) on the switch:

no ptp enable

PTP is enabled by default. You can disable it if you do not need to run PTP.
Step 7

Disable loop detection for the redundancy channel:

no keepalive

Step 8

Disable UDLD for the redundancy channel:

udld port disable

Step 9

Enter sub-interface mode and create a PRP channel group:

prp-channel-group prp-channel group

prp-channel group—Value of 1 or 2

The two interfaces that you assigned in step 2 are assigned to this channel group.

The no form of this command is not supported.

Step 10

Bring up the PRP channel:

no shutdown

Step 11

Specify the PRP interface and enter interface mode:

interface prp-channel prp-channel-number

prp-channel-number—Value of 1 or 2

Step 12

Configure bpdufilter on the prp-channel interface:

spanning-tree bpdufilter enable

Spanning-tree BPDU filter drops all ingress/egress BPDU traffic. This command is required to create independent spanning-tree domains (zones) in the network.

Step 13

(Optional) Configure LAN-A/B ports to quickly get to FORWARD mode:

spanning-tree portfast edge trunk

This command is optional but highly recommended. It improves the spanning-tree convergence time on PRP RedBoxes and LAN-A and LAN-B switch edge ports. It is also highly recommended to configure this command on the LAN_A/LAN_B ports directly connected to a RedBox PRP interface.

EXAMPLE

This example shows how to create a PRP channel on an IE 4000 switch, create a PRP channel group, and assign two ports to that group. 


switch# configure terminal
switch(config)# interface range GigabitEthernet1/1-2
switch(config-if)# no keepalive
switch(config-if)# udld port disable
switch(config-if)# prp-channel-group 1
switch(config-if)# no shutdown
switch(config-if)# spanning-tree bpdufilter enable

This example shows how to create a PRP channel with a VLAN ID of 2. 


switch# configure terminal
switch(config)# interface range GigabitEthernet1/1-2
switch(config-if)# switchport
switch(config-if)# switchport mode access
switch(config-if)# switchport access vlan 2
switch(config-if)# no ptp enable
switch(config-if)# no keepalive
switch(config-if)# udld port disable
switch(config-if)# prp-channel-group 1
switch(config-if)# no shutdown
switch(config-if)# spanning-tree bpdufilter enable

This example shows how to create a PRP channel on a switch configured with Layer 3. 


switch# configure terminal
switch(config)# interface range GigabitEthernet1/1-2
switch(config-if)# no switchport
switch(config-if)# no ptp enable
switch(config-if)# no keepalive
switch(config-if)# udld port disable
switch(config-if)# prp-channel-group 1
switch(config-if)# no shutdown
switch(config-if)# spanning-tree bpdufilter enable
switch(config-if)# exit
switch(config)# interface prp-channel 1
switch(config)# ip address 192.0.0.2 255.255.255.0

Adding Static Entries to the Node and VDAN Tables

Follow this procedure to add a static entry to the node or VDAN table.

SUMMARY STEPS

  1. Enter global configuration mode:
  2. Specify the MAC address to add to the node table for the channel group and whether the node is a DAN or a SAN (attached to either LAN_A or LAN_B):
  3. Specify the MAC address to add to the VDAN table:

DETAILED STEPS

Step 1

Enter global configuration mode:

configure terminal

Step 2

Specify the MAC address to add to the node table for the channel group and whether the node is a DAN or a SAN (attached to either LAN_A or LAN_B):

prp channel-group prp-channel group nodeTableMacaddress mac-address {dan | lan-a | lan-b}

prp-channel group —Value of 1 or 2

mac-address— MAC address of the node

Note 

Use the no form of the command to remove the entry.

Step 3

Specify the MAC address to add to the VDAN table:

prp channel-group prp-channel group vdanTableMacaddress mac-address

prp-channel group —Value of 1 or 2

mac-address— MAC address of the node or VDAN

Note 

IE 4010 vdan command requires a VLAN to be entered.

Use the no form of the command to remove the entry.

EXAMPLE


switch# configure terminal
switch(config-if)# prp channel-group 1 nodeTableMacaddress 0000.0000.0001 lan-a

Clearing All Node Table and VDAN Table Dynamic Entries

To clear all dynamic entries in the node table, enter

clear prp node-table [channel-group group ]

To clear all dynamic entries in the VDAN table, enter

clear prp vdan-table [channel-group group ]

If you do not specify a channel group, the dynamic entries are cleared for all PRP channel groups.


Note

The clear prp node-table and clear prp vdan-table commands clear only dynamic entries. To clear static entries, use the no form of the nodeTableMacaddress or vdanTableMacaddress commands shown in Adding Static Entries to the Node and VDAN Tables.

Disabling the PRP Channel and Group

SUMMARY STEPS

  1. Enter global configuration mode:
  2. Disable the PRP channel:
  3. Exit interface mode:

DETAILED STEPS

Step 1

Enter global configuration mode:

configure terminal

Step 2

Disable the PRP channel:

no interface prp-channel prp-channel-number

prp-channel number— Value of 1 or 2

Step 3

Exit interface mode:

exit

PRP Mode LED

For IE 4000, IE 4010, and IE 5000 systems with the HSR/PRP LED on the faceplate, the switch supports the following states.

Label Description

Color and State

Description

REDUNDANCY mode LED (IE 4010 and IE 5000)

HSR/PRP mode LED (IE 4000)

Green (solid)

LED Display mode PRP is enabled.

Port LEDs

Green (solid)

Port is configured for PRP for channel 1 or channel 2 (refer to specific ports per platform).

Black

PRP is not enabled or configured on the port.

Verifying Configuration

Command

Purpose

show prp channel {1 | 2 [detail | status | summary ] | detail | status | summary }

Displays configuration details for a specified PRP channel.
show prp control {VdanTableInfo | ptpLanOption | ptpProfile | supervisionFrameLifeCheckInterval | supervisionFrameOption | supervisionFrameRedboxMacaddress | supervisionFrameTime }

Displays PRP control information, VDAN table, and supervision frame information.
show prp node-table [channel-group <group > | detail ]

Displays PRP node table.
show prp statistics {egressPacketStatistics | ingressPacketStatistics | nodeTableStatistics | pauseFrameStatistics | ptpPacketStatistics }

Displays statistics for PRP components.

show prp vdan-table [channel-group <group > | detail ]

Displays PRP VDAN table.

show interface prp-channel {1 | 2 }

Displays information about PRP member interfaces.

Note

The show interface g1/1 or show interface g1/2 command should not be used to read PRP statistics if these interfaces are PRP channel members because the counter information can be misleading. Use the show interface prp-channel [1 | 2 ] command instead.

The following example shows the output for show prp channel when one of the interfaces in the PRP channel is down. 


show prp channel 2 detail
PRP-channel: PR2
------------
Layer type = L2
Ports: 2 Maxports = 2
Port state = prp-channel is Inuse
Protocol = Enabled
Ports in the group:
1) Port: Gi1/3
Logical slot/port = 1/3 Port state = Inuse
Protocol = Enabled
2) Port: Gi1/4
Logical slot/port = 1/4 Port state = Not-Inuse (link down)
Protocol = Enabled

The following example shows how to display the PRP node table and PRP VDAN table. 


Switch#show prp node-table
PRP Channel 1 Node Table
==================================
   Mac Address   Type  Dyn   TTL
---------------- ----- --- -------
 B0AA.7786.6781  lan-a  Y     59
 F454.3317.DC91  dan    Y     60
==================================
Channel 1 Total Entries: 2
Switch#show prp vdan-table
PRP Channel 1 VDAN Table
============================
   Mac Address   Dyn   TTL
---------------- --- -------
 F44E.05B4.9C81   Y     60
============================
Channel 1 Total Entries: 1

Configuration Example

The following diagram shows a network configuration in which the IE 4000 might operate. The commands in this example highlight the configuration of features and switches to support that configuration.

In this example, the configuration establishes two VLANs, 80 and 81, and the Spanning Tree Protocol is configured for each PRP channel on the VLANs, MST-PRP1 and MST-PRP2, respectively.

There are two IE 4000 switches within the topology, identified as switch 1 (SW1) and switch 2 (SW2).

The commands below show how to configure the Spanning Tree Protocol, VLANs, and PRP channels and groups on SW1:


spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
instance 1 vlan 80
instance 2 vlan 81
vlan 80
name MST-PRP2
!
vlan 81
name MST-PRP1
!
interface PRP-channel1
switchport access vlan 81
switchport mode access
spanning-tree bpdufilter enable
spanning-tree portfast edge trunk
!
interface PRP-channel2
switchport access vlan 80
switchport mode access
spanning-tree bpdufilter enable
spanning-tree portfast edge trunk
!
interface GigabitEthernet1/1
switchport access vlan 81
switchport mode access
media-type rj45
speed 100
prp-channel-group 1
!
interface GigabitEthernet1/2
switchport access vlan 81
switchport mode access
media-type rj45
speed 100
prp-channel-group 1
!
interface GigabitEthernet1/3
switchport access vlan 80
switchport mode access
media-type rj45
speed 100
prp-channel-group 2
!
interface GigabitEthernet1/4
switchport access vlan 80
switchport mode access
media-type rj45
speed 100
prp-channel-group 2
interface GigabitEthernet1/9
switchport access vlan 81
switchport mode access
!
interface GigabitEthernet1/10
no switchport
ip address 192.168.100.222 255.255.255.0
shutdown
!
interface GigabitEthernet1/11
switchport access vlan 80
switchport mode access
!
interface GigabitEthernet1/12
switchport access vlan 80
switchport mode access
!
interface GigabitEthernet1/13
switchport access vlan 81
switchport mode access
!        
interface Vlan80
ip address 10.208.80.111 255.255.255.0
!
interface Vlan81
ip address 10.208.81.111 255.255.255.0

The commands below show how to configure the Spanning Tree Protocol, VLANs, and PRP channels and groups on SW2:


spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
instance 1 vlan 80
instance 2 vlan 81
!
!
interface PRP-channel1
switchport access vlan 81
switchport mode access
spanning-tree bpdufilter enable
spanning-tree portfast edge trunk
!
interface PRP-channel2
switchport access vlan 80
switchport mode access
spanning-tree bpdufilter enable
spanning-tree portfast edge trunk
!
interface GigabitEthernet1/1
switchport access vlan 81
switchport mode access
media-type rj45
speed 100
prp-channel-group 1
!
interface GigabitEthernet1/2
switchport access vlan 81
switchport mode access
media-type rj45
speed 100
prp-channel-group 1
interface GigabitEthernet1/3
switchport access vlan 80
switchport mode access
media-type rj45
speed 100
prp-channel-group 2
interface GigabitEthernet1/4
switchport access vlan 80
switchport mode access
media-type rj45
speed 100
prp-channel-group 2
interface GigabitEthernet1/9
switchport access vlan 81
switchport mode access
interface GigabitEthernet1/10
no switchport
ip address 192.168.100.223 255.255.255.0
shutdown
!
interface GigabitEthernet1/11
switchport access vlan 80
switchport mode access
!
interface GigabitEthernet1/12
switchport access vlan 80
switchport mode access
interface GigabitEthernet1/13
switchport access vlan 81
switchport mode access
interface Vlan80
ip address 10.208.80.222 255.255.255.0
!
interface Vlan81
ip address 10.208.81.222 255.255.255.0

The commands below show how to configure the Spanning Tree Protocol and VLANs on SW3:


spanning-tree mode mst
spanning-tree extend system-id

spanning-tree mst configuration
instance 1 vlan 80
instance 2 vlan 81
interface GigabitEthernet1/0/1
switchport access vlan 81
switchport mode access
shutdown
no mdix auto
!
interface GigabitEthernet1/0/2
switchport access vlan 81
switchport mode access
interface GigabitEthernet1/0/5
switchport trunk allowed vlan 20,80,81,88
switchport mode trunk
interface GigabitEthernet1/0/8
switchport access vlan 80
switchport mode access

The commands below show how to configure the Spanning Tree Protocol and VLANs on SW4:


spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
instance 1 vlan 80
instance 2 vlan 81
vlan 80
name MST-PRP2
vlan 81
name MST-PRP1
interface FastEthernet0/3
port-type nni
switchport trunk allowed vlan 20,80,81,88
switchport mode trunk
interface FastEthernet0/7
port-type nni
switchport access vlan 80
!        
interface FastEthernet0/8
port-type nni
switchport access vlan 80
interface GigabitEthernet1/1
port-type nni
switchport access vlan 81
interface GigabitEthernet1/2
port-type nni
switchport access vlan 81

The commands below show how to configure the Spanning Tree Protocol and VLANs on SW5:


spanning-tree mode mst
spanning-tree extend system-id
spanning-tree mst configuration
instance 1 vlan 80
instance 2 vlan 81
vlan 80
name MST-PRP2
vlan 81
name MST-PRP1
interface FastEthernet1/7
switchport access vlan 80
switchport mode access
ip device tracking maximum 0
interface FastEthernet1/8
switchport access vlan 80
switchport mode access
ip device tracking maximum 0
interface GigabitEthernet1/1
switchport access vlan 81
switchport mode access
ip device tracking maximum 0
!
interface GigabitEthernet1/2
switchport access vlan 81
switchport mode access
ip device tracking maximum 0

Feature History

PRP is supported on IE 2000U, IE 4000, IE 4010, and IE 5000 switches. Not all versions of IE 2000U support the PRP feature, and not all industrial platforms support all features. The following table lists the PRP features supported by each platform.

Feature Name

Release

Feature Information

Precision Time Protocol (PTP) over Parallel Redundancy Protocol (PRP)

Cisco IOS Release 15.2(6)E

Supported on IE 4000, IE 4010, and IE 5000.

Parallel Redundancy Protocol Enhancements (Supervisor frame/ Mixed traffic support )

Cisco IOS Release 15.2(5)E

Supported on IE 2000U, IE 4000, and IE 5000.

Parallel Redundancy Protocol including PRP mode LED.

Cisco IOS Release 15.2(4)EC

Initial support on IE 4010.

Cisco IOS Release 15.2(2)EB

Initial support on IE 5000.

Cisco IOS Release 15.2(2)EA

Initial support on IE 4000.

Parallel Redundancy Protocol

Cisco IOS Release 15.0(2)EK

Initial support on the following IE 2000U platforms: IE-2000U-8TC-G , IE-2000U-16TC-G, IE-2000U-16TC-GP, IE-2000U-16TC-G-X

Note 

6-port IE 2000U SKUs do not support the PRP feature.