[j-nsp] Acx5048 ecmp feature and usage

[Giuliano Medalha]

Engineering team for QFX5100 BU (same Tridend2 box as ACX5048) released a
new version with ECMP for MPLS:

See the release notes bellow:

http://www.juniper.net/techpubs/en_US/junos14.1/information-products/topic-collections/ex-qfx-series/release-notes/ex-ocx-qfx-series-junos-release-notes-14.1X53-D35.pdf

Page 46.

I really does not know about the ACX5048 BU team ... but I think there is a
good chance to work too ...

Att,

Giuliano

Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuliano at wztech.com.br
http://www.wztech.com.br/



​
WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2016 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos
são confidenciais e para conhecimento exclusivo do destinatário. Se o
leitor  desta  mensagem  não  for o seu destinatário,
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo
dos documentos anexos. Neste caso, favor comunicar imediatamente
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida
apague-o.


CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are
solely for the intended recipient and may contain confidential or
privileged information. If you are not the intended recipient, any review,
transmission,  dissemination or other use of this information is
prohibited. If you have received this communication in error, please notify
the sender immediately and delete the material from any computer, including
any copies.

On Mon, Mar 28, 2016 at 11:12 PM, Tim Jackson <jackson.tim at gmail.com> wrote:

> For L3 and L3VPN ECMP should work fine. For any L2oMPLS you're gonna be
> SOL.
> On Mar 28, 2016 9:08 PM, "Alexandre Guimaraes" <
> alexandre.guimaraes at ascenty.com> wrote:
>
> > Gents,
> >
> > I had a demand where the equipment that best fits is an ACX5048 for N
> > reasons
> >
> > I use some vpls and l2circuits, but there is a feature that i need to
> use,
> > ecmp.
> >
> > Someone had knownledge about the ecmp feature using ACX5048?
> >
> > Att.
> > AŁexandre
> >
> > > Em 28 de mar de 2016, às 22:34, Mark Tees <marktees at gmail.com>
> escreveu:
> > >
> > >> On 27 March 2016 at 22:02, Saku Ytti <saku at ytti.fi> wrote:
> > >> On 27 March 2016 at 13:37, Mark Tinka <mark.tinka at seacom.mu> wrote:
> > >>
> > >> Hey,
> > >>
> > >>> As costs and management got out of control, they run l3vpn's and
> > >>> Internet in the same chassis, but on different line cards.
> > >>>
> > >>> Eventually, everything converged.
> > >>
> > >> I tend to agree. If there is significant CAPEX delta buying L3 MPLS
> > >> VPN + HQoS capable boxes and Internet transit capable boxes, then it
> > >> might make sense to buy two networks, as likely L3 MPLS VPN traffic
> > >> rates are very minor but service requires much higher touch hardware.
> > >> But I don't suspect the delta is high these days and more importantly
> > >> I don't think the IP device CAPEX is very large part of TCO.
> > >>
> > >> Another justification might be, if the software stack is very
> > >> different, but for L3 MPLS VPN will need all services IP Transit uses,
> > >> so having IP Transit on same devices does not require turning on
> > >> additional services, so it is not really creating additional risk on
> > >> the premium services.
> > >> If your bread and butter would be L2 VPN, then separating IP transit
> > >> on another edge device might be very prudent, as you could do away
> > >> with BGP and IP lookups completely on the edge.
> > >>
> > >> I am fan of Internet-in-VRF, mainly because global-table is special
> > >> case and it's hard to import/export route between global and VRF, and
> > >> this complexity has forced me to do some really bad/ugly solutions,
> > >> which would have been clean and simple if Internet was in VRF. It does
> > >> not have to mean ugly traceroutes, you can configure device on TTL
> > >> exceeded to pop labels and do IP lookup in transit for returning TTL
> > >> exceeded messages. This does not even exclude BGP free core, as your
> > >> core can have static route pointing to anycast IGP loopback added to
> > >> all edge devices with full BGP, so TTL exceeded message goes to
> > >> closest edge device for lookup, probably creating less than
> > >> millisecond additional delay on traceroute.
> > >
> > > Yes, ICMP tunnelling possibly seems to be what I need for that.
> > >
> > >>
> > >> OP states that mistakes in IGP do not affect each other, but mistakes
> > >> in the 'core' network IGP where the L2 circuits run, still break
> > >> everything.
> > >
> > > True, there is shared risk here but not in all cases for us.
> > >
> > >>
> > >> I'd say you need solid arguments to separate  the networks, state
> > >> exact specific problems and how it solves them, default to converged
> > >> network in absence of such arguments. For background it might be
> > >> interesting to hear what problems you've had, what is prompting this
> > >> separate edge.
> > >
> > > Agree. Rather than being paranoid about it I need a strict list.
> > >
> > >
> > >>
> > >>
> > >> --
> > >>  ++ytti
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Mark L. Tees
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp