My embedded system uses a Micrel KSZ8995M switch, connected to two "internal" devices (and by internal I mean sitting physically on the same board) and a LAN.
Device 1 is a ARMv5 processor running Busybox Linux, with a LAN IP configured either by DHCP or statically on eth0, and a link-local/APIPA 169.254.137.10 address on eth0:0.
Device 2 is a smaller chip running ARTOS and who knows what else, with only a link-local/APIPA 169.254.137.11 address.
+----------------------------+
| +----------+ +----------+ |
| | Device 1 | | Device 2 | |
| +-----+----+ +-----+----+ |
| | | | <-- a "unit"
| +-----+-------------+----+ |
| | Micrel KSZ899M switch | |
| +-----------+------------+ |
+-------------|--------------+
|
+--+--+
| LAN |
+ - +
The intention is for device 1 and device 2 to be able to talk to each other via TCP/IP, without any other devices on the LAN (or any recursively attached network) being able to see device 2 or see the data going between the two devices.
Also there may be multiple instances of the whole unit on the network, and the link-local addresses must not clash between units.
By my understanding, link-local addressing as defined in RFC 3927 is intended for "internal" communications only and packets dispatched between interface with link-local addressing should not be forwarded by switches or routers.
Woe and alas, with the system as a whole hooked up to the LAN, I'm seeing ARP responses to device 2 from multiple devices across the wider network, implying that the link-local IPs are visible and clashing across the network. That is, the Micrel appears to forward these and I cannot see any configuration with which to make it stop.
Have I misunderstood the way in which the APIPA addressing works?
Or, if I am correct but the Micrel merely does not support them properly, can I coerce it into compliance?
References:
By my understanding, link-local addressing as defined in RFC 3927 is intended for "internal" communications only and packets dispatched between interface with link-local addressing should not be forwarded by switches or routers.
Well, a Layer-2 switch doesn't even know about IP addresses. Your understanding is wrong. Link-local addresses must not be forwarded by routers, as defined in RFC 3927. (layer-3 network equiment)
The ARP requests are forwarded by switches, though. (layer-2 network equipment)
See the first sentence in the data sheet which states:
The KS8995M is a highly integrated Layer-2 managed switch
Refer Network Switch and the OSI Model for more details about the difference between layer-2 (MAC / Ethernet) and layer-3 (TCP/IP) communication.
As you already pointed out, the KSZ8895M does define "local" in this way:
"Local" packets. Based on DA (Destination Address) look-up. If the destination port from the look-up table matches the port where the packet was from, the packet is defined as "local".
This means that the switch does not forward packets (on layer-2, ethernet, MAC!), when the destination of this packet is assigned to the port where the packets is sent from. The "Destination Address" is a MAC address in this matter - not an IP address.
Conclusion: (REVISED)
By default, all devices attached to the switch are visible to the outside as long as the internal switch is physically connected to your LAN.
To avoid that, you must seperate the Network Segments physically or virtually.
But you are lucky, the KS8995M does support VLANs - using VLAN you can seperate the "internal" network from the outside:
This way the Port with "Device 1" can communicate with both the outside LAN segment and the private internal LAN segment. "Device 2" is virtually seperated from the outside, so the LAN can not communicate with "Device 2".
Refer Page 6 in the CLI User Guide for VLAN configuration.