nanog mailing list archives

Re: 1GE L3 aggregation


From: Mark Tinka <mark.tinka () seacom mu>
Date: Sat, 18 Jun 2016 13:07:18 +0200



On 16/Jun/16 23:24, Baldur Norddahl wrote:

The ZTE 5952E (routing switch) can do L3VPN including BGP. But it is
limited to about 30k routes. It is usable if the customer wants a default
route solution, but not if he wants the full default free zone.

Might be worthwhile to ask ZTE to develop their own implementation of
BGP Selective Download.

Our PoPs are connected in a ring topology (actually multiple rings). If a
link goes down somewhere, or an intermediate device crashes, the L2VPN will
reconfigure and find another path.

Which is what would happen anyway with your IGP if the service were
delivered in the Access, but with fewer moving parts and less
inter-dependence if the problem went beyond just ring failure or device
crash.

For a BGP customer I could offer two tunnels, one to each of our provider
edge routers. But very few of our customers are BGP customers, they just
want normal internet. For them we do VRRP between the two provider edge
routers and have the one tunnel go to both.

If your BGP customer-count grows, while managing 2 eBGP sessions per
customer is not life-threatening, it's certainly won't go unnoticed from
an operational perspective, especially if you are doing this as a matter
of (redundancy) course, in lieu of a revenue-generating request by the
customer to increase their SLA.



We actually moved away from a hybrid solution with L3 termination at the
customer edge to simply backhauling everything in L2VPNs. We did this
because the L2VPN tunnels are needed anyway for other reasons and it is
easier to have one way to do things.

I've never been one to support the confluence of infrastructure tunnels
with customer service tunnels. That's why we avoid infrastructure
tunnels in general, e.g., creating a tunnel from a data centre to a
peering point over which you will run peering traffic because the device
at the data centre can't support peering, or running a tunnel between
two PoP's to handle intra-PoP traffic, e.t.c. When you have all these
tunnels running around, side-by-side with customer revenue-generating
tunnels for their own sake (like a site-to-site l2vpn you've sold to a
customer), it can get hairy at scale, I think. Too much
inter-dependence, too many lines coming together. But again, that's just me.

Mark.


Current thread: