<div dir="ltr">Hi Nick,<div>Thank you very much for sharing your experience and your advice about the best way to secure layer 2 in the switches. About this point hard-coded layer 2 ACLs, are you talking about using the command "no switchport mac address learning" in the interface and adding the MAC address entry statically, with the command "mac address-table static xxxx.xxxx.xxxx vlan XX interface EthernetX", or you are talking about something different?</div><div><br></div><div>Best regards,</div><div><br></div><div>Salvador</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 5, 2024 at 1:56 PM Nick Hilliard (INEX) <<a href="mailto:nick@inex.ie">nick@inex.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Salvador<br>
<br>
Yeah, moving away from STP is a good idea. There is only one advantage <br>
with STP and that is that it keeps you honest about not <br>
over-provisioning your core links (there's always a blocking link). <br>
Otherwise it's a major source of problems on IX fabrics.<br>
<br>
EVPN+VXLAN works very well on Arista platforms.<br>
<br>
I would recommend against using port security. The reason for this is <br>
that when a port comes up:<br>
<br>
1. port comes up<br>
2. frames are received on the port<br>
3. the first frame received is punted to the switch CPU<br>
4. the management plane then issues a command to program the port ACL to <br>
only accept traffic with srcmac = the srcmac of the first packet<br>
5. port security is now active.<br>
<br>
The problem is that there is a time gap between 2 and 4. During this <br>
time gap, frames can continue to be received on the port, and will be <br>
learned by the switch, and forwarded to the fabric.<br>
<br>
On older switches, we found that this time gap could be as much as 50ms <br>
- 200ms, during which many packets could be transmitted.  We found this <br>
out when someone hard-looped the IXP connection at their end and <br>
reflected all the IXP traffic back to the IXP, which took the entire <br>
fabric down for 30 seconds because their port announced that it was the <br>
source of all MAC addresses on the IXP. Oops.<br>
<br>
What you want is hard-coded layer 2 ACLs. This also works extremely well <br>
on Arista devices<br>
<br>
Nick<br>
<br>
Salvador Bertenbreiter via ixpmanager wrote on 05/04/2024 18:28:<br>
> Hi guys,<br>
> I hope you're doing well.  We have a Peering Fabric that has many sites <br>
> and we are facing some limitations with our current plain layer 2 model, <br>
> so we are looking to migrate it to a EVPN+VXLAN topology for better <br>
> scalability and better use of all the links (some of them currently <br>
> unused due to STP). However, during my research I have seen some <br>
> problems that some IXPs have suffered due to compatibility issues <br>
> between EVPN+VXLAN and port-security. Talking with some IXP operators <br>
> they have told me of some issues with EVPN+VXLAN and port-security in <br>
> Cisco devices. I was wondering if anyone has some real-world experience <br>
> with EVPN+VXLAN and port-security in Arista devices?<br>
> <br>
> Here is one of the challenges I have found:<br>
> <a href="https://www.youtube.com/watch?v=Wd3_pfxfmHo&pp=ygUIZXZwbiBpeHA%3D" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=Wd3_pfxfmHo&pp=ygUIZXZwbiBpeHA%3D</a><br>
> <br>
> Best regards,<br>
> <br>
> Salvador<br>
> <br>
> <br>
> _______________________________________________<br>
> INEX IXP Manager mailing list<br>
> <a href="mailto:ixpmanager@inex.ie" target="_blank">ixpmanager@inex.ie</a><br>
> Unsubscribe or change options here: <a href="https://www.inex.ie/mailman/listinfo/ixpmanager" rel="noreferrer" target="_blank">https://www.inex.ie/mailman/listinfo/ixpmanager</a><br>
> <br>
</blockquote></div>