1

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:

Community
  • 1
  • 1
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • @Kaii: Yes! We have to use registers rather than the CLI commands, and managed to put together a set of register write operations that made sense for tagged VLAN, but couldn't get _quite_ to the end. Someone realised that port-based VLAN on this switch does allow each port to be in multiple VLANs, so we went with that for now. I'll dig up the config later. – Lightness Races in Orbit Dec 21 '12 at 19:37

2 Answers2

1

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:

  • Add Port with "Device 1" to the "VLAN 1" (private VLAN)
  • Add Port with "Device 2" only to "VLAN 1" (private VLAN)
  • Add Port with "Device 1" to the "VLAN 2" (outside VLAN)
  • Make sure the Port with "Outside LAN" only has "VLAN 2" (outside VLAN)
  • Make sure "VLAN 0" (default VLAN) is removed from all ports.

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.

Kaii
  • 20,122
  • 3
  • 38
  • 60
  • Oh, heh. Yes. I missed that switches stick to layer 2. So if I were to hide each "unit" behind a [layer-3-aware] router then I could isolate the APIPA traffic? – Lightness Races in Orbit Dec 01 '12 at 12:18
  • 1
    @LightnessRacesinOrbit Yes. If your embedded "Device 1" had a second NIC that would be the easiest way: connect the LAN with the second NIC of "Device 1" and use the internal switch only for internal communication (no cable attached to the internal switch). – Kaii Dec 01 '12 at 12:28
  • Alas not - we've had to resort to link-local addressing as we have just the one interface at our disposal. – Lightness Races in Orbit Dec 01 '12 at 12:31
  • @LightnessRacesinOrbit good news, i digged a bit through the documentation. You are lucky - see my edit. Feel free to ask for more detail. Unfortunately, you can't upvote again for the real solution ;-) – Kaii Dec 01 '12 at 12:41
  • It's not clear that `vlandelport` supports a `` of 0; we'll try it – Lightness Races in Orbit Dec 01 '12 at 13:12
  • (Also we can't use the CLI and I can't spy a way through the registers to perform `vlancreate` yet) – Lightness Races in Orbit Dec 01 '12 at 15:49
0

The KSZ8895M datasheet (which refers instead to KS8895M throughout, so I will assume functional equivalence) says on page 24:

The KS8895M will not forward the following packets:

  • Error packets. These include framing errors, FCS errors, alignment errors, and illegal size packet errors.
  • 802.3x pause frames. The KS8895M will intercept these packets and perform the appropriate actions.
  • "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 does suggest I think that the Micrel doesn't abide by RFC 3927, but defines "local" only in the manner defined above.

Then, no, you won't be able to get this to work unfortunately.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055