For LS1028, Where can the kernel extract the packets

[liu-jeff]

Hello, I want to know where can I extract the data packet in the kernel for LS1028

[vladimiroltean]

I find this question strange. What do you want to do, and why do you want to do custom packet processing in the kernel?

[liu-jeff]

I find this question strange. What do you want to do, and why do you want to do custom packet processing in the kernel?

I want to do something with packets forwarded by the switch, such as changing the IP header

[vladimiroltean]

You want to trap certain frames towards the CPU port of the switch, and re-inject them after modification? What criteria do you need for the frame trapping decision?

[liu-jeff]

You want to trap certain frames towards the CPU port of the switch, and re-inject them after modification? What criteria do you need for the frame trapping decision?

I expected the data forwarded by the switch to pass through the kernel, and then I modified the packet field in the kernel forward function. But it doesn't seem to go through the kernel, right?

[vladimiroltean]

No, by default the switch data path is completely offloaded in hardware. The CPU is just another switch port and by default it sees only the broadcast, unknown unicast and multicast frames. By adding trapping decisions, you can tell it to redirect some of the frames from the normal L2 forwarding process and just send them to the CPU. The trapping mechanism in sja1105 is not very advanced and you can only look at layer 2 information (destination MAC, VLAN ID).

[liu-jeff]

You want to trap certain frames towards the CPU port of the switch, and re-inject them after modification? What criteria do you need for the frame trapping decision?

No, by default the switch data path is completely offloaded in hardware. The CPU is just another switch port and by default it sees only the broadcast, unknown unicast and multicast frames. By adding trapping decisions, you can tell it to redirect some of the frames from the normal L2 forwarding process and just send them to the CPU. The trapping mechanism in sja1105 is not very advanced and you can only look at layer 2 information (destination MAC, VLAN ID).

If so, what should I do if I want to change the IP header of the switch forwarding packet

[liu-jeff]

No, by default the switch data path is completely offloaded in hardware. The CPU is just another switch port and by default it sees only the broadcast, unknown unicast and multicast frames. By adding trapping decisions, you can tell it to redirect some of the frames from the normal L2 forwarding process and just send them to the CPU. The trapping mechanism in sja1105 is not very advanced and you can only look at layer 2 information (destination MAC, VLAN ID).

For example, if I want to change the IP header of a frame with vlan priority of 7, how should I set the capture rule, or can I configure the switch directly in the CPU to change the IP header of the frame

[vladimiroltean]

If so, what should I do if I want to change the IP header of the switch forwarding packet

If you need some sort of IP routing offload, the sja1105 switch does not support that. It is a plain L2 switch. If you are ok with doing this in software, then a DSA/switchdev driver exposes one net device for each switch port by default. They don't do any sort of switching between them and act as 4 NICs by default (they just talk to the CPU port). Then hardware switching is enabled when the ports are put under a bridge. With this model, all you need to do is not put the switch ports in a bridge, and they will all transit the CPU and you can do your rewriting with netfilter, etc. But then you lose all TSN guarantees unless you create a custom application with real-time frame processing abilities.

[vladimiroltean]

For example, if I want to change the IP header of a frame with vlan priority of 7, how should I set the capture rule, or can I configure the switch directly in the CPU to change the IP header of the frame

You cannot use only VLAN PCP for frame trapping decisions. You can configure a plain L2 forwarding table entry, for routing to the CPU port based on {DMAC, VLAN ID}, or add a Virtual Link, which uses {DMAC, VLAN ID, VLAN PCP}, or add a MAC filtering entry, which just traps frames based on a maskable DMAC (the other 2 options do not use maskable keys).

[liu-jeff]

If so, what should I do if I want to change the IP header of the switch forwarding packet

If you need some sort of IP routing offload, the sja1105 switch does not support that. It is a plain L2 switch. If you are ok with doing this in software, then a DSA/switchdev driver exposes one net device for each switch port by default. They don't do any sort of switching between them and act as 4 NICs by default (they just talk to the CPU port). Then hardware switching is enabled when the ports are put under a bridge. With this model, all you need to do is not put the switch ports in a bridge, and they will all transit the CPU and you can do your rewriting with netfilter, etc. But then you lose all TSN guarantees unless you create a custom application with real-time frame processing abilities.

LS1028 switch chip is not sja1105 ah, it is not integrated with the CPU in one?

[liu-jeff]

For example, if I want to change the IP header of a frame with vlan priority of 7, how should I set the capture rule, or can I configure the switch directly in the CPU to change the IP header of the frame

You cannot use only VLAN PCP for frame trapping decisions. You can configure a plain L2 forwarding table entry, for routing to the CPU port based on {DMAC, VLAN ID}, or add a Virtual Link, which uses {DMAC, VLAN ID, VLAN PCP}, or add a MAC filtering entry, which just traps frames based on a maskable DMAC (the other 2 options do not use maskable keys).

Is this for 1021 or 1028

[liu-jeff]

