Table of Contents

Building Address Lists

Alex Moore Updated by Alex Moore

Read Time: 5 mins

General Overview

An address list is a list of IPv4 and/or IPv6 addresses and subnets. The only purpose of an address list is to group together IPs that you wish to add as a group to an inline device.

The primary purpose of an address list is to implement some kind of policy using an inline device on a group of IPs. For example, you could group all IPs that are on active accounts with a particular data service. You can then reference that address list on the inline device to implement a shaping rule on the group. You could also create an address list for all delinquent accounts, and implement a redirect rule on your inline device to send those users to a walled garden until they pay their bill. The possibilities are only limited by the functionality available in the inline device.

Name

The name of the address list can only contain letters and numbers - this is to ensure compatibility with a wide range of inline devices. Whatever name you enter here will be used to name the address list on the inline device.

If you create an address list named DelinquentCustomers and you have a Procera PRE as an inline device, the Procera PRE will have a NetObject named DelinquentCustomers on it. Renaming the address list in Sonar will also rename the address list on the inline device. A name must be unique.

Required Fields

Account Status

The Account Status limit allows you to include all accounts, regardless of status, or only accounts that have either an inactive or active status. This is commonly used to perform an action like redirecting any inactive accounts to a walled garden.

Delinquency

The Delinquency section allows you to include all accounts, only accounts that are current on their invoices, or only accounts that are delinquent. You could use this to perform an action like redirecting all delinquent accounts to a splash page informing them they must pay their bill to be reactivated.

When creating address lists, each new row is treated as an AND statement. If you select multiple items within a row, they are treated as an OR statement.

Non-required Fields

Non-required fields include Account Groups, Account Statuses, Account Types, and Data Services. If, under the Account Status section, you select Active and Lead, and under the Account Type section, you select Residential, the check applied would be as follows in plain English:

Any account who has either an Active status OR a Lead status, AND is Residential will be placed into this address list.

All changes you make to an address list will modify the address lists on your inline devices in real time, unless the inline device is disabled. Deleting an address list will also remove it from the inline device. If you wish to make changes to your address lists, and you do not want the changes to affect your inline devices until you are done, be sure to disable all your inline devices in Sonar first, make the changes, then re-enable the inline device and use the Rewrite Address Lists function.

Example Address Lists

The Basics

A standard set of Address Lists that should exist in any Sonar instance that is using inline devices to control access and shaping would be as follows: A Delinquent address list, an Active address list OR an Inactive address list, and X DataService lists where each data service has it's own address list. Note that if two data services share the same upload and download speeds, they can be grouped together in the same address list.

The Delinquent list should be set so that the Account Status is "All account statuses" and the Delinquency is "Delinquent".

The Active or Inactive list should be set so that the Account Status is "Only account statuses that activate an account" or "Only account statuses that do not activate an account". If your DHCP is being assigned by Sonar, it makes sense to use an Inactive address list to drop all traffic for accounts that are not active. If your DHCP is being assigned by a DHCP server or RADIUS pool, then soft assigned into Sonar, it makes more sense to drop customer IP traffic that is not part of an Active address list.

Any DataServices address lists can be built so that Account Status is set to "All account statuses" and Delinquency is set to "all". This way if somehow a delinquent or inactive customer were to gain access they would still be rate limited. In the example screen shots, I have built an address list for the Bronze Internet, Silver Internet, and Gold Internet services. If two services share the same data rates, you can group them together in the Data Services.

Legacy Equipment, Same Service

Imagine the following scenario, you have an area of your network where new equipment allows you to offer larger packages. You are slowly retrofitting your existing network footprint, but for the time being, you have areas in your network where the new speeds are not yet possible. Rather than creating new services for the new speeds and instructing your billing staff on which services are available in which areas, a simpler approach might be to add all customers with legacy equipment into a "Legacy Equipment" account group. Now you can take the same "Gold Internet" service and apply different data rates based on the account group. In the examples below, we have created "OldGoldInternet" as an address list to be applied to any accounts that have the gold service, but are part of the "Legacy Equipment" in Account Groups. This way no matter what equipment is deployed to the account, your billing staff can just add the Gold Internet as a service to any account.

If you have a use case that you are not quite sure of the best way to build an address list for, send us a message at support@sonar.software and we can step through it together!

How did we do?

Building RADIUS Groups

Finding your OIDs

Contact