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" < [email protected]> 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 <[email protected]> escreveu: > > > >> On 27 March 2016 at 22:02, Saku Ytti <[email protected]> wrote: > >> On 27 March 2016 at 13:37, Mark Tinka <[email protected]> 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 [email protected] > > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
