[179207] in North American Network Operators' Group
Re: Question about EX - SRX redundancy
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Thu Apr 2 18:22:38 2015
X-Original-To: nanog@nanog.org
Date: Thu, 2 Apr 2015 15:22:34 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Anurag Bhatia <me@anuragbhatia.com>
In-Reply-To: <CAJ0+aXZHJ6CfuWvG2VWq1sw5dyQ9Xav_vQEDQ18vVYX-SiNt_w@mail.gmail.com>
Cc: NANOG Mailing List <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--4LFBTxd4L5NLO6ly
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I just want to confirm your setup.
The "criss-cross" setup you were describing is different from what I=20
described.
You listed:
>>>>>> > 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)
=2E..meaning that your AEs cannot survive losing either one of the EX VC=20
members, and you're splitting each AE's connectivity across the two SRX=20
chassis cluster members. You need to dedicate an AE to an SRX chassis=20
cluster member.
IOW: ae18 should have one LAG member on EX0 and one member on EX1, and both=
=20
of those physical ports go to SRX0. Likewise, ae20 should have one LAG=20
member on EX0 and one member on EX1, and both of those physical ports go to=
=20
SRX1.
When you shut one of the AEs (e.g. ae18) in the setup I describe, you=20
*will* lose connectivity to its corresponding SRX, as those are=20
fate-sharing. You would need to configure interface monitoring on the=20
chassis cluster to flip over the primary to 2nd SRX in order to survive=20
that, since the second AE (ae20) that is tied to the 2nd SRX is still up.
Your failure modes are:
e.g. 1: lose an EX, you lose the throughput that's being contributed to the=
=20
AE by that VC member's ports, but both SRXs remain available and the=20
primary shouldn't flip (provided your node priorities and=20
interface-monitoring weights are set accordingly).
e.g. 2: shut an AE (which spans both EX VC members), one SRX goes dark=20
since you've killed the AE that's dedicated to it, and the primary will=20
need to flip (either through interface monitoring or manually) in order for=
=20
the setup to remain online.
--=20
Hugo
On Fri 2015-Apr-03 02:41:35 +0530, Anurag Bhatia <me@anuragbhatia.com> wrot=
e:
>Hi
>
>
>Tried exactly same. Note: it's ae18 and ae20 on EX side and reth4 on SRX
>side.
>
>
>Initially worked but when I took down ae18, i.e ae18 is disabled, now on
>ae20 I am getting:
>
>show interfaces ae20
>Physical interface: ae20, Enabled, Physical link is Up
> Interface index: 533, SNMP ifIndex: 924
> Link-level type: Ethernet, MTU: 1514, Speed: 2Gbps, BPDU Error: None,
>MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
> Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth
>needed: 0
>
>
>
>on reth4 on SRX I am getting:
>
>show interfaces reth4
>Physical interface: reth4, Enabled, Physical link is Down
> Interface index: 132, SNMP ifIndex: 696
>
>
>
>Any idea why so? All physical ports are up (none is shut) and only thing
>which I shut is one of ae bundles. Also rather then disabling ae18 if I
>disabled associated physical ports behavior is just the same i.e reth4 goes
>down.
>
>
>
>
>Thanks for your time and help!
>
>
>
>On Fri, Apr 3, 2015 at 12:25 AM, Hugo Slabbert <hugo@slabnet.com> wrote:
>
>> Putting the EXs in a VC and splitting your AEs across the 2x VC members
>> takes care of that.
>>
>> EXVC (ae1) >> Two Patches to SRX0 (reth1)
>> EXVC (ae2) >> Two Patches to SRX1 (reth1)
>>
>> ...where EXVC is a VC composed of EX0 and EX1, and ae1 and ae2 both have
>> one member interface from each VC member.
>>
>> In a failure of EX0 or EX1, your throughput on ae1 and ae2 halves as they
>> each lose a LAG member, but both SRX0 and SRX1 are still reachable.
>>
>> --
>> Hugo
>>
>>
>> On Thu 2015-Apr-02 23:50:46 +0530, Anurag Bhatia <me@anuragbhatia.com>
>> wrote:
>>
>> Hi
>>>
>>>
>>>
>>> Yes,
>>>
>>>
>>> Since SRX0 connected to EX0 and SRX1 connected to EX1 (only). Thus eith=
er
>>> pair - 0 will work or pair - 1 will work. I wish if criss crossing work=
ed
>>> then failure of one EX would have still made both SRX available.
>>>
>>>
>>> In current worst case scenario - failure of EX0 and SRX1 can cause full
>>> outage.
>>>
>>>
>>>
>>> Thanks.
>>>
>>> On Thu, Apr 2, 2015 at 9:21 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
>>>
>>> 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 correspond=
ing
>>>>
>>>>> 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@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 bund=
le
>>>>> 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@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@anuragbhatia.com> wrot=
e:
>>>>>> >
>>>>>> > 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 Junipe=
r's
>>>>>> > official page here
>>>>>> > <http://kb.juniper.net/InfoCenter/index?page=3Dcontent&id=3DKB2247=
4> 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 r=
eth
>>>>>> > 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
>>>>>
>>>>>
>>>>
>>>
>>> --
>>>
>>>
>>> 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
>>>
>>
>
>
>--=20
>
>
>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
--4LFBTxd4L5NLO6ly
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJVHcEqAAoJEJqxD/2xeDE+6KYP/icwQ7zcaAU9fnPpN+Kpzfc2
8W7skaViKCBONYqkw2evih4VuL6wYwQTz1nyCj8DoflYrxXoh49FCEM6Wer8h2+N
F7oR1JWzuYjS4WLZfCdcH2TvbXILFfCHU2mBHyQWUIaIfz3tR5hSrR4StVpxUcm4
34XxkEKxhSlN5q6G4FN2UnEcgKIQskT/o4S6ziarJG1KUxjJGG7VSWNLRZXxgRs8
kh3cyI6zjQcTI289wbktaupK1kgxEAyT1K0IjG6GnQuA2KkeMHPpPRlBPC0uzHQX
sWoXqOZYf8UVQTz0HaPlhTYo6h8/yD/aIBhbeGqSdgIaLPl28cNWeL1aFboSGj9b
RHEXr1gmnA+Vhc3kpxTpB7JZE/J4216/Dc7u1gcsLtESsrEYigb9VsOfPu9hn61P
HpElT7+iwEsyfAYs+/RSiMgBJ7PheVJ3+G4ALTAo4I/D8+wcB/RPxccVdY4dWnl5
ufsKx6QGUSxHB2wsg1zVuuVpV9BBISWBxypOKMADUA0GNATv+YT9Si8GAKIuWU3F
R+N9oM1nuBcoCHN01lJuiGgo+zYvbd+hTzARKCNnhFjN9foQeeO9cO4bx7BwMmg0
wBPTaJBOyH1vjy4zkXy3+d0C6bwzw5RueLzNcoJBW359SC8R0QvLaJH835wgYvyx
646PAUa1TVx2KvsrF4yQ
=8I8R
-----END PGP SIGNATURE-----
--4LFBTxd4L5NLO6ly--
