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" <[email protected]> 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:[email protected]] > *Sent:* Friday, October 04, 2013 2:52 PM > *To:* Andy Litzinger > *Cc:* [email protected] > *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 < > [email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp**** > > > > > -- **** > > Phil Fagan**** > > Denver, CO**** > > 970-480-7618**** > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