For example, if I want to change the IP header of a frame with vlan priority of 7, how should I set the capture rule, or can I configure the switch directly in the CPU to change the IP header of the frame

You cannot use only VLAN PCP for frame trapping decisions. You can configure a plain L2 forwarding table entry, for routing to the CPU port based on {DMAC, VLAN ID}, or add a Virtual Link, which uses {DMAC, VLAN ID, VLAN PCP}, or add a MAC filtering entry, which just traps frames based on a maskable DMAC (the other 2 options do not use maskable keys).

For ls1028, if also need to do the same, how do I configure a L2 forwarding table entry,

[vladimiroltean]

My bad. For the LS1028A Felix switch, you can trap frames based on VLAN PCP. You need to do something like this:

tc qdisc add dev swp0 ingress
tc filter add dev swp0 protocol 802.1Q parent ffff: flower skip_sw vlan_id 100 vlan_prio 7 action trap

Warning: I did not check this particular key, it is just based on other similar commands that have worked.

Now the theory is the same as in the LS1021A-TSN case. These frames are removed from the hardware data path, you can use the likes of netfilter to process/mangle those frames on the prerouting chain of swp0, and activate IP routing, software bridging, etc, between swp0 and another egress switch port. Warning 2: I did not actually try this either.

Frame trapping on LS1028A is not available in official OpenIL yet, you can use a "community" image to evaluate this feature. At some point in the future it will be integrated into official OpenIL as well.

[liu-jeff]

My bad. For the LS1028A Felix switch, you can trap frames based on VLAN PCP. You need to do something like this:

tc qdisc add dev swp0 ingress
tc filter add dev swp0 protocol 802.1Q parent ffff: flower skip_sw vlan_id 100 vlan_prio 7 action trap

Warning: I did not check this particular key, it is just based on other similar commands that have worked.

Now the theory is the same as in the LS1021A-TSN case. These frames are removed from the hardware data path, you can use the likes of netfilter to process/mangle those frames on the prerouting chain of swp0, and activate IP routing, software bridging, etc, between swp0 and another egress switch port. Warning 2: I did not actually try this either.

Frame trapping on LS1028A is not available in official OpenIL yet, you can use a "community" image to evaluate this feature. At some point in the future it will be integrated into official OpenIL as well.

Thank you very much. Will the features of the LS1028A TSN disappear if you do this?

[liu-jeff]

My bad. For the LS1028A Felix switch, you can trap frames based on VLAN PCP. You need to do something like this:

tc qdisc add dev swp0 ingress
tc filter add dev swp0 protocol 802.1Q parent ffff: flower skip_sw vlan_id 100 vlan_prio 7 action trap

Warning: I did not check this particular key, it is just based on other similar commands that have worked. Now the theory is the same as in the LS1021A-TSN case. These frames are removed from the hardware data path, you can use the likes of netfilter to process/mangle those frames on the prerouting chain of swp0, and activate IP routing, software bridging, etc, between swp0 and another egress switch port. Warning 2: I did not actually try this either. Frame trapping on LS1028A is not available in official OpenIL yet, you can use a "community" image to evaluate this feature. At some point in the future it will be integrated into official OpenIL as well.

Thank you very much. Will the features of the LS1028A TSN disappear if do this?

[vladimiroltean]

For the trapped frames, there will be additional latency incurred by the software processing path. Your operating system and application needs to ensure there is a bounded upper limit to this response time (using trace-cmd, kernelshark, etc etc).

[liu-jeff]

For the trapped frames, there will be additional latency incurred by the software processing path. Your operating system and application needs to ensure there is a bounded upper limit to this response time (using trace-cmd, kernelshark, etc etc).

Thank you very much. I also want to know if the LS1028 has the same characteristics as the LS1021， The CPU is just another switch port and by default it sees only the broadcast, unknown unicast and multicast frames？ if it is ,right now, I only have a LS1021 board. I want to test it with LS1021 first.how do I configure a L2 forwarding table entry,

[vladimiroltean]

Largely yes. In the LS1028A there are 2 CPU ports, swp4 running at 2.5G and swp5 running at 1G. One of the CPU ports has DSA tagging abilities, which means that it is able to annotate frames sent on that port with metadata such as the source port that the frame came from, QoS class etc. Similarly, the switch understands and consumes these tags also when the CPU sends frames to it over the CPU port, such that you can do explicit transmission on a certain front-panel port and bypass the normal switching process. On the other hand, the sja1105 does not have native support for DSA tagging. You have to (and can) use VLAN tags to accomplish this purpose. But other than that, the CPU port is just an Ethernet port in both cases. If the switch learns that a flow needs to be forwarded between two front-panel ports only, of course it will not send those frames to the CPU any longer. On the other hand, BUM frames (broadcast, unknown unicast, multicast) need to be initially flooded on all ports including the CPU, because the destination might be a non-switch port, case in which the CPU needs to take over those frames and do software bridging. Flooding and learning are enabled by default on bridged switch ports, and frame trapping, in this context, is just a mechanism to only deliver certain frames to the CPU (they should initially reach the CPU anyway, it is just a matter of whether the CPU responds in such a way that the switch learns the destination MAC). You can confirm this with tcpdump on the switch master interface (eth2). So, what do you need?

