hi all, I managed to resolve this issue as being down to the arp replies not being deterministic from the switch port-channel facing the secondary SRX cluster node1.
i.e they would use the incorrect physical interface from the port-channel list, where the arp's are sourced from the lowest physical interface number it seems from node1. so to me it seems unless junos supports a valid way of not using the physical interface mac-address i.e moving this mac-address to a second rethX.X sub-interface then a dual legged design from each SRX to the switches which could be running MC-LAG or vPC (or simple LACP to the same switch) then ip-monitoring for this purpose would not be supported. I would be surprised if this has not been considered, I am new to junos so go easy on me ;) br On Mon, Mar 16, 2015 at 12:22 PM, Sukhjit Hayre < [email protected]> wrote: > > I'm confused on where to physically or logically assign this address. > > I have declared my secondary address in the ip-monitoring stanza but the > connected Router is receiving quite a few ARPs from this address because > it's trying to ICMP for IP-monitoring purposes > > Issue is where do I expect the ARP to be received back on by Node1 as I > can see the reth1 child physical mac is being used to source the ARP and I > can the Router reply back to this MAC address > > The source address from the primary reth1 (node0) is ICMP'd fine but not > the secondary this causes issues down the line as the ip-monitoring > pre-check fails hence the node1 chassis is not ready to take the data-plane > for one of my redundancy-groups in this case RG1 > > Any pointers on this would be appreciated > > > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
