[j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses
Phil Fagan
philfagan at gmail.com
Fri Oct 4 21:59:27 EDT 2013
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.Litzinger at 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:philfagan at gmail.com]
> *Sent:* Friday, October 04, 2013 2:52 PM
> *To:* Andy Litzinger
> *Cc:* juniper-nsp at 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.Litzinger at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp****
>
>
>
>
> -- ****
>
> Phil Fagan****
>
> Denver, CO****
>
> 970-480-7618****
>
More information about the juniper-nsp
mailing list