SJA1105 Support Hairpin Mode

[klawson]

Can anyone from NXP advise whether the SJ1105 Ethernet switch supports "hairpin" / VEPA mode?

This is helpful for some modes of macvlan networking, which you can see in the VEPA diagram here: Introduction to Linux interfaces for virtual networking - Red Hat Developer 

In VEPA mode, for comms within the host you need the switch to be able to reflect back packets for a different MAC address on the same host, the green line below:

  

Alternatively there is Bridge mode, where the host manages packets itself within the host, as can be seen from the Bridge mode diagram from the same site, the green line showing that packets for within the same host do not go out to the physical network:

It would be helpful to understand whether the SJA1105 supports the former VEPA "hairpin" mode, but I haven't been able to confirm this from the datasheet.

Many thanks.

[jamesbone]

Yes, SJA1105 supports multicast, however, multicast addresses are not learned automatically, because they normally don’t show up as source addresses, only as destination address of a multicast packet.
However, you can manually add a multicast address with the correct routing information (to which ports this multicast packet should be sent to) into the L2 address table.

Usually multicast can be thought of as a tree, where a single host emits the multicast stream, and it gets split into one or more sub-paths on the active nodes (switches), depending where the “subscribers” to this multicast stream are sitting. Packets are duplicated, if the paths split up towards the subscribers.

This multicast tree is managed by a higher level instance, and management information is sent via specific protocols to the switching nodes. IGMP is one of those protocols. In fact, IGMP traffic is also multicast with a standard destination address, and should be trapped to the management processor of an active switch and evaluated – which could lead to setting, changing, or deleting a multicast entry in the switch address table. IGMP itself is not implemented in the switch, only the framework to trap such frames to the host processor is available. This framework has to be configured (set the trapping filters).

So, we recommend setting the route one time via a specific static L2 address table entry, as described above. The SJA1105PQRS host tools contain a python script named “write_l2_address_lookup_table” which shows how to add an entry to the L2 address table. This can be done either dynamically, or (if the multicast tree is very static in an engineered network) it can be loaded with the static config stream.

However, behavior of a “cheap switch” is also possible using SJA1105PQRS: Just add one static address table entry (you can again do that together with the static configuration stream), which uses MASK_MACADDR to only consider the “multicast bit” in the MAC address (01:00:00:00:00:00), und use 1fh (that is: all 5 ports) for DESTPORTS. This basically floods the multicasts to all ports. Flooding multicasts back to the port they have been received from is inhibited by the usual port specific REACH_PORT setting, where the bit representing the port itself is cleared, which disallows any traffic received from a port to get egressed back to this port.