Thanks a lot for the input so far!
To hopefully clarify the background: as Nathan already guessed I'm thinking
about a redundancy mechanism that may look something like this

    to external network
          │
  ┌───────┴──────────────┐         different          vs. same
  │  managed switch      │   eth1: 172.16.8.201/24    169.254.1.1/16
  └─────┬───┬────────────┘   eth2: 192.168.8.201/24   169.253.1.2/16
        │   │
        │   └──────────────────────────────────────────────────────┐
        │                 ┌─────────────┐       ┌──────────┐       │
        │                 │             │       │          │       │
   ┌────┴─────────────────┴──────┐      │       │          │       │
   │   eth1             eth2     │  ┌───┴───────┴──┐   ┌───┴───────┴──┐
   │           P L C             │  │   nuttx #1   │   │   nuttx #2   │
   │                             │  └──────────────┘   └──────────────┘
   └─────────────────────────────┘

Conceptually each nuttx device is connected via a 3-point switch
(potentially integrated) that will forward any packets not destined for the
respective device like so
      ◄───────┐ ┌─────────────►
  to PLC      │ │      to next device
              │ │ ┌───────┐
             ┌┴─┴─┴───┐   │
             │ switch │   │
             └────────┘   │
                  ┌───────┴──────┐
                  │   nuttx #1   │
                  └──────────────┘
The goal is to ensure that packets from/to any embedded device runing nuttx
will reach the PLC/device even if one connection fails.
Having just one IP address on the nuttx side of course still allows opening
two socket connections (one from each eth jack of the PLC) that can provide
redundant communication.
Using different addresses (and networks) provides a clear separation and
makes routing on the PLC side easier (the network stack knows on which eth
port to send).

Matthias

Reply via email to