[liu-jeff]

Largely yes. In the LS1028A there are 2 CPU ports, swp4 running at 2.5G and swp5 running at 1G. One of the CPU ports has DSA tagging abilities, which means that it is able to annotate frames sent on that port with metadata such as the source port that the frame came from, QoS class etc. Similarly, the switch understands and consumes these tags also when the CPU sends frames to it over the CPU port, such that you can do explicit transmission on a certain front-panel port and bypass the normal switching process. On the other hand, the sja1105 does not have native support for DSA tagging. You have to (and can) use VLAN tags to accomplish this purpose. But other than that, the CPU port is just an Ethernet port in both cases. If the switch learns that a flow needs to be forwarded between two front-panel ports only, of course it will not send those frames to the CPU any longer. On the other hand, BUM frames (broadcast, unknown unicast, multicast) need to be initially flooded on all ports including the CPU, because the destination might be a non-switch port, case in which the CPU needs to take over those frames and do software bridging. Flooding and learning are enabled by default on bridged switch ports, and frame trapping, in this context, is just a mechanism to only deliver certain frames to the CPU (they should initially reach the CPU anyway, it is just a matter of whether the CPU responds in such a way that the switch learns the destination MAC). You can confirm this with tcpdump on the switch master interface (eth2). So, what do you need? I used tcpdump on the LS1021ATSN board, and I couldn't catch the packets forwarded by the switch. I now want to capture the packets forwarded by the switch on the CPU, and then modify the ip header of the packet.

[liu-jeff]

Largely yes. In the LS1028A there are 2 CPU ports, swp4 running at 2.5G and swp5 running at 1G. One of the CPU ports has DSA tagging abilities, which means that it is able to annotate frames sent on that port with metadata such as the source port that the frame came from, QoS class etc. Similarly, the switch understands and consumes these tags also when the CPU sends frames to it over the CPU port, such that you can do explicit transmission on a certain front-panel port and bypass the normal switching process. On the other hand, the sja1105 does not have native support for DSA tagging. You have to (and can) use VLAN tags to accomplish this purpose. But other than that, the CPU port is just an Ethernet port in both cases. If the switch learns that a flow needs to be forwarded between two front-panel ports only, of course it will not send those frames to the CPU any longer. On the other hand, BUM frames (broadcast, unknown unicast, multicast) need to be initially flooded on all ports including the CPU, because the destination might be a non-switch port, case in which the CPU needs to take over those frames and do software bridging. Flooding and learning are enabled by default on bridged switch ports, and frame trapping, in this context, is just a mechanism to only deliver certain frames to the CPU (they should initially reach the CPU anyway, it is just a matter of whether the CPU responds in such a way that the switch learns the destination MAC). You can confirm this with tcpdump on the switch master interface (eth2). So, what do you need? Since I do not have LS1028 board for the time being,for LS1021, I want to know how to configure L2 forwarding table entry so that its CPU can capture the packets forwarded by the switch

[vladimiroltean]

I want to know how to configure L2 forwarding table entry so that its CPU can capture the packets forwarded by the switch

Considering the above discussion, you do understand that:

