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] -=-=-=-=-=-=-=-=-=-=-=-