Dear gentlemen,
this is not a pressing issue.
Just my lunatic idea that would help me in the lab at the moment...
Every once in a while, on random occasions, I have an opportunity to
review an Ethernet switch for its practical PTP capabilities. If I'm
lucky, I have at least two pieces of the switch on the lab desk, but
sometimes I only have one.
A particular prospective application is the electric energy business,
i.e. the power profile = L2 multicast P2P.
And, one of the test setups that have proven useful, is running PTP
through a VLAN trunk, in multiple simultaneous sessions.
There have been two different styles of running PTP (power profile)
through a VLAN trunk:
A) the old way: PTP just a single session in the default VLAN,
possibly untagged, seeping to all the untagged VLAN access ports on
the switch (ignoring VLAN isolation)
B) the more modern way: Announce+Sync+Follow-up properly tagged,
running in custom VLAN's, only the PDelay running either tagged with
the default VLAN, or untagged (on the trunk).
Now - to test the latter without a second switch, i.e. if I should
want to plug the trunk from the switch into a Linux box, I am out of
options how to cobble together the "traffic mix" in Linux.
I can certainly bind ptp4l to a VLAN subinterface, but in that case,
PDelay traffic gets tagged as well.
I've noticed the nftables' "bridge" address family, allowing me to
filter packets while passing through a soft-bridge device.
No clues if this would work per output interface for multicast
destinations.
Plus, I haven't found any way to filter the "opaque" PTP frame
structure (unknown to nftables), within the PTP ethertype, on
ptp.v2.message_id (as per the Wireshark display filter syntax).
Even if I could pull this off, I would only be able to run one such
session against the VLAN trunk, because in principle only one ptp4l
instance can handle the shared PDelay in the default VLAN.
Principally, to approach the problem systematically, I'd have to code
PTP support into the Linux soft-bridge :-) Not gonna happen, and
there's hardly any point beyond my today's hallucination.
AFAICT, ptp4l doesn't support VLAN tagging internally - which is
perfectly understandable, and probably has been debated before.
Let me know if I'm missing something :-)
Frank
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