• The CPU should already see the frames because it is a flooding destination
• L2 forwarding table entries act on the {DMAC, VID} from frames only
• There are 2 types of L2 forwarding entries: static (what I initially suggested, aka programmed by the user) and dynamic (automatically learned, based on the source MAC and VID of frames received by the switch on CPU ports), that achieve the same purpose (the difference being that you don't need to do anything for a dynamic forwarding entry)

I would like you to confirm that this is what you want:

• Trap frames on a switch port such as ETH2, based on {DMAC, VID} matching (e.g. DMAC corresponds to another host aa:bb:cc:dd:ee:ff, with e.g. VID 100)
• The CPU identifies the IP header and replaces the source and destination address, while keeping the Ethernet header intact
• The rewritten frame is re-injected on another switch port, e.g. ETH3
• Other frames that don't match the aa:bb:cc:dd:ee:ff DMAC and VID 100 are not trapped to the CPU, but instead forwarded autonomously by the switch.

The reason I'm asking is that I don't have a good way of suggesting you to do that at the moment. But if the above works for you in principle, I can implement a tc flower command for trapping based on a limited set of keys, that would behave the same way as it does on the LS1028A.

[liu-jeff]

I want to know how to configure L2 forwarding table entry so that its CPU can capture the packets forwarded by the switch

Considering the above discussion, you do understand that:

• The CPU should already see the frames because it is a flooding destination
• L2 forwarding table entries act on the {DMAC, VID} from frames only
• There are 2 types of L2 forwarding entries: static (what I initially suggested, aka programmed by the user) and dynamic (automatically learned, based on the source MAC and VID of frames received by the switch on CPU ports), that achieve the same purpose (the difference being that you don't need to do anything for a dynamic forwarding entry)

I would like you to confirm that this is what you want:

• Trap frames on a switch port such as ETH2, based on {DMAC, VID} matching (e.g. DMAC corresponds to another host aa:bb:cc:dd:ee:ff, with e.g. VID 100)
• The CPU identifies the IP header and replaces the source and destination address, while keeping the Ethernet header intact
• The rewritten frame is re-injected on another switch port, e.g. ETH3
• Other frames that don't match the aa:bb:cc:dd:ee:ff DMAC and VID 100 are not trapped to the CPU, but instead forwarded autonomously by the switch.

The reason I'm asking is that I don't have a good way of suggesting you to do that at the moment. But if the above works for you in principle, I can implement a tc flower command for trapping based on a limited set of keys, that would behave the same way as it does on the LS1028A.

Yes, can you tell me the command

[liu-jeff]

Largely yes. In the LS1028A there are 2 CPU ports, swp4 running at 2.5G and swp5 running at 1G. One of the CPU ports has DSA tagging abilities, which means that it is able to annotate frames sent on that port with metadata such as the source port that the frame came from, QoS class etc. Similarly, the switch understands and consumes these tags also when the CPU sends frames to it over the CPU port, such that you can do explicit transmission on a certain front-panel port and bypass the normal switching process. On the other hand, the sja1105 does not have native support for DSA tagging. You have to (and can) use VLAN tags to accomplish this purpose. But other than that, the CPU port is just an Ethernet port in both cases. If the switch learns that a flow needs to be forwarded between two front-panel ports only, of course it will not send those frames to the CPU any longer. On the other hand, BUM frames (broadcast, unknown unicast, multicast) need to be initially flooded on all ports including the CPU, because the destination might be a non-switch port, case in which the CPU needs to take over those frames and do software bridging. Flooding and learning are enabled by default on bridged switch ports, and frame trapping, in this context, is just a mechanism to only deliver certain frames to the CPU (they should initially reach the CPU anyway, it is just a matter of whether the CPU responds in such a way that the switch learns the destination MAC). You can confirm this with tcpdump on the switch master interface (eth2). So, what do you need? For LS1021, I want to know how to configure L2 forwarding table entry so that its CPU can capture the packets forwarded by the switch。

I want to know how to configure L2 forwarding table entry so that its CPU can capture the packets forwarded by the switch

Considering the above discussion, you do understand that:

• The CPU should already see the frames because it is a flooding destination
• L2 forwarding table entries act on the {DMAC, VID} from frames only
• There are 2 types of L2 forwarding entries: static (what I initially suggested, aka programmed by the user) and dynamic (automatically learned, based on the source MAC and VID of frames received by the switch on CPU ports), that achieve the same purpose (the difference being that you don't need to do anything for a dynamic forwarding entry)

I would like you to confirm that this is what you want:

• Trap frames on a switch port such as ETH2, based on {DMAC, VID} matching (e.g. DMAC corresponds to another host aa:bb:cc:dd:ee:ff, with e.g. VID 100)
• The CPU identifies the IP header and replaces the source and destination address, while keeping the Ethernet header intact
• The rewritten frame is re-injected on another switch port, e.g. ETH3
• Other frames that don't match the aa:bb:cc:dd:ee:ff DMAC and VID 100 are not trapped to the CPU, but instead forwarded autonomously by the switch.

The reason I'm asking is that I don't have a good way of suggesting you to do that at the moment. But if the above works for you in principle, I can implement a tc flower command for trapping based on a limited set of keys, that would behave the same way as it does on the LS1028A.

Thank you very much,I roughly hope so. However, I want to change the ipv6 header of the packet in the kernel so that its tsn can be recognized at three layers, such as the mapping of vlan priority and traffic class Could you please give me some suggestions!

[vladimiroltean]

However, I want to change the ipv6 header of the packet in the kernel so that its tsn can be recognized at three layers, such as the mapping of vlan priority and traffic class

I don't understand. So you don't want to do any sort of routing, you just want to fix up the IPv6 traffic class (DSCP) to match the value of the L2 COS (VLAN PCP)? Why do you insist on doing that on the switch if it doesn't natively support it? Can't you do it at the sender side (assign VLAN PCP based on DSCP value, and then the switch just looks at the PCP field), instead of wasting time trapping the frames to modify the headers? Alternatively, the LS1028A Felix can do QoS classification on L3 information, with the "tsntool dscpset" command. Is this what you want?

[liu-jeff]

However, I want to change the ipv6 header of the packet in the kernel so that its tsn can be recognized at three layers, such as the mapping of vlan priority and traffic class

I don't understand. So you don't want to do any sort of routing, you just want to fix up the IPv6 traffic class (DSCP) to match the value of the L2 COS (VLAN PCP)? Why do you insist on doing that on the switch if it doesn't natively support it? Can't you do it at the sender side (assign VLAN PCP based on DSCP value, and then the switch just looks at the PCP field), instead of wasting time trapping the frames to modify the headers? Alternatively, the LS1028A Felix can do QoS classification on L3 information, with the "tsntool dscpset" command. Is this what you want?

Thank you very much,For LS1028, since L3 information can be managed by tsntool, is the Felix switch an L3 device?

[vladimiroltean]

I would not call it an L3 switch since it is not able to do IP routing offload. It has a limited set of classification actions based on IP information.

[liu-jeff]

I would not call it an L3 switch since it is not able to do IP routing offload. It has a limited set of classification actions based on IP information.

So, for LS1028, can I use tsntool to modify the DSCP field of IPV6 packets?

[liu-jeff]

I would not call it an L3 switch since it is not able to do IP routing offload. It has a limited set of classification actions based on IP information.

But I not only want to modify the DSCP field of the packet, I also want to use the extension header of IPV6 to add some information I want.

[vladimiroltean]

The LS1028A Felix rewriter can change the DSCP from IPv6 but apparently not more, and certainly nothing from the extension header. Also, the DSCP rewriting is not supported yet in the driver by the way.

[liu-jeff]

The LS1028A Felix rewriter can change the DSCP from IPv6 but apparently not more, and certainly nothing from the extension header. Also, the DSCP rewriting is not supported yet in the driver by the way.

So I may still need to redirect the package to the CPU,you say you can implement a tc flower command for trapping based on a limited set of keys ,Could you please tell me how to do that?

[liu-jeff]

The LS1028A Felix rewriter can change the DSCP from IPv6 but apparently not more, and certainly nothing from the extension header. Also, the DSCP rewriting is not supported yet in the driver by the way.

I am looking forward to your reply！

[vladimiroltean]

This thread has been bouncing back and forth between LS1021A and LS1028A, so I am not exactly sure what you are looking forward to. Frame trapping based on source port, DMAC, VID and PCP on LS1021A?

[liu-jeff]

yes , I want to trap frame based on source port, DMAC, VID and PCP on LS1021A

[liu-jeff]

so could you please tell me how to do it

[vladimiroltean]

#!/bin/bash
# SPDX-License-Identifier: GPL-2.0

set -e -u -o pipefail

# The switch flow classification core implements ARINC 664 part 7 (AFDX) and
# 'thinks' in terms of Virtual Links (VL). However it also has one other
# operating mode (VLLUPFORMAT=0) where it acts closer to a pre-standard
# implementation of IEEE 802.1Qci (Per-Stream Filtering and Policing), which is
# what the driver is going to be implementing.
#
#                                 VL Lookup
#        Key = {DMAC && VLANID   +---------+  Key = { (DMAC[47:16] & VLMASK ==
#               && VLAN PCP      |         |                         VLMARKER)
#               && INGRESS PORT} +---------+                      (both fixed)
#            (exact match,            |             && DMAC[15:0] == VLID
#         all specified in rule)      |                    (specified in rule)
#                                     v             && INGRESS PORT }
#                               ------------
#                    0 (PSFP)  /            \  1 (ARINC664)
#                 +-----------/  VLLUPFORMAT \----------+
#                 |           \    (fixed)   /          |
#                 |            \            /           |
#  0 (forwarding) v             ------------            |
#           ------------                                |
#          /            \  1 (QoS classification)       |
#     +---/  ISCRITICAL  \-----------+                  |
#     |   \  (per rule)  /           |                  |
#     |    \            /   VLID taken from      VLID taken from
#     v     ------------     index of rule       contents of rule
#  select                     that matched         that matched
# DESTPORTS                          |                  |
#  |                                 +---------+--------+
#  |                                           |
#  |                                           v
#  |                                     VL Forwarding
#  |                                   (indexed by VLID)
#  |                                      +---------+
#  |                                      |         |
#  |                                      +---------+
#  |                                           |
#  |                                select TYPE, PRIORITY,
#  |                                 PARTITION, DESTPORTS
#  |                                           |
#  |                       +-------------------+
#  |                       |
#  |                       v
#  |   0 (rate      ------------    1 (time
#  |  constrained) /            \   triggered)
#  |       +------/     TYPE     \------------+
#  |       |      \  (per VLID)  /            |
#  |       v       \            /             v
#  |  VL Policing   ------------         VL Policing
#  |  +---------+                        +---------+
#  |  |         |                        |         |
#  |  +---------+                        +---------+
#  |  select SHARINDX                 select SHARINDX to
#  |  to rate-limit                 re-enter VL Forwarding
#  |  groups of VL's               with new VLID for egress
#  |  to same quota                           |
#  |       |                                  v
#  |       v                            select MAXLEN
#  |  select MAXLEN,                          |
#  |   BAG, JITTER                            v
#  |       |             ----------------------------------------------
#  |       v            /    Reception Window is open for this VL      \
#  |  exceed => drop   /    (the Schedule Table executes an entry i     \
#  |       |          /   M <= i < N, for which these conditions hold):  \ no
#  |       |    +----/                                                    \-+
#  |       |    |yes \       WINST[M] == 1 && WINSTINDEX[M] == VLID       / |
#  |       |    |     \     WINEND[N] == 1 && WINSTINDEX[N] == VLID      /  |
#  |       |    |      \                                                /   |
#  |       |    |       \ (the VL window has opened and not yet closed)/    |
#  |       |    |        ----------------------------------------------     |
#  |       |    v                                                           v
#  |       |  dispatch to DESTPORTS when the Schedule Table               drop
#  |       |  executes an entry i with TXEN == 1 && VLINDEX == i
#  v       v
# dispatch immediately to DESTPORTS
#
# The per-port classification key is always composed of {DMAC, VID, PCP} and
# is non-maskable. This 'looks like' the NULL stream identification function
# from IEEE 802.1CB clause 6, except for the extra VLAN PCP (which we could
# allow the user to not specify, and then the port-based default will be
# used).
#
# The action is always a full triplet of:
# a. 'police': (rate-based or time-based) and size-based
# b. 'flow steering': select the traffic class on the egress port
# c. 'redirect': select the egress port list
#
# For c, using Virtual Links to forward traffic based on {source port, DMAC,
# VID} may appear at first quite pointless, but in fact it allows the creation
# of private (per-port) FDB tables. The DESTPORTS feature can be used to
# implement e.g. flow trapping (redirect to CPU), which is what the demo below
# shows.

# But nonetheless, specifying DESTPORTS in the action is mandatory even if the
# intended behavior is unrelated to routing. So what we can do in the driver is
# to only allow the user to specify a VL rule for a {DMAC, VLAN} pair for which
# a static FDB entry has already been input. Then we can take the matching
# ports from the driver's list of static FDB entries and use those to populate
# DESTPORTS for the action. The end result is that the static FDB entry will be
# shadowed by a VL rule, but the forwarding decision will still be as per user
# request.
#
# For a and b, it would be nice to be able to do flow steering and policing as
# independent actions. So we can do:
# - Policing without flow steering: configure the PRIORITY of the VL to be the
#   port-based default priority.
# - Flow steering without policing: configure the VL as ISCRITICAL=1 and
#   TYPE=0 (rate constrained), but set BAG=0 and JITTER=0 to disable the
#   bandwidth checks.

# Chassis label to chip port mapping
swp2=1
swp3=2
swp4=3
swp5=0
cpu=4

sja1105-tool conf def ls1021atsn

# On swp4, trap all incoming frames with a DMAC of 01:02:03:04:05:06, a VID of
# 0 and a PCP of 0 (both port-based defaults) to the CPU
sja1105-tool config modify vl-lookup-table entry-count 1
sja1105-tool config modify vl-lookup-table[0] destports $((1 << $cpu))
sja1105-tool config modify vl-lookup-table[0] iscritical 0
sja1105-tool config modify vl-lookup-table[0] macaddr 01:02:03:04:05:06
sja1105-tool config modify vl-lookup-table[0] vlanid 0
sja1105-tool config modify vl-lookup-table[0] vlanprior 0
sja1105-tool config modify vl-lookup-table[0] port $swp4

# Mandatory table, but otherwise ignored because iscritical=0
sja1105-tool config modify vl-policing-table entry-count 1

# Mandatory table, but otherwise ignored because iscritical=0
sja1105-tool config modify vl-forwarding-table entry-count 1

# Define the frame buffer partitioning between the best-effort traffic and the
# virtual links. Again, this only needs to be formally specified: because we
# are only using virtual links with iscritical=0 (aka not really virtual
# links), we can actually not specify any memory at all for them.
sja1105-tool config modify l2-forwarding-parameters-table[0] part_spc "[910 0 0 0 0 0 0 0]"
sja1105-tool config modify vl-forwarding-parameters-table entry-count 1
sja1105-tool config modify vl-forwarding-parameters-table[0] partspc "[0 0 0 0 0 0 0 0]"

sja1105-tool config upload

# Test environment:
#       +----------------------------+
#       |           Switch           |
#       |                            |
#       | swp5       swp3       eth1 |
#       | swp4       swp2       eth0 |
#       +--|----------|--------------+
#          |          |
#      +---+          +--------------+
#      |                             |
# +---------+                   +---------+
# |   Host  |                   |   Host  |
# |    A    |                   |    B    |
# +---------+                   +---------+
#
# Host A runs:
# arp -s 10.0.0.200 01:02:03:04:05:06 dev eth0
# ping -f 10.0.0.200
#
# The switch runs:
# ./trapping.sh
# tcpdump -i eth2
# and sees all packets
#
# Host B runs:
# tcpdump -i eth0
# and sees no packet

[liu-jeff]

For the trapped frames, there will be additional latency incurred by the software processing path. Your operating system and application needs to ensure there is a bounded upper limit to this response time (using trace-cmd, kernelshark, etc etc).

Thank you very much. I also want to know if the LS1028 has the same characteristics as the LS1021， The CPU is just another switch port and by default it sees only the broadcast, unknown unicast and multicast frames？

#!/bin/bash
# SPDX-License-Identifier: GPL-2.0

set -e -u -o pipefail

# The switch flow classification core implements ARINC 664 part 7 (AFDX) and
# 'thinks' in terms of Virtual Links (VL). However it also has one other
# operating mode (VLLUPFORMAT=0) where it acts closer to a pre-standard
# implementation of IEEE 802.1Qci (Per-Stream Filtering and Policing), which is
# what the driver is going to be implementing.
#
#                                 VL Lookup
#        Key = {DMAC && VLANID   +---------+  Key = { (DMAC[47:16] & VLMASK ==
#               && VLAN PCP      |         |                         VLMARKER)
#               && INGRESS PORT} +---------+                      (both fixed)
#            (exact match,            |             && DMAC[15:0] == VLID
#         all specified in rule)      |                    (specified in rule)
#                                     v             && INGRESS PORT }
#                               ------------
#                    0 (PSFP)  /            \  1 (ARINC664)
#                 +-----------/  VLLUPFORMAT \----------+
#                 |           \    (fixed)   /          |
#                 |            \            /           |
#  0 (forwarding) v             ------------            |
#           ------------                                |
#          /            \  1 (QoS classification)       |
#     +---/  ISCRITICAL  \-----------+                  |
#     |   \  (per rule)  /           |                  |
#     |    \            /   VLID taken from      VLID taken from
#     v     ------------     index of rule       contents of rule
#  select                     that matched         that matched
# DESTPORTS                          |                  |
#  |                                 +---------+--------+
#  |                                           |
#  |                                           v
#  |                                     VL Forwarding
#  |                                   (indexed by VLID)
#  |                                      +---------+
#  |                                      |         |
#  |                                      +---------+
#  |                                           |
#  |                                select TYPE, PRIORITY,
#  |                                 PARTITION, DESTPORTS
#  |                                           |
#  |                       +-------------------+
#  |                       |
#  |                       v
#  |   0 (rate      ------------    1 (time
#  |  constrained) /            \   triggered)
#  |       +------/     TYPE     \------------+
#  |       |      \  (per VLID)  /            |
#  |       v       \            /             v
#  |  VL Policing   ------------         VL Policing
#  |  +---------+                        +---------+
#  |  |         |                        |         |
#  |  +---------+                        +---------+
#  |  select SHARINDX                 select SHARINDX to
#  |  to rate-limit                 re-enter VL Forwarding
#  |  groups of VL's               with new VLID for egress
#  |  to same quota                           |
#  |       |                                  v
#  |       v                            select MAXLEN
#  |  select MAXLEN,                          |
#  |   BAG, JITTER                            v
#  |       |             ----------------------------------------------
#  |       v            /    Reception Window is open for this VL      \
#  |  exceed => drop   /    (the Schedule Table executes an entry i     \
#  |       |          /   M <= i < N, for which these conditions hold):  \ no
#  |       |    +----/                                                    \-+
#  |       |    |yes \       WINST[M] == 1 && WINSTINDEX[M] == VLID       / |
#  |       |    |     \     WINEND[N] == 1 && WINSTINDEX[N] == VLID      /  |
#  |       |    |      \                                                /   |
#  |       |    |       \ (the VL window has opened and not yet closed)/    |
#  |       |    |        ----------------------------------------------     |
#  |       |    v                                                           v
#  |       |  dispatch to DESTPORTS when the Schedule Table               drop
#  |       |  executes an entry i with TXEN == 1 && VLINDEX == i
#  v       v
# dispatch immediately to DESTPORTS
#
# The per-port classification key is always composed of {DMAC, VID, PCP} and
# is non-maskable. This 'looks like' the NULL stream identification function
# from IEEE 802.1CB clause 6, except for the extra VLAN PCP (which we could
# allow the user to not specify, and then the port-based default will be
# used).
#
# The action is always a full triplet of:
# a. 'police': (rate-based or time-based) and size-based
# b. 'flow steering': select the traffic class on the egress port
# c. 'redirect': select the egress port list
#
# For c, using Virtual Links to forward traffic based on {source port, DMAC,
# VID} may appear at first quite pointless, but in fact it allows the creation
# of private (per-port) FDB tables. The DESTPORTS feature can be used to
# implement e.g. flow trapping (redirect to CPU), which is what the demo below
# shows.

# But nonetheless, specifying DESTPORTS in the action is mandatory even if the
# intended behavior is unrelated to routing. So what we can do in the driver is
# to only allow the user to specify a VL rule for a {DMAC, VLAN} pair for which
# a static FDB entry has already been input. Then we can take the matching
# ports from the driver's list of static FDB entries and use those to populate
# DESTPORTS for the action. The end result is that the static FDB entry will be
# shadowed by a VL rule, but the forwarding decision will still be as per user
# request.
#
# For a and b, it would be nice to be able to do flow steering and policing as
# independent actions. So we can do:
# - Policing without flow steering: configure the PRIORITY of the VL to be the
#   port-based default priority.
# - Flow steering without policing: configure the VL as ISCRITICAL=1 and
#   TYPE=0 (rate constrained), but set BAG=0 and JITTER=0 to disable the
#   bandwidth checks.

# Chassis label to chip port mapping
swp2=1
swp3=2
swp4=3
swp5=0
cpu=4

sja1105-tool conf def ls1021atsn

# On swp4, trap all incoming frames with a DMAC of 01:02:03:04:05:06, a VID of
# 0 and a PCP of 0 (both port-based defaults) to the CPU
sja1105-tool config modify vl-lookup-table entry-count 1
sja1105-tool config modify vl-lookup-table[0] destports $((1 << $cpu))
sja1105-tool config modify vl-lookup-table[0] iscritical 0
sja1105-tool config modify vl-lookup-table[0] macaddr 01:02:03:04:05:06
sja1105-tool config modify vl-lookup-table[0] vlanid 0
sja1105-tool config modify vl-lookup-table[0] vlanprior 0
sja1105-tool config modify vl-lookup-table[0] port $swp4

# Mandatory table, but otherwise ignored because iscritical=0
sja1105-tool config modify vl-policing-table entry-count 1

# Mandatory table, but otherwise ignored because iscritical=0
sja1105-tool config modify vl-forwarding-table entry-count 1

# Define the frame buffer partitioning between the best-effort traffic and the
# virtual links. Again, this only needs to be formally specified: because we
# are only using virtual links with iscritical=0 (aka not really virtual
# links), we can actually not specify any memory at all for them.
sja1105-tool config modify l2-forwarding-parameters-table[0] part_spc "[910 0 0 0 0 0 0 0]"
sja1105-tool config modify vl-forwarding-parameters-table entry-count 1
sja1105-tool config modify vl-forwarding-parameters-table[0] partspc "[0 0 0 0 0 0 0 0]"

sja1105-tool config upload

# Test environment:
#       +----------------------------+
#       |           Switch           |
#       |                            |
#       | swp5       swp3       eth1 |
#       | swp4       swp2       eth0 |
#       +--|----------|--------------+
#          |          |
#      +---+          +--------------+
#      |                             |
# +---------+                   +---------+
# |   Host  |                   |   Host  |
# |    A    |                   |    B    |
# +---------+                   +---------+
#
# Host A runs:
# arp -s 10.0.0.200 01:02:03:04:05:06 dev eth0
# ping -f 10.0.0.200
#
# The switch runs:
# ./trapping.sh
# tcpdump -i eth2
# and sees all packets
#
# Host B runs:
# tcpdump -i eth0
# and sees no packet

Thank you very much!

[niceniu]

Hello, in fact I also want to capture some packets on the LS1021A to the kernel to make some modifications. I ran the script you gave above, host A ping host B for testing, and I called the dev_queue_xmit (skb) function in the kernel to The modified data packet is sent to the network card eth2, and host B can indeed receive the modified data packet. But the strange thing is that the response packet from host B can also reach the kernel. I send the response packet to the network card eth2, and host A cannot receive this response packet. Can you give me some suggestions? Or how can we enable Host A and Host B to achieve two-way communication through the kernel

[vladimiroltean]

the response packet from host B can also reach the kernel

It will reach the kernel as long as the destination MAC has not been learned by the switch. I assume the destination MAC is host A's MAC address? I don't know if the switch learns the source MAC of frames that match a virtual link.

I send the response packet to the network card eth2, and host A cannot receive this response packet

Does the switch drop the reinjected packet over eth2? Does any error counter in sja1105-tool status ports increment?

[niceniu]

It will reach the kernel as long as the destination MAC has not been learned by the switch. I assume the destination MAC is host A's MAC address? I don't know if the switch learns the source MAC of frames that match a virtual link.

yes,the destination MAC is host A's MAC address,The switch did not learn the neighbor table, But I added the neighbor table to eth2 manually, but this didn't seem to work.

How to make the switch learn the source MAC of the frame that matches the virtual link and view the neighbor table of the switch?

Does the switch drop the reinjected packet over eth2? Does any error counter in sja1105-tool status ports increment?

How to see if the switch drops the packet injected into eth2? My counter results are as follows, is this normal?

[vladimiroltean]

No, your errors are indicated by the N_N664ERR counter:

This field counts the number of frames dropped since power-on or reset because they had an EtherType field other than 800h while the DRPNONA664 flag was set for the respective port in the MAC Configuration table (Table 14), they were not tagged while untagged traffic was not allowed (DRPUNTAG = 1; see Table 14), or that were not routed to any destination (because destination ports were down because flag EGRESS = 0, destination ports were not reachable for traffic sourced at the respective ingress port as per REACH_PORT of the respective ingress port, or destination ports were not members of the VLAN broadcast domain as per VLAN_BC of the respective VLAN).

In short, this is the "dropped due to no destinations" counter (and a few other irrelevant conditions). Out of curiosity, what is the DMAC in your application?