02-05-2019 08:00 AM - edited 03-10-2019 01:16 PM
Hey guys,
I've been running into an issue and wondering if anyone else has experienced the same problem. I have an ASR 9006 running IOS XR 5.3.3 in my lab and I've created a test bridge domain. Within that bridge domain, under the access circuit, I've configured a mac limit of 50 with the 'no flood' action. When this limit is hit, mac address learning is disabled as expected, but the problem is that its never re-enabled. If i stop all traffic on that interface, the mac learning remains disabled indefinitely until I change the configuration to either remove mac limiting or change the action to none. I would like to think that at some point it it would back off and re-enable mac learning after seeing that the mac address count has dropped below the threshold. Any ideas?
RP/0/RSP0/CPU0:LAB-ASR9006-01#sho l2vpn bridge-domain bd-name 9 det
AC: GigabitEthernet0/2/0/9.300, state is up
Type VLAN; Num Ranges: 1
VLAN ranges: [300, 300]
MTU 8986; XC ID 0x208000c; interworking none
MAC learning: disabled (MAC-limit action)
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: disabled (MAC-limit action)
MAC aging time: 300 s, Type: inactivity
MAC limit: 50, Action: limit, no-flood, Notification: syslog
MAC limit reached: yes
MAC port down flush: enabled
MAC Secure: disabled, Logging: disabled
Split Horizon Group: none
Dynamic ARP Inspection: disabled, Logging: disabled
IP Source Guard: disabled, Logging: disabled
DHCPv4 snooping: disabled
IGMP Snooping: enabled
IGMP Snooping profile: none
MLD Snooping profile: none
Storm Control: bridge-domain policer
Static MAC addresses:
Statistics:
packets: received 1437063 (multicast 189407949, broadcast 44127, unknown unicast 0, unicast 0), sent 18
bytes: received 301982330 (multicast 40280180924, broadcast 3293496, unknown unicast 0, unicast 0), sent 1008
MAC move: 0
Storm control drop counters:
packets: broadcast 0, multicast 0, unknown unicast 0
bytes: broadcast 0, multicast 0, unknown unicast 0
Dynamic ARP inspection drop counters:
packets: 0, bytes: 0
IP source guard drop counters:
packets: 0, bytes: 0
RP/0/RSP0/CPU0:LAB-ASR9006-01#sho run l2vpn bridge group 9
Mon Feb 5 06:23:53.371 EST
l2vpn
bridge group 9
bridge-domain 9
mac
aging
time 300
!
withdraw state-down
!
mtu 9000
interface GigabitEthernet0/2/0/9.300
mac
limit
maximum 50
action no-flood
notification syslog
!
!
!
vfi 9
vpn-id 9
autodiscovery bgp
rd auto
route-target 9:9
!
neighbor 192.168.2.100 pw-id 91
!
neighbor 192.168.2.200 pw-id 91
!
!
routed interface BVI9
!
!
!
RP/0/RSP0/CPU0:LAB-ASR9006-01#sho l2vpn forwarding bridge-domain 9:9 loc 0/2/CPU0
Mon Feb 5 06:29:21.345 EST
Bridge MAC
Bridge-Domain Name ID Ports addr Flooding Learning State
-------------------------------- ------ ----- ------- -------- -------- ---------
9:9 0 4 0 Enabled Enabled UP
01-10-2020 12:26 PM
hi jmoody, I stumbled on your unanswered question here and apologize for it being left unanswered for SO LONG!!
but I have an answer for you.
when mac limit detects the anomaly, it is required to manually intervene and unblock the condition through the clear l2vpn command:
RP/0/RSP0/CPU0:CORE-TOP#clear l2vpn bridge-domain bd BLABLA
This command only affects objects which have been shut down
due to MAC limit being reached or MAC secure violation.
Are you sure you want to clear and restart
all bridge-domains named BLABLA which are in this state? (y/n)[n]
xander
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide