[j-nsp] OSPF neig / SRX cluster / LACP
Morgan McLean
wrx230 at gmail.com
Thu Jan 16 14:41:01 EST 2014
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 for OSPF? To avoid cross traffic between the nodes?
Morgan
On Wed, Jan 15, 2014 at 11:52 PM, Samol <molasian at gmail.com> wrote:
> 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 from SRX clusters to MX-A are working,
> looks like it chose the right port by accident.
>
> Regards,
>
> 2014/1/16 Ben Dale <bdale at comlinx.com.au>:
> > 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 be down from a reth perspective,
> even if the LACP shows as up.
> >
> > On 16 Jan 2014, at 4:42 pm, Samol <molasian at gmail.com> wrote:
> >
> >> Hi Aaron,
> >>
> >> LACP is running on the reth interface and reth's are up. below is the
> >> configuration:
> >>
> >> Admin at coolSRX# show interfaces reth1
> >> vlan-tagging;
> >> redundant-ether-options {
> >> redundancy-group 1;
> >> lacp {
> >> passive;
> >> periodic fast;
> >> }
> >> }
> >>
> >> this link was successful for this. http://cooperlees.com/blog/?p=401
> >>
> >>
> >>
> >> 2014/1/16 Aaron Dewell <aaron.dewell at gmail.com>:
> >>>
> >>> 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's why the OSPF session from the right MX is down - because the MX is
> transmitting to the wrong node for that redundancy-group and it's being
> ignored.
> >>>
> >>> On Jan 15, 2014, at 11:52 PM, Samol wrote:
> >>>> 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 interesting that LAG are running even though links are
> >>>> connected two different nodes (this is for Reth interface). But I
> >>>> tried to use AE interface on SRX cluster, the theory is true that we
> >>>> can't bundle two links that land on different node. we just can't
> >>>> commit. that is the reason we move to Reth.
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 2014/1/16 Ben Dale <bdale at comlinx.com.au>:
> >>>>> 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 cluster must be connected to a different LAG at the
> peer devices. If a single peer switch is used to terminate the redundant
> Ethernet interface LAG, two separate LAGs must be used in the switch.
> >>>>>
> >>>>> From a single MX a single LAG should got to a single individual node
> from the chassis cluster.
> >>>>>
> >>>>> Can you paste the OSPF configs from each RI on the SRX and MX-B?
> >>>>>
> >>>>> On 16 Jan 2014, at 2:51 pm, Samol <molasian at gmail.com> wrote:
> >>>>>
> >>>>>> what i'm doing is LACP (ae) from MX to LACP (reth) SRX where one
> link is on Node0 and another is on node1. both link on SRX are member of
> Reth.
> >>>>>>
> >>>>>> Admin at coolSRX# show interfaces reth1
> >>>>>> vlan-tagging;
> >>>>>> redundant-ether-options {
> >>>>>> redundancy-group 1;
> >>>>>> lacp {
> >>>>>> passive;
> >>>>>> periodic fast;
> >>>>>> }
> >>>>>> }
> >>>>>>
> >>>>>> {primary:node0}[edit]
> >>>>>> Admin at coolSRX# run show lacp interfaces reth1
> >>>>>> Aggregated interface: reth1
> >>>>>> LACP state: Role Exp Def Dist Col Syn Aggr Timeout
> Activity
> >>>>>> ge-0/0/4 Actor No No Yes Yes Yes Yes Fast
> Passive
> >>>>>> ge-0/0/4 Partner No No Yes Yes Yes Yes Fast
> Active
> >>>>>> ge-9/0/4 Actor No No Yes Yes Yes Yes Fast
> Passive
> >>>>>> ge-9/0/4 Partner No No Yes Yes Yes Yes Fast
> Active
> >>>>>> LACP protocol: Receive State Transmit State Mux
> State
> >>>>>> ge-0/0/4 Current Fast periodic Collecting
> distributing
> >>>>>> ge-9/0/4 Current Fast periodic Collecting
> distributing
> >>>>>>
> >>>>>> All interfaces are UP. Reth's on SRX are also up. ae interfaces on
> MX-A and B are also UP.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2014/1/16 Ben Dale <bdale at comlinx.com.au>
> >>>>>>
> >>>>>> On 16 Jan 2014, at 11:22 am, Samol <molasian at gmail.com> 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 layers:
> >>>>>> - is the reth interface on SRX-B definitely up when you have both
> links enabled
> >>>>>> show chassis cluster interfaces
> >>>>>> - is your LACP up between MX-B and the cluster - bearing in mind
> that you cannot have a single LAG between MX-B and your SRX (it will need
> to be a LAG to each cluster node)
> >>>>>> show lacp interfaces
> >>>>>> - if the neighbor is only down on one of the RIs, assuming you have
> a VLAN between the MX and the SRX to carry each RI - double check that the
> VLAN is actually tagged on both LAGs between the two boxes
> >>>>>> show bridge domain interface aex.0
> >>>>>>
> >>>>>> Ben
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Samol Khoeurn
> >>>>>> (855) 077 55 64 02 / (855) 067 41 88 66
> >>>>>> Network Engineer
> >>>>>> Cisco: CCNA/CCNP SP/CCIP/
> >>>>>> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> >>>>>> www.linkedin.com/in/samolkhoeurn
> >>>>>> <OSPF on SRX clustering.png>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Samol Khoeurn
> >>>> (855) 077 55 64 02 / (855) 067 41 88 66
> >>>> Network Engineer
> >>>> Cisco: CCNA/CCNP SP/CCIP/
> >>>> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> >>>> www.linkedin.com/in/samolkhoeurn
> >>>>
> >>>> _______________________________________________
> >>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>>
> >>
> >>
> >>
> >> --
> >> Samol Khoeurn
> >> (855) 077 55 64 02 / (855) 067 41 88 66
> >> Network Engineer
> >> Cisco: CCNA/CCNP SP/CCIP/
> >> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> >> www.linkedin.com/in/samolkhoeurn
> >>
> >
>
>
>
> --
> Samol Khoeurn
> (855) 077 55 64 02 / (855) 067 41 88 66
> Network Engineer
> Cisco: CCNA/CCNP SP/CCIP/
> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> www.linkedin.com/in/samolkhoeurn
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Thanks,
Morgan
More information about the juniper-nsp
mailing list