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

[Hugo Slabbert]

This is very delayed, but are you connecting up the reth members to a LAG?  
e.g.

reth0 members are:
- srx1: ge-0/0/0
- srx2: ge-1/0/0

srx1      ge-0/0/0 <---> ge-a/b/c
          /                       \
     reth0                         aeX some switch (or MC-LAG setup)
          \                       /
srx2      ge-1/0/0 <---> ge-x/y/z

That's not how reth's work.  The reth is not a LAG; ge-a/b/c and ge-x/y/z 
on the switch should be discrete interfaces, just running the same config 
(e.g. same access VLAN or trunks with same member VLANs).

Does that make sense?

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal

On Mon 2015-Mar-16 20:47:33 +0000, Sukhjit Hayre <sukhjit.hayre at googlemail.com> wrote:

>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
>>
>>
>>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20160519/ef61d20e/attachment.sig>