cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8256
Views
5
Helpful
19
Replies

disable mac learning on nexus 9500

johncena74143
Level 1
Level 1

hi guys
I want to disable mac learning on nexus 9500 with nx-os 9.3.3 but Unfortunately i didn`t found any thing about disable mac learning on nexus 9500 with nx-os 9.3.3
i found a command in nexus 3548 with nx-os 6.x
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3548/sw/layer_2_switching/60x/b_Cisco_N3548_Layer_2_Switching_Config_602_A1_1/b_Cisco_N3548_Layer_2_Switching_Config_602_A1_1_chapter_01001.html
but this command not found in nexus 3548 with nx-os 9.3.3
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/layer2/93x/configuration/guide/b-cisco-nexus-3000-nx-os-layer-2-configuration-guide-93x.html
How can I do this

19 Replies 19

I would expect mac learning for static entries to not be overwritten. At the same time I would not expect l2fm (control plane process in charge of mac learning) to generate any updates to evpn.

P.S. for the "unconfigured" ones (meaning the ones without static entries) yes, thats a different story. That's expected to learn the mac and update the evpn. 

 

Anyway, I will test the static macs out of curiosity and see how it behaves.

 

Take care,

Sergiu

Hi Sergiu,

 I think I owe you the full picture of our problem. We run an Internet Exchange and we were using "feature port-security" for years to secure port from MAC address flood/hijack/spoof. When we bought Nexus 9300 we realized, this feature is not officially supported with VxLAN fabric (even vPC fabric peering has an issue with port-security as it runs internally on VxLAN, but that is a different story). Not able to use the "port-security feature" I was looking for alternative options securing the customer ports.

 

Option 1) MAC ACL on port - this makes sense to use, but even when MAC ACL is applied on the port, l2fm is still learning ALL MACs sent to that port, no matter how ACL looks like. EVPN is redistributing all MACs across the fabric. Only the traffic is blocked by ACL.

 

Option 2) Static MAC address configuration with port+VLAN - This is very tricky! It is similar behavior as what "feature port-security" does. In both cases MAC address is exported to EVPN with a "sticky/static flag" instructing all VTEPs in the domain, this MAC cannot be moved. This is an example of the message when you try to move "secured" MAC across VxLAN fabric:

 

2021 Jun 25 07:13:34 HOSTNAME %L2RIB-2-L2RIB_LOCAL_LEARNT_MAC_PRESENT_AS_REMOTE_STATIC: Locally learnt MAC 1111.1116.be74 in topology: 1500 already present as remote static

 

Unfortunately, this can happen when two customers will have a MAC collision (very rare, but it can happen, when a loop occurs).

 

The story continues, and here is where it starts to be interesting

 

Remote VTEP saying a message above will learn MAC in a collision from its Layer2 side (coming from clients) and will try to move MAC towards itself. Due to the "sticky/static" flag, it cannot move this MAC. Instead, this MAC will STAY! learned from the Layer2 side and will never age out. This is causing traffic blackholing for that MAC because all VTEPs see MAC on the original VTEP, but the local switch sees the MAC from a new location, which is its Layer2 network.

We opened a BUG https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvz21740 but unfortunately, Cisco is still not acknowledging this as a BUG and officially this is an "enhancement request".

 

We created a small script solving this issue, but it is still a workaround - available here https://github.com/nixcz/cisco-nexus-9300-evpn-fix

 

So please be careful using static MAC entries.

 

3) VACL - same a MAC PACL.

 

If you will find any way how to limit MACs on port let me know I will appreciate that, I haven't found any.

 

Marian

Sergiu.Daniluk
VIP Alumni
VIP Alumni

Thanks Martin for the details of your scenario. Very interesting indeed.

Looking over the config guide, seems like the following statement is present:

"Static MAC cannot be configured for a control plane with a BGP EVPN-enabled VNI."

Ref: https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/102x/configuration/vxlan/cisco-nexus-9000-series-nx-os-vxlan-configuration-guide-release-102x/m_configuring_vxlan_93x.html

Which indicates that Cisco BU didn't fully implemented this feature yet in the code or maybe it was not tested enough, hence marking your DDTS as enhancement request.

On the other hand, it is supported in flood-and-learn deployment. Personally, I do not really recommend F&L, but if the static mac feature something you really really need, it could be something you can consider. That's until will be fully supported in bgp evpn.

 

Reading over your post, I guess the only action you can do at the moment is discuss with your Cisco representative/accounting team/account manager about the feature you need. They can submit an official request to BU and they can get an official feedback (if/when can be added).

 

Stay safe,

Sergiu

 

 

 

Hi Sergiu,

 I'm glad you're interested. You are right, F&L will probably work, but my concern is VxLAN with port-security anyway. As per documentation:

And because this is also a problem with Fabric-Peering where EVPN is not used, I assume port-security is not an EVPN thing, but a VxLAN problem.

 

With fabric-peering, there is one more issue - if you have an orphan port in a fabric-peering setup, all traffic is always being forwarded to only one switch in a pair when port-security is enabled on this orphan port. Both switches are advertising their own PIP as a next-hop to EVPN for MACs on the orphan port. Remote VTEP does have two BGP next-hops for this route and has to perform the best-path selection. Because all parameters are the same, the decision will potentially end up on the IP address of the next-hop, therefore lower IP will have priority and all traffic is forwarded to only the first switch in a pair (with lower IP). In case the customer is connected to the second switch physically, its traffic needs to be redirected. This is usually not a problem when we are talking about low traffic, but if there is a customer with 100Gbit/s of the traffic, it will load the uplinks a lot.

 

Cheers and stay safe, Marian

Alvin5
Level 1
Level 1

Use mac-address mac-learning disable to disable MAC address learning. Depending on the view that you entered, you can disable it on a Layer 2 interface or a group of Ethernet ports, or on a VLAN. Use undo mac-address mac-learning disable to enable MAC address learning.

My Insite Sign In

1. switch# configure terminal

2. switch(config)# interface type slot/port

3. switch(config-if)# [no] switchport

mac-learn disable
4. switch(config-if)# clear mac
address-table dynamic interface type
slot/port

Review Cisco Networking for a $25 gift card