[ixpmanager] Experience with EVPN+VXLAN and port security in Arista?

[Nick Hilliard (INEX)]

nope, neither - I was referring to hard-coded layer 2 ACLs, e.g.

> interface Ethernet10
>    description IXP Foobar Memberport
>    mac access-group l2acl-ixp-viid1234 in
>    [...]
>
> mac access-list l2acl-ixp-viid1234
>    10 permit 66:44:22:11:33:55 00:00:00:00:00:00 any
>    20 deny any any

I.e. this replaces the "switchport port-security" command.

Nick

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20240406/6a2829ef/attachment.htm>