Question about EX - SRX redundancy

Hugo Slabbert hugo at slabnet.com
Thu Apr 2 15:51:05 UTC 2015


In:

>> > EX0  (ae1) >> Two Patches to SRX0 (reth1)
>> > EX1   (ae2)  >> Two Patches to SRX1 (reth1)

with:

>> > that if one EX goes down then I cannot make use of other corresponding
>> SRX.

Do you mean that e.g. if SRX0 is the chassis cluster primary and EX0 goes 
down, then you can't use SRX0, but you would like to be able to survive EX0 
going down *without* failing over the SRX chassis cluster to SRX1?

-- 
Hugo

On Thu 2015-Apr-02 20:47:03 +0530, Anurag Bhatia <me at anuragbhatia.com> wrote:

>Hi
>
>
>I thought cross chassis lag is supposed by the use of reth bundled at SRX
>end. I read this is basically the major difference in reth Vs ae bundle in
>SRX.
>
>
>Interesting factor here is that ae bundles can spread across multiple EX
>chassis in a virtual chassis environment but this cannot be the case with
>ae bundles in SRX.
>
>
>
>
>Thanks.
>
>On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford <bblackford at gmail.com> wrote:
>
>> It's my understanding that a cross chassis LAG is not supported. If there
>> is a way, I'm not aware of it. I'm running the same set up as your working
>> example in my locations and for now, this suits my requirements.
>>
>> Sent from my iPhone
>>
>> > On Apr 2, 2015, at 07:12, Anurag Bhatia <me at anuragbhatia.com> wrote:
>> >
>> > Hello everyone!
>> >
>> >
>> >
>> >
>> > I have got two Juniper EX series switches (on virtual chassis) and two
>> SRX
>> > devices on native clustering.
>> >
>> >
>> > I am trying to have a highly available redundancy between them with
>> atleast
>> > 2Gbps capacity all the time but kind of failing. I followed Juniper's
>> > official page here
>> > <http://kb.juniper.net/InfoCenter/index?page=content&id=KB22474> as
>> well as
>> > this detailed forum link here
>> > <
>> http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way-of-redundancy-between-SRX-and-EX/td-p/181365
>> >
>> > .
>> >
>> >
>> > I wish to have a case where devices are connected criss cross and
>> following
>> > the documentation I get two ae bundles in EX side and one single reth
>> > bundle on SRX side. Both ae bundles on EX side have identical
>> configuration
>> > and VLAN has both ae interfaces called up.
>> >
>> >
>> > If I do not go for criss cross connectivity like this:
>> >
>> >
>> >
>> > EX0  (ae1) >> Two Patches to SRX0 (reth1)
>> > EX1   (ae2)  >> Two Patches to SRX1 (reth1)
>> >
>> >
>> > Then it works all well and redundancy works fine. In this case as long
>> as 1
>> > out of 4 patch is connected connectivity stays live but this has trade
>> off
>> > that if one EX goes down then I cannot make use of other corresponding
>> SRX.
>> >
>> > If I do criss connectivity, something like:
>> >
>> >
>> > EX0 (ae1) >> Two Patches to SRX0 (reth1)
>> > EX0 (ae1) >> One patch to SRX1 (reth1)
>> >
>> > EX1 (ae2)  >> Two Patches to SRX1 (reth1)
>> > EX1 (ae2)  >> One patch to SRX0 (reth1)
>> >
>> >
>> > In this config system behaves very oddly with one ae pair (and it's
>> > corresponding physical ports) working well while failover to other ae
>> > bundle fails completely.
>> >
>> >
>> >
>> > I was wondering if someone can point me out here.
>> >
>> >
>> >
>> >
>> > Appreciate your time and help!
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> >
>> > Anurag Bhatia
>> > anuragbhatia.com
>> >
>> > Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter
>> > <https://twitter.com/anurag_bhatia>
>> > Skype: anuragbhatia.com
>> >
>> > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2
>>
>
>
>
>-- 
>
>
>Anurag Bhatia
>anuragbhatia.com
>
>Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter
><https://twitter.com/anurag_bhatia>
>Skype: anuragbhatia.com
>
>PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150402/1961e480/attachment.sig>


More information about the NANOG mailing list