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 <markt...@gmail.com> escreveu: > >> On 27 March 2016 at 22:02, Saku Ytti <s...@ytti.fi> wrote: >> On 27 March 2016 at 13:37, Mark Tinka <mark.ti...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp