[j-nsp] Acx5048 ecmp feature and usage

[Alexandre Guimaraes]

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