Post Go back to editing

FRER Configuration, Setup, and Status - Seeking Monitoring Guidance

Category: Software
Product Number: ADIN 6310
Software Version: v5.1.0

FRER Configuration, Setup, and Status - Seeking Monitoring Guidance

I'm implementing a Fault-Tolerant Redundancy (FRER, IEEE 802.1CB) configuration across two switches and two end devices (AM62p boards) to establish a redundant ring network. 
I've observed the status counters on the Listener switch and now seek advice on the best way to monitor the replicated data transmission across the FRER ring using a host port, 
specifically via Wireshark on Switch 1.

The core question is: How can I observe the data duplication (replication) that FRER creates, given that the Listener switch (Switch 2) removes the duplicate frames before they reach the end device (AM62p board 2)?

1. Network Configuration Overview

The setup consists of an FRER ring connecting two switches (Switch 1 and Switch 2), with the Talker (AM62p brd 1) connected to Switch 1 and the Listener (AM62p brd 2) connected to Switch 2.

1.1. Switch 1 (Talker Side)

Component    Configuration Details
FRER Config    Unicast/Multicast Miss Config: Port 1 and Port 2 set to 0.
    Stream Table: For Ports 1, 2, 3. Identification Type: Source MAC / VLAN. VLAN: 100. Source MAC: 08-04-b4-31-12-42.
    Talker Configuration: On Port 3 (connected to AM62p brd 1).
VLAN Config    VLAN 100: Learn and forward for Ports 1, 2, 3.
MSTP Exception    VLAN 100 added to the MSTP exception list.


1.2. Switch 2 (Listener Side)

Component    Configuration Details
FRER Config    Unicast/Multicast Miss Config: Port 0 and Port 1 set to 0.
    Stream Table: For Ports 0, 1, 2. Identification Type: Source MAC / VLAN. VLAN: 100. Source MAC: 08-04-b4-31-12-42.
    Listener Configuration: On Port 2 (connected to AM62p brd 2).
VLAN Config    VLAN 100: Learn and forward for Ports 0, 1, 2.
MSTP Exception    VLAN 100 added to the MSTP exception list.


1.3. End Devices

Device    Configuration Details
AM62p brd 1 (Talker)    VLAN ID 100 created and IP configured. Runs simple client to generate traffic. Source MAC: 08-04-b4-31-12-42.
AM62p brd 2 (Listener)    VLAN ID 100 created and IP configured. Runs simple server to receive data via VLAN 100. Crucially, no duplicate data is received.



2. Observed FRER Status (Switch 2 - Listener)

The status counters on the Listener Switch (Switch 2) demonstrate the FRER functionality, specifically the sequence reconciliation logic.

2.1. Status with Both Ethernet Ports Connected (Redundant Path Active)

Counter                Value    Interpretation
Passed-pkts            114        Packets successfully forwarded to the Listener device.
Discarded-pkts        342        Significantly high count. These are the replicated frames discarded by the Sequence Reconciliation Function as they were duplicates of frames already received and passed. → This confirms the data duplication and reconciliation is working.
Out-of-order-pkts    0    
Rogue-pkts            0    
Lost-pkts            0    


2.2. Status with One Cable Removed (Single Path Active)

Counter                Value    Interpretation
Passed-pkts            36        Packets successfully forwarded. (Fewer total packets due to reduced test duration/traffic).
Discarded-pkts        0        As expected. With only one path, no duplicate frames arrive, and thus no packets are discarded by the reconciliation function.
Out-of-order-pkts    0    
Rogue-pkts            0    
Lost-pkts            0    



3. Monitoring Question and Proposed Approach

The status counters confirm that Switch 1 is replicating the traffic and Switch 2 is reconciling it. However, since the duplicate frames are removed at Switch 2, I cannot capture the duplicated data on the AM62p brd 2.


Critical Negative Observation During Monitoring Attempt:

When I configured a host port on Switch 1 for monitoring and set it as a standard "learn and forward" port while mirroring traffic from the ring ports:

    The entire network bandwidth was severely reduced.

    The switch started flooding (dumping) data out of many ports.

This behavior is consistent with MAC address flapping caused by the two identical, 
replicated frames (Stream A and Stream B, both from MAC: 08−04−b4−31−12−42) hitting the switch's MAC address table via the two mirrored ports simultaneously.


