1GE L3 aggregation

Mark Tinka mark.tinka at seacom.mu
Sat Jun 18 11:07:18 UTC 2016



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.




More information about the NANOG mailing list