1GE L3 aggregation

Mark Tinka mark.tinka at seacom.mu
Mon Jun 20 06:50:24 UTC 2016



On 18/Jun/16 21:31, Baldur Norddahl wrote:

> Is the claim about fewer moving parts actually true? Yes if you are
> comparing to a plain native single-stack network with IPv4 (or IPv6)
> directly on the wire. But we are doing MPLS, so in our case it is L2VPN vs
> L3VPN. Both will reroute using the exact same mechanism, so no difference
> here.

I'm talking about all services.

We deliver Internet Access/IP Transit, l2vpn's, and l3vpn's on the same
chassis in the Access depending on what the customer wants.

We are only touching one box in this case (the Access switch), and not
more than one when delivering any of these services. This is what I mean
by fewer moving parts - and if a problem were to occur in the Access or
the core, provided that at least one path of the fibre was fine, that
problem would be masked from the Access.

When you have dependence between far-end devices (such as an l2vpn from
the Access terminating on a centralized IP gateway for onward services),
the coupling is too tight and makes things more fragile.

>
> I found that I could remove large parts of the configuration on the access
> edge devices when we went from L3VPN to L2VPN. Some people will find the
> network easier to understand when all major configuration is in only two
> devices, and those two devices are mostly a mirror of each other.

While I like lean configurations as much as the next guy, you can't run
away from them.

Removing lines from one device means you add more on another.

Standardization of configurations means you know what to expect (and
what not to expect) regardless of the number of devices. 2016 being all
the "automation" and "zero touch deployment" rage, it is now possible to
operate the network without having to struggle with what the
configuration on each device is. I'd rather invest in that than
centralized routers.

>
> I agree that L3VPN is the better solution, at least in principle. That is
> why we started by implementing L3VPN. But in practice the L2VPN solution we
> have now is actually easier.

We don't run l3vpn's for infrastructure requirements. We only run them
if a customer wants an l3vpn service.

Mark.



More information about the NANOG mailing list