Question:

What is the recommended method to monitor the duplicated traffic (the two distinct streams of identical, sequenced packets) that is traversing the FRER ring?

Parents
  • Hi Dhevak,

    Some notes on the FRER configuration.

    Talker:

    My understanding is that Port 1 and Port 2 are the redundant ports going to the second switch.
    The recommended configuration in the stream table is to only check P1 and P2 because this is where the FRER streams egressing from the switch

    Listener:

    Similarly, the configuration of the port map in the stream table on the listener switch should only have P2 checked, because this is where the stream would egress from the switch.

    What is the purpose of capturing the duplicated frames on the second Am62 board?
    If there are two redundant paths, is your intention to monitor the duplicated streams on both paths?
    It is possible to use a network tap between the redundant paths to monitor the streams.
    However, this could introduce additional latency.

  • Hai Karl

    Answer to your question

    1. What is the purpose of capturing the duplicated frames on the second Am62 board?
        The purpose is not to capture the duplicated frames. According to the FRER standard (IEEE 802.1CB), the destination Listener (the second Am62 board) is intended to eliminate the redundant frame, delivering only a single, ordered stream to the application.

        Actual Verification Purpose: We only need to confirm that the FRER Talker successfully replicates the frame and actively transmits it over the designated redundant path. 
        This proves the system is prepared for instantaneous fail over.

    2. If there are two redundant paths, is your intention to monitor the duplicated streams on both paths?
        No. The configuration is based on a main path and a single redundant path, not two mutually redundant paths. Therefore, the intention is not to monitor two duplicated streams.

        Monitoring Focus: The focus is exclusively on monitoring the data transfer activity on the redundant path. This ensures the path is electrically viable,  correctly routed, and instantaneously ready to sustain traffic should the main path fail.

        Verification Method: Since tapping the link via Wireshark caused configuration disruption and bandwidth reduction, i want a quantitative proof of active data transfer, 
     which is sufficient to validate the FRER feature.

  • When the ADIN6310/ADIN3310 is configured as a listener, the device handles the elimination of the redundant frames.

    If the verification purpose is to check if the FRER talker is successful in replicating the frames, is it possible to have a setup with Am62 board transmitting to the Switch (FRER Talker), then the switch would transmit to the redundant paths toward the second Am62 board? If there is a failure in one of the paths, the second Am62 board would be able to detect if it is still receiving redundant frames.

  • when i tried the "setup with Am62 board transmitting to the Switch (FRER Talker), then the switch would transmit to the redundant paths toward the second Am62 board?"

    Observation-

    Random case i have found data with R-Tag and sequential order 

    log-

        ether type Unknown (0xf1c1), length 66:

            0x0000:  0000 014d 0806 0001 0800 0604 0001 0804 
      ether type Unknown (0xf1c1), length 66:
            0x0000:  0000 014e 0806 0001 0800 0604 0001 0804
      ether type Unknown (0xf1c1), length 66:
            0x0000:  0000 014f 0806 0001 0800 0604 0001 0804
     so it seems to be working in talker side 
     
  • The log seems to show that the talker is adding R-tag and sending data in sequential order, which is what I was expecting the talker to output.

    Are you also seeing multiple copies of the same data? This verifies that the talker is sending out the same data over the redundant paths.

  • Are you also seeing multiple copies of the same data? This verifies that the talker is sending out the same data over the redundant paths.

    The log i have is only one sequence of data  on talker side,

    listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    00:22:55.295603 STP 802.1s, Rapid STP, CIST Flags [Proposal, Learn, Forward, Agreement], length 102
    00:22:56.567925 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 0148 0806 0001 0800 0604 0001 0804  ...H............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:22:56.765465 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:22:56.955387 IP6 am62xxsip-evm.mdns > ff02::fb.mdns: 0 PTR (QM)? 66.87.254.169.in-addr.arpa. (44)
    00:22:56.955618 IP am62xxsip-evm.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 66.87.254.169.in-addr.arpa. (44)
    00:22:56.955707 IP6 am62xxsip-evm.mdns > ff02::fb.mdns: 0 PTR (QM)? 66.87.254.169.in-addr.arpa. (44)
    00:22:57.295552 STP 802.1s, Rapid STP, CIST Flags [Proposal, Learn, Forward, Agreement], length 102
    00:22:57.505176 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:22:57.583335 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 0149 0806 0001 0800 0604 0001 0804  ...I............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:22:57.956781 IP6 am62xxsip-evm.mdns > ff02::fb.mdns: 0 PTR (QM)? 66.87.254.169.in-addr.arpa. (44)
    00:22:57.957014 IP am62xxsip-evm.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 66.87.254.169.in-addr.arpa. (44)
    00:22:57.957104 IP6 am62xxsip-evm.mdns > ff02::fb.mdns: 0 PTR (QM)? 66.87.254.169.in-addr.arpa. (44)
    00:22:58.499458 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:22:58.607340 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 014a 0806 0001 0800 0604 0001 0804  ...J............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:23:02.505150 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:23:02.607346 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 014d 0806 0001 0800 0604 0001 0804  ...M............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:23:03.295482 STP 802.1s, Rapid STP, CIST Flags [Proposal, Learn, Forward, Agreement], length 102
    00:23:03.786323 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:23:04.510178 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:23:04.569768 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 014e 0806 0001 0800 0604 0001 0804  ...N............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:23:05.295462 STP 802.1s, Rapid STP, CIST Flags [Proposal, Learn, Forward, Agreement], length 102
    00:23:05.499433 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:23:05.583359 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 014f 0806 0001 0800 0604 0001 0804  ...O............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:23:06.607379 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 0150 0806 0001 0800 0604 0001 0804  ...P............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:23:07.295438 STP 802.1s, Rapid STP, CIST Flags [Proposal, Learn, Forward, Agreement], length 102
    00:23:07.418767 LLDP, length 46
    00:23:07.788330 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:23:08.510205 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:23:08.570645 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 0151 0806 0001 0800 0604 0001 0804  ...Q............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............
    00:23:09.295421 STP 802.1s, Rapid STP, CIST Flags [Proposal, Learn, Forward, Agreement], length 102
    00:23:09.500663 ARP, Request who-has 10.5.0.2 tell 169.254.87.66, length 46
    00:23:09.583386 08:04:b4:31:12:42 (oui Unknown) > Broadcast, ethertype Unknown (0xf1c1), length 66:
            0x0000:  0000 0152 0806 0001 0800 0604 0001 0804  ...R............
            0x0010:  b431 1242 0a05 330b 0000 0000 0000 0a05  .1.B..3.........
            0x0020:  3316 0000 0000 0000 0000 0000 0000 0000  3...............

    when running in receiver side there has no R-TAG,

    its like above log without RTAG 

  • The ADIN6310 (Talker) is egressing the packets with R-TAG on port 1 and port 2. While on the receiving AM62 board, you are seeing the same packets without R-TAG?

    Can you share the configuration of FRER again?

  • Hi Karl.O,

    Thanks for the quick reply.

    1. R-TAG Observation:
    Yes, that is correct. The ADIN6310 (Talker) is engressing the packets with the R-TAG on both Port 1 and Port 2. However, on the receiving AM62 board, 


    2. FRER Configuration Details:

    -> Topology

    -> Talker configuration switch

    above is the FRER talker configuration additionally Vlan 100 configured for port 1,2,3 as learn and forward

    then VLAN 100 is added under MSTP .

    3.After configuration complete data is transferred from AM62 board 1 to 2 through switch .

    Thanks,

    Dhevak A

  • Hi Dhevak,

    I’m not seeing any issues with the FRER configuration.

    On the receiving AM62 board, could it be that the R-TAG is being stripped from the packets by the board?

    Regards,

    Karl

  • Hi Karl,

    I ran tcpdump on the receiver side earlier, but I did not specify the exact interface or port name.

    I will re-run the test immediately with the same configuration, but this time I will try to simultaneously capture the raw data from both incoming ports/interfaces, saving the output to separate files for comparison.

    I will get back to you with the results soon.

    Regards,

    Dhevak

Reply
  • Hi Karl,

    I ran tcpdump on the receiver side earlier, but I did not specify the exact interface or port name.

    I will re-run the test immediately with the same configuration, but this time I will try to simultaneously capture the raw data from both incoming ports/interfaces, saving the output to separate files for comparison.

    I will get back to you with the results soon.

    Regards,

    Dhevak

Children