IPAM DDI Software, Subscriber Management, CMDB and Per Customer VLANs
I would like recommendations on the following software/hardware elements required to run an access network. Assume you are building a greenfield network using a combination of access technologies such as DSL, GPON, AE, and WiFi. IPAM / DDI Solution: Needs full support for IPv6, Customer VLANs, RFC 1918, VRF, Overlapping Address Space, integration with DNS, DNSSEC, Integration with DHCP, and integration with ARIN. Looks like there are both open source and commercial solutions available according to old NANOG posts. Which cater to service providers? Who are the leaders in this space? Does anyone have experience with dealing with multiple vendors? Subscriber Management/BRAS/BNG: Redback was the big player back in the day, but I believe they are no longer. Juniper has their Subscriber Management feature pack on their MX routers, and Cisco has their Broadband Network Gateway on their ASR routers. Besides these two vendors I am not sure what other solutions are out there. I believe both of these solutions communicate upstream to external radius servers and DHCP servers. Is anyone using Subscriber Management, or is there another way of doing it? CMDB: A centralized database to keep track of all assets within the network would be nice. I would assume this would need to tie in with the IPAM solution and billing systems. I would also like to hear thoughts on the per customer VLAN model. Most of the whitepapers recommend a per customer VLAN for greenfield networks, but that seems like a management and documentation nightmare. The systems described above must be able to manage and maintain per customer VLANs in an automated fashion for this approach to work and scale. If you had your choice starting from the ground up how would you deploy an access network today?
hey,
Subscriber Management/BRAS/BNG: Redback was the big player back in the day, but I believe they are no longer. Juniper has their Subscriber Management feature pack on their MX routers, and Cisco has their Broadband Network Gateway on their ASR routers. Besides these two vendors I am not sure what other solutions are out there. I believe both of these solutions communicate upstream to external radius servers and DHCP servers. Is anyone using Subscriber Management, or is there another way of doing it?
ALU is the most known (and yet least known as subscriber management is mainly used by big telcos who are not sharing what they do internally) and has best subscriber management features both v4 and v6. Google "ALU 7750". -- tarko
On 2014-05-13 16:37, Kyle Leissner wrote:
I would like recommendations on the following software/hardware elements required to run an access network. Assume you are building a greenfield network using a combination of access technologies such as DSL, GPON, AE, and WiFi.
What a timely thread! With all the talk the past several days about incumbents and lack of alternatives, I'm glad to see someone starting a new network! If it's not ultra proprietary, what (major) geographical region are you looking to start in, how many homes/businesses do you intend to pass? Or is this all theoretical? I've recently helped a coalation of non profits start an access network in Kansans City Missiouri/Kansas. It passes about 1,000 homes. Uses wifi exclusively. Meraki / Ubiquiti gear in the access layer, Ubiquiti gear in the backbone. We've been ironing out things like grounding/access to facilities, user access policies, dealing with bandwidth hogs etc etc. Now we are getting to the support suite and asking some of the same questions you are. One thing I don't see you mention below is a network monitoring system. What are you using for that?
IPAM / DDI Solution: Needs full support for IPv6,
Of course. That's important.
Customer VLANs,
QinQ? You looking at offering metro-e services? RFC
1918,
ewww. v6 sir! Greenfield network and everything.
VRF, Overlapping Address Space,
ewww again. Those are horrible hacks, v6 all the things.
integration with DNS, DNSSEC,
So what does that mean? Create forward/reverse zone entries? Do you want to be able to delegate zone editing to customers? You'll need strong ACLs and what not. What does integration with DNSSEC mean to you?
Integration with DHCP,
v4? v6? SLACC? RADVD?
and integration with ARIN.
You mean the ARIN API? So you can setup auto SWIP? Looks like there are
both open source and commercial solutions available according to old NANOG posts.
Indeed. I've been looking at http://nocproject.org/ which should cater to most of the above requirements. Which cater to service providers? Who are the leaders in
this space? Does anyone have experience with dealing with multiple vendors?
Multiple vendors in what regard? You mean integrating offerings from multiple vendors? Honestly I'd spend money on a couple good integration engineers. What you are looking for almost certainly will need a good amount of perl/python/bash glue to work. You could also throw money at proprietary solutions, which might get you what you want.
Subscriber Management/BRAS/BNG: Redback was the big player back in the day, but I believe they are no longer. Juniper has their Subscriber Management feature pack on their MX routers, and Cisco has their Broadband Network Gateway on their ASR routers. Besides these two vendors I am not sure what other solutions are out there. I believe both of these solutions communicate upstream to external radius servers and DHCP servers. Is anyone using Subscriber Management, or is there another way of doing it?
What is subscriber management? You mean like provisioning and such? Ah here is a description: "Broadband Subscriber Management is a method of dynamically provisioning and managing subscriber access in a multiplay or triple play network environment. This method uses AAA configuration in conjunction with dynamic profiles to provide dynamic, per-subscriber authentication, addressing, access, and configuration for a host of broadband services including Internet access, gaming, IPTV, Video on Demand (VoD), and subscriber wholesaling." We (Free Network Foundation) are doing this with RADIUS. FreeRadius on the backend, hostapd on the access layer (fairly heavily modified, we'll be submitting patches upstream soon), pfsense (with pfblocker, but used in a reverse manner). This gives us full AAA capabilities. It's somewhat "hacked" together, but our testing has seen good results so far. We hope to deploy in limited production test this weekend.
CMDB: A centralized database to keep track of all assets within the network would be nice. I would assume this would need to tie in with the IPAM solution and billing systems.
Yes. Agreed. I've not necessarily come up with a good system for this. I'm using a combination of Zenoss / Observium (will retire Observium once I have figured out the Zenoss API).
If you had your choice starting from the ground up how would you deploy an access network today?
Well since I'm in the process of doing that: v6 only (though to be honest, we are v4 right now, but heavily testing v6. Still lots of broken stuff, like gaming) All FLOSS. Pfsense for internet edge (OSPF/BGP) routing, full l7 firewalling/IDS/IPS, proxy/caching Zenoss (up/down, trending) Observium (used as a CMDB, will be retiring for Zenoss soon) Slack/Rundeck (configuration management, command dispatching). Since everything is *NIX with a shell, I can just treat the routers/access points like *NIX boxes and have access to a full suite of tools. OpenWRT (qmp.cat firmware build) + Quagga (to redistribute the bmx6 protocol routes (adhoc/dynamic wireless) into OSPF/BGP (static wireless/wired) hostapd (heavily patched) FreeRADIUS Users fund/own the equipment. They can buy as little or much as they like (we advise them on a recommended bill of materials and help with sizing etc). This keeps costs low. Multiple transit providers of course. That's it off the top of my head.
On 14 May 2014 16:14, <charles@thefnf.org> wrote:
On 2014-05-13 16:37, Kyle Leissner wrote: RFC
1918,
ewww. v6 sir! Greenfield network and everything.
VRF, Overlapping Address Space,
ewww again. Those are horrible hacks, v6 all the things.
People use VRF's to provide Layer3 VPNs to customers. Customers typically use overlapping address space in their networks. VRFs are not horrible hacks. Regards, Dave
On Wed, 14 May 2014 17:09:02 +0100, Dave Bell said:
People use VRF's to provide Layer3 VPNs to customers. Customers typically use overlapping address space in their networks.
That's the customer's problem inside their networks. If you have overlapping address space in *your own greenfield* network, you're probably doing something wrong.
It depends on the service you are providing. If its fully managed up to the customer premises, I fail to see how you can get away without knowing what addressing the customer is using. On 14 May 2014 17:16, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 14 May 2014 17:09:02 +0100, Dave Bell said:
People use VRF's to provide Layer3 VPNs to customers. Customers typically use overlapping address space in their networks.
That's the customer's problem inside their networks. If you have overlapping address space in *your own greenfield* network, you're probably doing something wrong.
participants (6)
-
charles@thefnf.org
-
Dave Bell
-
Kyle Leissner
-
Mark Tinka
-
Tarko Tikan
-
Valdis.Kletnieks@vt.edu