I believe it was "set vlans <vlan name> disable-Mac-learning Xe-2 is not the backup RE. 1 & 3 are the primary and backups respectively.
-andy On Oct 4, 2013, at 6:59 PM, "Phil Fagan" <philfa...@gmail.com<mailto:philfa...@gmail.com>> wrote: What was the syntax to kill the learning? This is indeed a strange one. I wonder if it would happen on a stand alone switch vs VC. Also is xe-2 your backup for the VC? Wonder if its busy pushing tables to the backup. On Oct 4, 2013 5:50 PM, "Andy Litzinger" <andy.litzin...@theplatform.com<mailto:andy.litzin...@theplatform.com>> wrote: While I was logged in planning to configure the mac address aging you suggested I noticed there is another knob to completely disable mac learning on the vlan. Since there are only two ports on this vlan and they’re only sending to each other anyway they should really need to learn any macs. so I disabled it and let it run for 1 minute (via commit confirm 1). The entries dropped out of the mac-learning-log, but it didn’t have any noticeable impact on my CPU. the mac enumeration still seems like a weird deal though. I’ll report back anything JTAC uncovers. -andy From: Phil Fagan [mailto:philfa...@gmail.com<mailto:philfa...@gmail.com>] Sent: Friday, October 04, 2013 2:52 PM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses Very little is said other than indeed using MAC addresses is how the cluster speaks via the FAB http://forums.juniper.net/jnet/attachments/jnet/srx/1659/1/L2HAAppNotev2.pdf As you noted direct connect FAB is ideal; but a very very interesting find. Its possible there is a correct aging for your SRX VLAN that might help the CPU. https://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/mac-table-aging-time-bridging.html On Fri, Oct 4, 2013 at 2:45 PM, Andy Litzinger <andy.litzin...@theplatform.com<mailto:andy.litzin...@theplatform.com>> wrote: Hi, while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC engineer noticed that one pair of ports is making changes to the MAC learning table at an alarming rate. My SRX3400 fab links are connected to the ports in question (I'm waiting on parts to correct this and directly connect the fab ports). If you watch the mac-learning-log it looks like the SRX is sending packets over the fab link that use a private/fake Ethernet address and are quickly enumerating through a list of Ethernet addresses. Has anyone else ever seen this? is there a way to stop it or minimize its potential effect on the switch cpu? Note that it's not yet proven this is the source of the high cpu. > show ethernet-switching mac-learning-log <snip> Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:33:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a7:00:00 was learned on xe-2/0/28.0 the EX port config: > show configuration interfaces xe-0/0/28 Oct 04 13:00:13 description srx01-xe-1/0/1; mtu 9216; unit 0 { family ethernet-switching { vlan { members 500; } } } > show configuration interfaces xe-2/0/28 Oct 04 13:32:52 description srx02-xe-1/0/1; mtu 9216; unit 0 { family ethernet-switching { vlan { members 500; } } } SRX: srx01> show configuration interfaces fab0 fabric-options { member-interfaces { xe-1/0/1; } } srx01> show configuration interfaces fab1 fabric-options { member-interfaces { xe-9/0/1; } } srx01> show configuration interfaces xe-1/0/1 srx01> show configuration interfaces xe-9/0/1 srx01> thanks! -andy _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp -- Phil Fagan Denver, CO 970-480-7618<tel:970-480-7618> _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
