MAC learning about behavioral-model HOT 9 CLOSED

The question didn't specifically mention control plane software.
An example with some control plane code (in the form of unit tests) can be found here:

• https://github.com/p4lang/behavioral-model/blob/master/targets/simple_switch_grpc/tests/testdata/digest.p4
• https://github.com/p4lang/behavioral-model/blob/master/targets/simple_switch_grpc/tests/test_digest.cpp

And I believe the P4Runtime spec is pretty comprehensive regarding digest generation.

from behavioral-model.

Hi Christian,

AFAIK, learning has been fully implemented. Note that all generate_digest() does is generate a learning notification that then needs to be handled by the control plane. It does not update any table by itself. That is what the learn client (https://github.com/p4lang/behavioral-model/tree/master/targets/l2_switch/learn_client) is for. This code is an example that is meant to be used in conjunction with the l2_switch binary and l2_switch.p4. It will receive learning notifications and populate tables appropriately. If you start l2_switch, then learn_client you should see table entries being added as L2 traffic goes through.

from behavioral-model.

Hi Antonin,

I followed your instructions. I started l2_switch with the additional parameter

--notifications-addr ipc:///tmp/bmv2-0-notifications.ipc

to enable forwarding of notifications to the address that the learn_client is listening on. Now it's working.

Thank you!

from behavioral-model.

There might be a bug in the learning engine: If I pass the first time a network packet to switch port 1, the new SRC MAC of the packet is notified and the learn_client outputs:

I received 1 samples
Calling callback function
CB with 1 samples
ingress port is 1

So far, so good, but when I send a following packet with a different SRC MAC to switch port 2, the client outputs:

I received 1 samples
Calling callback function
CB with 1 samples
ingress port is 257

Subsequently port 101 (instead of port 2) is associated with the SRC MAC address in table 'dmac':

Action entry: forward - 101

Where the magic numbers 257 and 101 might come from?

from behavioral-model.

Well 0x101 is 257 so that's really one magic number :)
I'm not sure what could be going on. It may be useful if you could provide the command line with which you run the switch. I would also recommend running the switch with logging enable (--log-console). You can then see if that strange number shows up anywhere or if the packet is shown as coming in on port 2.

from behavioral-model.

I launched the switch by command:

sudo ./l2_switch l2_switch.json -i 0@veth0 -i 1@veth2 -i 2@veth4 -i 3@veth6 -i 4@veth8 --nanolog ipc:///tmp/bm-0-log.ipc --log-console -L debug --notifications-addr ipc:///tmp/bmv2-0-notifications.ipc --pcap

Thereafter I sent the first network packet (SRC MAC aabbccddeef1, DST MAC aabbccddeef2) on port 1 and subsequently the second packet (SRC MAC aabbccddeef2, DST MAC aabbccddeef1) on port 2. For the second packet the switch generated the following output:

[16:31:12.170] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Processing packet received on port 2
2
[16:31:12.170] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Parser 'parser': start

Some output removed for brevity...

[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Looking up key:

• ethernet.dstAddr : aabbccddeef1

[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Table 'dmac': hit with handle 0
[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Dumping entry 0
Match key:

• ethernet.dstAddr : EXACT aabbccddeef1
  Action entry: forward - 1,

[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Action entry is forward - 1,
[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Pipeline 'ingress': end
[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Egress port is 1
[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Learn id is 1
[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Mgid is 0
[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Pipeline 'egress': start
[16:31:12.171] [bmv2] [D] [thread 31314] [1.0] [cxt 0] Pipeline 'egress': end
[16:31:12.172] [bmv2] [D] [thread 31315] [1.0] [cxt 0] Transmitting packet of size 73 out of port 1

OK - port 1 is the right output port!

[16:31:13.173] [bmv2] [D] [thread 31335] Entry 1 added to table 'smac'
[16:31:13.173] [bmv2] [D] [thread 31335] Dumping entry 1
Match key:

• ethernet.srcAddr : EXACT aabbccddeef2
  Action entry: _nop -

[16:31:13.174] [bmv2] [D] [thread 31335] Entry 1 added to table 'dmac'
[16:31:13.174] [bmv2] [D] [thread 31335] Dumping entry 1
Match key:

• ethernet.dstAddr : EXACT aabbccddeef2

Everything is fine up to here, but the last line of switch logging output contains the magic number that associates MAC aabbccddeef2 with port 257:

Action entry: forward - 101,

Content of table 'dmac':

RuntimeCmd: table_dump dmac
dmac:
0: aabbccddeef1 => forward - 0,
1: aabbccddeef2 => forward - 101,
default: broadcast -

from behavioral-model.

This was addressed in ff0cdf4
There was a "legacy hack" in l2_switch.p4 that was overwriting the ingress port value to 257. Thanks for reporting this.

from behavioral-model.

If the l2_switch example is not enough for you, I believe @jafingerhut has an example here: https://github.com/jafingerhut/p4-guide/tree/master/control-plane-types
BTW, do not use the P4 public forums to ask about Tofino. Refer to the available customer documentation or reach out to Barefoot customer engineering.

from behavioral-model.

FYI, I do not recall any code example in my p4-guide Github repository have working examples of digests sent to control software, at least not yet. The program you link to does have P4_16 source code that calls the v1model digest extern function, but I have never tried to get those messages to control software before.

from behavioral-model.