[j-nsp] MX Design

[Michael Still]

On Thu, Sep 13, 2012 at 10:08 AM, Chuck Anderson <cra at wpi.edu> wrote:
> On Thu, Sep 13, 2012 at 10:55:41AM +0200, Johan Borch wrote:
>> Hi,
>>
>> I have two mx and two ex connected as follows, L2 on the EX and L2/L3
>> on MX, MX handles all the routing.
>>
>>
>> MX -- MX
>> |   \   /   |
>> |   /   \   |
>> EX -- EX
>>    \    /
>> Access-sw
>>
>>
>> What is the best way to tie everything together? MSTP all the way up
>> to MX or is there a better way? How do I transport VLAN's between the
>> MX, with just tagging the interfaces between or is some kind of MPLS
>> better?
>
> We have a similar setup and are currently doing MSTP all the way
> through, with 2 MSTIs and half the VLANs in each MSTI.  It works ok as
> long as you are diligent about monitoring for STP topology changes and
> minimizing/mitigating them as much as possible.  Don't allow random
> users to plug/unplug STP-enabled devices, put all your edge ports into
> edge mode and use bpdu-block-on-edge.  Also use no-root-port
> protection on the MXes and set your bridge-priorities appropriately
> (such as priority 0 for one MX, 4k for the other).
>
> Options for avoiding/migrating away from MSTP:
>
> 1. MX Virtual Chassis + EX Virtual Chassis + regular AEs between them.
>    Gets you full load-sharing, all links active on all VLANs, at the
>    expense of fate-sharing your MXes with a single
>    control-plane/management-plane between them.  This might actually
>    work well with the latest 11.4 release...
>
> 2. EX Redundant Trunk Groups (RTG) to disable one of the uplink ports
>    locally until the other one fails.  Active-Passive only, but
>    simple--no control protocols to worry about.  Combine with EX VC
>    and use regular AE to Access-sw if possible.
>
> 3. MX Multi-Chassis LAG (MC-LAG).  Either Active-Active or
>    Active-Passive.  Somewhat complicated control protocol that is
>    bug-prone.  I've seen PR's in the release notes that describe
>    problems of the sort that I first encountered on Nortel's
>    Split-Multi-Link Trunking 5-7 years ago.  The same mistakes are
>    being made by Juniper.  I think this proves that this technology is
>    perhaps overly complicated and difficult to get the implementation
>    right.  Requires robust LACP implementation on the edge device,
>    which should be OK if you stick with Juniper, hit-or-miss with
>    other vendors.
>
> 4. Wait for Juniper to implement IEEE 802.1aq Shortest Path Bridging
>    (SPB), especially SPB-MAC (SPBM).  It is unclear to me if the EX
>    line hardware can support the MAC-in-MAC encapsulation required by
>    SPBM.  It is my belief that this is the future of L2 networking.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

Or treat the MX as if it couldn't do any "switching" and run L3
between the EXs and MXs only.  Make the EXs the next hop for your
devices "under" them and have OSPF between the EXs and MXs with MXs
supplying 0.0.0.0/0 and ECMP going on the between them.  Load sharing,
dynamic / easy failover, no FHRP (EXs are in a stack), and a setup
that's been proven to work for many years.  Oh and you don't need STP
at all.



-- 
[stillwaxin at gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwaxin at gmail.com ~]$