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: [email protected] pgp key: B178313E | also on Signal On Mon 2015-Mar-16 20:47:33 +0000, Sukhjit Hayre <[email protected]> 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 < [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
signature.asc
Description: Digital signature
_______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
