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

[Salvador Bertenbreiter]

Hi Nick,
Great, thanks for the information.

On Sat, Apr 6, 2024, 06:16 Nick Hilliard (INEX) <nick at inex.ie> wrote:

> nope, neither - I was referring to hard-coded layer 2 ACLs, e.g.
>
> interface Ethernet10
>    description IXP Foobar Member port
>    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> 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
>> > 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/20240412/cd817c52/attachment.htm>