1GE L3 aggregation

Mon Jun 20 14:07:02 UTC 2016

On 2016-06-20 08:50, Mark Tinka wrote:
> We don't run l3vpn's for infrastructure requirements. We only run them 
> if a customer wants an l3vpn service. Mark. 

For a long time we only had one l3vpn customer: our self. It is a good 
way to separate the control network from the internet. So our config was 
"vrf default" = IGP and remote access to devices, "vrf internet" = the 
thing we deliver to customers.

There are two reasons we are not doing l3vpn with ip termination at the 
access edge devices anymore:

1) We have our own GPON switches and this is our original business. We 
later connected to the ILEC to resell DSL service on their DSLAMs. The 
ILEC delivers customers as Q-in-Q with one vlan per customer. 
Unfortunately our access edge devices do not support layer 3 Q-in-Q 
termination, so we had no other choice than to backhaul the DSL 
customers in a l2vpn. We then reconfigured our GPON service to emulate 
the same Q-in-Q one VLAN per customer so we only have one way to do things.

2) IP address scarcity. We used to allocate IP addresses to the edge 
devices in blocks of 64 (/26 subnet). But this still creates 
inefficiency where one area has free address space and another area is 
out. Also it is much work to constantly allocate new address blocks. It 
is easier with the centralized solution because customers can be pooled 
together irrespectively of where they actually live using the supervlan 
feature.

Also we have trouble with a bad IPv6 implementation, that made the 
network unstable when we did IPv6 termination at the access edge. This 
has since been solved. But it is a reminder that we sometimes end up 
with different solutions than planed due to bugs and other unforeseen 
trouble.

Regards,

Baldur