New interface in R82.10 + 3900 appliance: eth-switch, eth-cpuport

[HeikoAnkenbrand]

During today’s upgrade to 3900 appliances, I noticed that there are two new interfaces on 3900 appliances running R82.10 - see picture.

Interface:
  - eth-switch
  - eth-cpuport

Now the question comes up for me: what are they used for?

The only information available can be found here:
3900 Appliances Getting Started Guide - 3900 Appliances Hardware --> Switch Ports Explanation 

I assume this has to do with communication between (eth-cpuport), and eth-switch Distributed Switch Architecture (DSA) tag in connection with tools like "fw monitor", "tcpdump", and "cppcap". Is there an explanation for why this is used with the new processor types and network drivers in 3900 appliances?

Could someone from Check Point explain in more detail what these are used for?

[Chris_Atkinson]

I had posted the same GSG that you've linked, in some ways reminds me of sk166552 (SMB).

[PhoneBoy]

I believe they are related to the interfaces used in the 3900s...which are similar to SMB appliances...that allow for "switches" to be created with the various ports.
Not sure that can be configured in Gaia OS yet.

[Bob_Zimmerman]

I've been poking a 3920 remotely.

If you check ethtool -i, eth-switch uses the net_cn10k driver. Early in the boot, dmesg says "Machine model : Marvell CN103XX board", and this is the driver for the integrated ethernet interfaces on that family of chips. The same driver is also used for eth9, eth10, eth11, and the interface named Mgmt.

Incidentally, eth9 thinks it's capable of 10g, 25g, 50g, and 100g. I'm tempted to get a 25g transceiver from FS to see if it's actually an SFP28 slot.

If you check the same on eth-cpuport, it uses the "DSA Pseudo Ethernet" driver and has no bus info. The copper ports other than the one named Mgmt all use the same "DSA Pseudo Ethernet" driver. This driver is part of Marvell's "Distributed Switch Architecture", which involves a switch chip connected to the processor via an internal Ethernet link, but managed over MDIO, I2C, or SPI rather than over PCIe. This system supports tagging traffic which arrives over a switchport with the port on which it arrived, so the OS can treat all the switchports as if they were real, directly-owned interfaces (basically using the switch as a port multiplexer). That appears to be what Check Point is currently doing.

I haven't tried bridging two interfaces to see if the switch still forwards the traffic to the OS, but I bet it does. The system allows the bridging to be programmed into the switch, but then the firewall couldn't filter traffic on that bridge. Switch chips which implement the DSA are generally not as smart as the switch chips in the QLS cards. Specifically, you can't typically tell a DSA switch chip to handle one traffic flow but not others involving the same ports, which is one of the selling points of the ConnectX-6 DX used in the QLS.

[emmap]

The switching capabilities for these devices are planned to be supported in R82.20, so there'll be more information available at that time I'm sure.

[HeikoAnkenbrand]

I think that the DSA architecture is already included in R82.10 as preparation for R82.20. We can already see the following approaches in the packet flow.

Traffic reaches the appliance switch port.

- The switch port appends a Distributed Switch Architecture (DSA) tag to the packet.

- This tag is visible in traffic captures made with the tools “tcpdump,” “cppcap,” and “fw monitor.”

- The switch port then sends the packet, including the DSA tag, through the “eth-cpuport” to the Master Port (“eth-switch”) queue.

- One of the CoreXL SND instances retrieves the packet from the queue, strips off the DSA tag, and passes the packet to a CoreXL Firewall instance.

- The CoreXL Firewall instance sends the first packet of a connection to the Firewall Slow Path (also called the F2F path) for full inspection.

- Based on the Firewall’s decision, the remaining packets in that connection are processed through the appropriate path: Fast, Medium, or Slow.

- If the packet is accepted, SecureXL adds the required DSA tag and forwards the packet to the relevant appliance port.