[j-nsp] Acx5048 ecmp feature and usage

[Tim Jackson]

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