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

[Hugo Slabbert]

In that case, you build a LAG on node0 that goes to a LAG on the switch, 
and a LAG on node1 that goes to a separate LAG on the switch.

Is that the setup you're having issues with?  e.g. (assuming a 2-member EX 
switch on the other end for simplicity's sake):

      |=     - ge-0/0/0 <---> ge-0/0/0 -
srx1 |     /                           \
      |=   /-- ge-0/0/1 <---> ge-1/0/0 --- ae0 on some switch
          /
     reth0 (w/ lacp)
          \
      |=   \-- ge-1/0/0 <---> ge-0/0/1 --- ae1 on some switch
srx2 |     \                           /
      |=     - ge-1/0/1 <---> ge-1/0/1 -


We have that running in production without issue, though we are not using 
IP monitoring.

The key part is in that diagram is that the 2 LACP interfaces on the 
switch(es) are discrete; you don't have 1 LACP bundle for all 4x SRX 
interfaces together.  There is no actual aeX interface on the SRX chassis 
cluster; you just add LACP config to the reth, and the links are brought up 
sensibly given the LACP config on the other (switch) end with two discrete 
bundles:

> show configuration interfaces reth0
description "Outside Shared Interface to EX Stack (ge-0/0/16 and ge-1/0/16)";
redundant-ether-options {
     redundancy-group 1;
     lacp {
         active;
         periodic fast;
     }
}

Again, we're not running ip-monitoring, so I'm not sure if that is 
also/still problematic even with the LAGs sorted out.

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

On Thu 2016-May-19 20:22:45 +0100, sukhjit.hayre at googlemail.com <sukhjit.hayre at googlemail.com> wrote:

>
>
>Hi Hugo
>
>No you have it wrong, say you wanted to double the links from node0 to switch 1 or node1 to switch 2 because it was close to being utilised.
>
>That's the design where static routing/ip-monitoring is not supported per the initial email I sent and due to issue that I described.
>
>--
>BR
>
>Sukhjit Hayre
>2xCCIE #40428 (SP, R/S)
>
>Sent from iPhone
>
>> On 19 May 2016, at 19:51, Hugo Slabbert <hugo at slabnet.com> wrote:
>>
>> 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/1e8480ee/attachment.sig>