Tag :: ARP

There are use cases where all broadcast, multicast  and unknown MAC traffic are not needed to be flooded into the

Forced periodic ARP refresh adds support for a mechanism that allows forcing ARP/NDP refresh requests to be sent in periodic intervals independently of ARP/NDP entries' confirmed time in the kernel. By default, when a neighbor entry gets confirmed by various processes such as ARP synchronization between MLAG peers, an ARP refresh request is not sent for at least another duration of ARP aging timeout (or ND cache expiry time for the IPv6 case). This feature provides support for a configuration to force sending refresh requests at the configured ARP/ND aging timeout regardless of the last confirmed time.

This feature introduces support for scaling both IPv4 and IPv6 hosts on our devices. Existing MDB profiles offer a maximum host scale of 128k with unique MAC rewrites. However, if hosts share the MAC rewrites, the scale can reach up to 204k. To address this issue, we are introducing a new MDB profile that will support a host scale of up to 192k when each host has a unique MAC rewrite. If hosts share the MAC rewrites, the scale can reach up to 256k.

Each ARP/ND packet into a switch may generate an update for the switch ARP/Neighbor table and this update may need to be synchronized with the MLAG peer when VXLAN is configured. Prior to this feature, these updates (on a VXLAN setup) are synchronized by sending an UDP packet (one packet per update) containing the IP/MAC/VLAN information from the MLAG peer where the ARP/ND packet is received to the other MLAG peer. 

Selective ARP install is the selective programming of remote ARPs in hardware as received through EVPN Type 2 MAC-IP routes in an EVPN VXLAN/ MPLS Integrated Routing and Bridging (IRB) scenario. Instead of installing every MAC+IP binding received from EVPN into the hardware, the switch installs them only when there is routed traffic destined to the IP, thereby saving TCAM space on the switch. However, there is a tradeoff as there is an initial one-time latency to install the hardware TCAM entry on the first flow of routed traffic to the IP.

Enabling “Proxy ARP/ND for Single Aggregation (AG) VTEP Campus Deployments without EVPN” allows an aggregation VTEP to proxy reply to a VXLAN-encapsulated ARP request/NS when the ARP/NS target host is remote and the ARP/ND binding is already learned by the AG VTEP.

ARP and IPv6 Neighbor Discovery use a neighbor cache to store neighbor address resolutions. The capacity of the neighbor cache is determined by the resources and capabilities of the device platform. The neighbor cache capacity feature adds a means to specify a per-interface capacity for the neighbor cache. A neighboring device, through misconfiguration or maliciousness, can unfairly use a large number of address resolutions. This feature can help to mitigate this over-utilization.

VXLAN ARP and IPv6 Neighbor Discovery (NDP) packet headend replication capability via VxlanSwFwd matches the COPP rate limit for these packets for the supported platforms regardless of the size of the VXLAN flood VTEP list. However, there still remains a case where the handling capacity is limited by CPU: the handling of ARP broadcast and NS multicast that result from Glean traffic (post routing).