With the SJA1105, how to know where the unknown traffic comes from ?

表示  限定  | 次の代わりに検索 

With the SJA1105, how to know where the unknown traffic comes from ?

Contributor II


I am developing a mesh router prototype with the LS1021ATSN-PA.

The router needs to receive all the frames that cannot be forwarded with a set of static rules.

From these frame the router learns of the topology and setup the routing rules.

Everything is setup and the host port is receiving the data by configuring the FL_DOMAIN field of the l2-forwarding-table, but I didn't find a way to know the source port of the data.

I know it is possible to configure MAC_FLTRES and MAC_FLT fields from general-parameters-table to do that in the case of management traffic when you know the destination MAC address, but how can I know the source port of all the forwarded frames regardless of the destination address ?

Thank you for your support.

2 返答(返信)

NXP Employee
NXP Employee

I think the state-of-the-art way of accomplishing this is to tag frames with VLAN according to the source port they came on. The drawback is the fact that you won't be able to do any other VLAN processing on the switch if you use VLAN this way (since double-tagged VLAN aka QinQ is not supported).

An implementation might look like this:

* Change general-parameters-table.tpid to something else than 0x8100. This way the switch should never recognize VLAN-tagged frames as such, and will always append a second VLAN tag.

* Change the vlanid values in mac-configuration-table[i] for every switch port 0 -> 4 to the actual index of the port.

* Applying the 2 steps above should force the switch to apply a VLAN tag with an ID equal to the source port index to any incoming frames, regardless of them being VLAN-tagged or not.

* Configure the vlan-lookup-table by adding 4 (i = 0 -> 3) entries as follows:

    - Set VLANID i to entry i

    - Leave VMEMB_PORT and VLAN_BC as 0x1f (don't restrict the port domain of this VLAN, thereby still allowing regular switching to work).

    - Configure TAG_PORT for entry i to (1 << 4). This makes sure that packets sent to the host port are being tagged.

* Increase

* On the host, configure the Ethernet interface to sniff frames belonging to VLAN 0, 1, 2, 3. The source port information is available in the VLAN tag, which you can then strip away.

* In the scenario where the switch forwards frames between 2 non-host ports, the VLAN tagging is stripped away automatically and not visible in the outside world (except in the forward-to-host scenario).

I haven't actually tested these steps, but you should be able to recover the source port from the VLAN tags of sniffed frames.

What is the final purpose of implementing manual L2 address learning this way?

Contributor II

Since posting this question I understand better how this is working, and I probably don't need it.

I am prototyping a shortest-path bridge and first though I needed to do all the learning manually on the host.

Now I believe I only need to use the VLAN lookup table to setup the broadcast routing trees from the state link database and let the normal address learning and auto-broadcasting do the work.

Then the normal management traffic for the state-link protocol could be setup using the MAC_FLTRES and MAC_FLT fields that supports port-tagging.

Not sure yet if it will all work out.

Thank you very much for your response.

0 件の賞賛