Hi Mohsen,

Perhaps I misunderstood your intentions. MAC learning I was talking about is 
what a switch/bridge domain does to populate its forwarding tables to perform 
l2 forwarding. My old and limited experience with port-security was as a 
feature on l2 interface in a BD.
If what you wanted was ARP for L3 interfaces, then we’re talking about IP 
neighbours. The size of the ip-neighbour DB (which is shared between ARP and ND 
entries) has only a global not a per-interface limit.
DBGvpp# set ip neighbor-config ?
  set ip neighbor-config                   set ip neighbor-config ip4|ip6 
[limit <limit>] [age <age>] [recycle|norecycle]
there are no other means to control what IP neighbours are or aren’t learned.

/neale


From: Mohsen Meamarian <meamarian.moh...@gmail.com>
Date: Wednesday, 4 August 2021 at 07:26
To: Neale Ranns <ne...@graphiant.com>
Cc: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] MAC Learning in vpp
Hi Neal,
Thanks, Is there a way to view and limit learned MAC addresses for an interface 
without adding an interface to a bridge-domain?

On Tue, Aug 3, 2021 at 12:15 PM Neale Ranns 
<ne...@graphiant.com<mailto:ne...@graphiant.com>> wrote:
HI Mohsen,

Learning in a BD is enabled by default – your trace shows learning on. You can 
turn in on or off through configuration on the BD or on the input interface.
DBGvpp# set bridge-domain ?
  set bridge-domain learn                  set bridge-domain learn 
<bridge-domain-id> [disable]
  set bridge-domain learn-limit            set bridge-domain learn-limit 
<bridge-domain-id> <learn-limit>

or

DBGvpp# set interface l2 ?
  set interface l2 learn                   set interface l2 learn <interface> 
[disable]

Ping and ARP work with learning on.

Note also in the commands above, there is a mechanism to limit the number of 
MACs that can be learnt in each BD.

/neale


From: Mohsen Meamarian 
<meamarian.moh...@gmail.com<mailto:meamarian.moh...@gmail.com>>
Date: Tuesday, 3 August 2021 at 06:37
To: Neale Ranns <ne...@graphiant.com<mailto:ne...@graphiant.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] MAC Learning in vpp
Thanks neale,
What is the easiest way to enable learning on an interface while other 
functionality , including passing the ping and arp packets , work normally?

I want l2_learn_process run for that interface so that I can write a function 
to do something like put a limiting on maximum connected devices with it's help.


On Mon, Aug 2, 2021, 23:38 Neale Ranns 
<ne...@graphiant.com<mailto:ne...@graphiant.com>> wrote:

HI Moshen,

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> on behalf of Mohsen Meamarian 
via lists.fd.io<http://lists.fd.io> 
<meamarian.mohsen=gmail....@lists.fd.io<mailto:gmail....@lists.fd.io>>
Date: Monday, 2 August 2021 at 18:45
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] MAC Learning in vpp
Hi friends,
I want to implement port security in vpp. I assume that the l2learn_process 
function in l2_learn.c runs periodically when vpp is active and When a device 
is connected to my system , this function helps to learn it's mac. Is this 
assumption true ?

No. l2_learn runs for all packets that are received on a link on which learning 
is enabled. You can see it in the trace you provided. It is learning in this 
VLIB node that will populated the l2fib.

because when I run the sh l2fib command , it returns nothing. but when I set an 
interface as a bridge , the sh l2fib command returns something. my commands :

create bridge-domain 2 arp-term 1
create loopback interface
set int l2 bridge loop0 2 bvi
set interface state loop0 up
set interface l2 bridge GigabitEthernet0/8/0 2

show bridge-domain 2 detail
show l2fib all

but i have a problem here. vpp drop ping packet.Where can the problem come from?

I attached my trace command result to this mail.I get " l2-flood: BVI L3 mac 
mismatch " error.

That shows an ARP packet destined to a unicast MAC. That packet was flooded, 
suggesting an l2fib miss and unknown-unicast flooding is enabled. The dst MAC 
of the packet did not match the MAC of the BVI (the only other interface in the 
BD) so it was dropped.

/neale

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19912): https://lists.fd.io/g/vpp-dev/message/19912
Mute This Topic: https://lists.fd.io/mt/84615988/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to