[j-nsp] Separate internet transit network versus converged
saku at ytti.fi
Sun Mar 27 07:02:01 EDT 2016
On 27 March 2016 at 13:37, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 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.
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
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
More information about the juniper-nsp