On a Netgear R7800 (Atheros IPQ8065) I see both CPU(eth0), CPU(eth1) in LuCI. Why do we need 2 interfaces? Is each one somehow tied to each CPU core or it has nothing to do with CPU cores?
As followup, what is the correct way to configure the following scenarios:
Scenario 1:
Plain access point mode, with WAN port being another LAN port. Do I delete VLAN2 and tag CPU(eth0) on VLAN1 and move WAN port to VLAN1 untagged?
Scenario 2:
WAN port just another LAN port
VLAN5 and VLAN1 tagged on LAN4 port uplink (trunk?) to another wired router that knows about VLAN1&5
additional Guest SSID on the 2.4GHz radio only, bridged to VLAN5
In both cases I don't know what to do with VLAN2 and CPU(eth0).
The switch chip has 7 ports. Five of those are the Ethernet ports on the outside of the case, and two are internal connections between the switch chip and the CPU chip. At the CPU end they are accessed as eth0 and eth1. This has nothing to do with the number of processor cores. It is possible to share a single CPU port between WAN and LAN duties, and some lower-end routers do that, but it becomes a bottleneck at ISP speeds over half of the ethernet port speed (500 Mbps in this case).
The switch can switch anything to anything.
In scenario 1 you could just change the WAN ethernet port from being in VLAN2 to being in VLAN1 along with the other 4 LAN ports, so they all work the same as LAN ports. VLAN2 and eth0 would be unused. You don't have to delete VLAN2 from the switch, it would sit unused.
Scenario 2 you could change the second VLAN number from 2 to 5, then tag them both to an external port. The guest network would attach to VLAN5 as eth0.5 if you tag the CPU ports, or eth0 if they are untagged.
Two physical interfaces are an advantage in getting information in, out, and through the CPU. They are both "wired" to the CPU (typically inside the SoC). On a multi-core CPU, the kernel determines which core is performing a task at any given instant in time.
Those two physical interfaces are connected to the switch, which then lets you "wire" them to the various physical ports.
Typically "eth0" (to pick one) is used for traffic to/from the ISP and "eth1" is for traffic to/from the local network. In many situations, this balances the two, as a lot of traffic through the router is to/from the local network and the open Internet.
In my use of all-in-one routers as APs, I typically will use the "other" Ethernet interface for my management interface. That way if there is something wrong with the network (or DoS of some sort) that is dragging down the wire-to-wireless interface, I hopefully can still access the device through the management interface.
Lots of good info. Thanks! Glad I asked.
To summarize, in plain access point mode, it should not matter whether a single eth is used, which one is used or if both of them are used for different VLANs.
I've seen some chatter about irqbalance and distributing the load across cores, does having 2 eth ports help with that? I'm just curious how it all works at this point.
Ports eth0 and eth1 must be tagged otherwise the CPU doesn't know where the traffic comes from, correct? But do they have to be tagged in a very simple scenario where there's a single VLAN1 in access point mode, in effect making it all just a switch?
What happens if you tag both eth0 and eth1 to VLAN1, is that allowed?
Can one have a combination say eth0 tagged, eth1 untagged? Or is it enforced that eth0/1 must be tagged?
I could try all of these but not sure whether the hardware rules are enforced in LuCI or OopenWRT and also don't want to lock myself out and reset it all (which I've done before).
There are two places that tagging is important, leaving out "one-armed" configurations; in the switch and on the interface itself.
The switch works by "wiring" all ports that have the same VLAN together. When a packet arrives at a port, if it is untagged, it is given the PVID as a tag. If it is already tagged and it is a "permitted" VLAN tag, it retains the tag. Depending on the specifics of the switch and its driver, if it is not a permitted tag, the packet may be dropped (I haven't seen config parameters for this behavior nor looked for it in detail). Inside the switch, if the destination MAC address is on a port that permits the VLAN, then it is sent out that port. For broadcast packets, it is sent out all ports that permit that VLAN. If the port is tagged for that VLAN, the tag is retained. If the port is untagged for that VLAN, the tag is dropped.
The interface can also have tags, each of which creates a "sub-interface" that can be accessed by the kernel, and through the kernel user-space applications. Each sub-interface "filters" to that specific VLAN, and tags outgoing packets with the VLAN. Each sub-interface (or bridge over that sub-interface) typically has its own IPv4 address, and its own set of IPv6 addresses. This allows "trunking" where one physical wire (which may be inside of the SoC or on the PCB) handles multiple subnets or streams of data. If you're only carrying one stream of data to/from a physical interface, you don't really need to use tagging as the switch's use of PVID is sufficient. Personally, when I can, I always use VLAN tags for clarity and future extensibility. That said, my network infrastructure uses many VLANs for segregation of traffic, monitoring, and firewalling.
If you tag both eth0 and eth1 to the same VLAN, that should be OK, as long as they don't have the same IP address. It's like plugging them both into the same Ethernet cable.
Most of what you describe will "work" if both the interfaces and the switch are configured properly, if you only have one stream of data to/from each of the physical interfaces.
If there is only one VLAN connected to a port it doesn't have to be tagged. Tagging the CPU ports from the outset makes sense though because it is then easy to add more VLANs without needing to reconfigure the existing networks in the CPU.
Yes, but there is no point to doing that. It would make the LAN available to the CPU in two redundant places, eth0.1 and eth1.1.
If you did connect both of those to the LAN software bridge, you have a network loop, which is bad. Packets will start chasing around the loop and use up all the bandwidth, essentially DoS'ing yourself.
So don't do that. There's no point.
Yes of course. The two ports are independent of each other.
A good way not to lock yourself out is to connect to the LAN via wifi before you start changing switch settings. Then if you mess up the Ethernet system you can still get in on wifi.
I have a problem on TP-Link Archer C7v2, running 21.02.0-rc.3. As far as I've understood from this thread, I can choose either CPU (eth1) or CPU (eth0) to handle a specific VLAN. But: If I swap VLAN 10 from CPU (eth1) to CPU(eth0) I loose access to my device. VLAN 10 is the management VLAN, connected to the LAN infrastructure via the TP-Link's WAN port.
Forced the above config marked as "Not working - LUCI NOT accessible over LAN:" onto the device, rebooted, and it is still not accessible. I suspect there may be a bug or something in my way. Why can't I bridge CPU(eth0) to tagged VLAN 10 "mgmt" and access it via the LAN wired to the "WAN" port? It only works when tagging VLAN 10 to CPU(eth1).
I can't answer you, sorry, but I can thank you for documenting the configuration that blocks you out from the router, because that is something that happened to me.
You have to also change the lan's software connection from eth1.10 to eth0.10 in the LAN bridge (physical settings tab on edit the lan network).
Generally one would use one CPU port for the WAN link to the ISP and the other one for everything else. On something like a C7 where the CPU is way too slow to route at gigabit speed anyway, port allocation isn't something that needs to be optimized.
@mk24 Perfect. Assigning all bridges to eth0.10 (instead of eth1.10) helped so I could set CPU (eth1) completely to "off" and CPU (eth0) completely to "tagged".
