[j-nsp] vSRX Cluster ip-monitoring secondary address

[Sukhjit Hayre]

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 <
sukhjit.hayre at googlemail.com> 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
>
>
>