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