Issue we faced was mac learning not mac aging. Multi-chassis protection is not mentioned in kb but it is required and configuring it solved the issue for us.
Sent from my iPhone On Mar 18, 2015, at 10:28 PM, Luca Salvatore <l...@digitalocean.com<mailto:l...@digitalocean.com>> wrote: Hi, We have multi-chassis enabled for ae0 only, do you have any juniper document that mentions it is needed on all mc-lag links? We speak to ATAC quite a lot a this has never been mentioned to us. We use static ARPs on all IRBs where VRRP is running and also for the ICL link. I don't think the redundant path would matter. irb.6 is used for ICCP and there is a static ARP on that IRB set to use AE0. MC-LAG as a whole is functionally fine. Its just the MAC address ageing which is the problem. For example, yesterday I shutdown a VM running off one of the MC-LAG interfaces. Core1 aged it out after the standard 5 minutes, but it was never aged out of core2. Its been 20 hours since it was removed from core1 and core2 still has the MAC in the table. On Wed, Mar 18, 2015 at 2:04 PM, Syed Iftikhar Ahmed <iah...@emw-me.com<mailto:iah...@emw-me.com>> wrote: Hi, I think iccp is up because you have a redundant path available using ae10 to reach iccp peer. I faced similar issue on a customer site and had to separate iccp link using l3 lag between chassis. Also please check if you have multi-chassis protection enabled, we enabled it on mc-lag interfaces as well as mc-lag unit0 as well as per Engineering recommendation. Also for arp learning we need to add arp entry for each irb interface to ensure arp is learned over ICL link not via a mc-lag interface. I assume you have rstp disabled already for mc-lag interfaces. Sent from my iPhone On Mar 18, 2015, at 9:35 PM, Luca Salvatore <l...@digitalocean.com<mailto:l...@digitalocean.com>> wrote: here it all is. You'll just have to trust me that the ping works between peers using the ICCP IP. We use public addressing on these and I don't want to post the public IPs here. I've changed them to 10.1.1.1 and 10.1.1.2 in the output. I'm able to ping without issue. Some details ae0 is the iccp / icl link ae10 is a random mc-lag interface We have been running this config in prod in numerous sites for a while. This particular set of switches has a difference of about 80,000 mac addresses between each core. core1> show interfaces mc-ae id 10 Member Link : ae10 Current State Machine's State: mcae active state Local Status : active Local State : up Peer Status : active Peer State : up Logical Interface : ae10.0 Topology Type : bridge Local State : up Peer State : up Peer Ip/MCP/State : 10.1.1.2 ae0.0 up core1> show configuration interfaces ae0 | display set set interfaces ae0 mtu 1522 set interfaces ae0 aggregated-ether-options link-speed 10g set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 aggregated-ether-options lacp periodic fast set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk set interfaces ae0 unit 0 family ethernet-switching vlan members 1010-1050 core1> show configuration interfaces ae10 | display set set interfaces ae10 mtu 1522 set interfaces ae10 aggregated-ether-options link-speed 10g set interfaces ae10 aggregated-ether-options lacp active set interfaces ae10 aggregated-ether-options lacp periodic fast set interfaces ae10 aggregated-ether-options lacp system-id 00:00:00:00:00:10 set interfaces ae10 aggregated-ether-options lacp admin-key 8888 set interfaces ae10 aggregated-ether-options mc-ae mc-ae-id 10 set interfaces ae10 aggregated-ether-options mc-ae redundancy-group 3 set interfaces ae10 aggregated-ether-options mc-ae chassis-id 0 set interfaces ae10 aggregated-ether-options mc-ae mode active-active set interfaces ae10 aggregated-ether-options mc-ae status-control active set interfaces ae10 aggregated-ether-options mc-ae events iccp-peer-down prefer-status-control-active set interfaces ae10 unit 0 family ethernet-switching interface-mode trunk set interfaces ae10 unit 0 family ethernet-switching vlan members 1010-1050 core1> show configuration protocols iccp | display set set protocols iccp local-ip-addr 10.1.1.1 set protocols iccp peer 10.1.1.2 redundancy-group-id-list 3 set protocols iccp peer 10.1.1.2 liveness-detection minimum-interval 500 set protocols iccp peer 10.1.1.2 liveness-detection minimum-receive-interval 500 set protocols iccp peer 10.1.1.2 liveness-detection multiplier 2 set protocols iccp peer 10.1.1.2 liveness-detection transmit-interval minimum-interval 1000 set protocols iccp peer 10.1.1.2 liveness-detection detection-time threshold 2000 core2> show interfaces mc-ae id 10 Member Link : ae10 Current State Machine's State: mcae active state Local Status : active Local State : up Peer Status : active Peer State : up Logical Interface : ae10.0 Topology Type : bridge Local State : up Peer State : up Peer Ip/MCP/State : 10.1.1.1 ae0.0 up core2> show configuration interfaces ae0 | display set set interfaces ae0 mtu 1522 set interfaces ae0 aggregated-ether-options link-speed 10g set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 aggregated-ether-options lacp periodic fast set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk set interfaces ae0 unit 0 family ethernet-switching vlan members 1010-1050 core2> show configuration interfaces ae10 | display set set interfaces ae10 mtu 1522 set interfaces ae10 aggregated-ether-options link-speed 10g set interfaces ae10 aggregated-ether-options lacp active set interfaces ae10 aggregated-ether-options lacp periodic fast set interfaces ae10 aggregated-ether-options lacp system-id 00:00:00:00:00:10 set interfaces ae10 aggregated-ether-options lacp admin-key 8888 set interfaces ae10 aggregated-ether-options mc-ae mc-ae-id 10 set interfaces ae10 aggregated-ether-options mc-ae redundancy-group 3 set interfaces ae10 aggregated-ether-options mc-ae chassis-id 1 set interfaces ae10 aggregated-ether-options mc-ae mode active-active set interfaces ae10 aggregated-ether-options mc-ae status-control standby set interfaces ae10 aggregated-ether-options mc-ae events iccp-peer-down prefer-status-control-active set interfaces ae10 unit 0 family ethernet-switching interface-mode trunk set interfaces ae10 unit 0 family ethernet-switching vlan members 1010-1050 set protocols iccp local-ip-addr 10.1.1.2 set protocols iccp peer 10.1.1.1 redundancy-group-id-list 3 set protocols iccp peer 10.1.1.1 liveness-detection minimum-interval 500 set protocols iccp peer 10.1.1.1 liveness-detection minimum-receive-interval 500 set protocols iccp peer 10.1.1.1 liveness-detection multiplier 2 set protocols iccp peer 10.1.1.1 liveness-detection transmit-interval minimum-interval 1000 set protocols iccp peer 10.1.1.1 liveness-detection detection-time threshold 2000 On Wed, Mar 18, 2015 at 12:13 PM, Syed Iftikhar Ahmed <iah...@emw-me.com<mailto:iah...@emw-me.com>> wrote: Sh interface mc-ae id xx Iccp link configuration. Ping output between chassis using iccp ips And any one mc-lag interface config from both chassis Sent from my iPhone On Mar 18, 2015, at 7:50 PM, Luca Salvatore <l...@digitalocean.com<mailto:l...@digitalocean.com>> wrote: Hi, Yes VRRP is in use. Running 13.2R5.10, single RE. Running active-active What config do you want to see? I don't want to post the whole thing. On Tue, Mar 17, 2015 at 7:09 PM, Syed Iftikhar Ahmed <iah...@emw-me.com<mailto:iah...@emw-me.com>> wrote: Is it active/ active or active/ standby setup. Config for 9200 is different than the One mentioned jn Kb, are you using vrrp as well? Please post your config, junos version. Do you have two RE in chassis or one? Sent from my iPhone > On Mar 18, 2015, at 12:39 AM, Luca Salvatore > <l...@digitalocean.com<mailto:l...@digitalocean.com>> wrote: > > Hi, > > Anyone seen an issue where the standby mc-lag peer does not age out MACs > that it has learned from the active peer? > > i'm seeing a huge difference in the mac address count on two ex9208 mc-lag > peers. By huge I mean about 75,000 difference. > > some basic testing shows that when a mac address is aged out of the active > peer, the standby one just keeps it forever. > > Thanks > Luca. > _______________________________________________ > juniper-nsp mailing list > juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Luca Salvatore Network Engineer Cell: +1 (929) 214-7242<tel:%2B1%20%28929%29%20214-7242> Desk: +1 (347) 305-4030<tel:%2B1%20%28347%29%20305-4030> -- Luca Salvatore Network Engineer Cell: +1 (929) 214-7242<tel:%2B1%20%28929%29%20214-7242> Desk: +1 (347) 305-4030<tel:%2B1%20%28347%29%20305-4030> -- Luca Salvatore Network Engineer Cell: +1 (929) 214-7242 Desk: +1 (347) 305-4030 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp