1769-L24 Dual Ethernet: One IP Switch, Not Two Ports

You open the controller properties, land on the Internet Protocol tab, and there is exactly one address field. Two RJ45 jacks on the front of the controller, one place to type an IP. Nothing is broken, and no firmware revision is going to add the second field.

Stop Looking for the Second IP Field

These are the four attempts that burn a shift on this problem. Start by ruling all of them out.

The fourth row is the dangerous one. It works well enough on a Friday to survive commissioning, then produces broadcast noise on the machine segment and I/O multicast on the enterprise LAN. That is not a network design; that is a bridge.

Know What the Two Ports Actually Are

The 1769-L24 is a CompactLogix 5370 L2. Every controller in the 5370 family uses the same Device Level Ring style port pair: two media ports on one internal two-port Ethernet switch, sitting in front of a single CIP network interface.

• One IP address, one mask, one gateway, one MAC for the controller. That is why the configuration dialog offers one of each.
• The internal switch forwards at Layer 2 between the two jacks. No routing engine, no NAT, no per-port VLAN, no IP forwarding toggle.
• The port pair exists for topology, not for segregation. It lets you daisy-chain adapters and drives, or close a Device Level Ring, without putting a switch in the panel.
• In a ring, an active supervisor node beacons the ring and blocks one path to break the loop; on a cable fault it unblocks and traffic keeps flowing. With no supervisor configured, cabling both ports into the same network is a Layer 2 loop and a broadcast storm.

So the answer to "can I put process on one port and I/O on the other" is no, and the reason is architectural. Move the boundary out of the controller.

Move the Network Boundary Outside the Controller

You have three real options. Pick by how much traffic has to cross and who owns the plant LAN.

1. 1:1 NAT appliance such as the 9300-ENA, placed between the machine segment and the plant network. The controller keeps one private machine address; the NAT presents it on the plant network under a plant address. This is the clean answer when IT owns the upper network and hands you one address per machine.
2. A routed boundary — Layer 3 switch or firewall between the two subnets, with the controller's gateway pointed at the machine-side interface. Works for explicit messaging and HMI traffic. Implicit I/O does not cross it, which is fine, because your drives live on the machine side anyway.
3. Physically separate the traffic sources. If the only reason for a second network was one HMI or a historian, put that device on the machine segment and route or NAT its data out instead of dual-homing the controller.

Do not go shopping for a local expansion module that adds a second interface. Segregation happens upstream of the chassis.

Commission the 1:1 NAT Path

1. Assign the controller a static address on the machine subnet. Disable BOOTP/DHCP on the interface afterward so a power cycle without the server does not strand the controller.
2. Cable both controller ports into the machine segment only — ring or daisy-chain. Nothing from the plant network touches either jack.
3. Address the NAT device's private side on the machine subnet and its public side on the plant subnet, using addresses your network owner issued.
4. Create the 1:1 mapping: controller private address to controller public address. Add a mapping for every machine-side device the plant needs to reach, including the HMI if it is polled from above.
5. Set the controller's default gateway to the NAT device's private-side address only if the controller must initiate outbound sessions (MSG instructions to plant devices, time sync). Otherwise leave it at the machine-side router or blank.
6. From the plant side, browse and download to the public address. From the panel, use the private address. Write both into the drawing and onto a label inside the door.

Use a CIP-aware 1:1 NAT, not a generic broadband router doing port translation. EtherNet/IP embeds endpoint addresses inside the CIP Forward_Open payload and defaults to multicast for the target-to-originator direction of implicit connections. A generic NAT rewrites the IP header and leaves the embedded addresses alone, so explicit messaging half-works and I/O connections never establish.

Wire the Machine Side as a Ring or Daisy-Chain

With the boundary handled, use the port pair for what it is built for.

• Every node physically in the ring must be DLR-capable and running 100 Mbps full duplex. One unmanaged switch spliced into the ring path kills the ring.
• Nominate exactly one active supervisor. Any DLR-capable node can do it — the controller or a DLR-capable managed switch. Configure a backup at lower precedence; the highest precedence node becomes active.
• Hang non-DLR devices off a switch that is itself a ring node, or off the machine segment outside the ring. Laptops, printers and single-port devices do not belong in the ring path.
• Linear daisy-chain is legal and has zero fault tolerance. Any cable pull or de-energized node drops everything downstream. If drives are powered down independently for maintenance, close the ring or use a switch.
• Watch duplex. A port that auto-negotiates to half duplex will pass ping traffic and drop I/O connections under load.

Verify, Then Watch These Pitfalls

Check in this order. The first three take two minutes and catch most of it.

1. Read the IP off the controller's status display and confirm it matches the machine-side address you assigned.
2. Ping the private address from a laptop on the machine segment, then ping the public address from a plant-side host. Both must answer.
3. Browse from RSLinx on both sides. The controller appears once per side, not twice, and not as a duplicate on the machine segment.
4. Read the ring supervisor status. It must report Normal, not Ring Fault, with no partial network faults.
5. Pull one ring cable on purpose. I/O connections stay up, the supervisor reports a ring fault and names the last active nodes. Reconnect and confirm the status returns to Normal.
6. Let the machine run for a shift and check the controller for module faults and connection timeouts on the drives.

Recurring traps on this class of controller: no IGMP querier on the machine segment, so implicit I/O multicast floods every port; BOOTP/DHCP left enabled after commissioning; the same address reused on both sides of the NAT; and an engineer six months later plugging the spare front port into the office jack "because it was free" and re-bridging the networks. Cap or label the unused port.

If ring status stays faulted with known-good cable, media and duplex on every node, or if implicit I/O will not establish through the NAT after ping and explicit messaging both succeed across the mapping, stop swapping hardware. Open a case with Rockwell Automation Technical Support with the controller catalog number, firmware revision, the NAT mapping table and a packet capture from the machine side.

FAQ