We got another MX connected to this SRXs also. so if one MX is down,
we can route thru another MX.
Regards,
2014/1/17 Morgan McLean :
> Ben's got it; your MX will still see both ports as current with LACP due to
> packets still coming in, though from two separate LACP bundles. This will
> make th
Ben's got it; your MX will still see both ports as current with LACP due to
packets still coming in, though from two separate LACP bundles. This will
make the MX think it can send traffic down either interface, half of the
time going to a node that won't pass the traffic.
Why are you using a reth
Hmm...so a member port of Reth which is on node 1 (secondary) is not
used since Reth is for failover between two nodes though LACP is
configured. It would work when the two members of Reth are on the same
node. In this case, Reth combined with LACP is redundancy and
balancing. Currently, the ospf f
You'll see in Cooper's blog that both nodes are going back into a *single* EX
switch with *two* ae interfaces configured - one to each node.
These ae links have two ports allocated to them.
All LACP does is provide redundancy/balancing between ports to the primary node
- the secondary node will
Hi Aaron,
LACP is running on the reth interface and reth's are up. below is the
configuration:
Admin@coolSRX# show interfaces reth1
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
lacp {
passive;
periodic fast;
}
}
this link was successful for this. http:/
reth interfaces are for failover not for bundle. You can use two LAGs within a
reth interface (multiple interface on a single node in a LAG) but not across
both. It's up (probably) because you aren't running LACP. If you turn on
LACP, then various links will be down. I'm going to guess that
I can't access to the devices at the moment, but basically what we did
was under each routing instance, we just put the interfaces inside the
ospf area. very straight forward configuration of ospf. I have thought
of links LAG from MX should only connect to each node individually.
but it's interesti
I'm surprised that this is even working at all.
http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/interface-security-aggregated-ethernet-lacp-chassis-cluster-understanding.html
Specifically:
Note: The redundant Ethernet interface LAG child links from each node in the
chassis cluste
Depending on how you have your redundancy groups set up, only the active
links will be active at any given time. That means that the mxs won't see
two links active, they will see one each. So you should have two
adjacencies on the srx and one on each mx in this scenario.
Lacp would only be useful
Yup, one link from each node connect to MX-B. then these two link are
member of reth. and another one link from each node to MX-A creating
another reth.
2014/1/16 Morgan McLean
> You're not trying to use lacp with two srx nodes at once right?
>
>
> On Wednesday, January 15, 2014, Samol wrote:
On 16 Jan 2014, at 11:22 am, Samol wrote:
>
> I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not
> for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown
> interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are
> UP.
>
Check it in lay
You're not trying to use lacp with two srx nodes at once right?
On Wednesday, January 15, 2014, Samol wrote:
> Hi Experts,
>
> I'm running out of idea what else to try. I think it has something to do
> with clustering on SRX that makes ospf neigh never comes up. Let me explain
> you the scenario
Hi Experts,
I'm running out of idea what else to try. I think it has something to do
with clustering on SRX that makes ospf neigh never comes up. Let me explain
you the scenario, I have two SRXs and two MXs. The two SRXs are clustered
and two routing instances there, INSIDE and OUTSIDE. both MXs a
13 matches
Mail list logo
