nanog mailing list archives

Re: Linux BNG


From: Baldur Norddahl <baldur.norddahl () gmail com>
Date: Sat, 14 Jul 2018 21:05:38 +0200



Den 14/07/2018 kl. 19.09 skrev Raymond Burkholder:

Where do you have this happening? Do you have aggregation switches doing this? Are those already in place, or being planned? Because I would make a suggestion for how to do the aggregation.

The POI (Point of Interconnect) with the incumbent telco is one customer per vlan using QinQ. This telco owns all the copper and runs the VDSL2 DSLAMs. They give us a transparent ethernet tunnel to the CPE. We own the CPE. Internally the incumbent uses a MPLS network to transport the VLANs. We in turn also use MPLS with L2VPN to transport the traffic to one of two datacenters.

In addition we have our own FTTH network in the ground. This is GPON on Zhone equipment. To make things easier we made the Zhone GPON OLT emulate the same one VLAN per customer setup.

The incumbent have telco buildings in each city area. Typically distance between buildings is 10 km. In each such building they have a room where alternative telcos, like us, can rent rack space. The only available power is -48V DC. We currently only have Zhone MXK GPON switches and ZTE MPLS switch equipment in these facilities.

Our current BNG solution is some big iron routers (ZTE M6000). This is a device that will do things like 4 million routes in hardware and move many Tb/s (not that we have traffic anything near that level). It works well enough but is not perfect. I think a discussion of the BNG limitations of ZTE M6000 would be a different thread.

One of the problems with ZTE M6000 is the price and that goes double for any alternatives mentioned here (Cisco, Juniper etc). Right now I am facing the prospect of investing in more line cards for M6000. I can buy a few servers for the price of one line card and perhaps get a solution that is more "perfect".

As to VXLAN the Zhone MXK can not do it and it is not an option for the POI with the incumbent. It would be an alternative to running MPLS but we are happy with the MPLS solution.

I have considered OpenFlow and might do that. We have OpenFlow capable switches and I may be able to offload the work to the switch hardware. But I also consider this solution harder to get right than the idea of using Linux with tap devices. Also it appears the Openvswitch implements a different flavour of OpenFlow than the hardware switch (the hardware is limited to some fixed tables that Broadcom made up), so I might not be able to start with the software and then move on to hardware.

Regards,

Baldur



Current thread: