[j-nsp] OSPF neig / SRX cluster / LACP

Ben Dale bdale at comlinx.com.au
Thu Jan 16 01:52:46 EST 2014


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
> 




More information about the juniper-nsp mailing list