Re: [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.

     |=     - 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 -

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): 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;
    }
}



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

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

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

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 <h...@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: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Mon 2015-Mar-16 20:47:33 +0000, Sukhjit Hayre <sukhjit.ha...@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.ha...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

signature.asc
Description: Digital signature

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp