[j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses

Andy Litzinger Andy.Litzinger at theplatform.com
Sat Oct 5 10:51:09 EDT 2013


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" <philfagan at gmail.com<mailto:philfagan at 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.Litzinger at theplatform.com<mailto: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<mailto:philfagan at gmail.com>]
Sent: Friday, October 04, 2013 2:52 PM
To: Andy Litzinger
Cc: juniper-nsp at puck.nether.net<mailto: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<mailto: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<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp



--
Phil Fagan
Denver, CO
970-480-7618<tel:970-480-7618>


More information about the juniper-nsp mailing list